From owner-freebsd-hackers Sun Sep 8 03:11:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA00411 for hackers-outgoing; Sun, 8 Sep 1996 03:11:07 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA00330; Sun, 8 Sep 1996 03:10:58 -0700 (PDT) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id DAA00197 ; Sun, 8 Sep 1996 03:10:56 -0700 (PDT) Received: from io.org by mail.crl.com with SMTP id AA07774 (5.65c/IDA-1.5); Sun, 8 Sep 1996 01:09:33 -0700 Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by io.org (8.6.12/8.6.12) with SMTP id EAA18037; Sun, 8 Sep 1996 04:04:56 -0400 Date: Sun, 8 Sep 1996 04:04:56 -0400 (EDT) From: Brian Tao To: Chuck Robey Cc: FREEBSD-HACKERS-L , FREEBSD-SCSI-L Subject: Re: Streamlogic RAIDION drive arrays In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 7 Sep 1996, Chuck Robey wrote: > > This seems somewhat odd to me. I thought you'd expend the additional cost > of RAID where you really need reliability. True enough... I was approaching a hardware RAID solution mainly from a performance standpoint. The need for a reliable e-mail server is obvious, but people often mention how news is "expendable". I disagree with that. A news server is just like a giant database server: it needs to be fast, big, *and* reliable. I have five non-customer feeds that consistently accept 90% of the articles I send then, and another four above 50%. If I lose even half a day's batch, I'm going to hear about it. Not to mention customers who get just as upset about losing articles from their favourite groups as if it were personal e-mail. > If you lose news (assuming this doesn't happen very often) you just > reload from another server, right? Assuming that some of your upstream feeds have spooled output batches and can backfill you the missing articles. > If you lose mail, it's gone, no backup at all. I'll be doing nightly backups of the mail spool to tape in case of catastrophic failure. With a projected 20GB of mail, this is going to get rather expensive. :( I read a study in some computer journal a few months back that warned of a 2x to 5x increase in cost to make an "normal" non-redundant system into a fully-redundant, high reliability, self-monitoring and self-healing server. I can start to see why now, just in the disk subsystem alone. -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-hackers Sun Sep 8 03:11:29 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA00502 for hackers-outgoing; Sun, 8 Sep 1996 03:11:29 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA00465 for ; Sun, 8 Sep 1996 03:11:22 -0700 (PDT) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id DAA00243 for ; Sun, 8 Sep 1996 03:06:48 -0700 (PDT) Received: from parkplace.cet.co.jp by mail.crl.com with SMTP id AA15798 (5.65c/IDA-1.5 for ); Sun, 8 Sep 1996 02:51:24 -0700 Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id JAA09080; Sun, 8 Sep 1996 09:47:59 GMT Date: Sun, 8 Sep 1996 18:47:58 +0900 (JST) From: Michael Hancock To: Terry Lambert Cc: FreeBSD Hackers Subject: Re: namei performance (was Re: FreeBSD vs. Linux 96 (my impressions)) In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 8 Sep 1996, Michael Hancock wrote: > On Fri, 6 Sep 1996, Terry Lambert wrote: > > > > Surprisingly `namei' turned out to be the single biggest contributor to > > > time spent in the kernel. > [snip] > > The namei() call tends to copy the path string around, and so is a > > big offender; this is correctable with a couple of interface changes; > > the nameifree() change drops it about 10%, for instance, by moving > > the alloc/free operation to the same API level, and reducing the > > extra testing that has to go on everywhere in the error cases. > > > > Changing the path string into a pre-parsed list of path components is > > about another 6% win, and you can get another 8% by putting in the > > change to not go through with the allocation on a preexisting element. > > This complicated parsing of symbolic links, since it means you have > > to loop-unroll the mutual recusrsion (which is how symbolic links > > are currently implemented). To avoid using too much kernel stack, > > you have to reduce the stack usage to get there -- another reason > > for a pre-parsed list not allocated on the stack. > > How would it compare to a SYSV lookuppn() which works component by > component? Namei can handle components up to mount boundaries requiring > less calls. I should clarify this. Namei allows the file system dependent layer make the decision to go component by component or by components up to a mount point. nfs_lookup requires component by component, but presumably ufs_lookup can operate on chunks of the pathname up to a mount point. Example: /var/spool/news/comp/unix/bsd/freebsd/misc ^ ^ sd1 sd2 parse pathname into components foreach component (9) VOP_LOOKUP(component[i]) or while pathname not processed (3?) VOP_LOOKUP(pathname) I might be off by one, I'm not entirely clear how many times VOP_LOOKUP gets called in the cases above. Isn't the biggest problem, with the namei way of doing things, the lock put on the directory? A directory will be locked between operations, even if the caller blocks. The directory is locked even for reads which serializes access to the directory. It would be interesting to see if using multiple-reader/single writer locks would improve performance here. Regards, Mike Hancock From owner-freebsd-hackers Sun Sep 8 03:11:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA00578 for hackers-outgoing; Sun, 8 Sep 1996 03:11:41 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA00517; Sun, 8 Sep 1996 03:11:31 -0700 (PDT) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id DAA00324 ; Sun, 8 Sep 1996 03:09:41 -0700 (PDT) Received: from io.org by mail.crl.com with SMTP id AA08426 (5.65c/IDA-1.5); Sun, 8 Sep 1996 01:15:27 -0700 Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by io.org (8.6.12/8.6.12) with SMTP id EAA18738; Sun, 8 Sep 1996 04:10:51 -0400 Date: Sun, 8 Sep 1996 04:10:50 -0400 (EDT) From: Brian Tao To: "Matthew N. Dodd" Cc: FREEBSD-HACKERS-L , FREEBSD-SCSI-L Subject: Re: Streamlogic RAIDION drive arrays In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 7 Sep 1996, Matthew N. Dodd wrote: > > Check out BoxHill. They have some nifty stuff. They are a CMD > integrator. http://www.boxhill.com/ Thanks. They even have a neat little HTML-based tutorial showing how parity information works in a RAID. :) -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-hackers Sun Sep 8 03:12:32 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA00660 for hackers-outgoing; Sun, 8 Sep 1996 03:12:32 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA00649 for ; Sun, 8 Sep 1996 03:12:18 -0700 (PDT) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id DAA00219 for ; Sun, 8 Sep 1996 03:12:15 -0700 (PDT) Received: from DeepCore.dk (aalb9.pip.dknet.dk) by mail.crl.com with SMTP id AA06470 (5.65c/IDA-1.5 for ); Sun, 8 Sep 1996 00:55:23 -0700 Received: (from sos@localhost) by DeepCore.dk (8.7.5/8.7.3) id RAA12747; Sat, 7 Sep 1996 17:45:11 +0200 (MET DST) Message-Id: <199609071545.RAA12747@DeepCore.dk> Subject: Re: Support for fixed-scan monitors To: arver@sn.no, Arve.Ronning@alcatel.no Date: Sat, 7 Sep 1996 17:45:11 +0200 (MET DST) Cc: j@uriah.heep.sax.de, arver@sn.no, freebsd-hackers@FreeBSD.org In-Reply-To: <323164E0.41C67EA6@alcatel.no> from Arve Ronning at "Sep 7, 96 02:04:48 pm" From: sos@FreeBSD.org Reply-To: sos@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL15 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In reply to Arve Ronning who wrote: >=20 > The (MDA present) and (VGA present) 'probes' are simple write-something= -and- > check-if-it-can-be-read-back (like the original in scinit()). >=20 > What this is all meant to achieve is : > 1) if PREFER_MDA is *not* defined, the code is unchanged. > 2) if PREFER_MDA is defined and only MDA present, MDA is used. > 3) if PREFER_MDA is defined and both MDA and VGA present, MDA is used. > 4) if PREFER_MDA is defined and only VGA is present, VGA is used. >=20 > So, in effect PREFER_MDA does what it says : PREFER MDA over VGA, while= the > original code does PREFER VGA over MDA. Hmm I have some old patches lying around for syscons, so that it can used both a mda & a vga simultaniously if both are present, priority could easily be changed.=20 If I remember right you can set the PC to boot into whichever you want by setting the BIOS to either monochrome og vga. Syscons could then take over the device that the BIOS used as default. As I see it there is no need to muck with the bootblocks.... > Would you be interested in looking at the patches and give me your opin= ion ? > Do you think there would be any interest in including this in -current = ? (or > any other version for that matter:). Lets have a look at it, I'm mostly for the "dual video card" support, tha= n for some specific hacks to the bootblocks & drivers... I dont think we need "Yet another kernel option", we have plenty of that allready. -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D- S=F8ren Schmidt (sos@FreeBSD.org) FreeBSD Cor= e Team Even more code to hack -- will it ever end .. From owner-freebsd-hackers Sun Sep 8 03:23:38 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA01104 for hackers-outgoing; Sun, 8 Sep 1996 03:23:38 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA01086; Sun, 8 Sep 1996 03:23:35 -0700 (PDT) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id DAA00283 ; Sun, 8 Sep 1996 03:23:34 -0700 (PDT) Received: from io.org by mail.crl.com with SMTP id AA08274 (5.65c/IDA-1.5); Sun, 8 Sep 1996 01:14:04 -0700 Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by io.org (8.6.12/8.6.12) with SMTP id EAA18608; Sun, 8 Sep 1996 04:08:13 -0400 Date: Sun, 8 Sep 1996 04:08:12 -0400 (EDT) From: Brian Tao To: Joe Greco Cc: FREEBSD-HACKERS-L , FREEBSD-SCSI-L Subject: Re: Streamlogic RAIDION drive arrays In-Reply-To: <199609080523.AAA17753@brasil.moneng.mei.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 8 Sep 1996, Joe Greco wrote: > > That would be a matter of incompetence. If you are not doing real > time outbound feeds in this day and age, you do not belong playing the > news game. Unfortunately, many customer sites (heck, many ISP's) aren't run by people who are well-versed in the black art of running an efficient news server. Some have too little bandwidth during some parts of the day to keep up, while others are simply mismanaged (always running out of disk, or the server has crashed, etc.) It's not your fault in that case, but customers don't seem to care when they call you up and complain. :-/ -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-hackers Sun Sep 8 03:24:53 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA01148 for hackers-outgoing; Sun, 8 Sep 1996 03:24:53 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA01143; Sun, 8 Sep 1996 03:24:51 -0700 (PDT) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id DAA00299 ; Sun, 8 Sep 1996 03:24:51 -0700 (PDT) Received: from cheops.anu.edu.au by mail.crl.com with SMTP id AA08048 (5.65c/IDA-1.5); Sun, 8 Sep 1996 01:11:52 -0700 Message-Id: <199609080811.AA08048@mail.crl.com> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA213880044; Sun, 8 Sep 1996 18:07:24 +1000 From: Darren Reed Subject: no more mbufs! To: freebsd-bugs@freebsd.org Date: Sun, 8 Sep 1996 18:07:23 +1000 (EST) Cc: freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I just made my 2.1.5 box run out of mbufs: kernel: Out of mbuf clusters - increase maxusers! so I thought I'd let it rest and wait for things to expire... (a reboot is going to be necessary, I can see...) however, netstat -m now looks like this: 1038 mbufs in use: 1025 mbufs allocated to data 2 mbufs allocated to packet headers 3 mbufs allocated to protocol control blocks 8 mbufs allocated to socket names and addresses 1024/1024 mbuf clusters in use 2177 Kbytes allocated to network (100% in use) 0 requests for memory deined 0 requests for memory delayed 0 calls to protocol drain queues there appear to be no outstanding connections in netstat -an output. To get the machine in this state, I was using it as the source of running iptest against an UltraSparc2 (making heavy use of sending packets out via BPF). Some minutes later, "netstat -m" still reports the same. Reboot time I guess: new kernel and has been up less than half an hour. Darren From owner-freebsd-hackers Sun Sep 8 04:07:54 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA02764 for hackers-outgoing; Sun, 8 Sep 1996 04:07:54 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA02759 for ; Sun, 8 Sep 1996 04:07:53 -0700 (PDT) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id EAA00688 for ; Sun, 8 Sep 1996 04:07:51 -0700 (PDT) Message-Id: <199609081107.EAA00688@who.cdrom.com> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA251740797; Sun, 8 Sep 1996 21:06:38 +1000 From: Darren Reed Subject: namei caching. To: hackers@freebsd.org Date: Sun, 8 Sep 1996 21:06:37 +1000 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Out of curiosity, I had a look at the vfs_cache.c and saw this: * For simplicity (and economy of storage), names longer than * a maximum length of NCHNAMLEN are not cached; they occur * infrequently in any case, and are almost never of interest. there is one case where these are possibly common: AUFS does anyone use freebsd to serve mac users via AUFS, if so, what is the average file name length ? (Oh, I assume NCHNAMLEN is a name segment length - the bit between /'s) darren From owner-freebsd-hackers Sun Sep 8 06:23:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA00683 for hackers-outgoing; Sun, 8 Sep 1996 06:23:41 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA00678; Sun, 8 Sep 1996 06:23:39 -0700 (PDT) Received: from ekeberg.sn.no (ekeberg.sn.no [194.143.8.8]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id GAA01221 ; Sun, 8 Sep 1996 06:23:37 -0700 (PDT) Received: from ralingen116.telepost.no (ralingen116.telepost.no [193.212.209.95]) by ekeberg.sn.no (8.7.5/8.7.3/on4) with SMTP id ; Sun, 8 Sep 1996 15:18:04 +0200 (MET DST) X-Authentication-Warning: ekeberg.sn.no: Host ralingen116.telepost.no [193.212.209.95] didn't use HELO protocol Message-ID: <323343E2.297D@sn.no> Date: Sun, 08 Sep 1996 15:08:34 -0700 From: Arve Ronning Reply-To: arver@sn.n, Arve.Ronning@alcatel.no X-Mailer: Mozilla 2.0 (Win16; I) MIME-Version: 1.0 To: Bruce Evans CC: sos@FreeBSD.ORG, Arve.Ronning@alcatel.no, durham@w2xo.pgh.pa.us, freebsd-hackers@FreeBSD.ORG, j@uriah.heep.sax.de Subject: Re: Support for fixed-scan monitors References: <199609080131.LAA27126@godzilla.zeta.org.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bruce Evans wrote: > > >> If I remember right you can set the PC to boot into whichever you > >> want by setting the BIOS to either monochrome og vga. Syscons could > >> then take over the device that the BIOS used as default. As I see > >> it there is no need to muck with the bootblocks.... > > > >With MDA *and* VGA present...Hmm... > >Some BIOSes may be able to do that, but the ones I've tried have failed either > >by silently resetting the primary to VGA or by not initializing the MDA correctly > >on the next power-on boot (I thought my MDA monitor had departed for good, but it > > Syscons (and pcvt) should start the same device as the BIOS, anyway. Given the quirks of BIOSes, that would have to be the [CEV]GA. I don't think syscons knows which device is being used by BIOS (please correct me if I'm wrong here). I haven't checked pcvt. So, I believe this is mostly a matter of choice (and not of using what BIOS uses). > The new option(s) could reverse the default, or force MDA (fail the probe > if none), or force [CEV]GA. Then it should be possible to switch to > the other screen, or use both (syscons on one and pcvt on the other :-). > That sounds nifty :). (using syscons *and* pcvt I mean:). However, what if the screen used by BIOS is on a monitor which doesn't accept the default scan rates (my situation) ? During boot, we would not see : a) the BIOS messages b) the '>> FreeBSD....Boot:' prompt In this case, there is little we can do about a) (except perhaps hack the BIOS :(. But we *can* do something about b) by hacking the bootblocks (which is what I did:). BTW, I forgot to say (yesterday) that my patches are for *2.1.5R* ! - Arve From owner-freebsd-hackers Sun Sep 8 06:35:12 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA00999 for hackers-outgoing; Sun, 8 Sep 1996 06:35:12 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA00980; Sun, 8 Sep 1996 06:35:09 -0700 (PDT) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id GAA01258 ; Sun, 8 Sep 1996 06:35:07 -0700 (PDT) Message-Id: <199609081335.GAA01258@who.cdrom.com> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA278679625; Sun, 8 Sep 1996 23:33:45 +1000 From: Darren Reed Subject: Re: no more mbufs! To: avalon@coombs.anu.edu.au (Darren Reed) Date: Sun, 8 Sep 1996 23:33:45 +1000 (EST) Cc: freebsd-bugs@freebsd.org, freebsd-hackers@freebsd.org In-Reply-To: <199609080811.AA08048@mail.crl.com> from "Darren Reed" at Sep 8, 96 06:07:23 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Darren Reed, sie said: > > > Hi, I just made my 2.1.5 box run out of mbufs: > > kernel: Out of mbuf clusters - increase maxusers! > > so I thought I'd let it rest and wait for things to expire... > > (a reboot is going to be necessary, I can see...) > > however, netstat -m now looks like this: > 1038 mbufs in use: > 1025 mbufs allocated to data > 2 mbufs allocated to packet headers > 3 mbufs allocated to protocol control blocks > 8 mbufs allocated to socket names and addresses > 1024/1024 mbuf clusters in use > 2177 Kbytes allocated to network (100% in use) > 0 requests for memory deined > 0 requests for memory delayed > 0 calls to protocol drain queues > > there appear to be no outstanding connections in netstat -an output. > > To get the machine in this state, I was using it as the source of running > iptest against an UltraSparc2 (making heavy use of sending packets out via > BPF). > > Some minutes later, "netstat -m" still reports the same. > > Reboot time I guess: new kernel and has been up less than half an hour. Sigh, and you know what ? I've already got a patch for this amognst the IP Filter patches for ip_input.c - guess this is why I never had a problem until I put virgin 2.1.5 kernel on my box. I didn't think of this until I did up maxusers and did recreate the above situation. Maybe someone will take this and commit it sometime... discovered the bug when I crashed my SunOS4 box, and managed to crash Ultrix too. Seems like it just fucks the mbufs on FreeBSD. NetBSD fixed it when they rewrote everything to use TAILQ, dunno about BSD/OS. So IP Filter users, don't worry about the above bug report :-) Darren *** /sys/netinet/ip_input.c.orig Wed Sep 6 20:31:35 1995 --- /sys/netinet/ip_input.c Sun Apr 21 12:12:53 1996 *************** *** 507,512 **** --- 523,530 ---- * if they are completely covered, dequeue them. */ while (q != (struct ipasfrag *)fp && ip->ip_off + ip->ip_len > q->ip_off) { + struct mbuf *m0; + i = (ip->ip_off + ip->ip_len) - q->ip_off; if (i < q->ip_len) { q->ip_len -= i; *************** *** 514,522 **** m_adj(dtom(q), i); break; } q = q->ipf_next; - m_freem(dtom(q->ipf_prev)); ip_deq(q->ipf_prev); } insert: --- 532,541 ---- m_adj(dtom(q), i); break; } + m0 = dtom(q); q = q->ipf_next; ip_deq(q->ipf_prev); + m_freem(m0); } insert: From owner-freebsd-hackers Sun Sep 8 06:47:32 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA01354 for hackers-outgoing; Sun, 8 Sep 1996 06:47:32 -0700 (PDT) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA01347; Sun, 8 Sep 1996 06:47:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.5/8.6.5) with SMTP id GAA14816; Sun, 8 Sep 1996 06:48:18 -0700 (PDT) Message-Id: <199609081348.GAA14816@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Darren Reed cc: freebsd-bugs@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: no more mbufs! In-reply-to: Your message of "Sun, 08 Sep 1996 23:33:45 +1000." <199609081335.GAA01258@who.cdrom.com> From: David Greenman Reply-To: dg@root.com Date: Sun, 08 Sep 1996 06:48:18 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Sigh, and you know what ? I've already got a patch for this amognst the >IP Filter patches for ip_input.c - guess this is why I never had a problem >until I put virgin 2.1.5 kernel on my box. I didn't think of this until I >did up maxusers and did recreate the above situation. > >Maybe someone will take this and commit it sometime... discovered the bug >when I crashed my SunOS4 box, and managed to crash Ultrix too. Seems like >it just fucks the mbufs on FreeBSD. NetBSD fixed it when they rewrote >everything to use TAILQ, dunno about BSD/OS. Committed. Thanks! -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Sun Sep 8 10:46:26 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA12099 for hackers-outgoing; Sun, 8 Sep 1996 10:46:26 -0700 (PDT) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA12089 for ; Sun, 8 Sep 1996 10:46:20 -0700 (PDT) Received: from ns2.harborcom.net by mail.crl.com with SMTP id AA28940 (5.65c/IDA-1.5 for ); Sun, 8 Sep 1996 10:47:06 -0700 Received: from beavis.harborcom.net (pve-pm2-45.harborcom.net [206.158.5.45]) by ns2.harborcom.net (8.7.4/8.6.12) with ESMTP id NAA27793 for ; Sun, 8 Sep 1996 13:45:45 -0400 (EDT) Message-Id: <199609081745.NAA27793@ns2.harborcom.net> From: "Vince Doss" To: Subject: hardware recognition Date: Sun, 8 Sep 1996 13:45:25 -0400 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk During free bsd 2.1.5 install from cd-rom I had to load from dos but it found my cd drive ( NEC ) but then said "unknown phase" I cant load from cd because of this am not sure what is meant by "phase" From owner-freebsd-hackers Sun Sep 8 12:19:41 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA17605 for hackers-outgoing; Sun, 8 Sep 1996 12:19:41 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA17600; Sun, 8 Sep 1996 12:19:38 -0700 (PDT) Received: from dan.emsphone.com (-@dan.emsphone.com [199.67.51.101]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id MAA02333 ; Sun, 8 Sep 1996 12:19:37 -0700 (PDT) Received: (from dan@localhost) by dan.emsphone.com (8.7.5/8.7.3) id OAA07807; Sun, 8 Sep 1996 14:18:11 -0500 (CDT) Message-Id: <199609081918.OAA07807@dan.emsphone.com> Subject: Re: Streamlogic RAIDION drive arrays To: winter@jurai.net (Matthew N. Dodd) Date: Sun, 8 Sep 1996 14:18:10 -0500 (CDT) Cc: taob@io.org, freebsd-hackers@FreeBSD.org, freebsd-scsi@FreeBSD.org In-Reply-To: from "Matthew N. Dodd" at Sep 7, 96 10:16:56 pm From: dnelson@emsphone.com (Dan Nelson) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk in the last episode, Matthew N. Dodd said: > > On Sat, 7 Sep 1996, Brian Tao wrote: > > I'm looking at Raidion, CMD, Mylex and a local Toronto integrator > > called Dataplex. One thing in common is the impressive cost. ;-) A > > Check out BoxHill. They have some nifty stuff. They are a CMD > integrator. http://www.boxhill.com/ If we're all plugging our favorite RAID companies :), we have two Storage Computer boxes (50 & 90 gig) and are happy with them. Just last week, one box took a drive offline, reformatted it, and put back online as a spare, without us even noticing :). http://www.storage.com/ . -Dan Nelson dnelson@emsphone.com From owner-freebsd-hackers Sun Sep 8 14:46:50 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA27021 for hackers-outgoing; Sun, 8 Sep 1996 14:46:50 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA27014 for ; Sun, 8 Sep 1996 14:46:46 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA03696; Sun, 8 Sep 1996 14:37:53 -0700 From: Terry Lambert Message-Id: <199609082137.OAA03696@phaeton.artisoft.com> Subject: Re: namei performance (was Re: FreeBSD vs. Linux 96 (my impressions)) To: michaelh@cet.co.jp (Michael Hancock) Date: Sun, 8 Sep 1996 14:37:53 -0700 (MST) Cc: terry@lambert.org, koshy@india.hp.com, jkh@time.cdrom.com, jehamby@lightside.com, imp@village.org, lada@ws2301.gud.siemens.co.at, dennis@etinc.com, hackers@FreeBSD.org In-Reply-To: from "Michael Hancock" at Sep 8, 96 10:55:41 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > Surprisingly `namei' turned out to be the single biggest contributor to > > > time spent in the kernel. > [snip] > > The namei() call tends to copy the path string around, and so is a > > big offender; this is correctable with a couple of interface changes; > > the nameifree() change drops it about 10%, for instance, by moving > > the alloc/free operation to the same API level, and reducing the > > extra testing that has to go on everywhere in the error cases. > > > > Changing the path string into a pre-parsed list of path components is > > about another 6% win, and you can get another 8% by putting in the > > change to not go through with the allocation on a preexisting element. > > This complicated parsing of symbolic links, since it means you have > > to loop-unroll the mutual recusrsion (which is how symbolic links > > are currently implemented). To avoid using too much kernel stack, > > you have to reduce the stack usage to get there -- another reason > > for a pre-parsed list not allocated on the stack. > > How would it compare to a SYSV lookuppn() which works component by > component? Namei can handle components up to mount boundaries requiring > less calls. The minus in the SVR4 approach is mostly a result of the way symlinks are handled, IMO. The non-iteration fix for the BSD namei() is possible, but you rarely ever see a case in practice where it eats intervening path components; in fact, given the way mount pount traversal is handled, it would take a lot of work to make this go and still handle the covered vnode case. Also in practice, I believe cache locality for path components prior to the terminal component is very high. This means thast a per component lookup can be a *very* big win after the first lookup primes the name cache... probably a bigger win than the penalty. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Sep 8 15:07:36 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA28220 for hackers-outgoing; Sun, 8 Sep 1996 15:07:36 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA28212 for ; Sun, 8 Sep 1996 15:07:27 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA03751; Sun, 8 Sep 1996 15:05:30 -0700 From: Terry Lambert Message-Id: <199609082205.PAA03751@phaeton.artisoft.com> Subject: Re: namei performance (was Re: FreeBSD vs. Linux 96 (my impressions)) To: michaelh@cet.co.jp (Michael Hancock) Date: Sun, 8 Sep 1996 15:05:30 -0700 (MST) Cc: terry@lambert.org, hackers@FreeBSD.ORG In-Reply-To: from "Michael Hancock" at Sep 8, 96 06:47:58 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > How would it compare to a SYSV lookuppn() which works component by > > component? Namei can handle components up to mount boundaries requiring > > less calls. > > I should clarify this. Namei allows the file system dependent layer make > the decision to go component by component or by components up to a mount > point. nfs_lookup requires component by component, but presumably > ufs_lookup can operate on chunks of the pathname up to a mount point. I understood the reference; I've been into UNIX FS code for about 5 years now. 8-). Like I said in my previous posting, I think that cache locality in the component name cache would more than make up for this. There is also the issue of multibyte support at the FS level, if you want to get technical about it. If the path seperator is literal, then each FS which wants to eat components will have to have an understanding of seperator processing, etc. This has the unfortunate side effect of locking you into a single path representation geometry. This fails for VFAT/VFAT32/HPFS/NTFS, all of which have "long names" and 8.3 names for each file. For the Mac FS, it fails because of the 32 character "short" Mac file name and the ProDOS name on each file, and for the fact that the seperator character in the file name and out is a null, not a '/' (you can hide this difference by translating between '/' and ':' in the UNIX stored name for Mac clients of the FS). > Isn't the biggest problem, with the namei way of doing things, the lock > put on the directory? A directory will be locked between operations, even > if the caller blocks. The directory is locked even for reads which > serializes access to the directory. Actually, it's possible to only write-lock the directory block for the next traversal while you block the process. This requires a sliding block window of two blocks. As long as you guarantee that the block itself will be internally consistent when you block, this will not prevent reader traversal. The only real reason for imposing locks at this point is to enable kernel reentrancy, probably by another processor in the SMP case, but maybe also for kernel preemptability for kernel multithreading and/or RT scheduling support. > It would be interesting to see if using multiple-reader/single writer > locks would improve performance here. Actually, it probably would not. Multiple-reader/single-writer locks would block reading while a write was in progress. Since a read of a directory block is a snapshot of a directory block in a consistent state copied to user space, then there is no reason to block the reader, since the readers will always get a copy of a consistent state for the block. This type of locking is generally more useful where the operations on the state do not idempotently move from one consistent state to another; for instance, in an update of two or more files in a source tree. The actual locking methodology that probaly wants to be used is seven state: no lock, R (read), W (write), X (exclusive), IR (intention read), IW, and IX. Use of intention modes means that it is posible to avoid collisions -- it is much better to use collision avoidance rather than collision detection, since it means you don't need to use exception code to support the unwinding of complex state in case of a collision. The state unwinding issues are also the rationale behind moving to single entry/single exit, and dividing the kernel functions into the categories: o Expects no lock to be held o Expects one or more locks to be held o Asserts lock (expects lock is not held) o Deasserts lock (expects lock is held) The issues of kernel preemption for RT scheduling, kernel preemption for kernel multithreading, and kernel reentrancy on a state context for SMP support, are all topologically identical problems. The only difference is that the SMP case must be able to synchronize state between processors. This means the SMP case is the limiting case, and pursuit of it will buy you all your other cases (they are subsets of the SMP problem). So the current SMP approach is probably the best approach for getting maximum functionality without needing a redesign for each integration. In any case, seperating stack state and global state in the lookup and similar places in the FS is a necessary step in increasing concurrency. The stack state must be seperated because it includes processor locality, and prevents use of superscalar systems (there is at least one German company talking about 1024 processor PPC systems). It even has a noticible effect at the Intel processor level; the current practical limits of 4 Intel processors are because of most operating systems synchronizing access to the system bus, and in particular, memory. The sole exception is Sequent's OS, and they haven't dealt with the FS issues (this is easy to prove using two shells and two find commands). Even then, there is an inherent APIC address limit of 5 bits -- 32 processors -- for Intel systems. Hopefully we can learn from other peoples successes as well as their failures. A good idea is good or bad independent of its originator. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sun Sep 8 16:11:43 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA01916 for hackers-outgoing; Sun, 8 Sep 1996 16:11:43 -0700 (PDT) Received: from augur.opr.com ([206.158.128.143]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA01911 for ; Sun, 8 Sep 1996 16:11:41 -0700 (PDT) Received: (from ivan@localhost) by augur.opr.com (8.6.12/8.6.12) id SAA01498 for hackers@FreeBSD.org; Sun, 8 Sep 1996 18:08:53 -0400 From: Ivan Pulleyn Message-Id: <199609082208.SAA01498@augur.opr.com> Subject: atapi.c To: hackers@FreeBSD.org Date: Sun, 8 Sep 1996 18:08:53 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi, While attempting to make my el-cheapo ide cdrom work with FreeBSD, I noticed the following problem with atapi.c. During atapi_probe(), an atapi_wait() is called before sending an identify request to the device. This causes a busy timeout if the cdrom is the only device on the controller. Removing the following lines seemed to fix it for me ( using 2.1.5-RELEASE sources ). If other people are having problems with ATAPI cdroms, I suggest trying this out. Ivan... /usr/src/sys/i386/isa/atapi.c 321,327d320 < /* Wait for controller not busy. */ < if (atapi_wait (port, 0) < 0) { < print (("atapiX.%d at 0x%x: controller busy, status=%b\n", < unit, port, inb (port + AR_STATUS), ARS_BITS)); < return (0); < } < -- Ivan Pulleyn work: Millennium Computer home: 44 Anthony Street ivan@torpid.com 2851 Clover Street Rochester, NY 14619 http://www.torpid.com/ Pittsford, NY 14534 716 235-1206 sleep- 716 248-0510 x 234 From owner-freebsd-hackers Sun Sep 8 16:42:28 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA03582 for hackers-outgoing; Sun, 8 Sep 1996 16:42:28 -0700 (PDT) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA03570 for ; Sun, 8 Sep 1996 16:42:09 -0700 (PDT) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id TAA02851 for hackers@freebsd.org; Sun, 8 Sep 1996 19:42:01 -0400 From: Bill Paul Message-Id: <199609082342.TAA02851@skynet.ctr.columbia.edu> Subject: First cut of libnisdb available To: hackers@freebsd.org Date: Sun, 8 Sep 1996 19:42:00 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Well, after a couple weeks of sleepless nights, I think I've got it. I've uploaded copies of nisdb.tar.gz to ftp.ctr.columbia.edu:/pub/misc/freebsd and skynet.ctr.columbia.edu:/pub/freebsd/nis I'm also going to put a copy in ~wpaul on freefall. This distribution includes the code for libnisdb, a man page, and library binaries for FreeBSD (static, shared, profiled and pic archive). Following is a description of how the library evolved to this point, how it works and roughly how it compares to the Solaris implementation. I expect to start work on bootstrapping rpc.nisd and the client-side library. Whee. When last we left our hero... ----------------------------- Last time I said that I had a working prototype libnisdb library that was based on Berkeley DB. Well, a couple of things have lead me to abandon the use of Berkeley DB as a back end, not the least of which was speed (and lack thereof). Once I had the library completed, I started running tests with the same ridiculously large sample passwd database that I normally use with ypserv. (This is a snapshot of the Columbia CUNIX cluster's /etc/passwd file containing over 30,000 entries.) I found that stuffing the entire file into a single table with two searchable columns (name and uid) took well over seven minutes. (This is on my home machine, a 486DX2/66 with 20MB of RAM and FreeBSD 2.1.0.) This was quite a bit slower than I expected. Furthermore, the resulting table file was over 11MB in size (the original flat ASCII file was a bit over 2MB). By contrast, the same table created with the Sun library was only 9MB. When I attempted to run a head to head test on the Solaris machine, I discovered another disadvantage to using Berkeley DB: test programs that worked perfectly well on my home system would die mysteriously with SIGBUSes on the SPARC, due to what turned out to be memory alignment problems. Berkeley DB does not guarantee that the data it returns will be aligned in any particular way, however my scheme assumed otherwise. This just happened to work on my home system due to the behavior of FreeBSD's malloc(3). On Solaris/SPARC, if you need to guarantee alignment, you must use memalign(). The Solaris port of Berkeley DB doesn't do this, so hijinks ensued. Ultimately I was able to work around this by copying critical data into aligned buffers. This allowed my test programs to work, but the results only showed what I expected: the Sun library was considerably faster than mine. (I also discovered that the SPARC 10 was considerably faster than my 486, but that's another matter. :) Retrievals tended to take longer, and the 'create a ridiculously large table in one shot' test took nearly twice as long. The Sun library was able to create the table in about 50 seconds, whereas mine took almost 2 minutes. (This may not seem like a tremendous difference, but it was more than enough to make me cringe.) "My lord, I have a cunning plan!" --------------------------------- This led me to rethink my scheme a little. It seemed as though I was doing more I/O than the Sun library, and this was what was slowing me down. My original idea was this: An NIS+ entry is specified as a structure containing a 'type' field and a series of 'column' structures. For a passwd type table, there would be seven columns, the first being the username, the second being the password, the third the UID, and so on. For a passwd table, only the name and uid columns would be marked as searchable, so when a query is made, it can only bein terms of these two columns. (I can ask for all users where name=wpaul or uid=1234, but not where gid=3 or shell=/bin/false, since I never told the database I wanted to search by these columns.) When an entry is added, we do the following things: - The entry itself is assigned a 32-bit 'tag,' which is basically just a shorthand way of referencing it. Each entry has a unique tag, which is generated by passing the entry through a hash function. (The main reason for using tags is to make comparing entries and making lists of entries easier: it is much simpler to compare two 32-bit quantities than it is to do string compares on all the various parts of an entry.) - The entry is stored in a Berkeley DB database using the 32-bit 'tag' as a key. If we know the for a given entry, we can then read it back from the database. - We construct 'relations' from the searchable columns and assign the entry's tag to them. For example, if the entry has name=wpaul and uid=1063, then we would store two additional records in the DB database: one with a key of 'name=wpaul' (literally, like that) and another with a key of 'uid=1063'. The data for both these records would be the tag for this entry. To see how this works, imagine that we do a query where we say: find me all entries where 'uid=1063' (which would be equivalent to a getpwuid(1063)). The library would attempt to do a db->get for a record with a key of 'uid=1063'. Assuming it finds a matching record, it then sees that the data contains a single 32-bit tag. It then checks for a record with a key matching this tag, and reads it back. If we were to add a second entry where 'name=foo' and 'uid=1063,' the library then has a little extra work to do: there already exists a record with a key of 'uid=1063,' so it needs to update it to include the tag for the new entry. Now there are three 'relation' records: 'name=wpaul,' 'name=foo' and 'uid=1063.' The 'name=wpaul' and 'name=foo' records only contain one tag each (for their respective entries), but 'uid=1063' now contains two. This means that if we repeat the query we did above, we would now get back two entries from the database. Queries can become a little more complicated if you specify two attributes and both yield multiple 'tags'. For example, let's say that the 'shell' column is also searchable, and we do a query that says: find me all entries where 'uid=0' and 'shell=/bin/csh'. The library would then check the database for records with keys of 'uid=0' and 'shell=/bin/csh'. Let's say that the 'uid=0' record has 10 tags and the 'shell=/bin/csh' has 100 tags. This means there are 10 users with 'uid=0' and 100 with 'shell=/bin/csh'. Clearly, not all of the users that have /bin/csh as their shell also have a UID of 0. So what we have to do is find all the tags that appear in both the 'uid=0' list and the 'shell=/bin/csh' list. Again, this is where the tags come in handy: you can just do simple comparisons of 32-bit values rather than a mess of string compares. On problem is finding a fast way to do the search: right now I'm using a 'brute force' algorithm that just selects the smallest tag list and does a search through all the larger lists using the smallest list as a base. If a tag from the smaller list does not appear in all of the larger lists, it is thrown out. (After explaining this to a friend of mine, he said to me: "Bill, I think what you've created here is just a really efficient bubble sort." I think he may be right, unfortunately he wasn't able to provide me with a more effective alternative. Before you jump forward with what you think is a clever solution, remember the NIS+ protocol definition allows for tables with up to 64 searchable columns, which means you can end up having to take an intersection of a large number of tag lists.) Anyway, the problem with this approach is that it requires writing at least three DB records for every addition: one to add the actual entry and one each for every 'relation.' And if there are already matching relations in the table, we have to do extra work to read them back, update them with the tag for the new entry, and then save them back again. This results in a fair amount of I/O and syscall overhead, which slows things down to a crawl. If you hash it, they will come. ------------------------------- I decided to try fixing this by deferring the I/O until the last minute. One of the reasons I wanted to use Berkeley DB for this was so that I could (ab)use its internal handling of hash tables (or B-trees, if using the btree method). Using Berkeley DB meant that it would do all the dirty work of arranging the relation entries in an efficient way so that I wouldn't have to. But Berkeley DB wasn't behaving quite the way I wanted, so I took matters into my own hands: instead of storing the 'relation' records as individual Berkeley DB records, I stored them in memory as part of a hash table. In fact, there's really a hash table for each searchable column. To store a relation, we take the data in an entry column and hash it to a 32-bit value. This is then used as the index to the table. At the corresponding index location, we attach the list of tags. So for 'name=wpaul,' we hash 'wpaul' and use the resulting value as an index into the 'name=' table, and store the entry tag there. Then we hash '1063' and use that as an index into the 'uid=' table and store the same entry tag there. If we have another entry where 'uid=1063,' we will hash to the same location, find that there's already a list there and add the new tag to the list. Note that while hash values are 32 bits in size, I'm not allocating an array with ULONG_MAX indexes. What I actually do is allocate four buckets (I call them pages) each with 256 slots. I them mask off all but the lower 8 bits of the hash value so that it will map to one of the slots on the first page. If the corresponding slot is empty, a new list is created there. If it's occupied, I shift the hash value by 8 bits and mask again, then use that value as an index into the next page. If the slot on that page is occupied, I shift again, and so on, until I run out of pages. If I run out of pages, then I resort to chaining: the new list is linked to an existing list on the page with the slot that has the smallest chain count. (I try to keep the chain counts of each slot the same to even out the distribution.) What happens now is that when a new entry is added, it is written to the DB database, but the 'relation' information is kept in memory. When the database is checkpointed, the relation hash structures are dumped to the database in one swell foop. When the database is re-opened, the hash structures are read back into memory again. Once I had this new scheme working, I ran more tests. There was some improvement: on my home machine, the 'create a whopping great table all in one shot' test completed in about 4 minutes as opposed to the 7 minutes it needed before. On the Solaris machine, the time dropped from 1:50 to 1:15. "You want how much disk space?!" -------------------------------- As luck would have it, more complications arose. While Berkeley DB can handle very large key and data items, it tends to waste disk space under some conditions. To save the relation data, I was basically converting the entire structure into an opaque form using the XDR library and saving it as one huge data item (with an ASCII key called 'relation_array'). For the 30,000 entry passwd table, the total size of all the relation data, once XDR'ed, was on the order of 2MB. This meant that 2MB of the total table file was occupied by a single key/data pair. Now let's say I re-open the database and add one more entry. The relation data grows ever so slightly so that it now just over 2MB in size. Berkeley DB, rather than re-using the old 2MB chunk of space and expanding it a little, allocates a whole new chunk of space that is 2MB + and adds that on top of the old 2MB chunk, which is now just sitting there taking up room. The strategy, I think, is that the old 2MB chunk, which is now too small to hold the new relation data 'glob' will be placed on the 'free list' and partitioned up to hold smaller data items that come along. This means that as new entries are stored, they may fill in the vacated space, but each time the relation data is expanded, it will allocate a whole new 2MB+ chunk of space to hold it. The result was a tremendous jump if file size every time I added a new entry to the huge table: the first entry added 2MB to the file size, the next entry another 2MB, and so on. This was the last straw. I tried using both the hash and btree methods and tweaked the various correspinding 'openinfo' parameters until I was blue in the face: nothing helped. One potential solution that occured to me was to write my own file compaction routines, but this would involve first learning how to grok Berkeley DB files, which I didn't really want to do. What I needed to do was create my own file storage system that would allow the same kind of quick access to arbitrary records afforded by Berkeley DB but that would not waste space, or which would allow me to reclaim space without going insane. When the going gets weird, the weird turn pro. ---------------------------------------------- The answer to this problem came to me when I remembered something about the Sun libnisdb library that I'd noticed while I was doing my original tests. When I went to compile my first test program using the Solaris library, the linker complained that it could not resolve the symbol '_db_free_result'. All the other nis_db functions resolved just fine, but not this one. This confused me a bit since db_free_result() was clearly documented to exist in both the nis_db(3n) man page and the header file. To figure out what was happening, I ran nm(1) on the Sun /usr/lib/libnisdb.a, and sure enough, I saw the problem: db_free_result() was there, but as a mangled C++ name. I was compiling my program with gcc. Not knowing much about C++, I took the quick way out by adding a #define to the test program that mapped the unmangled name to the mangled one, just to make the linker happy so I could get on with my life. Anyway, one of the things I saw in the output from nm(1) was a reference to xdrstdio_create(). I couldn't figure out why they would need to use this function, particularly since libnisdb doesn't do an RPCs itself. Then it hit me: you can use the XDR library to encode or decode data to or from any kind of stream, be it a socket, a pipe, a tty, or even a _file_. (For an example of how to do this with an AF_UNIX socket, see the rpc.yppasswdd(8) source code.) The XDR File Format (XFF) ------------------------- >From this bit of information, I created the XDR File Format (XFF). There can be XFF files and XFF log files. A regular XFF file contains three things: - An XDR-encoded XFF header containing the library version, the file type, and offsets to a few other key locations within the file. - A series of XDR-encoded entries, stored back to back. Since the NIS+ protocol definition already describes an entry_obj structure for holding entries, we use the entry_obj structure and associated XDR filter for storing entries in XFF file. - An XDR-encoded copy of the relation info for the table. This is dumped as one big glob after the last entry in the file. An XFF log file contains two things: - An XFF header, just like the XFF header for a standard file. - A series of XDR-encoded log entries. A log entry is stored as a log_entry structure and contains an entry_obj structure inside it along with an action flag, a status flag, and a set of attributes, if needed (to delete an entry, we specify the attributes of the entry we want to delete rather than supplying a copy of the entry itself). An XFF log file doesn't have any relation info in it: instead, the log entries are used to update the relation data in memory. With this new scheme, we have to change the nature of the 'tags' used to identify entries. They're still unsigned 32-bit values, but now they are computed differently and have special meaning. Each tag is now not only a unique identifier, it's also a seek pointer into the XFF file. To illustrate this, let's say we do a query: find all users where 'uid=0'. Let's also say this yields a list of three tags. This means we have three entries that satisfy the query. To read back, for example, the entry associated with tag1, we do this: - Use fseek() to move the file pointer 'tag1' bytes into the file. - Use xdrstdio_create() to create an XDR stream from the file stream. - Read back the entry into an entry_obj structure using the xdr_entry_obj() filter. - Use xdr_destroy() to destroy the XDR stream. Presto. We don't need to write any file format to structure conversion routines since rpcgen and the XDR library take care of all that for us. Initially however, we don't create an XFF file: we create a log. When we do an entry, we write a log entry to the log file (also using the XDR library) that says: 'an add operation was performed, and this is the entry that was added.' Deletions are logged in the same way. (Note that an update or replace is treaded as an add/delete pair.) All we have is a log file until the user calls db_checkpoint(). At that point, all the log entries are played back and used to update the real XFF table file. Once all the log entries are committed, the log is removed. If new changes are made, the library will create a new log file and start the process over again. But wait, there's more ---------------------- This leads to a couple of complications: we may, at a particular time, have both a committed XFF table file and a log. As far as the user is concerned, these must both appear as a single cohesive NIS+ table. The user should not know that the data is split among two files. This requires a bit of behind the scenes sleight of hand, but is is not that hard to achieve. The relation tables have to contain tags relating to both the real file and the log file if we want lookups to work right. The question is: how can we tell when a tag refers to an offset in the real file, and how can we tell when it refers to an offset in the log file. The answer is that when we store a tag relating to the log file, we bias it by adding to it the total size of the real file. If we then do a lookup and realize that the tag value is too large to possibly an offset into the real XFF file, we use it as an offset into the XFF log file instead. (If that doesn't work, we signal an error.) We have to do similar magic when handling db_first_entry()/db_next_entry() enumerations-type queries. When db_next_entry() reaches the end of of the real file, it has to check to see if a log file exists and make proper use of it if it does. Both these cases are handled internaly by the xff_get_entry(), xff_first_entry() and xff_next_entry() functions. This avoids complicating the top level library functions. The last complication has to do with deletions. If a user deletes an entry in an already committed XFF file, we have to do two things: - Log the deletion action. - Update the relation tables. - Mark the entry in the original table as deleted. This requires us to touch the original table before the log is committed, but this is unavoidable: if we didn't do this, db_first_entry() and db_next_entry() would not know to skip the entry during an enumeration query. One possible alternative would be to keep a list of 'losing' tags and have xff_first_entry()/xff_next_entry() check their current file positions against the list, but this would require extra processing at each instance of xff_next_entry() and would require extra memory. Regardless, deletions offer one last problem, which is that we need to go through some complex gymnastics to reclaim space that is left in committed table files as the result of a deletion. We can't overwrite the deleted entry with another entry since entries are not of fixed size (which means we may clobber the entry following the deleted one). And we can't just shift all the subsequent entries up a slot since that would throw them out of sync with their tags in the relation tables. Unfortunately, there is no simple way around this: if an entry is deleted in the original file, we just have to compact it. If, after we commit the XFF log, we notice that there were deletions, we compact the file to reclaim space. This involves creating a new file containing all of the still valid entries from the old file: entries marked as deleted are skipped (but we make note of their offsets). Once the new file is created, we run a special fixup routine on the relation tables which basically visits all of the tags in the tables and, if needed, fixes them up so that they stay in sync with the actual entries in the file. And the survey says... ---------------------- Initial tests of the first version of XFF -- which did not include logging -- were very encouraging. The 'create a big fat table in one shot' test would now run to completion on my home machine in about 1 minute, 30 seconds. On the SPARC, it took about 46 seconds, which was four seconds faster than the Sun library. But then I started to think more about what I was doing and I realized that I this was reeally just a temporary situation. Without logging, my library could easily fall apart. Supposing that I get halfway through the test and then crash. I will have saved 15,000 entries to to the XFF file, which is good. But I don't save the relation tables until a checkpoint, and since I crashed before I could do the checkpoint, the relation data would not be saved, which is bad. With the log, I can just replay all the log entries at startup and rebuild the relation tables in memory. But this raised a few questions since I noticed that the Sun library and my library didn't always behave the same way. These questions are not easy to answer until you understand how the Sun library works. Things you were never meant to know ----------------------------------- I will now totally dispell the mystery surrounding the implementation of the Sun libnisdb library and tell you how it works. I'm sure Sun would rather I didn't do this, but I don't care. I don't like the way Sun's library works, and I want people to understand why. The nis_db(3n) man page says that the Sun database implementation is 'memory based.' This is an understatement of epic proportions. The Sun library maintains a structure or set of structures describing the relations between entries, just as my library does. It also keeps this structure or set of structures in memory in order to speed up queries, just as my library does. What it also does, which my library doesn't do, is maintain the _entire_ contents of a table in memory along with the relation data. This means that if you have an NIS+ table with 10,000 entries, the library will keep all 10,000 entries in memory. When you add an entry, the Sun library does two things: it writes the addition to a log, and it adds the entry to its in-core image of the table. If you do a deletion, it writes the deletion to the log and removes the entry from its in-core image of the table. If you crash prior to doing a checkpoint, the in-core table is lost, but it is reconstructed at restart using the log. When you checkpoint, the Sun library essentially dumps both its in-core relation data and all of the entries into a single file. This is where it uses the XDR library: it can dump its data structures straight to disk using its own XDR filters. Once the new file has been successfuly written, the log is removed. By keeping the table entirely in-core, the Sun library avoids a few of the issues that I had to contend with: - You don't have to do any I/O to do a lookup: everything is in memory, so you just crunch a few numbers an out pops a pointer to the desired entry. - Reclaiming space freed by deletions is easy: you just free() the memory occupied by the deleted entry and expunge its relation data from the tables. - To 'commit' changes in the log, you just dump your in-core table image to disk. When the Sun library starts up, it reads the existing checkpointed table image from disk (if it exists) and then replays the log, thereby modifying its in-core image of the table to reflect the changes in the log. The image on disk remains unchanged. This reduces the checkpoint operation to one big save operation where the in-core image of the table is written out and ultimately replaces the old one. - You don't have any file descriptors to juggle unless there's a log present. In my library, I go through a fair amount of trouble to manage file descriptors (actually FILE * pointers): you need one for each open table file, one for each open log file, and one more for each db_first_entry()/db_next_entry() enumeration query that's currently in progress. But, as with most things, there's a tradeoff: in exchange for all these simplifications, the Sun library uses a hell of a lot more memory than mine. When running tests on the SPARC 10, my library, with the 30,000 entry table open, would consume about 1260 pages of virtual memory (according to ps -elf). By contrast, the Sun library, with the same table, consumed over 4400 pages. At 4K per page, that's about 5MB for my library versus 18MB for the Sun library. Some may view Sun's approach as reasonable since the VM system will probably page out a lot of the extra pages anyway, thereby (ab)using the VM system as part of the database. I don't think relying on the VM system is such a good idea: what happens if you port the code to another platform where the VM system behaves differently? I'm sure Sun likes the implementation just fine: even with lots of paging space, there's no arguing that the performance of the library will improve if you throw more RAM at it, particularly with large tables. This means that if you're looking to buy machines to use as NIS+ servers in an environment with many thousands of users, you'll have to buy lots of RAM, and Sun will be only too happy to sell it to you. There's one other difference between Sun's library and mine that I can't quite explain: on the SPARC, a fully populated NIS+ table file containing 30,000+ entries takes up about 9.6MB of disk space when constructed with the Sun libnisdb. With my libnisdb, the exact same table consumes only 7.5MB. I suspect this is because Sun's in-core table image has the entry_obj structure for each entry encapsulated in some larger structure (possibly with forward/backward pointers to link them together), and all these larger 'encapsulation' structures are also being dumped to disk when the table is checkpointed. And so, in closing... --------------------- The final version of my libnisdb is still not quite as fast as I would like it to be, mainly because of the less memory-intensive approach I used. For me, a checkpoint is largely a copy operation whereas with Sun's library, it's just a store. At the moment, creating a 30,000 entry table on my home machine takes about 2:45 (as opposed to the 7+ minutes it took with the prototype), and about 1:12 on the SPARC. If I were to use the same memory-based approach as Sun, this time would be reduced by about a third, which would bring me right in line with Sun's times (maybe a little faster since I didn't use C++ :). Also, a single lookup takes a little longer for my library since I need to do I/O to read entries from disk. However, overall startup time for my library is shorter because I don't have to load the entire table into memory: instead, I load only the relation table. And my table files are smaller no matter what. On the whole, I'd rather be in Philadelphia. So what do you think, sirs? -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "If you're ever in trouble, go to the CTR. Ask for Bill. He will help you." ============================================================================= From owner-freebsd-hackers Sun Sep 8 17:17:48 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA05828 for hackers-outgoing; Sun, 8 Sep 1996 17:17:48 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA05823; Sun, 8 Sep 1996 17:17:47 -0700 (PDT) Received: from io.org (io.org [198.133.36.1]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id RAA03086 ; Sun, 8 Sep 1996 17:17:45 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by io.org (8.6.12/8.6.12) with SMTP id UAA12408; Sun, 8 Sep 1996 20:16:25 -0400 Date: Sun, 8 Sep 1996 20:16:24 -0400 (EDT) From: Brian Tao To: Dan Nelson cc: "Matthew N. Dodd" , freebsd-hackers@FreeBSD.org, freebsd-scsi@FreeBSD.org Subject: Re: Streamlogic RAIDION drive arrays In-Reply-To: <199609081918.OAA07807@dan.emsphone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 8 Sep 1996, Dan Nelson wrote: > > If we're all plugging our favorite RAID companies :), we have two > Storage Computer boxes (50 & 90 gig) and are happy with them. Are they on FreeBSD boxes? :) -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-hackers Sun Sep 8 18:12:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA10864 for hackers-outgoing; Sun, 8 Sep 1996 18:12:10 -0700 (PDT) Received: from scruz.net (nic.scruz.net [165.227.1.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA10855 for ; Sun, 8 Sep 1996 18:12:07 -0700 (PDT) Received: from osprey.grizzly.com by scruz.net (8.7.3/1.34) id SAA08604; Sun, 8 Sep 1996 18:12:01 -0700 (PDT) Received: (from markd@localhost) by osprey.grizzly.com (8.7.5/8.7.3) id RAA00220; Sun, 8 Sep 1996 17:56:40 -0700 (PDT) Date: Sun, 8 Sep 1996 17:56:40 -0700 (PDT) Message-Id: <199609090056.RAA00220@osprey.grizzly.com> From: Mark Diekhans To: freebsd-hackers@freebsd.org Subject: First pass at XPG/3 style positional arguments for *printf functions Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Enclosed is a patch to 2.2-960801-SNAP lib/libc/stdio/vfprintf.c and lib/libc/stdio/printf.3 to implement the XPG/3 style positional arguments (e.g. %2$s) to the *printf family of functions. Its been tested against a program derived from the Tcl tests, so I believe its fairly solid. This functionality is essential for building localized software. It is part most current libc implementations (including GNU). Comments welcome and if any one wants to work with me on getting this into current, that would be great. Mark *** printf.3.ORG Sun Sep 8 13:56:14 1996 --- printf.3 Sun Sep 8 15:15:18 1996 *************** *** 176,181 **** --- 176,191 ---- the following appear in sequence: .Bl -bullet .It + An optional field, consisting of a decimal digit string followed by a + .Cm $ , + specifying the next argument to access . + If this field is not provided, the argument following the last + argument accessed will be used. + Arguments are numbered starting at + .Cm 1 . + If unaccessed arguments in the format string are interspersed with ones that + are accessed the results will be indeterminate. + .It Zero or more of the following flags: .Bl -hyphen .It *************** *** 394,399 **** --- 404,411 ---- A field width or precision, or both, may be indicated by an asterisk .Ql * + or an asterisk followed by one or more decimal digits and a + .Ql $ instead of a digit string. In this case, an *************** *** 402,407 **** --- 414,421 ---- A negative field width is treated as a left adjustment flag followed by a positive field width; a negative precision is treated as though it were missing. + If a single format directive mixes positional (nn$) + and non-positional arguments, the results are undefined. .Pp The conversion specifiers and their meanings are: .Bl -tag -width "diouxX" *** vfprintf.c.ORG Sat Sep 7 19:47:59 1996 --- vfprintf.c Sun Sep 8 16:16:35 1996 *************** *** 75,80 **** --- 75,82 ---- static int __sbprintf __P((FILE *, const char *, va_list)); static char * __ultoa __P((u_long, char *, int, int, char *)); static char * __uqtoa __P((u_quad_t, char *, int, int, char *)); + static void __find_arguments __P((const char *, va_list, void ***)); + static void __grow_type_table __P((int, unsigned char **, int *)); /* * Flush out all the vectors defined by the given uio, *************** *** 274,279 **** --- 276,282 ---- #endif /* FLOATING_POINT */ + #define STATIC_ARG_TBL_SIZE 8 /* Size of static argument table. */ /* * Flags used during conversion. *************** *** 295,301 **** { register char *fmt; /* format string */ register int ch; /* character from fmt */ ! register int n; /* handy integer (short term usage) */ register char *cp; /* handy char pointer (short term usage) */ register struct __siov *iovp;/* for PRINT macro */ register int flags; /* flags as above */ --- 298,304 ---- { register char *fmt; /* format string */ register int ch; /* character from fmt */ ! register int n, n2; /* handy integer (short term usage) */ register char *cp; /* handy char pointer (short term usage) */ register struct __siov *iovp;/* for PRINT macro */ register int flags; /* flags as above */ *************** *** 323,328 **** --- 326,335 ---- struct __siov iov[NIOV];/* ... and individual io vectors */ char buf[BUF]; /* space for %c, %[diouxX], %[eEfgG] */ char ox[2]; /* space for 0x hex-prefix */ + void **argtable; /* args, built due to positional arg */ + void *statargtable [STATIC_ARG_TBL_SIZE]; + int nextarg; /* 1-based argument index */ + va_list orgap; /* original argument pointer */ /* * Choose PADSIZE to trade efficiency vs. size. If larger printf *************** *** 365,382 **** iovp = iov; \ } /* * To extend shorts properly, we need both signed and unsigned * argument extraction methods. */ #define SARG() \ ! (flags&LONGINT ? va_arg(ap, long) : \ ! flags&SHORTINT ? (long)(short)va_arg(ap, int) : \ ! (long)va_arg(ap, int)) #define UARG() \ ! (flags&LONGINT ? va_arg(ap, u_long) : \ ! flags&SHORTINT ? (u_long)(u_short)va_arg(ap, int) : \ ! (u_long)va_arg(ap, u_int)) #ifdef _THREAD_SAFE _thread_flockfile(fp,__FILE__,__LINE__); --- 372,424 ---- iovp = iov; \ } + /* + * Get the argument indexed by nextarg. If the argument table is + * built, use it to get the argument. If its not, get the next + * argument (and arguments must be gotten sequentially). + */ + #define GETARG(type) \ + ((argtable != NULL) ? *((type*)(argtable[nextarg++])) : \ + (nextarg++, va_arg(ap, type))) + /* * To extend shorts properly, we need both signed and unsigned * argument extraction methods. */ #define SARG() \ ! (flags&LONGINT ? GETARG(long) : \ ! flags&SHORTINT ? (long)(short)GETARG(int) : \ ! (long)GETARG(int)) #define UARG() \ ! (flags&LONGINT ? GETARG(u_long) : \ ! flags&SHORTINT ? (u_long)(u_short)GETARG(int) : \ ! (u_long)GETARG(u_int)) ! ! /* ! * Get * arguments, including the form *nn$. Preserve the nextarg ! * that the argument can be gotten once the type is determined. ! */ ! #define GETASTER(val) \ ! n2 = 0; \ ! cp = fmt; \ ! while (is_digit(*cp)) { \ ! n2 = 10 * n2 + to_digit(*cp); \ ! cp++; \ ! } \ ! if (*cp == '$') { \ ! int hold = nextarg; \ ! if (argtable == NULL) { \ ! argtable = statargtable; \ ! __find_arguments (fmt0, orgap, &argtable); \ ! } \ ! nextarg = n2; \ ! val = GETARG (int); \ ! nextarg = hold; \ ! fmt = ++cp; \ ! } else { \ ! val = GETARG (int); \ ! } ! #ifdef _THREAD_SAFE _thread_flockfile(fp,__FILE__,__LINE__); *************** *** 399,404 **** --- 441,449 ---- } fmt = (char *)fmt0; + argtable = NULL; + nextarg = 1; + orgap = ap; uio.uio_iov = iovp = iov; uio.uio_resid = 0; uio.uio_iovcnt = 0; *************** *** 445,451 **** * -- ANSI X3J11 * They don't exclude field widths read from args. */ ! if ((width = va_arg(ap, int)) >= 0) goto rflag; width = -width; /* FALLTHROUGH */ --- 490,497 ---- * -- ANSI X3J11 * They don't exclude field widths read from args. */ ! GETASTER (width); ! if (width >= 0) goto rflag; width = -width; /* FALLTHROUGH */ *************** *** 457,463 **** goto rflag; case '.': if ((ch = *fmt++) == '*') { ! n = va_arg(ap, int); prec = n < 0 ? -1 : n; goto rflag; } --- 503,509 ---- goto rflag; case '.': if ((ch = *fmt++) == '*') { ! GETASTER (n); prec = n < 0 ? -1 : n; goto rflag; } *************** *** 483,488 **** --- 529,543 ---- n = 10 * n + to_digit(ch); ch = *fmt++; } while (is_digit(ch)); + if (ch == '$') { + nextarg = n; + if (argtable == NULL) { + argtable = statargtable; + __find_arguments (fmt0, orgap, + &argtable); + } + goto rflag; + } width = n; goto reswitch; #ifdef FLOATING_POINT *************** *** 500,506 **** flags |= QUADINT; goto rflag; case 'c': ! *(cp = buf) = va_arg(ap, int); size = 1; sign = '\0'; break; --- 555,561 ---- flags |= QUADINT; goto rflag; case 'c': ! *(cp = buf) = GETARG(int); size = 1; sign = '\0'; break; *************** *** 510,516 **** case 'd': case 'i': if (flags & QUADINT) { ! uqval = va_arg(ap, quad_t); if ((quad_t)uqval < 0) { uqval = -uqval; sign = '-'; --- 565,571 ---- case 'd': case 'i': if (flags & QUADINT) { ! uqval = GETARG(quad_t); if ((quad_t)uqval < 0) { uqval = -uqval; sign = '-'; *************** *** 536,544 **** fp_begin: if (prec == -1) prec = DEFPREC; if (flags & LONGDBL) ! _double = (double)va_arg(ap, long double); else ! _double = va_arg(ap, double); /* do this before tricky precision changes */ if (isinf(_double)) { if (_double < 0) --- 591,599 ---- fp_begin: if (prec == -1) prec = DEFPREC; if (flags & LONGDBL) ! _double = (double)GETARG(long double); else ! _double = GETARG(double); /* do this before tricky precision changes */ if (isinf(_double)) { if (_double < 0) *************** *** 588,607 **** #endif /* FLOATING_POINT */ case 'n': if (flags & QUADINT) ! *va_arg(ap, quad_t *) = ret; else if (flags & LONGINT) ! *va_arg(ap, long *) = ret; else if (flags & SHORTINT) ! *va_arg(ap, short *) = ret; else ! *va_arg(ap, int *) = ret; continue; /* no output */ case 'O': flags |= LONGINT; /*FALLTHROUGH*/ case 'o': if (flags & QUADINT) ! uqval = va_arg(ap, u_quad_t); else ulval = UARG(); base = 8; --- 643,662 ---- #endif /* FLOATING_POINT */ case 'n': if (flags & QUADINT) ! *GETARG(quad_t *) = ret; else if (flags & LONGINT) ! *GETARG(long *) = ret; else if (flags & SHORTINT) ! *GETARG(short *) = ret; else ! *GETARG(int *) = ret; continue; /* no output */ case 'O': flags |= LONGINT; /*FALLTHROUGH*/ case 'o': if (flags & QUADINT) ! uqval = GETARG(u_quad_t); else ulval = UARG(); base = 8; *************** *** 614,627 **** * defined manner.'' * -- ANSI X3J11 */ ! ulval = (u_long)va_arg(ap, void *); base = 16; xdigs = "0123456789abcdef"; flags = (flags & ~QUADINT) | HEXPREFIX; ch = 'x'; goto nosign; case 's': ! if ((cp = va_arg(ap, char *)) == NULL) cp = "(null)"; if (prec >= 0) { /* --- 669,682 ---- * defined manner.'' * -- ANSI X3J11 */ ! ulval = (u_long)GETARG(void *); base = 16; xdigs = "0123456789abcdef"; flags = (flags & ~QUADINT) | HEXPREFIX; ch = 'x'; goto nosign; case 's': ! if ((cp = GETARG(char *)) == NULL) cp = "(null)"; if (prec >= 0) { /* *************** *** 646,652 **** /*FALLTHROUGH*/ case 'u': if (flags & QUADINT) ! uqval = va_arg(ap, u_quad_t); else ulval = UARG(); base = 10; --- 701,707 ---- /*FALLTHROUGH*/ case 'u': if (flags & QUADINT) ! uqval = GETARG(u_quad_t); else ulval = UARG(); base = 10; *************** *** 657,663 **** case 'x': xdigs = "0123456789abcdef"; hex: if (flags & QUADINT) ! uqval = va_arg(ap, u_quad_t); else ulval = UARG(); base = 16; --- 712,718 ---- case 'x': xdigs = "0123456789abcdef"; hex: if (flags & QUADINT) ! uqval = GETARG(u_quad_t); else ulval = UARG(); base = 16; *************** *** 809,817 **** --- 864,1195 ---- #ifdef _THREAD_SAFE _thread_funlockfile(fp); #endif + if ((argtable != NULL) && (argtable != statargtable)) + free (argtable); return (ret); /* NOTREACHED */ } + + /* + * Type ids for argument type table. + */ + #define T_UNUSED 0 + #define T_SHORT 1 + #define T_U_SHORT 2 + #define TP_SHORT 3 + #define T_INT 4 + #define T_U_INT 5 + #define TP_INT 6 + #define T_LONG 7 + #define T_U_LONG 8 + #define TP_LONG 9 + #define T_QUAD 10 + #define T_U_QUAD 11 + #define TP_QUAD 12 + #define T_DOUBLE 13 + #define T_LONG_DOUBLE 14 + #define TP_CHAR 15 + #define TP_VOID 16 + + /* + * Find all arguments when a positional parameter is encountered. Returns a + * table, indexed by argument number, of pointers to each arguments. The + * initial argument table should be an array of STATIC_ARG_TBL_SIZE entries. + * It will be replaces with a malloc-ed on if it overflows. + */ + static void + __find_arguments (fmt0, ap, argtable) + const char *fmt0; + va_list ap; + void ***argtable; + { + register char *fmt; /* format string */ + register int ch; /* character from fmt */ + register int n, n2; /* handy integer (short term usage) */ + register char *cp; /* handy char pointer (short term usage) */ + register int flags; /* flags as above */ + int width; /* width from format (%8d), or 0 */ + unsigned char *typetable; /* table of types */ + unsigned char stattypetable [STATIC_ARG_TBL_SIZE]; + int tablesize; /* current size of type table */ + int tablemax; /* largest used index in table */ + int nextarg; /* 1-based argument index */ + + /* + * Add an argument type to the table, expanding if necessary. + */ + #define ADDTYPE(type) \ + ((nextarg >= tablesize) ? \ + __grow_type_table(nextarg, &typetable, &tablesize) : 0, \ + typetable[nextarg++] = type, \ + (nextarg > tablemax) ? tablemax = nextarg : 0) + + #define ADDSARG() \ + ((flags&LONGINT) ? ADDTYPE(T_LONG) : \ + ((flags&SHORTINT) ? ADDTYPE(T_SHORT) : ADDTYPE(T_INT))) + + #define ADDUARG() \ + ((flags&LONGINT) ? ADDTYPE(T_U_LONG) : \ + ((flags&SHORTINT) ? ADDTYPE(T_U_SHORT) : ADDTYPE(T_U_INT))) + + /* + * Add * arguments to the type array. + */ + #define ADDASTER() \ + n2 = 0; \ + cp = fmt; \ + while (is_digit(*cp)) { \ + n2 = 10 * n2 + to_digit(*cp); \ + cp++; \ + } \ + if (*cp == '$') { \ + int hold = nextarg; \ + nextarg = n2; \ + ADDTYPE (T_INT); \ + nextarg = hold; \ + fmt = ++cp; \ + } else { \ + ADDTYPE (T_INT); \ + } + fmt = (char *)fmt0; + typetable = stattypetable; + tablesize = STATIC_ARG_TBL_SIZE; + tablemax = 0; + nextarg = 1; + memset (typetable, T_UNUSED, STATIC_ARG_TBL_SIZE); + + /* + * Scan the format for conversions (`%' character). + */ + for (;;) { + for (cp = fmt; (ch = *fmt) != '\0' && ch != '%'; fmt++) + /* void */; + if (ch == '\0') + goto done; + fmt++; /* skip over '%' */ + + flags = 0; + width = 0; + + rflag: ch = *fmt++; + reswitch: switch (ch) { + case ' ': + case '#': + goto rflag; + case '*': + ADDASTER (); + goto rflag; + case '-': + case '+': + goto rflag; + case '.': + if ((ch = *fmt++) == '*') { + ADDASTER (); + goto rflag; + } + while (is_digit(ch)) { + ch = *fmt++; + } + goto reswitch; + case '0': + goto rflag; + case '1': case '2': case '3': case '4': + case '5': case '6': case '7': case '8': case '9': + n = 0; + do { + n = 10 * n + to_digit(ch); + ch = *fmt++; + } while (is_digit(ch)); + if (ch == '$') { + nextarg = n; + goto rflag; + } + width = n; + goto reswitch; + #ifdef FLOATING_POINT + case 'L': + flags |= LONGDBL; + goto rflag; + #endif + case 'h': + flags |= SHORTINT; + goto rflag; + case 'l': + flags |= LONGINT; + goto rflag; + case 'q': + flags |= QUADINT; + goto rflag; + case 'c': + ADDTYPE(T_INT); + break; + case 'D': + flags |= LONGINT; + /*FALLTHROUGH*/ + case 'd': + case 'i': + if (flags & QUADINT) { + ADDTYPE(T_QUAD); + } else { + ADDSARG(); + } + break; + #ifdef FLOATING_POINT + case 'e': + case 'E': + case 'f': + case 'g': + case 'G': + if (flags & LONGDBL) + ADDTYPE(T_LONG_DOUBLE); + else + ADDTYPE(T_DOUBLE); + break; + #endif /* FLOATING_POINT */ + case 'n': + if (flags & QUADINT) + ADDTYPE(TP_QUAD); + else if (flags & LONGINT) + ADDTYPE(TP_LONG); + else if (flags & SHORTINT) + ADDTYPE(TP_SHORT); + else + ADDTYPE(TP_INT); + continue; /* no output */ + case 'O': + flags |= LONGINT; + /*FALLTHROUGH*/ + case 'o': + if (flags & QUADINT) + ADDTYPE(T_U_QUAD); + else + ADDUARG(); + break; + case 'p': + ADDTYPE(TP_VOID); + break; + case 's': + ADDTYPE(TP_CHAR); + break; + case 'U': + flags |= LONGINT; + /*FALLTHROUGH*/ + case 'u': + if (flags & QUADINT) + ADDTYPE(T_U_QUAD); + else + ADDUARG(); + break; + case 'X': + case 'x': + if (flags & QUADINT) + ADDTYPE(T_U_QUAD); + else + ADDUARG(); + break; + default: /* "%?" prints ?, unless ? is NUL */ + if (ch == '\0') + goto done; + break; + } + } + done: + /* + * Build the argument table. + */ + if (tablemax >= STATIC_ARG_TBL_SIZE) { + *argtable = (void **) + malloc (sizeof (void *) * (tablemax + 1)); + } + + (*argtable) [0] = NULL; + for (n = 1; n <= tablemax; n++) { + (*argtable) [n] = ap; + switch (typetable [n]) { + case T_UNUSED: + (void) va_arg (ap, int); + break; + case T_SHORT: + (void) va_arg (ap, int); + break; + case T_U_SHORT: + (void) va_arg (ap, int); + break; + case TP_SHORT: + (void) va_arg (ap, short *); + break; + case T_INT: + (void) va_arg (ap, int); + break; + case T_U_INT: + (void) va_arg (ap, unsigned int); + break; + case TP_INT: + (void) va_arg (ap, int *); + break; + case T_LONG: + (void) va_arg (ap, long); + break; + case T_U_LONG: + (void) va_arg (ap, unsigned long); + break; + case TP_LONG: + (void) va_arg (ap, long *); + break; + case T_QUAD: + (void) va_arg (ap, quad_t); + break; + case T_U_QUAD: + (void) va_arg (ap, u_quad_t); + break; + case TP_QUAD: + (void) va_arg (ap, quad_t *); + break; + case T_DOUBLE: + (void) va_arg (ap, double); + break; + case T_LONG_DOUBLE: + (void) va_arg (ap, long double); + break; + case TP_CHAR: + (void) va_arg (ap, char *); + break; + case TP_VOID: + (void) va_arg (ap, void *); + break; + } + } + + if ((typetable != NULL) && (typetable != stattypetable)) + free (typetable); + } + + /* + * Increase the size of the type table. + */ + static void + __grow_type_table (nextarg, typetable, tablesize) + int nextarg; + unsigned char **typetable; + int *tablesize; + { + unsigned char *oldtable = *typetable; + int newsize = *tablesize * 2; + + if (*tablesize == STATIC_ARG_TBL_SIZE) { + *typetable = (unsigned char *) + malloc (sizeof (unsigned char) * newsize); + bcopy (oldtable, *typetable, *tablesize); + } else { + *typetable = (unsigned char *) + realloc (typetable, sizeof (unsigned char) * newsize); + + } + memset (&typetable [*tablesize], T_UNUSED, (newsize - *tablesize)); + + *tablesize = newsize; + } + #ifdef FLOATING_POINT From owner-freebsd-hackers Sun Sep 8 18:37:29 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA12314 for hackers-outgoing; Sun, 8 Sep 1996 18:37:29 -0700 (PDT) Received: from srv1-bsb.GNS.com.br ([200.239.56.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA12307 for ; Sun, 8 Sep 1996 18:37:25 -0700 (PDT) Received: (from mail@localhost) by srv1-bsb.GNS.com.br (8.7.5/8.7.5) id WAA23478; Sun, 8 Sep 1996 22:36:25 -0300 (EST) Received: from dl0123-bsb.gns.com.br(200.239.56.123) by srv1-bsb.GNS.com.br via smap (V1.3) id sma023476; Sun Sep 8 22:36:00 1996 Received: by DANIEL.sobral (IBM OS/2 SENDMAIL VERSION 1.3.14/2.12um) id AA0086; Sun, 08 Sep 96 18:46:46 +0300 Message-Id: <9609081546.AA0086@DANIEL.sobral> Date: Sun, 8 Sep 96 18:46:45 +0300 From: "Daniel C. Sobral" Subject: namei() To: hackers@freefall.freebsd.org Reply-To: e8917523@linf.unb.br In-Reply-To: <199609061651.JAA12132@freefall.freebsd.org> from "owner-hackers-digest@freefall.freebsd.org" at Sep 6 96 9:51 am X-Disclaimer: Klaatu Barada Nikto! X-Mailer: ELM [version 2.3 PL11] for OS/2 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > From: A JOSEPH KOSHY > Date: Fri, 06 Sep 1996 10:08:31 +0500 > Subject: Re: FreeBSD vs. Linux 96 (my impressions) > > >>>> "tl" == "Terry Lambert" writes > > tl> This is mostly because the BSD namei() interface is a piece of shit no > tl> one seems prepared to allow a change to because there are one or two > tl> CSRG hackers locked in a closet somewhere, and every once in a while > tl> they shove something out under the door, and God Forbid we lose out > tl> on the ability to integrate those occasional changes. > > On another point, I did some basic kernel profiling while doing some > assorted operations (make kernel, find | cpio -O /dev/null) etc. > > Surprisingly `namei' turned out to be the single biggest contributor to > time spent in the kernel. Does anyone have some ideas on improving namei()? -- Daniel C. Sobral (8-DCS) dcs@gns.com.br e8917523@linf.unb.br From owner-freebsd-hackers Sun Sep 8 18:38:25 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA12382 for hackers-outgoing; Sun, 8 Sep 1996 18:38:25 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA12375 for ; Sun, 8 Sep 1996 18:38:23 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id BAA13241; Mon, 9 Sep 1996 01:38:08 GMT Date: Mon, 9 Sep 1996 10:38:08 +0900 (JST) From: Michael Hancock Reply-To: Michael Hancock To: Terry Lambert cc: hackers@freebsd.org Subject: Re: namei performance (was Re: FreeBSD vs. Linux 96 (my impressions)) In-Reply-To: <199609082205.PAA03751@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 8 Sep 1996, Terry Lambert wrote: > The actual locking methodology that probaly wants to be used is seven > state: no lock, R (read), W (write), X (exclusive), IR (intention read), > IW, and IX. In the current code, the lock is an exclusive lock on the directory to prevent consistency problems. For example, VOP_CREAT on SYSV has to do a rescan of the directory because it doesn't lock the directory to ensure that the file didn't get created by someone else after the lookup was done. Could you walk thru this case with the above framework? Regards, Mike Hancock From owner-freebsd-hackers Sun Sep 8 19:41:38 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA18550 for hackers-outgoing; Sun, 8 Sep 1996 19:41:38 -0700 (PDT) Received: from w2xo.pgh.pa.us (w2xo.pgh.pa.us [206.210.70.5]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA18541 for ; Sun, 8 Sep 1996 19:41:36 -0700 (PDT) Received: (from durham@localhost) by w2xo.pgh.pa.us (8.6.12/8.6.9) id WAA00925 for hackers@freebsd.org; Sun, 8 Sep 1996 22:39:51 -0400 Date: Sun, 8 Sep 1996 22:39:51 -0400 From: Jim Durham Message-Id: <199609090239.WAA00925@w2xo.pgh.pa.us> To: hackers@freebsd.org Subject: NOSHARED Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Could someone point out to me where the variable NOSHARED is being set in the 2.1 source tree? thanks, Jim Durham From owner-freebsd-hackers Sun Sep 8 20:02:20 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA20372 for hackers-outgoing; Sun, 8 Sep 1996 20:02:20 -0700 (PDT) Received: from mnl.sequel.net (mnl.sequel.net [204.255.104.30]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA20365 for ; Sun, 8 Sep 1996 20:02:15 -0700 (PDT) Received: from rommel by mnl.sequel.net (SMI-8.6/SMI-SVR4) id LAA29594; Mon, 9 Sep 1996 11:05:42 +0800 Message-Id: <199609090305.LAA29594@mnl.sequel.net> From: "ROMMEL ESGUERRA" To: Date: Mon, 9 Sep 1996 11:02:49 +0800 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1085 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Dear BSD's, I really admired the FreeBSD operating system project and it's milestone age. I'm a five year software developer in Windows envrionment ranging from relational database application, to network and multimedia development. I'm really interested in FreeBSD continuing development, and I would like to take a part on its commitment and progressive development. However, I'm not yet oriented in the specification as well as the operating system's development. I'm presently taking up master's degree and concentrating in client/server technology. I hope I can be a part of it's future development process. -- Rommel C. Esguerra ( rce@mnl.sequel.net) Manila, Philippines Tel. No. 8244701 Fax No. 8244741 From owner-freebsd-hackers Sun Sep 8 21:12:14 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA24697 for hackers-outgoing; Sun, 8 Sep 1996 21:12:14 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA24689; Sun, 8 Sep 1996 21:12:10 -0700 (PDT) Received: from dan.emsphone.com (-@dan.emsphone.com [199.67.51.101]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id VAA03665 ; Sun, 8 Sep 1996 21:12:09 -0700 (PDT) Received: (from dan@localhost) by dan.emsphone.com (8.7.5/8.7.3) id XAA11748; Sun, 8 Sep 1996 23:10:47 -0500 (CDT) Message-Id: <199609090410.XAA11748@dan.emsphone.com> Subject: Re: Streamlogic RAIDION drive arrays To: taob@io.org (Brian Tao) Date: Sun, 8 Sep 1996 23:10:46 -0500 (CDT) Cc: dnelson@emsphone.com, winter@jurai.net, freebsd-hackers@FreeBSD.org, freebsd-scsi@FreeBSD.org In-Reply-To: from "Brian Tao" at Sep 8, 96 08:16:24 pm From: dnelson@emsphone.com (Dan Nelson) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk in the last episode, Brian Tao said: > > On Sun, 8 Sep 1996, Dan Nelson wrote: > > > > If we're all plugging our favorite RAID companies :), we have two > > Storage Computer boxes (50 & 90 gig) and are happy with them. > > Are they on FreeBSD boxes? :) Well, no... They serve a Novell server and two SCO boxes. The Novell and one of the SCO machines both have two scsi cards in them, as do the RAID boxes. We use the disk-concatenation feature of both OS's to get one drive, but the throughput of two F/W scsi busses. If Micro Focus ever made a FreeBSD version of Cobol, we would use FreeBSD, though. We've hit the 2-gig filesize limit on SCO quite a few times. -Dan Nelson dnelson@emsphone.com From owner-freebsd-hackers Sun Sep 8 21:47:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA28496 for hackers-outgoing; Sun, 8 Sep 1996 21:47:02 -0700 (PDT) Received: from po2.glue.umd.edu (po2.glue.umd.edu [129.2.128.45]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA28489 for ; Sun, 8 Sep 1996 21:46:59 -0700 (PDT) Received: from ginger.eng.umd.edu (ginger.eng.umd.edu [129.2.103.20]) by po2.glue.umd.edu (8.7.5/8.7.3) with ESMTP id AAA24983; Mon, 9 Sep 1996 00:46:55 -0400 (EDT) Received: from localhost (chuckr@localhost) by ginger.eng.umd.edu (8.7.5/8.7.3) with SMTP id AAA07319; Mon, 9 Sep 1996 00:46:55 -0400 (EDT) X-Authentication-Warning: ginger.eng.umd.edu: chuckr owned process doing -bs Date: Mon, 9 Sep 1996 00:46:54 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@ginger.eng.umd.edu To: Jim Durham cc: hackers@freebsd.org Subject: Re: NOSHARED In-Reply-To: <199609090239.WAA00925@w2xo.pgh.pa.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 8 Sep 1996, Jim Durham wrote: > Could someone point out to me where the variable NOSHARED is being > set in the 2.1 source tree? It's in share/mk/bsd.prog.mk. Well, I mean to say, it's used there, and if you want, you could define it in your etc/make.conf, or on the command line when you make world. I sure wouldn't advise you to do that. I forces things to be built nonshared (no dynamic linking), so all the binaries get extremely bloated in size, and take a much longer time to startup. I'm really talking radically larger now. Experiment on a simple hello world C program ... link it -Bstatic, you'll see what I mean. There are parts of the tree that are built this way on purpose, stuff in /sbin, say. This is for emergencies, so stuff in that directory will work even if your /usr partition fails to mount (so your runtime linker can't get at the shared libraries). One popular mistake to make is to give root a shell such as tcsh (usually in /usr/local/bin, and usually linked dynamically). First time you lose /usr, you find you can no longer do stuff manually, because root's shell can't execute. No running fsck manually, and saving yourself. Some people build tcsh statically for that reason. That kinda mistake you only have to make once (no I haven't done that, I do dumber ones). > > thanks, > Jim Durham > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and n3lxx, both FreeBSD (301) 220-2114 | version 2.2 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Sun Sep 8 21:50:32 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA28820 for hackers-outgoing; Sun, 8 Sep 1996 21:50:32 -0700 (PDT) Received: from cc.nsysu.edu.tw (cc.nsysu.edu.tw [140.117.11.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA28812 for ; Sun, 8 Sep 1996 21:50:29 -0700 (PDT) Received: from galaxy.cie.nsysu.edu.tw (galaxy.cie.nsysu.edu.tw [140.117.168.1]) by cc.nsysu.edu.tw (8.7.5/8.7.3) with SMTP id MAA02081 for ; Mon, 9 Sep 1996 12:48:14 +0800 (CST) Received: by cie.nsysu.edu.tw (4.1/SMI-4.1-SysuNet) id AA13645; Mon, 9 Sep 96 12:47:12 CST From: jychen@cie.nsysu.edu.tw (Jian-ying Chen) Message-Id: <9609090447.AA13645@cie.nsysu.edu.tw> Subject: GDB Compile Problem! To: freebsd-hackers@FreeBSD.org Date: Mon, 9 Sep 1996 12:47:12 +0800 (CST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hello all: I try to rebuild my gdb( GNU debuger ) but it told me that trad-core.c: In function `trad_unix_core_file_p': trad-core.c:108: `NBPG' undeclared (first use this function) What is NBPG and what it should be? Thanks in advance! From owner-freebsd-hackers Sun Sep 8 22:04:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA00137 for hackers-outgoing; Sun, 8 Sep 1996 22:04:35 -0700 (PDT) Received: from diablo.ppp.de (diablo.ppp.de [193.141.101.34]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA00118 for ; Sun, 8 Sep 1996 22:04:33 -0700 (PDT) Received: by diablo.ppp.de (Smail3.1.28.1 #1) id m0uzyW9-000QhjC; Mon, 9 Sep 96 07:04 MET DST Received: from 193.141.161.123 (monster.pong.ppp.de [193.141.161.123]) by pong.PPP.DE (8.6.12/8.6.12) with SMTP id DAA06114; Mon, 9 Sep 1996 03:20:11 +0200 Message-ID: <323370CF.5616@pong.ppp.de> Date: Mon, 09 Sep 1996 03:20:15 +0200 From: Stefan Bethke Organization: Not very well... X-Mailer: Mozilla 2.02 (Macintosh; I; 68K) MIME-Version: 1.0 To: "Sean P. Robertson" CC: freebsd-hackers Subject: Re: FTP Mirror HOW-TO References: <3232317A.41C67EA6@awod.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Sean P. Robertson wrote: > > I am looking for documentation on how to set up an FTP Mirror site. I > have read the man pages for FTPD and other stuff but have not found the > answer. Any help would be appreciated. There is perl script named "mirror" which I found to be somewhat clumsy. A friend of mine has written an alternative in C. You can find it at http://people/stefan/cwftp/ http://pub/people/stefan/cwftp/ ftp://pub/people/stefan/cwftp/ Stefan From owner-freebsd-hackers Sun Sep 8 22:20:15 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA00752 for hackers-outgoing; Sun, 8 Sep 1996 22:20:15 -0700 (PDT) Received: from kanto.cc.jyu.fi (root@kanto.cc.jyu.fi [130.234.1.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA00747 for ; Sun, 8 Sep 1996 22:20:12 -0700 (PDT) Received: from localhost (kallio@localhost [127.0.0.1]) by kanto.cc.jyu.fi (8.7.2/8.7.2) with ESMTP id IAA01961; Mon, 9 Sep 1996 08:16:47 +0300 (EET DST) Date: Mon, 9 Sep 1996 08:16:45 +0300 (EET DST) From: Seppo Kallio To: Joerg Wunsch cc: FreeBSD hackers , Wolfram Schneider Subject: Re: SECURITY HOLE in FreeBSD 2.1.5 ????????!!!!!!! In-Reply-To: <199609070742.JAA08466@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > It indeed creates this file, but you should have UTSL'ed before. It > is deliberately created with ``insecure'' permissions, and it is the > new copy of /etc/passwd if the -p option has been specified. Thus, it > doesn't contain passwords. Then it is OK. The name was missleading me. > > We cannot add users to the system when someone is using passwd command. > > It is really big problem in a node having 4000 accounts when we try to add > > 1000 account now when new students come in start of September. > > Passwd command should not lock the passwd files for the entire time after > > user type passwd to the time he/she succeeds to type his/hers new passwd! > > Of course, the passwd command *should* lock the master password file > while modifications are in progress. Yes. But not right after user pushes the enter putton after passwd -command. That is not all the time user is "in" the passwd command. As you say "while modifications are in progress". There is no modification in progress until user pushes enter after the second new passwd. Or do you agree? > However, you are perhaps > interested in Guido's ``incremental update'' modifications: > > revision 1.11 > date: 1996/07/01 19:38:27; author: guido; state: Exp; lines: +218 -133 > Implement incremental passwd database updates. This is done by ading a '-u' > option to pwd_mkdb and adding this option to utilities invoking it. > Further, the filling of both the secure and insecure databases has been > merged into one loop giving also a performance improvemnet. Can you tell me, where I can find this modification? > Btw., i found a real security hole while browsing through the sources: > adduser backs up the contents of master.passwd into a world readable > file in case pwd_mkdb(8) returned an error. Wolfram, can you fix this > please (by setting umask(066) first, i think)? > > -- > cheers, J"org Thank you. Seppo Kallio kallio@jyu.fi Computing Center Fax +358-14-603611 U of Jyväskylä 62.14N 25.44E Phone +358-14-603606 PL 35, 40351 Jyväskylä, Finland http://www.jyu.fi/~kallio From owner-freebsd-hackers Mon Sep 9 01:19:43 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA07427 for hackers-outgoing; Mon, 9 Sep 1996 01:19:43 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA07419 for ; Mon, 9 Sep 1996 01:19:37 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA08160; Mon, 9 Sep 1996 10:19:07 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA05958; Mon, 9 Sep 1996 10:18:53 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id JAA07751; Mon, 9 Sep 1996 09:46:54 +0200 (MET DST) From: J Wunsch Message-Id: <199609090746.JAA07751@uriah.heep.sax.de> Subject: Re: GDB Compile Problem! To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Mon, 9 Sep 1996 09:46:54 +0200 (MET DST) Cc: jychen@cie.nsysu.edu.tw (Jian-ying Chen) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <9609090447.AA13645@cie.nsysu.edu.tw> from Jian-ying Chen at "Sep 9, 96 12:47:12 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Jian-ying Chen wrote: > I try to rebuild my gdb( GNU debuger ) but it told me that > > trad-core.c: In function `trad_unix_core_file_p': > trad-core.c:108: `NBPG' undeclared (first use this function) > > What is NBPG and what it should be? It's the now obsolete name for ``number of bytes per page''. Use PAGE_SIZE instead. (Both used to be the same.) Don't forget to get this back to the GNU folks. I recently noticed that binutils are also broken now. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Sep 9 01:20:32 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA07525 for hackers-outgoing; Mon, 9 Sep 1996 01:20:32 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA07518 for ; Mon, 9 Sep 1996 01:20:24 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA08148; Mon, 9 Sep 1996 10:18:50 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA05948; Mon, 9 Sep 1996 10:18:39 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id JAA07694; Mon, 9 Sep 1996 09:42:35 +0200 (MET DST) From: J Wunsch Message-Id: <199609090742.JAA07694@uriah.heep.sax.de> Subject: Re: ft0 doesn't work with new motherboard To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Mon, 9 Sep 1996 09:42:35 +0200 (MET DST) Cc: mark@seeware.DIALix.oz.au (Mark Hannon) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199609072204.WAA00253@putte.seeware.DIALix.oz.au> from Mark Hannon at "Sep 7, 96 10:04:53 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Mark Hannon wrote: > Some month ago I upgraded to a Pentium motherboard for my FreeBSD system. > Prior to that change I had been using a Conner floppy tape drive with some > success. What floppy controller is there? (The chip ID from the board, not what FreeBSD claims it were.) > ===> tape_cmd: 6 > ft0: bad seek in tape_cmd; pcn = 1 newcn = 6 > ft0: bad seek in tape_cmd; pcn = 1 newcn = 6 > ft0: bad seek in tape_cmd; pcn = 1 newcn = 6 > ft0: bad seek in tape_cmd; pcn = 2 newcn = 6 > ft0: bad seek in tape_cmd; pcn = 2 newcn = 6 > ft0: tape_cmd seek failed! > Anybody now what this means? I think it means the FDC doesn't correctly grok `seek' commands. These commands are used for floppy tapes to send out the tape command. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Sep 9 01:22:11 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA07904 for hackers-outgoing; Mon, 9 Sep 1996 01:22:11 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA07886 for ; Mon, 9 Sep 1996 01:22:04 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id KAA08179 for ; Mon, 9 Sep 1996 10:19:11 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id KAA05962 for freebsd-hackers@freebsd.org; Mon, 9 Sep 1996 10:19:11 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id KAA08132 for freebsd-hackers@freebsd.org; Mon, 9 Sep 1996 10:10:11 +0200 (MET DST) From: J Wunsch Message-Id: <199609090810.KAA08132@uriah.heep.sax.de> Subject: Re: Support for fixed-scan monitors To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Mon, 9 Sep 1996 10:10:11 +0200 (MET DST) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <323343E2.297D@sn.no> from Arve Ronning at "Sep 8, 96 03:08:34 pm" X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Arve Ronning wrote: > > Syscons (and pcvt) should start the same device as the BIOS, anyway. > Given the quirks of BIOSes, that would have to be the [CEV]GA. I > don't think syscons knows which device is being used by BIOS (please > correct me if I'm wrong here). I haven't checked pcvt. So, I believe > this is mostly a matter of choice (and not of using what BIOS uses). This is a mistake of motherboard and BIOS vendors. There used to be a jumper on the motherboards back in the old days, denoting the prefered graphics console. (The BIOSes usually complained if it was set wrong, i.e. choose a nonexistant adapter.) pcvt correctly honors it, but i agree that this feature is now almost worthless. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-hackers Mon Sep 9 01:48:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA08995 for hackers-outgoing; Mon, 9 Sep 1996 01:48:07 -0700 (PDT) Received: from alpo.whistle.com (s205m1.whistle.com [207.76.205.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA08990 for ; Mon, 9 Sep 1996 01:48:04 -0700 (PDT) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.7.5/8.7.3) with SMTP id BAA01373; Mon, 9 Sep 1996 01:38:31 -0700 (PDT) Message-ID: <3233D739.52BFA1D7@whistle.com> Date: Mon, 09 Sep 1996 01:37:13 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0b6 (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: R.E.Wolff@BitWizard.nl CC: hackers@freebsd.org Subject: Sig 11 page Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk You should also mention in your page that the FreeBSD group has isolated the EXACT same phenomenon, and that under FreeBSD compiling a kernel (or doing "make world" which is even more gruelling) is more stressfull on ram that any simm tester. sig-10 and sig-11 in these circumstances are nearly always found to be bad hardware as on linux.. If you add this comment I think we would add a link to you rpage from the FreeBSD web page as well, it'd shut up all those "My friend says it's The OS and I should switch to " comments.. It's also a well written and good page to reference. julian Re: http://www.bitwizard.nl/sig11/ From owner-freebsd-hackers Mon Sep 9 02:46:14 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA10905 for hackers-outgoing; Mon, 9 Sep 1996 02:46:14 -0700 (PDT) Received: from relay.philips.nl (ns.philips.nl [130.144.65.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA10895 for ; Mon, 9 Sep 1996 02:46:09 -0700 (PDT) Received: (from smap@localhost) by relay.philips.nl (8.6.9/8.6.9-950414) id LAA06825; Mon, 9 Sep 1996 11:41:49 +0200 Received: from unknown(192.26.173.32) by ns.philips.nl via smap (V1.3+ESMTP) with ESMTP id sma006686; Mon Sep 9 11:40:47 1996 Received: from spooky.lss.cp.philips.com (spooky.lss.cp.philips.com [130.144.199.105]) by smtp.nl.cis.philips.com (8.6.10/8.6.10-0.9z-02May95) with ESMTP id LAA04431; Mon, 9 Sep 1996 11:43:37 +0200 Received: (from guido@localhost) by spooky.lss.cp.philips.com (8.6.10/8.6.10-0.991c-08Nov95) id LAA12024; Mon, 9 Sep 1996 11:40:43 +0200 From: Guido van Rooij Message-Id: <199609090940.LAA12024@spooky.lss.cp.philips.com> Subject: Re: vx device broken in 21.1.5? To: dfr@render.com (Doug Rabson) Date: Mon, 9 Sep 1996 11:40:43 +0200 (MET DST) Cc: Guido.vanRooij@nl.cis.philips.com, freebsd-hackers@FreeBSD.org Reply-To: Guido.vanRooij@nl.cis.philips.com In-Reply-To: from Doug Rabson at "Sep 6, 96 11:45:31 am" X-Mailer: ELM [version 2.4ME+ PL19 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Doug Rabson wrote: > On Fri, 6 Sep 1996, Doug Rabson wrote: > > > On Fri, 6 Sep 1996, Guido van Rooij wrote: > > > > > I am getting a very poor performance with a 3c590 card in FreeBSd 2.1.5. > > > When Ftp-ing I get like 600K/sec put performance, but only 10K/sec > > > when getting data. Are there some overrun problems? > > > > There are some problems but I don't know if they are overruns. I have > > been experimenting with some patches based on examining the OpenBSD driver > > with some confusing but promising results. I'll try to come up with a > > patch today. > > Try this patch. I pulled in some code from OpenBSD which detects a > particular overrun hang in this card. This improves the throughput of the > device enourmously. Oddly, the overrun hang which is code detects has > never happened for me. Part of the test is to read the VX_W4_FIFO_DIAG > register; if I reduce the patch to simply reading this register and > discarding the result, I get a similar performance improvement. Since I > have no documentation for the card, I have no idea why this should be the > case. I tried the patch but it doesn't solve part of my problem. It makes things worse. Basically, now I am getting buffer overflows when *putting* out a file with ftp. I checked what happened with a ping -f -s 1000 somenearbyhost and noticed that both the original 2.1.5 driver as well as the one with your patch give `no buffer space available' after some time. But with your patch I am getting them earlier. -Guido From owner-freebsd-hackers Mon Sep 9 03:42:11 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA13974 for hackers-outgoing; Mon, 9 Sep 1996 03:42:11 -0700 (PDT) Received: from yokogawa.co.jp (yhqfm.yokogawa.co.jp [202.33.29.34]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id DAA13954 for ; Mon, 9 Sep 1996 03:41:48 -0700 (PDT) Received: from sjc.yokogawa.co.jp.yokogawa.co.jp ([133.140.4.100]) by yokogawa.co.jp (8.6.9+2.4Wb3/3.3Wb4-firewall:08/09/94) with ESMTP id TAA22703 for ; Mon, 9 Sep 1996 19:41:32 +0900 Received: from leia.pa.yokogawa.co.jp by sjc.yokogawa.co.jp.yokogawa.co.jp (8.7.1+2.6Wbeta4/6.4J.6-YOKOGAWA-R/GW) id TAA18256; Mon, 9 Sep 1996 19:41:30 +0900 (JST) Received: from sapphire by leia.pa.yokogawa.co.jp (1.38.193.4/6.4J.6-YOKOGAWA/pa) id AA14253; Mon, 9 Sep 1996 19:41:30 +0900 Received: from localhost by sapphire.pa.yokogawa.co.jp (8.6.12/3.3Wb) id TAA11154; Mon, 9 Sep 1996 19:42:26 +0900 Message-Id: <199609091042.TAA11154@sapphire.pa.yokogawa.co.jp> To: freebsd-hackers@freebsd.org Subject: Re: a problem of setitimer() Reply-To: mihoko@pa.yokogawa.co.jp In-Reply-To: Your message of "Fri, 10 May 1996 18:20:25 +1000" References: <199605100820.SAA03647@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii From: Mihoko Tanaka X-Mailer: Mew version 1.06 on Emacs 19.28.2, Mule 2.3 Date: Mon, 09 Sep 1996 19:42:26 +0900 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, Long long ago, :-) I asked the following question and got some answer from Mr. Evans about it. bde> >I'm running FreeBSD-2.1.0R. bde> >I found the problem of realitexpire() [sys/kern/kern_time.c]. bde> >If the time is late, the process which uses the system call bde> >setitimer() can't get SIGALARM until the next timeout has come. bde> bde> >For example, the current time is 7:30 and the next timeout is 7:32, bde> >then the time is changed to 7:15. bde> >The process gets SIGALARM at 7:32, not at 7:17. bde> bde> >I suggest following coding. bde> >How about? bde> bde> I think the correct fix is to adjust all the timers in settimeofday(). bde> It now says /* WHAT DO WE DO ABOUT PENDING REAL-TIME TIMEOUTS??? */ bde> and does nothing. Why does it nothing ? I agree that all the timers are adjusted in settimeofday() when the current time is changed. Or, the system is locked several times when we change the current time on a large scale. For instance, I change the current time to '9 Sep 1996' from '9 Sep 1999' by using 'date' command, (of course I know it's my silly doings :-) ) then my freebsd has been locked for 5 minutes. The kernel is looping in realitexpire() at that time because 'time' has so big value. How about the following patch ? (it's for -current.) ------------------------ cut here -------------------------------------- --- kern_time.c Mon Sep 9 19:27:30 1996 +++ kern_time.c.new Mon Sep 9 19:30:05 1996 @@ -56,6 +56,8 @@ */ static void timevalfix __P((struct timeval *)); +static void recalc_realtimer(struct timeval); + #ifndef _SYS_SYSPROTO_H_ struct gettimeofday_args { @@ -122,6 +124,7 @@ */ delta.tv_sec = atv.tv_sec - time.tv_sec; delta.tv_usec = atv.tv_usec - time.tv_usec; + recalc_realtimer(delta); time = atv; /* * XXX should arrange for microtime() to agree with atv if @@ -144,6 +147,21 @@ tz = atz; return (0); } + +static void +recalc_realtimer(struct timeval delta) +{ + struct proc *p=(struct proc *)allproc; + int np=nprocs; + + while(--np >=0) { + if (timerisset(&p->p_realtimer.it_value)) { + timevaladd(&p->p_realtimer.it_value, &delta); + timevalfix(&p->p_realtimer.it_value); + } + p = p->p_next; + } +} extern int tickadj; /* "standard" clock skew, us./tick */ int tickdelta; /* current clock skew, us. per tick */ ------------------------ cut here -------------------------------------- -- Mihoko Tanaka From owner-freebsd-hackers Mon Sep 9 04:18:57 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA15800 for hackers-outgoing; Mon, 9 Sep 1996 04:18:57 -0700 (PDT) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA15795 for ; Mon, 9 Sep 1996 04:18:53 -0700 (PDT) Received: from minnow.render.com (minnow.render.com [193.195.178.1]) by minnow.render.com (8.6.12/8.6.9) with SMTP id LAA22303; Mon, 9 Sep 1996 11:19:13 +0100 Date: Mon, 9 Sep 1996 11:19:12 +0100 (BST) From: Doug Rabson To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= cc: Ollivier Robert , freebsd-hackers@freebsd.org Subject: Re: vx device broken in 21.1.5? In-Reply-To: <199609062213.CAA00356@nagual.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 7 Sep 1996, [KOI8-R] =E1=CE=C4=D2=C5=CA =FE=C5=D2=CE=CF=D7 wrote: > > According to Guido van Rooij: > > > I am getting a very poor performance with a 3c590 card in FreeBSd 2.1= =2E5. > > > When Ftp-ing I get like 600K/sec put performance, but only 10K/sec=20 > > > when getting data. Are there some overrun problems? > >=20 > > Last time I got the same symptoms, the card was slowly dying. I hope Do= ug's > > patch will fix it though. >=20 > Today I got it died immediately (I don't saw slow dies yet) > and also apply this patch after it... At least it does no harm, > I can't say more at this moment. > BTW, there was small typo in the patch: .. -> . Ack! That was part of the patch which I had #if'ed out while trying to find out why it worked at all. That'll teach me to post stuff which I haven't compiled :-( Has anyone tried the patch? Does it work for you? Does it make things worse? -- Doug Rabson, Microsoft RenderMorphics Ltd.=09Mail: dfr@render.com =09=09=09=09=09=09Phone: +44 171 734 3761 =09=09=09=09=09=09FAX: +44 171 734 6426 From owner-freebsd-hackers Mon Sep 9 04:51:11 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA16836 for hackers-outgoing; Mon, 9 Sep 1996 04:51:11 -0700 (PDT) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA16830 for ; Mon, 9 Sep 1996 04:51:07 -0700 (PDT) Received: by gvr.win.tue.nl (8.6.13/1.53) id NAA24120; Mon, 9 Sep 1996 13:49:03 +0200 From: guido@gvr.win.tue.nl (Guido van Rooij) Message-Id: <199609091149.NAA24120@gvr.win.tue.nl> Subject: Re: vx device broken in 21.1.5? To: dfr@render.com (Doug Rabson) Date: Mon, 9 Sep 1996 13:49:03 +0200 (MET DST) Cc: ache@nagual.ru, roberto@keltia.freenix.fr, freebsd-hackers@freebsd.org In-Reply-To: from Doug Rabson at "Sep 9, 96 11:19:12 am" X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk One update on the problem where it dies when youflood ping another machine. Basically, I found out that it hangs in OACTIVE mode. Input still works (as canbe seen by netstat -I). Output is just dead. -Guido From owner-freebsd-hackers Mon Sep 9 05:25:44 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA17800 for hackers-outgoing; Mon, 9 Sep 1996 05:25:44 -0700 (PDT) Received: from mh004.infi.net (mh004.infi.net [198.22.1.119]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA17794 for ; Mon, 9 Sep 1996 05:25:42 -0700 (PDT) Received: from cpq-lte.ric.pmu.com by mh004.infi.net with ESMTP (Infinet-S-3.3) id IAA00602; Mon, 9 Sep 1996 08:24:42 -0400 (EDT) Message-Id: <199609091224.IAA00602@mh004.infi.net> From: "Steve Sims" To: "Bruce Evans" , , Subject: Re: Problem with sio0 Date: Mon, 9 Sep 1996 08:24:01 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: base64 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk QnJ1Y2UgLSBpcyB0aGlzIGEgY29pbmNpZGVuY2UsIG9yIFdIQVQ/ICBJIGhhdmUgYmVlbiBzdWZm ZXJpbmcgZm9yIGEgY291cGxlIG9mIG1vbnRocyB3aXRoIHRoaXMgZXhhY3Qgc2FtZSBwcm9ibGVt IG9uIGEgQ29tcHVrZSBMVEUvRWxpdGUuDQoNCkkgY2hhdHRlZCB3aXRoIE5hdGUgYSBsaXR0bGUg Yml0IG9uIHRoaXMsIGFuZCBoZSByZWNvbW1lbmRlZCB0aGF0IEkgaGl0IHlvdSB3aXRoIHRoaXMu DQoNCkhhdmluZyBqdXN0IGxvYWRlZCB0aGUgOC8xIDIuMiBTTkFQLCBJJ2xsIHRyeSB0aGUgcGF0 Y2hlcyBlbmNsb3NlZCBhbmQgbGV0IHlvdSBrbm93IHdoYXQgSSBmaW5kLiAgVGhpcyBoYXMgYmVl biBNT1NUIGlycml0YXRpbmcsIGJ1dCBhIHByb2ZvdW5kIGxhY2sgb2YgdGltZSBoYXMgcHJldmVu dGVkIG1lIGZyb20gdXBncmFkaW5nIG15IHNvdXJjZSAvIHBva2luZyBhcm91bmQuDQoNCkZXSVcs IHRoZSBib290IHByb2JlIGRvZXNuJ3QgZmluZCB0aGUgTWVnYWhlcnR6IFgtSmFjayBhdCBzaW8x IGVpdGhlci4uLi4NCg0KLi4uc2pzLi4uDQoNCi0tLS0tLS0tLS0NCj4gRnJvbTogQnJ1Y2UgRXZh bnMgPGJkZUB6ZXRhLm9yZy5hdT4NCj4gVG86IGZyZWVic2QtaGFja2Vyc0BGcmVlQlNELm9yZzsg aG91c2xleUBwci1jb21tLmNvbQ0KPiBTdWJqZWN0OiBSZTogUHJvYmxlbSB3aXRoIHNpbzANCj4g RGF0ZTogRnJpZGF5LCBTZXB0ZW1iZXIgMDYsIDE5OTYgMTo0NSBQTQ0KPiANCj4gPkkgaGF2ZSBh IENvbXBhcSBDb250dXJhIDQzMEMgbGFwdG9wLiAgT24gYm9vdCBJIGdldCBhIG1lc3NhZ2U6DQo+ ID4NCj4gPnNpbzAgbm90IGZvdW5kIGF0IDB4M2Y4DQo+ID4NCj4gPlRoZSBjb21wdXRlcnMgQklP UywgRE9TL1dpbmRvemUgYW5kIE9TLzIgYWxsIGFyZSBhYmxlIHRvIGZpbmQgaXQgYXQgMHgzZjgN Cj4gPndpdGggSVJRIDQgYW5kIHRoaW5rIGl0IGlzIGEgTlMxNjU1MEFGLiAgSSBtb2RpZmllZCAN Cj4gPi91c3Ivc3JjL3N5cy9pMzg2L2lzYS9zaW8uYyB0byBwcmludCB0aGUgY29udGVudHMgb2Yg dGhlIGFycmF5ICJmYWlsdXJlcyIuICANCj4gPk9uIGJvb3QgYWxsIGxvY2F0aW9ucyBjb250YWlu ZWQgMCBleGNlcHQgIzUgYW5kICM4LiAgDQo+ID4NCj4gPkkgd291bGQgbGlrZSB0byBmaXggdGhp cyBwcm9ibGVtLiAgSSBpcyB0aGVyZSBtb3JlIHRlc3RpbmcgSSBjYW4gZG8gdG8gaGVscD8NCj4g PkkgdHJpZWQgaWdub3JpbmcsIGNvbW1lbnRlZCBvdXQsIHRoZSBsaW5lcyB0aGF0IHNldCAjNSAm IDguICBUaGF0IGNhdXNlZCANCj4gPiI2NSBldmVudHMgb24gYSBkZXZpY2Ugd2l0aG91dCBhIHRw IiAoYmFzaWNhbGx5KS4NCj4gDQo+IEluLCAtY3VycmVudCwgdHJ5IGluY3JlYXNpbmcgdGhlIGRl bGF5cy4gIEkgZ3Vlc3MgdGhpcyB3b3VsZCB3b3JrIGJlY2F1c2UNCj4gdGhlIGZhaWx1cmUgbWVz c2FnZXMgc2hvdyB0aGF0IHRoZSBleHBlY3RlZCBpbnRlcnJ1cHQgYXJyaXZlZCBhIGxpdHRsZQ0K PiBsYXRlLiAgQWxzbyB0cnkgdGhlIENGQ1IgY2hhbmdlIGluIHRoZSBlbmNsb3NlZCBkaWZmcy4N Cj4gDQo+IFRoZSBkZWxheXMgc29tZWhvdyBkaWRuJ3QgbWFrZSBpdCBpbnRvIDIuMS41LiAgVHJ5 IHRoZSBlbmNsb3NlZCBwYXRjaA0KPiBmb3IgMi4xLjUuICBJdCBtaWdodCB3b3JrIGZvciBlYXJs aWVyIHZlcnNpb25zIHRvby4NCj4gDQo+IEJydWNlDQpbU05JUF0NCg0KLi4uc2pzLi4u From owner-freebsd-hackers Mon Sep 9 06:11:25 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA19597 for hackers-outgoing; Mon, 9 Sep 1996 06:11:25 -0700 (PDT) Received: from nevis.oss.uswest.net (nevis.oss.uswest.net [204.147.85.3]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id GAA19592 for ; Mon, 9 Sep 1996 06:11:23 -0700 (PDT) Received: (from greg@localhost) by nevis.oss.uswest.net (8.6.12/8.6.12) id IAA23759 for hackers@FreeBSD.org; Mon, 9 Sep 1996 08:10:52 -0500 From: "Greg Rowe" Message-Id: <9609090810.ZM23757@nevis.oss.uswest.net> Date: Mon, 9 Sep 1996 08:10:52 -0500 X-Mailer: Z-Mail (3.2.1 10oct95) To: hackers@FreeBSD.org Subject: Bind Version ? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Is there an easy way to determine the version of Bind running on FreeBSD that somehow corresponds to Paul's version naming scheme (4.9.X) ? I'm interested in knowing the version/patch level for 2.1.5. Thanks. -- Greg Rowe | U S West - Interact Services | INTERNET greg@uswest.net 111 Washington Ave. South | Fax: (612) 672-8537 Minneapolis, MN USA 55401 | Voice: (612) 672-8535 Never trust an operating system you don't have source for.... From owner-freebsd-hackers Mon Sep 9 06:34:19 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA20719 for hackers-outgoing; Mon, 9 Sep 1996 06:34:19 -0700 (PDT) Received: from zed.ludd.luth.se (root@zed.ludd.luth.se [130.240.16.33]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA20695 for ; Mon, 9 Sep 1996 06:33:35 -0700 (PDT) Received: from obie.ludd.luth.se (obie.ludd.luth.se [130.240.16.24]) by zed.ludd.luth.se (8.7.5/8.7.2) with ESMTP id PAA25756; Mon, 9 Sep 1996 15:33:14 +0200 Received: from localhost (pantzer@localhost) by obie.ludd.luth.se (8.6.11/8.6.11) with SMTP id PAA01823; Mon, 9 Sep 1996 15:33:13 +0200 Date: Mon, 9 Sep 1996 15:33:12 +0200 (MET DST) From: Mattias Pantzare To: Stefan Bethke cc: freebsd-hackers Subject: Re: FTP Mirror HOW-TO In-Reply-To: <323370CF.5616@pong.ppp.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 9 Sep 1996, Stefan Bethke wrote: > A friend of mine has written an alternative in C. You can find it at > http://people/stefan/cwftp/ > http://pub/people/stefan/cwftp/ > ftp://pub/people/stefan/cwftp/ Hm, maybe a computer name in the URLs? :-) They won't work like that... From owner-freebsd-hackers Mon Sep 9 08:58:39 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA27010 for hackers-outgoing; Mon, 9 Sep 1996 08:58:39 -0700 (PDT) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA26995 for ; Mon, 9 Sep 1996 08:58:28 -0700 (PDT) Received: from dialup-usr11.etinc.com (dialup-usr11.etinc.com [204.141.95.132]) by etinc.com (8.6.12/8.6.9) with SMTP id MAA16753 for ; Mon, 9 Sep 1996 12:03:46 -0400 Date: Mon, 9 Sep 1996 12:03:46 -0400 Message-Id: <199609091603.MAA16753@etinc.com> X-Sender: dennis@etinc.com (Unverified) X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: hackers@freebsd.org From: dennis@etinc.com (Dennis) Subject: X.25 netccitt code Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Does anyone know of any code floating around that works with the netccitt interface? Even some simple test modules would be useful. any old docs lying around? Its way too messy to try and figure out from the source. Dennis From owner-freebsd-hackers Mon Sep 9 09:16:39 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA28520 for hackers-outgoing; Mon, 9 Sep 1996 09:16:39 -0700 (PDT) Received: from sequent.kiae.su (sequent.kiae.su [193.125.152.6]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA28509 for ; Mon, 9 Sep 1996 09:16:29 -0700 (PDT) Received: by sequent.kiae.su id AA16929 (5.65.kiae-2 ); Mon, 9 Sep 1996 20:05:35 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 9 Sep 96 20:05:34 +0400 Received: (from ache@localhost) by nagual.ru (8.7.5/8.7.3) id UAA00484; Mon, 9 Sep 1996 20:05:15 +0400 (MSD) Message-Id: <199609091605.UAA00484@nagual.ru> Subject: Re: vx device broken in 21.1.5? In-Reply-To: from "Doug Rabson" at "Sep 9, 96 11:19:12 am" To: dfr@render.com (Doug Rabson) Date: Mon, 9 Sep 1996 20:05:15 +0400 (MSD) Cc: roberto@keltia.freenix.fr, freebsd-hackers@freebsd.org From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (Andrey A. Chernov) Organization: self X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL25 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Has anyone tried the patch? Does it work for you? Does it make things > worse? It not makes things worse, but not help the problem too. My problem was not performance decrease but complete card hang until reboot. -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-hackers Mon Sep 9 09:18:13 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA28661 for hackers-outgoing; Mon, 9 Sep 1996 09:18:13 -0700 (PDT) Received: from sequent.kiae.su (sequent.kiae.su [193.125.152.6]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA28647 for ; Mon, 9 Sep 1996 09:18:04 -0700 (PDT) Received: by sequent.kiae.su id AA16886 (5.65.kiae-2 ); Mon, 9 Sep 1996 20:05:27 +0400 Received: by sequent.KIAE.su (UUMAIL/2.0); Mon, 9 Sep 96 20:05:25 +0400 Received: (from ache@localhost) by nagual.ru (8.7.5/8.7.3) id UAA00469; Mon, 9 Sep 1996 20:04:03 +0400 (MSD) Message-Id: <199609091604.UAA00469@nagual.ru> Subject: Re: vx device broken in 21.1.5? In-Reply-To: <199609091149.NAA24120@gvr.win.tue.nl> from "Guido van Rooij" at "Sep 9, 96 01:49:03 pm" To: guido@gvr.win.tue.nl (Guido van Rooij) Date: Mon, 9 Sep 1996 20:04:02 +0400 (MSD) Cc: dfr@render.com, roberto@keltia.freenix.fr, freebsd-hackers@freebsd.org From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (Andrey A. Chernov) Organization: self X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL25 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > One update on the problem where it dies when youflood ping another machine. > > Basically, I found out that it hangs in OACTIVE mode. Input still works (as > canbe seen by netstat -I). Output is just dead. Yes, I saw it too, with new patch and without it, nothing changed... -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-hackers Mon Sep 9 10:35:52 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA06776 for hackers-outgoing; Mon, 9 Sep 1996 10:35:52 -0700 (PDT) Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA06770 for ; Mon, 9 Sep 1996 10:35:50 -0700 (PDT) Received: (from henrich@localhost) by crh.cl.msu.edu (8.7.5/8.7.3) id NAA02362 for freebsd-hackers@freebsd.org; Mon, 9 Sep 1996 13:35:49 -0400 (EDT) From: Charles Henrich Message-Id: <199609091735.NAA02362@crh.cl.msu.edu> Subject: yylineno ? To: freebsd-hackers@freebsd.org Date: Mon, 9 Sep 1996 13:35:49 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Im mucking with older software to try and get it running, and its using yylineno in lex, however flex doesnt support this variable(?). Anyone have any ideas on what to replace it with? -Crh Charles Henrich Michigan State University henrich@msu.edu http://pilot.msu.edu/~henrich From owner-freebsd-hackers Mon Sep 9 10:47:03 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA07430 for hackers-outgoing; Mon, 9 Sep 1996 10:47:03 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA07423 for ; Mon, 9 Sep 1996 10:47:00 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id DAA23167; Tue, 10 Sep 1996 03:32:44 +1000 Date: Tue, 10 Sep 1996 03:32:44 +1000 From: Bruce Evans Message-Id: <199609091732.DAA23167@godzilla.zeta.org.au> To: freebsd-hackers@FreeBSD.org, j@uriah.heep.sax.de Subject: Re: Support for fixed-scan monitors Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> > Syscons (and pcvt) should start the same device as the BIOS, anyway. > >> Given the quirks of BIOSes, that would have to be the [CEV]GA. I Or mono. >> don't think syscons knows which device is being used by BIOS (please No, but it's easy to decide: using_mono = *(u_short *)0x463 == 0x3b4; >> correct me if I'm wrong here). I haven't checked pcvt. So, I believe >> this is mostly a matter of choice (and not of using what BIOS uses). > >This is a mistake of motherboard and BIOS vendors. There used to be a This is a mistake of console driver authors :-). >jumper on the motherboards back in the old days, denoting the prefered >graphics console. (The BIOSes usually complained if it was set wrong, >i.e. choose a nonexistant adapter.) > >pcvt correctly honors it, but i agree that this feature is now almost >worthless. pcvt actually looks in the CMOS RAM to determine the adaptor that the BIOS is supposed to use. The jumper method was worse, except possibly for bootstrapping the screen/monitor combination. It may be wrong to use the CMOS value because the bootstrap may have changed the mode (I'm not sure of the BIOS changes the CMOS to match the mode). Bruce From owner-freebsd-hackers Mon Sep 9 10:51:28 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA07592 for hackers-outgoing; Mon, 9 Sep 1996 10:51:28 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA07587 for ; Mon, 9 Sep 1996 10:51:26 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id KAA21469; Mon, 9 Sep 1996 10:51:11 -0700 (PDT) To: Charles Henrich cc: freebsd-hackers@FreeBSD.org Subject: Re: yylineno ? In-reply-to: Your message of "Mon, 09 Sep 1996 13:35:49 EDT." <199609091735.NAA02362@crh.cl.msu.edu> Date: Mon, 09 Sep 1996 10:51:11 -0700 Message-ID: <21467.842291471@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Im mucking with older software to try and get it running, and its using > yylineno in lex, however flex doesnt support this variable(?). Anyone have a ny > ideas on what to replace it with? A rule which counts newlines and manipulates a global integer called yylineno has generally been my solution. :-) Jordan From owner-freebsd-hackers Mon Sep 9 10:53:55 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA07716 for hackers-outgoing; Mon, 9 Sep 1996 10:53:55 -0700 (PDT) Received: from guarany.cpd.unb.br (guarany.cpd.unb.br [164.41.2.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA07697 for ; Mon, 9 Sep 1996 10:53:28 -0700 (PDT) Received: from antares.linf.unb.br by guarany.cpd.unb.br (AIX 3.2/UCB 5.64/4.03) id AA64753; Mon, 9 Sep 1996 14:54:46 -0300 Received: from cygnus by antares.linf.unb.br (4.1/SMI-4.1) id AA20513; Mon, 9 Sep 96 14:54:50 WST From: e8917523@antares.linf.unb.br (Daniel C. Sobral) Message-Id: <9609091854.AA20513@antares.linf.unb.br> Subject: Re: hackers-digest V1 #1447 To: hackers@freefall.freebsd.org Date: Mon, 9 Sep 1996 14:57:10 -0400 (WST) In-Reply-To: <199609090112.SAA10873@freefall.freebsd.org> from "owner-hackers-digest@freefall.freebsd.org" at Sep 8, 96 06:12:12 pm Disclaimer: Klaatu Barada Nikto! X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > From: Ivan Pulleyn > Date: Sun, 8 Sep 1996 18:08:53 -0400 (EDT) > Subject: atapi.c > > Hi, > > While attempting to make my el-cheapo ide cdrom work with FreeBSD, I > noticed the following problem with atapi.c. During atapi_probe(), an > atapi_wait() is called before sending an identify request to the device. > This causes a busy timeout if the cdrom is the only device on the controller. > Removing the following lines seemed to fix it for me ( using 2.1.5-RELEASE > sources ). The problem is not so simple... > If other people are having problems with ATAPI cdroms, I suggest trying > this out. Rather, replace atapi.h and atapi.c with the files included in atapi_960816, somewhere (incoming?) at ftp.freebsd.org. This still lefts a known (and fixed) bug, though. -- Daniel C. Sobral (8-DCS) e8917523@linf.unb.br "Master, do we seek victory in contention?" "Seek rather not to contend, for without contention there can be neither victory nor defeat." From owner-freebsd-hackers Mon Sep 9 11:09:01 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA08724 for hackers-outgoing; Mon, 9 Sep 1996 11:09:01 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA08715; Mon, 9 Sep 1996 11:08:56 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id DAA23576; Tue, 10 Sep 1996 03:52:07 +1000 Date: Tue, 10 Sep 1996 03:52:07 +1000 From: Bruce Evans Message-Id: <199609091752.DAA23576@godzilla.zeta.org.au> To: arver@sn.no, bde@zeta.org.au Subject: Re: Support for fixed-scan monitors Cc: Arve.Ronning@alcatel.no, durham@w2xo.pgh.pa.us, freebsd-hackers@freebsd.org, j@uriah.heep.sax.de, sos@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >However, what if the screen used by BIOS is on a monitor which doesn't accept the >default scan rates (my situation) ? During boot, we would not see : >a) the BIOS messages >b) the '>> FreeBSD....Boot:' prompt >In this case, there is little we can do about a) (except perhaps hack the BIOS :(. >But we *can* do something about b) by hacking the bootblocks (which is what I did:). How do you stop the BIOS from blowing up the monitor that doesn't accept normal scan rates? :-). I deleted your mail with the bootblock changes. How does it set to mono mode? Does it just set mode 7? I'm surprised that you can't set the value in the CMOS. Bruce From owner-freebsd-hackers Mon Sep 9 11:14:44 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA09079 for hackers-outgoing; Mon, 9 Sep 1996 11:14:44 -0700 (PDT) Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA09037; Mon, 9 Sep 1996 11:14:36 -0700 (PDT) Received: (from henrich@localhost) by crh.cl.msu.edu (8.7.5/8.7.3) id OAA02906; Mon, 9 Sep 1996 14:14:35 -0400 (EDT) From: Charles Henrich Message-Id: <199609091814.OAA02906@crh.cl.msu.edu> Subject: Grrr. NFS to a Sun (Slowaris 5.5.1) To: freebsd-hackers@freebsd.org, freebsd-bugs@freebsd.org, freebsd-current@freebsd.org Date: Mon, 9 Sep 1996 14:14:35 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Okay, I'm having a horrendous time on 960801-SNAP to a Sparc E6000 NFS server. About every 6mb of transfers its as though some packets were eaten, and it locks up the entire NFS side of my machine (damnit), and it takes about 60 seconds, when things click back in. Then another 5mb or so later click same thing, ad nausem. Anyone else having any problems with NFS clients on 0801 ? Its been my impression that the NFS on FreeBSD went really downhill between 0612 and 0801 ... I've been having all sorts of annoying pauses and glitches to a RS/6000 as well, but nothing nearly as bad as to the sparc. Hints anyone? -Crh Charles Henrich Michigan State University henrich@msu.edu http://pilot.msu.edu/~henrich From owner-freebsd-hackers Mon Sep 9 11:31:19 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA09883 for hackers-outgoing; Mon, 9 Sep 1996 11:31:19 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA09878 for ; Mon, 9 Sep 1996 11:31:16 -0700 (PDT) Received: (from jkh@localhost) by time.cdrom.com (8.7.5/8.6.9) id LAA01925 for hackers@freebsd.org; Mon, 9 Sep 1996 11:31:04 -0700 (PDT) Date: Mon, 9 Sep 1996 11:31:04 -0700 (PDT) From: "Jordan K. Hubbard" Message-Id: <199609091831.LAA01925@time.cdrom.com> To: hackers@freebsd.org Subject: /usr/src/gnu/usr.bin/ld/rtld/Makefile Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The realinstall rule looks kind of funky - why make that first test -f case do the ||, for example, and why not wrap the chflags and ln commands that follow behind tests of their own so that the commands don't simply fail? Ignored or not, their failure catches my attention in the logs every time I do a make release. If nobody objects, I'll clean it up. Jordan From owner-freebsd-hackers Mon Sep 9 11:56:13 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA11382 for hackers-outgoing; Mon, 9 Sep 1996 11:56:13 -0700 (PDT) Received: from scruz.net (nic.scruz.net [165.227.1.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA11370 for ; Mon, 9 Sep 1996 11:56:09 -0700 (PDT) Received: from osprey.grizzly.com by scruz.net (8.7.3/1.34) id LAA06148; Mon, 9 Sep 1996 11:56:03 -0700 (PDT) Received: (from markd@localhost) by osprey.grizzly.com (8.7.5/8.7.3) id LAA01130; Mon, 9 Sep 1996 11:56:30 -0700 (PDT) Date: Mon, 9 Sep 1996 11:56:30 -0700 (PDT) Message-Id: <199609091856.LAA01130@osprey.grizzly.com> From: Mark Diekhans To: henrich@crh.cl.msu.edu CC: freebsd-hackers@FreeBSD.org In-reply-to: <199609091735.NAA02362@crh.cl.msu.edu> (message from Charles Henrich on Mon, 9 Sep 1996 13:35:49 -0400 (EDT)) Subject: Re: yylineno ? Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >Im mucking with older software to try and get it running, and its using >yylineno in lex, however flex doesnt support this variable(?). Anyone have any >ideas on what to replace it with? adding %option yylineno will enable yylineno compatiblity (at least in version 2.5.3). From owner-freebsd-hackers Mon Sep 9 12:49:54 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA14937 for hackers-outgoing; Mon, 9 Sep 1996 12:49:54 -0700 (PDT) Received: from hemi.com (hemi.com [204.132.158.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA14932 for ; Mon, 9 Sep 1996 12:49:52 -0700 (PDT) Received: (from mbarkah@localhost) by hemi.com (8.7.5/8.7.3) id NAA09770 for hackers@freebsd.org; Mon, 9 Sep 1996 13:49:49 -0600 (MDT) From: Ade Barkah Message-Id: <199609091949.NAA09770@hemi.com> Subject: Using 2.1.5's gethostbydns in 2.1-R, any problems ? To: hackers@freebsd.org Date: Mon, 9 Sep 1996 13:49:48 -0600 (MDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, Will I have complications if I simply copy 2.1.5's gethostbydns (/usr/src/lib/libc/net/gethostbydns.c) to my 2.1-RELEASE machine to fix some old bugs ? Thanks for any ideas, -Ade ------------------------------------------------------------------- Inet: mbarkah@hemi.com - HEMISPHERE ONLINE - ------------------------------------------------------------------- From owner-freebsd-hackers Mon Sep 9 13:12:01 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA16291 for hackers-outgoing; Mon, 9 Sep 1996 13:12:01 -0700 (PDT) Received: from megazone.bigpanda.com (hac-nj1-15.ix.netcom.com [206.214.115.47]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA16277 for ; Mon, 9 Sep 1996 13:11:53 -0700 (PDT) Received: from localhost.bigpanda.com (localhost.bigpanda.com [127.0.0.1]) by megazone.bigpanda.com (8.7.5/8.6.12) with SMTP id QAA02289 for ; Mon, 9 Sep 1996 16:10:11 -0400 (EDT) Message-Id: <199609092010.QAA02289@megazone.bigpanda.com> X-Authentication-Warning: megazone.bigpanda.com: Host localhost.bigpanda.com [127.0.0.1] didn't use HELO protocol X-Mailer: exmh version 1.6.7 5/3/96 To: hackers@freebsd.org From: Richard Hwang Reply-to: Richard Hwang Subject: rebuilding trashed disklabel Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 09 Sep 1996 16:10:11 -0400 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have a drive here (western digital 32500 2.5G ide) on a Dell P6 system with 80M RAM which had FreeBSD on it. (The whole drive was allocated to FreeBSD; no multiple boot to other operating systems.) When I rebooted the system, it failed to boot, claiming that I should insert bootable media. When I checked out the disklabel, it looked something like this: [...] 1 partition: # size offset fstype [fsize bsize bps/cpg] c: 65536 0 4.2BSD 0 0 0 # (Cyl. 0 - 31) I figured that all I had to do was to rebuild the disklabel, and then I'd get the entire drive back, since the data is probably still there (unless it decided to follow the disklabel into oblivion). The problem is that I don't know the sizes of the partitions. Here is what I do know: wd0a / 32M wd0b swap ?M (probably between 80M - 256M?) wd0e /var ?M wd0f /tmp ?M wd0g /usr ?M I was able to recover wd0a successfully by defining wd0a. I have a perl script which adjusts the partition offsets, writes the disklabel, and tries to mount the partition, but realized that it would take forever to finish. Is there some easier way to restore the other partitions? -Rich -- Richard Hwang rhwang@io.com From owner-freebsd-hackers Mon Sep 9 14:36:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA21507 for hackers-outgoing; Mon, 9 Sep 1996 14:36:35 -0700 (PDT) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA21495 for ; Mon, 9 Sep 1996 14:36:31 -0700 (PDT) Message-Id: <199609092136.OAA21495@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA296844978; Tue, 10 Sep 1996 07:36:18 +1000 From: Darren Reed Subject: Re: rebuilding trashed disklabel To: rhwang@mail.io.com Date: Tue, 10 Sep 1996 07:36:18 +1000 (EST) Cc: hackers@freebsd.org In-Reply-To: <199609092010.QAA02289@megazone.bigpanda.com> from "Richard Hwang" at Sep 9, 96 04:10:11 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Richard Hwang, sie said: > > I have a drive here (western digital 32500 2.5G ide) on a Dell P6 system with > 80M RAM which had FreeBSD on it. (The whole drive was allocated to FreeBSD; > no multiple boot to other operating systems.) When I rebooted the system, it > failed to boot, claiming that I should insert bootable media. When I checked > out the disklabel, it looked something like this: [...] > I was able to recover wd0a successfully by defining wd0a. I have a perl > script which adjusts the partition offsets, writes the disklabel, and tries > to mount the partition, but realized that it would take forever to finish. > > Is there some easier way to restore the other partitions? I wrote a program to find and print superblocks on raw partitions for SunOS4 when I did the exact same thing to my boot drive. I'll see if I can find it around, but meantime that might give you enough to start with. Darren From owner-freebsd-hackers Mon Sep 9 15:29:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA25588 for hackers-outgoing; Mon, 9 Sep 1996 15:29:07 -0700 (PDT) Received: from yangtze.cs.UMD.EDU (yangtze.cs.umd.edu [128.8.128.118]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA25577 for ; Mon, 9 Sep 1996 15:29:02 -0700 (PDT) Received: by yangtze.cs.UMD.EDU (8.7.5/UMIACS-0.9/04-05-88) id SAA01670; Mon, 9 Sep 1996 18:29:00 -0400 (EDT) From: fwmiller@cs.UMD.EDU (Frank W. Miller) Message-Id: <199609092229.SAA01670@yangtze.cs.UMD.EDU> Subject: kernel performance To: freebsd-hackers@FreeBSD.ORG Date: Mon, 9 Sep 1996 18:29:00 -0400 (EDT) Cc: fwmiller@cs.UMD.EDU (Frank W. Miller) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk For lack of a better place to start, I chose this mailing list. I am curious if there are any performance monitoring facilities built into the kernel. In particular, I am interested in obtaining timings of the execution of the read() and write() system calls. I want to break the measurements down according to how much time is spent in various areas of the kernel code, how much is spent waiting for I/O device hardware, etc. Any pointers would be helpful. Later, FM -- Frank W. Miller Department of Computer Science fwmiller@cs.umd.edu University of Maryland, College Park http://www.cs.umd.edu/~fwmiller College Park, Maryland 20742 From owner-freebsd-hackers Mon Sep 9 17:12:48 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA00396 for hackers-outgoing; Mon, 9 Sep 1996 17:12:48 -0700 (PDT) Received: from w2xo.pgh.pa.us (w2xo.pgh.pa.us [206.210.70.5]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA00382 for ; Mon, 9 Sep 1996 17:12:36 -0700 (PDT) Received: (from durham@localhost) by w2xo.pgh.pa.us (8.6.12/8.6.9) id UAA04548; Mon, 9 Sep 1996 20:11:31 -0400 Date: Mon, 9 Sep 1996 20:11:31 -0400 (EDT) From: Jim Durham X-Sender: durham@w2xo.pgh.pa.us To: Chuck Robey cc: hackers@freebsd.org Subject: Re: NOSHARED In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 9 Sep 1996, Chuck Robey wrote: > On Sun, 8 Sep 1996, Jim Durham wrote: > > > Could someone point out to me where the variable NOSHARED is being > > set in the 2.1 source tree? > > It's in share/mk/bsd.prog.mk. Well, I mean to say, it's used there, and > if you want, you could define it in your etc/make.conf, or on the command > line when you make world. I sure wouldn't advise you to do that. I > forces things to be built nonshared (no dynamic linking), so all the > binaries get extremely bloated in size, and take a much longer time to > startup. I replied to this to another person and neglected to cc: hackers. So, let me explain. I was compiling a hacked copy of slattach.c. I noticed the binary was huge and figured out that it was being linked statically. Being of a curious mind, I decided to investigate and found the place in bsd.prog.mk where it was tested to control whether or not shared libs are used. What bothered me at that point was why the original binary was linked to use shared libs and the /usr/src/sbin/slattach directory's Makefile caused slattach to be statically linked when I made it? If the binary that came with the dist was dynamically linked, why was my new compile static? I then went looking for where NOSHARED was set. I figured it had to be in /usr/src/sbin/slattach's Makefile. No dice. I even looked at /usr/src and usr/src/sbin Makefiles. No dice. That is what prompted the question. Maybe it's because the distribution was trimmed by picking and choosing what binaries to make dynamic to save space in the distribution and the source tree just makes them all static to simplify things? If so, my question remains.. where the heck is it set to YES or TRUE? Just curious.. regards, -Jim Durham From owner-freebsd-hackers Mon Sep 9 17:14:16 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA00459 for hackers-outgoing; Mon, 9 Sep 1996 17:14:16 -0700 (PDT) Received: from diablo.ppp.de (diablo.ppp.de [193.141.101.34]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA00449 for ; Mon, 9 Sep 1996 17:14:11 -0700 (PDT) Received: by diablo.ppp.de (Smail3.1.28.1 #1) id m0v0GSf-000QhGC; Tue, 10 Sep 96 02:13 MET DST Received: from 193.141.161.123 (monster.pong.ppp.de [193.141.161.123]) by pong.PPP.DE (8.6.12/8.6.12) with SMTP id CAA07282; Tue, 10 Sep 1996 02:10:41 +0200 Message-ID: <3234B1E8.605F@pong.ppp.de> Date: Tue, 10 Sep 1996 02:10:16 +0200 From: Stefan Bethke Organization: Not very well... X-Mailer: Mozilla 2.02 (Macintosh; I; 68K) MIME-Version: 1.0 To: freebsd-hackers CC: "Sean P. Robertson" , Julian Elischer , "Christoph P. Kukulies" , Gary Jennejohn Subject: Re: FTP Mirror HOW-TO References: <3232317A.41C67EA6@awod.com> <323370CF.5616@pong.ppp.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk http://www.promo.de/people/stefan/cwftp/ http://www.promo.de/pub/people/stefan/cwftp/ ftp://ftp.promo.de/pub/people/stefan/cwftp/ Sorry, seemed a bit late that night... From owner-freebsd-hackers Mon Sep 9 17:25:23 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA00816 for hackers-outgoing; Mon, 9 Sep 1996 17:25:23 -0700 (PDT) Received: from po1.glue.umd.edu (po1.glue.umd.edu [129.2.128.44]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA00811 for ; Mon, 9 Sep 1996 17:25:21 -0700 (PDT) Received: from modem.eng.umd.edu (modem.eng.umd.edu [129.2.98.187]) by po1.glue.umd.edu (8.8.Beta.0/8.7.3) with ESMTP id UAA07931; Mon, 9 Sep 1996 20:25:15 -0400 (EDT) Received: from localhost (chuckr@localhost) by modem.eng.umd.edu (8.7.5/8.7.3) with SMTP id UAA01517; Mon, 9 Sep 1996 20:25:14 -0400 (EDT) X-Authentication-Warning: modem.eng.umd.edu: chuckr owned process doing -bs Date: Mon, 9 Sep 1996 20:25:14 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@modem.eng.umd.edu To: Jim Durham cc: hackers@freebsd.org Subject: Re: NOSHARED In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 9 Sep 1996, Jim Durham wrote: > I replied to this to another person and neglected to cc: hackers. > So, let me explain. > > I was compiling a hacked copy of slattach.c. I noticed the binary > was huge and figured out that it was being linked statically. > > Being of a curious mind, I decided to investigate and found the > place in bsd.prog.mk where it was tested to control whether or not > shared libs are used. > > What bothered me at that point was why the original binary was linked > to use shared libs and the /usr/src/sbin/slattach directory's Makefile > caused slattach to be statically linked when I made it? If the binary that > came with the dist was dynamically linked, why was my new compile static? > > I then went looking for where NOSHARED was set. I figured it had > to be in /usr/src/sbin/slattach's Makefile. No dice. I even looked at > /usr/src and usr/src/sbin Makefiles. No dice. > > That is what prompted the question. Maybe it's because the distribution > was trimmed by picking and choosing what binaries to make dynamic to save > space in the distribution and the source tree just makes them all static > to simplify things? > > If so, my question remains.. where the heck is it set to YES or TRUE? > Just curious.. Makefile.inc in sbin. Causes all the binaries in sbin to be statically compiled, but I went into that in the previous mail. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and n3lxx, both FreeBSD (301) 220-2114 | version 2.2 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Mon Sep 9 17:31:32 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA00988 for hackers-outgoing; Mon, 9 Sep 1996 17:31:32 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA00983 for ; Mon, 9 Sep 1996 17:31:28 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id AAA01296; Tue, 10 Sep 1996 00:30:50 GMT Date: Tue, 10 Sep 1996 09:30:49 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: hackers@freebsd.org Subject: Re: namei performance (was Re: FreeBSD vs. Linux 96 (my impressions)) In-Reply-To: <199609082205.PAA03751@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 8 Sep 1996, Terry Lambert wrote: > Like I said in my previous posting, I think that cache locality in the > component name cache would more than make up for this. > > There is also the issue of multibyte support at the FS level, if you > want to get technical about it. If the path seperator is literal, then > each FS which wants to eat components will have to have an understanding > of seperator processing, etc. This has the unfortunate side effect of > locking you into a single path representation geometry. > > This fails for VFAT/VFAT32/HPFS/NTFS, all of which have "long names" > and 8.3 names for each file. For the Mac FS, it fails because of the > 32 character "short" Mac file name and the ProDOS name on each file, > and for the fact that the seperator character in the file name and out > is a null, not a '/' (you can hide this difference by translating > between '/' and ':' in the UNIX stored name for Mac clients of the FS). > I like the pre-parsing of the pathname into components idea for all these reasons. Freeing the code from delimiter processing is definitely a win. I also think the component list can be processed up to mount point by the underlying filesystem-dependent layer. The name cache is a central resource available to all file systems. It isn't necessary to have the processing go through the abstraction and the name cache can still be primed by component. Regards, Mike Hancock From owner-freebsd-hackers Mon Sep 9 17:52:47 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA02389 for hackers-outgoing; Mon, 9 Sep 1996 17:52:47 -0700 (PDT) Received: from cornus.FSL.ORST.EDU (root@FSL.ORST.EDU [128.193.112.105]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA02381 for ; Mon, 9 Sep 1996 17:52:40 -0700 (PDT) Received: from vaccinium.ORST.EDU (vaccinium.FSL.ORST.EDU [128.193.112.180]) by cornus.FSL.ORST.EDU (8.6.9/8.6.9) with ESMTP id RAA22791; Mon, 9 Sep 1996 17:52:33 -0700 Received: by vaccinium.ORST.EDU (SMI-8.6/SMI-SVR4) id RAA09684; Mon, 9 Sep 1996 17:59:40 -0700 Date: Mon, 9 Sep 1996 17:59:39 -0700 (PDT) From: Tai Hsu To: Chuck Robey cc: Jim Durham , hackers@freebsd.org Subject: Re: NOSHARED In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk How can I unsubscribe this e-mail FAQ? Thanks, Tai On Mon, 9 Sep 1996, Chuck Robey wrote: > On Mon, 9 Sep 1996, Jim Durham wrote: > > > I replied to this to another person and neglected to cc: hackers. > > So, let me explain. > > > > I was compiling a hacked copy of slattach.c. I noticed the binary > > was huge and figured out that it was being linked statically. > > > > Being of a curious mind, I decided to investigate and found the > > place in bsd.prog.mk where it was tested to control whether or not > > shared libs are used. > > > > What bothered me at that point was why the original binary was linked > > to use shared libs and the /usr/src/sbin/slattach directory's Makefile > > caused slattach to be statically linked when I made it? If the binary that > > came with the dist was dynamically linked, why was my new compile static? > > > > I then went looking for where NOSHARED was set. I figured it had > > to be in /usr/src/sbin/slattach's Makefile. No dice. I even looked at > > /usr/src and usr/src/sbin Makefiles. No dice. > > > > That is what prompted the question. Maybe it's because the distribution > > was trimmed by picking and choosing what binaries to make dynamic to save > > space in the distribution and the source tree just makes them all static > > to simplify things? > > > > If so, my question remains.. where the heck is it set to YES or TRUE? > > Just curious.. > > Makefile.inc in sbin. Causes all the binaries in sbin to be statically > compiled, but I went into that in the previous mail. > > ----------------------------+----------------------------------------------- > Chuck Robey | Interests include any kind of voice or data > chuckr@eng.umd.edu | communications topic, C programming, and Unix. > 9120 Edmonston Ct #302 | > Greenbelt, MD 20770 | I run Journey2 and n3lxx, both FreeBSD > (301) 220-2114 | version 2.2 current -- and great FUN! > ----------------------------+----------------------------------------------- > > From owner-freebsd-hackers Mon Sep 9 18:03:00 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA02923 for hackers-outgoing; Mon, 9 Sep 1996 18:03:00 -0700 (PDT) Received: from cornus.FSL.ORST.EDU (root@FSL.ORST.EDU [128.193.112.105]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA02915 for ; Mon, 9 Sep 1996 18:02:57 -0700 (PDT) Received: from vaccinium.ORST.EDU (vaccinium.FSL.ORST.EDU [128.193.112.180]) by cornus.FSL.ORST.EDU (8.6.9/8.6.9) with ESMTP id SAA23166; Mon, 9 Sep 1996 18:02:55 -0700 Received: by vaccinium.ORST.EDU (SMI-8.6/SMI-SVR4) id SAA09710; Mon, 9 Sep 1996 18:10:01 -0700 Date: Mon, 9 Sep 1996 18:09:59 -0700 (PDT) From: Tai Hsu To: hackers@freebsd.org cc: Tai Hsu Subject: unsubscribe Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk From owner-freebsd-hackers Mon Sep 9 18:27:16 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA03917 for hackers-outgoing; Mon, 9 Sep 1996 18:27:16 -0700 (PDT) Received: from alpo.whistle.com (s205m1.whistle.com [207.76.205.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA03906 for ; Mon, 9 Sep 1996 18:27:11 -0700 (PDT) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.7.5/8.7.3) with SMTP id SAA09479 for ; Mon, 9 Sep 1996 18:20:46 -0700 (PDT) Message-ID: <3234C21F.1CFBAE39@whistle.com> Date: Mon, 09 Sep 1996 18:19:27 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0b6 (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: hackers@freebsd.org Subject: [Fwd: "lost" software package] Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Message-ID: <3234957A.59E2B600@whistle.com> Date: Mon, 09 Sep 1996 15:08:58 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0b6 (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: hackers@freesdb.org Subject: "lost" software package Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Once upon a time, I pulled a file from oine of the ports/packages/incoming directories (or somewhere) that ran as a frontend to gdb (I think) and graphed out what variable pointed to what variables etc.. very useful for documanting the 'state' of a system in graphical form.. has anyone got a clue what it was and how I get it again? thanks... julian From owner-freebsd-hackers Mon Sep 9 20:10:22 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA09114 for hackers-outgoing; Mon, 9 Sep 1996 20:10:22 -0700 (PDT) Received: from bonsai.hiwaay.net (max7-116.HiWAAY.net [206.104.17.116]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA09106 for ; Mon, 9 Sep 1996 20:10:14 -0700 (PDT) Received: (from steve@localhost) by bonsai.hiwaay.net (8.7.5/8.6.12) id WAA12875; Mon, 9 Sep 1996 22:06:10 -0500 (CDT) Date: Mon, 9 Sep 1996 22:06:10 -0500 (CDT) Message-Id: <199609100306.WAA12875@bonsai.hiwaay.net> From: Steve Price To: roberte@ghost.mep.ruhr-uni-bochum.de CC: henrich@crh.cl.msu.edu, hackers@freebsd.org Subject: Re: bin/1590: AT time parsing broken Reply-to: sprice@hiwaay.net Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Robert Eckardt wrote: # # The following reply was made to PR bin/1590; it has been noted by GNATS. # # From: Robert Eckardt # To: henrich@msu.edu # Cc: FreeBSD-gnats-submit@freebsd.org # Subject: Re: bin/1590: AT time parsing broken # Date: Tue, 10 Sep 1996 02:48:22 +0200 (MET DST) # # > FreeBSD 2.2-960801-SNAP # [..] # > 1:22pm crh> at 1pm tommorow # > at: Trying to travel back in time # # Have you tried `at 1pm tomorrow' instead ? # ~~~ # I tried it on 2.1.5-R: # # 2:45 ghost: /home/re 1% at 2am tommorow # at: Trying to travel back in time # 2:45 ghost: /home/re 1% at 2am tomorrow # _ # # # Robert You saw that too. :) at(1) seems to ignore the command line after the time arguments (at least sometimes). IMHO, an invalid keyword should be treated as such. In light of my opinion, I suggest the following patch. Oh yeah, I threw in a gratiutous spelling correction to boot. :) Steve Index: parsetime.c =================================================================== RCS file: /u/FreeBSD/cvs/src/usr.bin/at/parsetime.c,v retrieving revision 1.7 diff -u -r1.7 parsetime.c --- parsetime.c 1996/07/19 00:44:55 1.7 +++ parsetime.c 1996/09/10 02:55:31 @@ -149,7 +149,8 @@ } /* not special - must be some random id */ - return ID; + panic("garbled time"); + return ID; /* NOTREACHED */ } /* parse_token */ @@ -357,7 +358,7 @@ else if (tlen == 4) { minute = hour%100; if (minute > 59) - panic("garbeld time"); + panic("garbled time"); hour = hour/100; } From owner-freebsd-hackers Mon Sep 9 20:33:20 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA10034 for hackers-outgoing; Mon, 9 Sep 1996 20:33:20 -0700 (PDT) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA10020 for ; Mon, 9 Sep 1996 20:33:13 -0700 (PDT) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id XAA04929; Mon, 9 Sep 1996 23:32:35 -0400 From: Bill Paul Message-Id: <199609100332.XAA04929@skynet.ctr.columbia.edu> Subject: Re: [Fwd: "lost" software package] To: julian@whistle.com (Julian Elischer) Date: Mon, 9 Sep 1996 23:32:34 -0400 (EDT) Cc: hackers@freebsd.org In-Reply-To: <3234C21F.1CFBAE39@whistle.com> from "Julian Elischer" at Sep 9, 96 06:19:27 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Of all the gin joints in all the towns in all the world, Julian Elischer had to walk into mine and say: > > X-Mailer: Mozilla 3.0b6 (X11; I; FreeBSD 2.2-CURRENT i386) Rrrrr...... I hate it when people send mail with netscrape. But anyway. > Once upon a time, > I pulled a file from oine of the ports/packages/incoming > directories > (or somewhere) > that ran as a frontend to gdb (I think) > and graphed out what variable pointed to what variables etc.. > very useful for documanting the 'state' of a system in graphical form.. > has anyone got a clue what it was > and how I get it again? > > thanks... julian This sounds like ddd. It is a front end to gdb, and it does graphing of variables. Unfortunately, it requires Motif. It's also written in C++ and can be a little tricky to build (don't use -O2 optimization with gcc 2.6.3 or the resulting binary will blow up rather quickly). I played with it briefly. I had two complaints about it: 1) since it uses Motif and is written in C++, it's a bit of a memory pig and 2) since I tend to do most of my coding from a dumb terminal, graphical debuggers don't tend do to me a whole lot of good. (Hey: the terminal's next to the couch and the console's way over by the window, okay?) You should be able to find the source with archie. Someone somewhere should have a binary for FreeBSD. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "If you're ever in trouble, go to the CTR. Ask for Bill. He will help you." ============================================================================= From owner-freebsd-hackers Mon Sep 9 20:37:13 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA10207 for hackers-outgoing; Mon, 9 Sep 1996 20:37:13 -0700 (PDT) Received: from rosemary.fsl.noaa.gov (rosemary.fsl.noaa.gov [137.75.8.41]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA10202 for ; Mon, 9 Sep 1996 20:37:07 -0700 (PDT) Received: from rosemary.fsl.noaa.gov (localhost [127.0.0.1]) by rosemary.fsl.noaa.gov (8.7.5/8.6.9) with SMTP id VAA00416; Mon, 9 Sep 1996 21:36:52 -0600 (MDT) Message-ID: <3234E253.41C67EA6@fsl.noaa.gov> Date: Mon, 09 Sep 1996 21:36:52 -0600 From: Sean Kelly Organization: NOAA Forecast Systems Laboratory X-Mailer: Mozilla 3.0b6Gold (X11; I; FreeBSD 2.1.5-RELEASE i386) MIME-Version: 1.0 To: Mattias Pantzare CC: hackers@freebsd.org Subject: Typing URLs (was Re: FTP Mirror HOW-TO) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Mattias testified: > Hm, maybe a computer name in the URLs? :-) They won't work like that... > [without a hostname] Actually, some do, at least with Netscrape. Try these URLs: microsoft ibm mci That's right: you don't need http://, www., or even .com/. Netscrape assumes all that. Heck, even freebsd works to get to the FreeBSD home page (since www.freebsd.{com,org}) are the same host. A few more curiosities ... freebsd.com is FreeBSD, Inc (FREEBSD2-DOM) 246 Park St. Clyde, CA 94520 whereas freebsd.org is The FreeBSD Project (FREEBSD-DOM) 839 S.E. 209th Ave. Gresham, OR 97030-2235 Not that it really matters these days. -- Sean Kelly NOAA Forecast Systems Laboratory Boulder Colorado USA From owner-freebsd-hackers Mon Sep 9 22:24:21 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA15446 for hackers-outgoing; Mon, 9 Sep 1996 22:24:21 -0700 (PDT) Received: from mx.serv.net (mx.serv.net [199.201.191.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA15422 for ; Mon, 9 Sep 1996 22:24:16 -0700 (PDT) Received: from MindBender.serv.net by mx.serv.net (8.7.5/SERV Revision: 2.30 † id WAA16784; Mon, 9 Sep 1996 22:24:22 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.serv.net (8.7.5/8.7.3) with SMTP id WAA12504 for ; Mon, 9 Sep 1996 22:19:43 -0700 (PDT) Message-Id: <199609100519.WAA12504@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: freebsd-hackers@freebsd.org Subject: Anyone using SuperMicro P6? Date: Mon, 09 Sep 1996 22:19:43 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Anyone running FreeBSD on a SuperMicro P6 motherboard? Specifically I'm interested in the P6DNF or P6SNF. Please email if you have it working. Thanks. ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@MindBender.serv.net --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... ----------------------------------------------------------------------------- From owner-freebsd-hackers Tue Sep 10 00:36:57 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA24816 for hackers-outgoing; Tue, 10 Sep 1996 00:36:57 -0700 (PDT) Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA24806 for ; Tue, 10 Sep 1996 00:36:43 -0700 (PDT) Received: from sol1.gud.siemens.co.at (root@firix [10.1.143.100]) by zwei.siemens.at (8.7.4/8.7.3) with SMTP id JAA07672 for ; Tue, 10 Sep 1996 09:35:18 +0200 (MET DST) Received: from ws2301.gud.siemens.co.at by sol1.gud.siemens.co.at with smtp (Smail3.1.28.1 #7 for ) id m0v0NMR-00021oC; Tue, 10 Sep 96 09:35 MET DST Received: by ws2301.gud.siemens.co.at (1.37.109.16/1.37) id AA154740690; Tue, 10 Sep 1996 09:31:30 +0200 From: "Hr.Ladavac" Message-Id: <199609100731.AA154740690@ws2301.gud.siemens.co.at> Subject: Re: yylineno ? To: markd@Grizzly.COM (Mark Diekhans) Date: Tue, 10 Sep 1996 09:31:29 +0200 (MESZ) Cc: henrich@crh.cl.msu.edu, freebsd-hackers@FreeBSD.org In-Reply-To: <199609091856.LAA01130@osprey.grizzly.com> from "Mark Diekhans" at Sep 9, 96 11:56:30 am X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk E-mail message from Mark Diekhans contained: > > >Im mucking with older software to try and get it running, and its using > >yylineno in lex, however flex doesnt support this variable(?). Anyone have any > >ideas on what to replace it with? > > adding > > %option yylineno > > will enable yylineno compatiblity (at least in version 2.5.3). and lex -l will turn on this compatibility option even on flex which is delivered with FreeBSD. RTFM, please. /Marino > From owner-freebsd-hackers Tue Sep 10 00:39:14 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA24932 for hackers-outgoing; Tue, 10 Sep 1996 00:39:14 -0700 (PDT) Received: from srv1-bsb.GNS.com.br ([200.239.56.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA24927 for ; Tue, 10 Sep 1996 00:39:11 -0700 (PDT) Received: (from mail@localhost) by srv1-bsb.GNS.com.br (8.7.5/8.7.5) id EAA19760; Tue, 10 Sep 1996 04:38:44 -0300 (EST) Received: from dl0100-bsb.gns.com.br(200.239.56.100) by srv1-bsb.GNS.com.br via smap (V1.3) id sma019732; Tue Sep 10 04:38:13 1996 Received: by DANIEL.sobral (IBM OS/2 SENDMAIL VERSION 1.3.14/2.12um) id AA0141; Tue, 10 Sep 96 04:35:54 +0300 Message-Id: <9609100135.AA0141@DANIEL.sobral> Date: Tue, 10 Sep 96 4:35:53 +0300 From: "Daniel C. Sobral" Subject: iname() To: hackers@freefall.freebsd.org Reply-To: e8917523@linf.unb.br In-Reply-To: <199609100052.RAA02399@freefall.freebsd.org> from "owner-hackers-digest@freefall.freebsd.org" at Sep 9 96 5:52 pm X-Disclaimer: Klaatu Barada Nikto! X-Mailer: ELM [version 2.3 PL11] for OS/2 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > On Sun, 8 Sep 1996, Terry Lambert wrote: > > > This fails for VFAT/VFAT32/HPFS/NTFS, all of which have "long names" > > and 8.3 names for each file. For the Mac FS, it fails because of the Err... This does not seem to be the case for HPFS. At least, OS/2 makes names that don't fall into 8.3 convention invisible to DOS sessions and can't even copy those files to FAT (you have to provide a new, acceptable, name). Of course, not knowing the internals of OS/2, it may be just that IBM is too stupid to provide a useful resource already coded into the system available to its users... :-) -- Daniel C. Sobral (8-DCS) dcs@gns.com.br e8917523@linf.unb.br From owner-freebsd-hackers Tue Sep 10 01:42:14 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA01047 for hackers-outgoing; Tue, 10 Sep 1996 01:42:14 -0700 (PDT) Received: from ns.pa-consulting.com (ns.pa-consulting.com [193.118.224.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA01042 for ; Tue, 10 Sep 1996 01:42:09 -0700 (PDT) Received: from SMTPGATE.PA-CONSULTING.COM by ns.pa-consulting.com (8.6.4) id JAA00457; Tue, 10 Sep 1996 09:52:05 +0100 Received: by SMTPGATE.PA-CONSULTING.COM with Microsoft Mail id <32359D17@SMTPGATE.PA-CONSULTING.COM>; Tue, 10 Sep 96 09:53:43 PDT From: Duncan Barclay To: freebsd-hackers Subject: undocumented kernel priority changing Date: Tue, 10 Sep 96 09:41:00 PDT Message-ID: <32359D17@SMTPGATE.PA-CONSULTING.COM> Encoding: 36 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Does anyone know why the following is not documented (either in the nice, renice, or getrlimit pages, and not in the 4.4 "daemon" book) in kern_synch.c (2.1.0R, havent had time to put on 2.1.5R) mi_switch() ... /* * Check if the process exceeds its cpu resource allocation. * If over max, kill it. In any case, if it has run for more * than 10 minutes, reduce priority to give others a chance. */ ... if (s > 10 * 60 && p->p_ucred->cr_uid && p->p_nice == NZERO) { p->p_nice = NZERO + 4; resetpriority(p); } ... It took me a while to figure out what was nicing my processes (would you believe it, one was an editor!). Whilst I acknowledge that a lot of people wont see this happening it is rather annoying to have it and it being not documented (unlesws I missed it). Shoot me if you will but a couple of config options may not go amiss, at least for single/few user sites. I will plonk them in sometime soon. Cheers Duncan Barclay  From owner-freebsd-hackers Tue Sep 10 01:42:16 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA01060 for hackers-outgoing; Tue, 10 Sep 1996 01:42:16 -0700 (PDT) Received: from ns.pa-consulting.com (ns.pa-consulting.com [193.118.224.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA01041 for ; Tue, 10 Sep 1996 01:42:08 -0700 (PDT) Received: from SMTPGATE.PA-CONSULTING.COM by ns.pa-consulting.com (8.6.4) id JAA00454; Tue, 10 Sep 1996 09:52:02 +0100 Received: by SMTPGATE.PA-CONSULTING.COM with Microsoft Mail id <32359D14@SMTPGATE.PA-CONSULTING.COM>; Tue, 10 Sep 96 09:53:40 PDT From: Duncan Barclay To: freebsd-hackers Subject: FW: ft0 doesn't work with new motherboard Date: Tue, 10 Sep 96 09:41:00 PDT Message-ID: <32359D14@SMTPGATE.PA-CONSULTING.COM> Encoding: 293 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ---------- From: Duncan Barclay To: owner-freebsd-hackers Subject: RE: ft0 doesn't work with new motherboard Date: 09 September 1996 09:13 >Hi all, >Some month ago I upgraded to a Pentium motherboard for my FreeBSD system. >Prior to that change I had been using a Conner floppy tape drive with some >success. After the upgrade ft0 refuses to be recognized, originally I >thought the drive had been damaged in the swap and I took it back to the >store - imagine my embarrasment when the vendor said that it was working >fine, sure enough when I hooked it up and used DOS then the drive is >recognized OK.... FreeBSD is however a different story. >I played around with ft.c to try and dig some more info out, defining >DPRT gives me the following messages at boot. (I also forced a call to >ftreq_hwinfo , thus my comments about a hack...) I think I had a similar problem on my Connor drive. I managed to track the problem down to the seek code bit of the state machine. The time outs dont seem to be long enough for tapes with lots of tracks. My drive worked fine for tracks 0...6 but took longer to seek than the time out in the code. As you have gone a bit faster I guess the spin loops are shorter? The main problem is that the retry code for this event is a bit broken, ie. it doesnt retry! The following is some comments I posted (and sent to bugs using send-pr) a while back. All the diffs refer to 2.1R, but it hasnt changed in 2.1.5R so should work. Duncan After a while the machine appeared to hang (I was in single user mode at the time, however later tests shows the process to be waiting on bdone). As I had hacked /sbin/ft to print the segment number I continued to play a little seeking the tape to that segment and kept getting the hangs. Eventually I discovered that the drive took a little longer than the code waits for to respond when it moves the head a few tracks. Specifics: ACMD_BLOCKIO (or similar) calls ACMD_READID to find out where the head is. ACMD_READID issues read id commands to the drive. If the first read id command returns garbage then ACMD_READID then calls ACMD_SEEKSTS to stop the tape moving. ACMD_SEEKSTS waits for the tape to stop and to become ready, timing out after 10seconds. If this timeout occurs then control goes back to ACMD_READID and ACMD_READID should do a further 4 retries. It doesnot. It hangs. My fix for _my_ tape drive is to up the timeout specified by ACMD_READID in the call to ACMD_SEEKSTS to 90seconds. In fact by drive takes about 12seconds to become ready. THIS IS NOT A REAL FIX. I think that the retry stuff in ACMD_READID is broken (a comment in the header of ft.c seems to indicate that hangs did occur and may have been fixed). I am willing to have ago at fixing this, but: I have never written a device driver. I have no time for 6months. I have no idea how QIC tapes work at the s/w level. The state machine in ft.c is big and it would take a long time to trace out what I need to know. I seem to remember someone saying they were going to maintain this code a while back. Anyway, it seems to work and my backup is done. So tonight 2.1-R from my new CDROM (ATAPI Im afraid...:-)) Thanks Raggy PS., Non of the above is anything to do with whom I work for. *** ft.c Thu Apr 4 16:34:51 1996 --- /cdrom/usr/src/sys/i386/isa/ft.c Mon May 29 18:01:41 1995 *************** *** 91,97 **** /* Enable or disable debugging messages. */ #define FTDBGALL 0 /* 1 if you want everything */ ! /*#define DPRT(a) printf a */ #define DPRT(a) /* Constants private to the driver */ --- 91,97 ---- /* Enable or disable debugging messages. */ #define FTDBGALL 0 /* 1 if you want everything */ ! /*#define DPRT(a) printf a */ #define DPRT(a) /* Constants private to the driver */ *************** *** 161,168 **** { 3, 2, "QIC-500", "307.5/550", 0, 0, 0, 0, 0 }, /* ??? */ { 3, 3, "QIC-500", "295/900", 0, 0, 0, 0, 0 }, /* ??? */ { 3, 4, "QIC-500", "1100/550", 0, 0, 0, 0, 0 }, /* ??? */ ! { 3, 5, "QIC-500", "1100/900", 0, 0, 0, 0, 0 }, /* ??? */ ! { 2,11, "TR-1", "750/550", 36, 369, 11808, 128, 32640 } /* dmlb */ }; #define NGEOM (sizeof(ftgtbl) / sizeof(QIC_Geom)) --- 161,167 ---- { 3, 2, "QIC-500", "307.5/550", 0, 0, 0, 0, 0 }, /* ??? */ { 3, 3, "QIC-500", "295/900", 0, 0, 0, 0, 0 }, /* ??? */ { 3, 4, "QIC-500", "1100/550", 0, 0, 0, 0, 0 }, /* ??? */ ! { 3, 5, "QIC-500", "1100/900", 0, 0, 0, 0, 0 } /* ??? */ }; #define NGEOM (sizeof(ftgtbl) / sizeof(QIC_Geom)) *************** *** 766,772 **** CALL_ACMD(2, ACMD_STATUS, QC_STATUS, 8, 0); case 2: if ((async_ret & async_arg1) != 0) goto complete; - DPRT (("seeksts retry, %d left\n", async_retries-1)); if (--async_retries == 0) { DPRT(("ft%d: acmd_seeksts retries exceeded\n", ftu)); goto complete; --- 765,770 ---- *************** *** 807,813 **** * 4 microstep head back to 0 * 5 fail */ - DPRT (("readid retry number %d\n", errcnt+1)); if (++errcnt >= 5) { DPRT(("ft%d: acmd_readid errcnt exceeded\n", fdcu)); async_ret = -2; --- 805,810 ---- *************** *** 816,825 **** } if (errcnt == 1) { ft->moving = 0; ! CALL_ACMD(4, ACMD_SEEKSTS, QC_STOP, QS_READY, 90); } else { ft->moving = 0; ! CALL_ACMD(4, ACMD_SEEKSTS, QC_STPAUSE, QS_READY, 90); } DPRT(("readid retry %d...\n", errcnt)); async_state = 0; --- 813,822 ---- } if (errcnt == 1) { ft->moving = 0; ! CALL_ACMD(4, ACMD_SEEKSTS, QC_STOP, QS_READY, 0); } else { ft->moving = 0; ! CALL_ACMD(4, ACMD_SEEKSTS, QC_STPAUSE, QS_READY, 0); } DPRT(("readid retry %d...\n", errcnt)); async_state = 0; *************** *** 842,848 **** async_ret = retpos+1; goto complete; case 4: - DPRT (("readid state 4\n")); CALL_ACMD(5, ACMD_SEEK, QC_FORWARD, 0, 0); case 5: ft->moving = 1; --- 839,844 ---- *************** *** 1835,1844 **** * XXX - This doesn't seem to work on my Colorado Jumbo 250... * if it works on your drive, I'd sure like to hear about it. */ ! /* ! * dmlb - But it does work on my Connor Tapestore 800. ! */ ! #if 1 /* Report drive status */ for (sts = -1, tries = 0; sts < 0 && tries < 3; tries++) sts = qic_status(ftu, QC_TSTATUS, 8); --- 1831,1837 ---- * XXX - This doesn't seem to work on my Colorado Jumbo 250... * if it works on your drive, I'd sure like to hear about it. */ ! #if 0 /* Report drive status */ for (sts = -1, tries = 0; sts < 0 && tries < 3; tries++) sts = qic_status(ftu, QC_TSTATUS, 8); *** ftape.h Tue Apr 2 18:11:23 1996 --- /cdrom/usr/src/sys/sys/ftape.h Sat Aug 13 11:52:48 1994 *************** *** 39,45 **** #define QCV_ECCSIZE 3072 /* Bytes ecc eats */ #define QCV_ECCBLKS 3 /* Blocks ecc eats */ #define QCV_NFMT 3 /* Number of tape formats */ ! #define QCV_NLEN 11 /* Number of tape lengths */ #define QCV_HDRMAGIC 0xaa55aa55 /* Magic for header segment */ #define QCV_FSMAGIC 0x33cc33cc /* Magic for fileset */ --- 39,45 ---- #define QCV_ECCSIZE 3072 /* Bytes ecc eats */ #define QCV_ECCBLKS 3 /* Blocks ecc eats */ #define QCV_NFMT 3 /* Number of tape formats */ ! #define QCV_NLEN 5 /* Number of tape lengths */ #define QCV_HDRMAGIC 0xaa55aa55 /* Magic for header segment */ #define QCV_FSMAGIC 0x33cc33cc /* Magic for fileset */ ---------- From: owner-freebsd-hackers To: freebsd-hackers Subject: ft0 doesn't work with new motherboard Date: 07 September 1996 22:04 Hi all, Some month ago I upgraded to a Pentium motherboard for my FreeBSD system. Prior to that change I had been using a Conner floppy tape drive with some success. After the upgrade ft0 refuses to be recognized, originally I thought the drive had been damaged in the swap and I took it back to the store - imagine my embarrasment when the vendor said that it was working fine, sure enough when I hooked it up and used DOS then the drive is recognized OK.... FreeBSD is however a different story. I played around with ft.c to try and dig some more info out, defining DPRT gives me the following messages at boot. (I also forced a call to ftreq_hwinfo , thus my comments about a hack...) tape_start start tape_recal start tape_recal end tape_start end ===> tape_cmd: 6 ft0: bad seek in tape_cmd; pcn = 1 newcn = 6 ft0: bad seek in tape_cmd; pcn = 1 newcn = 6 ft0: bad seek in tape_cmd; pcn = 1 newcn = 6 ft0: bad seek in tape_cmd; pcn = 2 newcn = 6 ft0: bad seek in tape_cmd; pcn = 2 newcn = 6 ft0: tape_cmd seek failed! ft0: QIC status timeout ===> tape_cmd: 6 ft0: bad seek in tape_cmd; pcn = 2 newcn = 8 ft0: bad seek in tape_cmd; pcn = 2 newcn = 8 ft0: bad seek in tape_cmd; pcn = 2 newcn = 8 ft0: bad seek in tape_cmd; pcn = 2 newcn = 8 ft0: bad seek in tape_cmd; pcn = 2 newcn = 8 ft0: tape_cmd seek failed! ft0: QIC status timeout Entering Mark's ugly hack ===> tape_cmd: 9 ft0: bad seek in tape_cmd; pcn = 2 newcn = 11 ft0: bad seek in tape_cmd; pcn = 2 newcn = 11 ft0: bad seek in tape_cmd; pcn = 3 newcn = 11 ft0: bad seek in tape_cmd; pcn = 3 newcn = 11 ft0: bad seek in tape_cmd; pcn = 3 newcn = 11 ft0: tape_cmd seek failed! ft0: QIC status timeout Anybody now what this means?? From reading the code I can't really work it out. I would appreciate any ideas for how to go further. Regards/mark -- +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Mark Hannon,| FreeBSD - Free Unix for your PC| mark@seeware.DIALix.oz.au| | Melbourne, | PGP key available by fingering | epamha@epa.ericsson.se | | Australia | seeware@melbourne.DIALix.oz.au | | +-=-=-=-=-=-=-+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ From owner-freebsd-hackers Tue Sep 10 02:27:19 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA03841 for hackers-outgoing; Tue, 10 Sep 1996 02:27:19 -0700 (PDT) Received: from elbe.desy.de (elbe.desy.de [131.169.82.208]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA03836 for ; Tue, 10 Sep 1996 02:27:13 -0700 (PDT) From: Lars Gerhard Kuehl Date: Tue, 10 Sep 96 11:27:07 +0200 Message-Id: <9609100927.AA06740@elbe.desy.de> To: Duncan.Barclay@pa-consulting.com Subject: Re: undocumented kernel priority changing Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Shoot me if you will but a couple of config options may not go amiss, at > least for single/few user sites. I will plonk them in sometime soon. For sites with only a few active processes that isn't a problem at all. (No competition.) If there are many active processes 'renicing' is highly desirable. The limit is usually reached only by jobs submitted with 'interactive' nice levels. It might be an advantage to increase the limit if someone likes to use xemacs on a 16MHz 386SX. (10 minutes cpu time even on a 100 MHz 586 is pretty a lot ;) Lars From owner-freebsd-hackers Tue Sep 10 02:57:08 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA05635 for hackers-outgoing; Tue, 10 Sep 1996 02:57:08 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA05626 for ; Tue, 10 Sep 1996 02:56:57 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id TAA05559; Tue, 10 Sep 1996 19:22:28 +0930 From: Michael Smith Message-Id: <199609100952.TAA05559@genesis.atrad.adelaide.edu.au> Subject: Re: undocumented kernel priority changing To: lars@elbe.desy.de (Lars Gerhard Kuehl) Date: Tue, 10 Sep 1996 19:22:28 +0930 (CST) Cc: Duncan.Barclay@pa-consulting.com, hackers@freebsd.org In-Reply-To: <9609100927.AA06740@elbe.desy.de> from "Lars Gerhard Kuehl" at Sep 10, 96 11:27:07 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Lars Gerhard Kuehl stands accused of saying: > > For sites with only a few active processes that isn't a problem at all. > (No competition.) If there are many active processes 'renicing' is highly > desirable. The limit is usually reached only by jobs submitted > with 'interactive' nice levels. It might be an advantage to increase > the limit if someone likes to use xemacs on a 16MHz 386SX. > (10 minutes cpu time even on a 100 MHz 586 is pretty a lot ;) It's peanuts for long-lived processes in any sort of 'embedded' application: mstradar:/home/radar>uptime 11:49AM up 23:35, 3 users, load averages: 0.19, 0.27, 0.25 mstradar:/home/radar>ps ax ... 8651 ?? SN 36:01.06 /home/radar/rd12/libexec/FreeBSD/exptd -f /home/radar 3303 p0- SN 83:44.55 /usr/local/rsi/idl//bin/bin.linux/idl analysis_init As you can see, it's been up less than a day, and the current load is pretty low. Depending on configuration, with just these two running the system will push a load average of 1.8 or more nonstop. (These two also normally start out of /etc/rc.local, so they've been restarted some time after the system booted.) Your point about only having a few processes is quite valid though - there's no problem with either responsiveness or overall performance there. > Lars -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Tue Sep 10 03:24:52 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA07162 for hackers-outgoing; Tue, 10 Sep 1996 03:24:52 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA07155 for ; Tue, 10 Sep 1996 03:24:48 -0700 (PDT) Received: from root.com (implode.root.com [198.145.90.17]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id DAA06462 for ; Tue, 10 Sep 1996 03:24:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.5/8.6.5) with SMTP id DAA17937; Tue, 10 Sep 1996 03:22:57 -0700 (PDT) Message-Id: <199609101022.DAA17937@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Michael Smith cc: lars@elbe.desy.de (Lars Gerhard Kuehl), Duncan.Barclay@pa-consulting.com, hackers@FreeBSD.org Subject: Re: undocumented kernel priority changing In-reply-to: Your message of "Tue, 10 Sep 1996 19:22:28 +0930." <199609100952.TAA05559@genesis.atrad.adelaide.edu.au> From: David Greenman Reply-To: dg@root.com Date: Tue, 10 Sep 1996 03:22:57 -0700 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >Lars Gerhard Kuehl stands accused of saying: >> >> For sites with only a few active processes that isn't a problem at all. >> (No competition.) If there are many active processes 'renicing' is highly >> desirable. The limit is usually reached only by jobs submitted >> with 'interactive' nice levels. It might be an advantage to increase >> the limit if someone likes to use xemacs on a 16MHz 386SX. >> (10 minutes cpu time even on a 100 MHz 586 is pretty a lot ;) > >It's peanuts for long-lived processes in any sort of 'embedded' application: > >mstradar:/home/radar>uptime >11:49AM up 23:35, 3 users, load averages: 0.19, 0.27, 0.25 >mstradar:/home/radar>ps ax >... > 8651 ?? SN 36:01.06 /home/radar/rd12/libexec/FreeBSD/exptd -f /home/radar > 3303 p0- SN 83:44.55 /usr/local/rsi/idl//bin/bin.linux/idl analysis_init > >As you can see, it's been up less than a day, and the current load is pretty >low. Depending on configuration, with just these two running the system >will push a load average of 1.8 or more nonstop. (These two also normally >start out of /etc/rc.local, so they've been restarted some time after >the system booted.) > >Your point about only having a few processes is quite valid though - there's >no problem with either responsiveness or overall performance there. FreeBSD already has a sophisticated mechanism for controlling process priorities (not nice value) for CPU hungry processes. The code in mi_switch() looks like a total hack to me and should be removed in my opinion. Nothing except the user or superuser should change the 'base scheduling priority' ("nice" value) of a process - certainly not automagically in the kernel. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Tue Sep 10 04:13:23 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA10173 for hackers-outgoing; Tue, 10 Sep 1996 04:13:23 -0700 (PDT) Received: from cyclone.degnet.baynet.de (root@cyclone.degnet.baynet.de [194.95.214.129]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA10163 for ; Tue, 10 Sep 1996 04:13:11 -0700 (PDT) Received: from neuron.bsd.uni-passau.de (ppp2 [194.95.214.132]) by cyclone.degnet.baynet.de (8.6.12/8.6.9) with SMTP id NAA07397; Tue, 10 Sep 1996 13:12:00 +0200 Message-ID: <323567A9.4E16@degnet.baynet.de> Date: Tue, 10 Sep 1996 13:05:45 +0000 From: Darius Moos Reply-To: moos@degnet.baynet.de X-Mailer: Mozilla 3.0b8Gold (Win95; I) MIME-Version: 1.0 To: "Frank W. Miller" CC: freebsd-hackers , master@iaas.msu.su Subject: Re: kernel performance References: <199609092229.SAA01670@yangtze.cs.UMD.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Maybe gprof is usefull to you. Have a look at "man gprof". Darius Moos. Frank W. Miller wrote: > > For lack of a better place to start, I chose this mailing list. > > I am curious if there are any performance monitoring facilities built > into the kernel. In particular, I am interested in obtaining > timings of the execution of the read() and write() system calls. > I want to break the measurements down according to how much time > is spent in various areas of the kernel code, how much is spent > waiting for I/O device hardware, etc. > > Any pointers would be helpful. > > Later, > FM > > -- > Frank W. Miller Department of Computer Science > fwmiller@cs.umd.edu University of Maryland, College Park > http://www.cs.umd.edu/~fwmiller College Park, Maryland 20742 -- email: moos@degnet.baynet.de From owner-freebsd-hackers Tue Sep 10 04:47:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA11281 for hackers-outgoing; Tue, 10 Sep 1996 04:47:51 -0700 (PDT) Received: from elbe.desy.de (elbe.desy.de [131.169.82.208]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA11275 for ; Tue, 10 Sep 1996 04:47:35 -0700 (PDT) From: Lars Gerhard Kuehl Date: Tue, 10 Sep 96 13:43:29 +0200 Message-Id: <9609101143.AA06822@elbe.desy.de> To: msmith@atrad.adelaide.edu.au, Duncan.Barclay@pa-consulting.com, dg@root.com Subject: Re: undocumented kernel priority changing Cc: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Michael Smith: >> (10 minutes cpu time even on a 100 MHz 586 is pretty a lot ;) > It's peanuts for long-lived processes in any sort of 'embedded' application: DG: } FreeBSD already has a sophisticated mechanism for controlling process } priorities (not nice value) for CPU hungry processes. The code in mi_switch() Well, I'm somewhat familiar with long term jobs: some 10 to 4 hours cpu time a year (simulating transport phenomena in inductivle coupled plasmas). The 'base scheduling priority' usually hasn't any effect regarding their overall run time, unless there are more jobs running with very different base priorities. In the latter case the 'sophisticated mechanism' simply doesn't suffice. Since the 'nice value' is lowered only if the user hasn't cared for it at all, changing it automagically is not that bad, though it should be possible that at(1) can inform the user and perhaps it could depend on whether the process is connected to a terminal. Lars From owner-freebsd-hackers Tue Sep 10 05:36:03 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA12941 for hackers-outgoing; Tue, 10 Sep 1996 05:36:03 -0700 (PDT) Received: from mh004.infi.net (mh004.infi.net [198.22.1.119]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA12935 for ; Tue, 10 Sep 1996 05:36:01 -0700 (PDT) Received: from cpq-lte.ric.pmu.com by mh004.infi.net with ESMTP (Infinet-S-3.3) id IAA25548; Tue, 10 Sep 1996 08:29:43 -0400 (EDT) Message-Id: <199609101229.IAA25548@mh004.infi.net> From: "Steve Sims" To: "Bruce Evans" , Subject: Re: Problem with sio0 Date: Tue, 10 Sep 1996 08:29:23 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: base64 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk U29ycnksIEJydWNlLCBubyBqb3kgd2l0aCB0aGUgc2lvLmMgcGF0Y2hlcyBvbiBteSBDb21wYXEg TFRFL0VsaXRlIDQvNzUuDQoNCkkgZnV0emVkIGFyb3VuZCBtb3N0IG9mIHRoZSBuaWdodCB0cnlp bmcgdG8gZ2V0IHRoZSBibGFzdGVkIHRoaW5nIHRvIGZpbmQgc2lvWzAxXSwgdG8gbm8gYXZhaWwu ICBBZG1pdHRlZGx5LCBzaW8xIGlzIG9uIGEgcGNjYXJkIG1vZGVtLCBzbyBJIHB1dCB0aGF0IG9u IHRoZSBiYWNrIGJ1cm5lciBmb3Igbm93LCBidXQgSSBhbSBwZWV2ZWQgdGhhdCBJIGNhbid0IGdl dCBzaW8wIHRvIHByb2JlIGNvcnJlY3RseSBlaXRoZXIuDQoNCkknbSB3aWxsaW5nIHRvIHdvcmsg dGhpcyBvbmUgYXMgbG9uZyBhcyB5b3UgaGF2ZSB0aGUgcGF0aWVuY2UgdG8gZ3VpZGUgbWUsIGJ1 dCBJIGFkbWl0IHRoYXQgSSdtIHN0cmFpbmluZyBmb3IgY2x1ZXMuDQoNCk15IGJhc2Ugc3lzdGVt IGlzIDItMi05NjA4MDEtU05BUC4gIEkgcHVsbGVkIHNpby5jIGZyb20gLWN1cnJlbnQgYW5kIGZv bGRlZCB0aGF0IGl0LCBubyBqb3kuDQoNCkkgKG1hbnVhbGx5KSBhcHBsaWVkIHRoZSBzaW8uYyBw YXRjaGVzIHlvdSBtZW50aW9uZWQsIG5vIGpveS4NCg0KSSBtdW5nZWQgdGhyb3VnaCB0aGUgY29k ZSBhbmQgYXBwbGllZCAnREVMQVkoMTAwMDApJyB0byBuZWFybHkgZXZlcnkgc3BvdCBpbiB0aGUg c291cmNlIHRoYXQgaGFkIHRoZSAvKiBFWFRSQSBERUxBWSA/ICovIGNvbW1lbnQsIG5vIGpveS4N Cg0KV2hlcmUgZG8gSSBzdGFydCB0byBnZXQgdGhpcyBvbmUgaGFtbWVyZWQgb3V0Pw0KDQouLi5z anMuLi4NCg0KLS0tLS0tLS0tLQ0KPiBGcm9tOiBTdGV2ZSBTaW1zIDxTaW1zU0BJbmZpLk5ldD4N Cj4gVG86IEJydWNlIEV2YW5zIDxiZGVAemV0YS5vcmcuYXU+OyBmcmVlYnNkLWhhY2tlcnNARnJl ZUJTRC5vcmc7IGhvdXNsZXlAcHItY29tbS5jb20NCj4gU3ViamVjdDogUmU6IFByb2JsZW0gd2l0 aCBzaW8wDQo+IERhdGU6IE1vbmRheSwgU2VwdGVtYmVyIDA5LCAxOTk2IDg6MjQgQU0NCj4gDQo+ IEJydWNlIC0gaXMgdGhpcyBhIGNvaW5jaWRlbmNlLCBvciBXSEFUPyAgSSBoYXZlIGJlZW4gc3Vm ZmVyaW5nIGZvciBhIGNvdXBsZSBvZiBtb250aHMgd2l0aCB0aGlzIGV4YWN0IHNhbWUgcHJvYmxl bSBvbiBhIENvbXB1a2UgTFRFL0VsaXRlLg0KPiANCj4gSSBjaGF0dGVkIHdpdGggTmF0ZSBhIGxp dHRsZSBiaXQgb24gdGhpcywgYW5kIGhlIHJlY29tbWVuZGVkIHRoYXQgSSBoaXQgeW91IHdpdGgg dGhpcy4NCj4gDQo+IEhhdmluZyBqdXN0IGxvYWRlZCB0aGUgOC8xIDIuMiBTTkFQLCBJJ2xsIHRy eSB0aGUgcGF0Y2hlcyBlbmNsb3NlZCBhbmQgbGV0IHlvdSBrbm93IHdoYXQgSSBmaW5kLiAgVGhp cyBoYXMgYmVlbiBNT1NUIGlycml0YXRpbmcsIGJ1dCBhIHByb2ZvdW5kIGxhY2sgb2YgdGltZSBo YXMgcHJldmVudGVkIG1lIGZyb20gdXBncmFkaW5nIG15IHNvdXJjZSAvIHBva2luZyBhcm91bmQu DQo+IA0KPiBGV0lXLCB0aGUgYm9vdCBwcm9iZSBkb2Vzbid0IGZpbmQgdGhlIE1lZ2FoZXJ0eiBY LUphY2sgYXQgc2lvMSBlaXRoZXIuLi4uDQo+IA0KPiAuLi5zanMuLi4NCj4gDQo+IC0tLS0tLS0t LS0NCj4gPiBGcm9tOiBCcnVjZSBFdmFucyA8YmRlQHpldGEub3JnLmF1Pg0KPiA+IFRvOiBmcmVl YnNkLWhhY2tlcnNARnJlZUJTRC5vcmc7IGhvdXNsZXlAcHItY29tbS5jb20NCj4gPiBTdWJqZWN0 OiBSZTogUHJvYmxlbSB3aXRoIHNpbzANCj4gPiBEYXRlOiBGcmlkYXksIFNlcHRlbWJlciAwNiwg MTk5NiAxOjQ1IFBNDQo+ID4gDQo+ID4gPkkgaGF2ZSBhIENvbXBhcSBDb250dXJhIDQzMEMgbGFw dG9wLiAgT24gYm9vdCBJIGdldCBhIG1lc3NhZ2U6DQo+ID4gPg0KPiA+ID5zaW8wIG5vdCBmb3Vu ZCBhdCAweDNmOA0KPiA+ID4NCj4gPiA+VGhlIGNvbXB1dGVycyBCSU9TLCBET1MvV2luZG96ZSBh bmQgT1MvMiBhbGwgYXJlIGFibGUgdG8gZmluZCBpdCBhdCAweDNmOA0KPiA+ID53aXRoIElSUSA0 IGFuZCB0aGluayBpdCBpcyBhIE5TMTY1NTBBRi4gIEkgbW9kaWZpZWQgDQo+ID4gPi91c3Ivc3Jj L3N5cy9pMzg2L2lzYS9zaW8uYyB0byBwcmludCB0aGUgY29udGVudHMgb2YgdGhlIGFycmF5ICJm YWlsdXJlcyIuICANCj4gPiA+T24gYm9vdCBhbGwgbG9jYXRpb25zIGNvbnRhaW5lZCAwIGV4Y2Vw dCAjNSBhbmQgIzguICANCj4gPiA+DQo+ID4gPkkgd291bGQgbGlrZSB0byBmaXggdGhpcyBwcm9i bGVtLiAgSSBpcyB0aGVyZSBtb3JlIHRlc3RpbmcgSSBjYW4gZG8gdG8gaGVscD8NCj4gPiA+SSB0 cmllZCBpZ25vcmluZywgY29tbWVudGVkIG91dCwgdGhlIGxpbmVzIHRoYXQgc2V0ICM1ICYgOC4g IFRoYXQgY2F1c2VkIA0KPiA+ID4iNjUgZXZlbnRzIG9uIGEgZGV2aWNlIHdpdGhvdXQgYSB0cCIg KGJhc2ljYWxseSkuDQo+ID4gDQo+ID4gSW4sIC1jdXJyZW50LCB0cnkgaW5jcmVhc2luZyB0aGUg ZGVsYXlzLiAgSSBndWVzcyB0aGlzIHdvdWxkIHdvcmsgYmVjYXVzZQ0KPiA+IHRoZSBmYWlsdXJl IG1lc3NhZ2VzIHNob3cgdGhhdCB0aGUgZXhwZWN0ZWQgaW50ZXJydXB0IGFycml2ZWQgYSBsaXR0 bGUNCj4gPiBsYXRlLiAgQWxzbyB0cnkgdGhlIENGQ1IgY2hhbmdlIGluIHRoZSBlbmNsb3NlZCBk aWZmcy4NCj4gPiANCj4gPiBUaGUgZGVsYXlzIHNvbWVob3cgZGlkbid0IG1ha2UgaXQgaW50byAy LjEuNS4gIFRyeSB0aGUgZW5jbG9zZWQgcGF0Y2gNCj4gPiBmb3IgMi4xLjUuICBJdCBtaWdodCB3 b3JrIGZvciBlYXJsaWVyIHZlcnNpb25zIHRvby4NCj4gPiANCj4gPiBCcnVjZQ0KPiBbU05JUF0N Cj4gDQo+IC4uLnNqcy4uLg== From owner-freebsd-hackers Tue Sep 10 05:44:09 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA13457 for hackers-outgoing; Tue, 10 Sep 1996 05:44:09 -0700 (PDT) Received: from terra.Sarnoff.COM (terra.sarnoff.com [130.33.11.203]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id FAA13447 for ; Tue, 10 Sep 1996 05:44:06 -0700 (PDT) Received: (from rminnich@localhost) by terra.Sarnoff.COM (8.6.12/8.6.12) id IAA17025; Tue, 10 Sep 1996 08:43:17 -0400 Date: Tue, 10 Sep 1996 08:43:17 -0400 (EDT) From: "Ron G. Minnich" X-Sender: rminnich@terra To: freebsd-hackers@freebsd.org Subject: any experiences with cyrix 6x86? any infant mortalities? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk the 166 mhz. 6x86 cards sure look like a sweet deal. But how's the lifetime? I hear rumors of early death with these parts? any recommended vendors? thanks ron Ron Minnich |"If you leave out all the killings, D.C. has as rminnich@sarnoff.com | low a crime rate as many cities" -- (609)-734-3120 | D.C. Mayor Marion Barry ftp://ftp.sarnoff.com/pub/mnfs/www/docs/cluster.html From owner-freebsd-hackers Tue Sep 10 07:01:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA17024 for hackers-outgoing; Tue, 10 Sep 1996 07:01:04 -0700 (PDT) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.225.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA17015 for ; Tue, 10 Sep 1996 07:00:50 -0700 (PDT) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id PAA02402 for ; Tue, 10 Sep 1996 15:55:49 +0200 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id QAA05084 for freebsd-hackers@freefall.cdrom.com; Tue, 10 Sep 1996 16:08:06 +0200 Date: Tue, 10 Sep 1996 16:08:06 +0200 From: Christoph Kukulies Message-Id: <199609101408.QAA05084@gilberto.physik.rwth-aachen.de> To: freebsd-hackers@freefall.FreeBSD.org Subject: libncurses (latest) Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Can anyone send me the latest libncurses (via mail appendix). I looked around in freefall/incoming and didn't see anything obvious. --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Tue Sep 10 07:44:23 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA20049 for hackers-outgoing; Tue, 10 Sep 1996 07:44:23 -0700 (PDT) Received: from cornus.FSL.ORST.EDU (root@FSL.ORST.EDU [128.193.112.105]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA20030; Tue, 10 Sep 1996 07:44:18 -0700 (PDT) Received: from picea.FSL.ORST.EDU (hernanw@picea.FSL.ORST.EDU [128.193.112.3]) by cornus.FSL.ORST.EDU (8.6.9/8.6.9) with ESMTP id HAA01662; Tue, 10 Sep 1996 07:44:12 -0700 Received: (from hernanw@localhost) by picea.FSL.ORST.EDU (8.7/8.6.9) id HAA00342; Tue, 10 Sep 1996 07:44:11 -0700 (PDT) Date: Tue, 10 Sep 1996 07:44:10 -0700 (PDT) From: Wayne Hernandez To: Freebsd Hubs cc: freebsd-hackers@freebsd.org Subject: sup3 no longer available Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk lucus.fsl.orst.edu, aka sup3.freebsd.org is no longer available. It was causing to much problems for a network full of Suns. Wayne From owner-freebsd-hackers Tue Sep 10 08:20:05 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA21971 for hackers-outgoing; Tue, 10 Sep 1996 08:20:05 -0700 (PDT) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA21924 for ; Tue, 10 Sep 1996 08:20:00 -0700 (PDT) Message-Id: <199609101520.IAA21924@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA087428786; Wed, 11 Sep 1996 01:19:46 +1000 From: Darren Reed Subject: Re: rebuilding trashed disklabel To: rhwang@mail.io.com Date: Wed, 11 Sep 1996 01:19:46 +1000 (EST) Cc: hackers@freebsd.org In-Reply-To: <199609092010.QAA02289@megazone.bigpanda.com> from "Richard Hwang" at Sep 9, 96 04:10:11 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Richard Hwang, sie said: > > I have a drive here (western digital 32500 2.5G ide) on a Dell P6 system with > 80M RAM which had FreeBSD on it. (The whole drive was allocated to FreeBSD; > no multiple boot to other operating systems.) When I rebooted the system, it > failed to boot, claiming that I should insert bootable media. When I checked > out the disklabel, it looked something like this: I found the program I wrote, written for SunOS4 so you may have to do some work before it works under FreeBSD. You should probably run it across your entire disk (c partition or whatever that is) so you know where all possible super blocks are. Sometimes daatSometimes data in progarms can throw it, but there are a few sanity checks to keep it on track. Well, I just compiled it on 2.1.5, by changing "stand/param.h" to "sys/param.h" and "ufs/fs.h" to "ufs/ffs/fs.h" that done, it compiles (1 warning) with a simple cc and away you go. Sorry, this is an RTFS for docs, etc. Was an emergency quick hack :-) Maybe some more smarts could be gotten from the disklabel as it needs help in knowing about disk geometry. Darren #include #include #include #include #include #include #define BLKSIZ 512 /* size of cyliner in longs */ #define NTRACK 16 #define NSECT 63 extern char *optarg; extern int optind; main(argc, argv) int argc; char *argv[]; { int fd, nsect = NSECT, ntrack = NTRACK; int search = 0; u_long *block, blksiz; u_long *u, cyl = 0, o; char *part = "/dev/rsd0c", c; struct fs *fs; while ((c = getopt(argc, argv, "h:p:Ss:t:V")) != -1) switch (c) { case 's' : nsect = atoi(optarg); break; case 'S' : search |= 1; break; case 't' : ntrack = atoi(optarg); break; case 'h' : ntrack = atoi(optarg); break; case 'p' : part = optarg; break; case 'V' : search |= 2; break; } blksiz = BLKSIZ * ntrack * nsect; block = (u_long)malloc(blksiz); if ((fd = open(part, O_RDONLY)) == -1) { fprintf(stderr, "%s ", part); perror("open"); exit(-1); } while (read(fd, block, blksiz) == blksiz) { for (u = block, o = blksiz/4 - sizeof(*fs)/4; o; o--, u++) { fs = (struct fs *)u; if (fs->fs_magic == 0x011954) printsuperblock(block, u, cyl, fs, search); } cyl++; printf("%d\r", cyl); fflush(stdout); } } printsuperblock(bs, u, cyl, fs, opts) u_long *bs, *u, cyl; struct fs *fs; int opts; { if ((int)fs->fs_rps < 0 || !fs->fs_ncyl || (0 > fs->fs_minfree || fs->fs_minfree > 100)) return; if (!fs->fs_fsmnt[0] && !(opts & 2)) return; printf("Superblock %#x for mnt [%s] @%d/%d size %d at %s", fs->fs_magic, fs->fs_fsmnt, cyl, (u - bs)>>9, fs->fs_ncyl, ctime(&fs->fs_time)); printf("\tSuperblock addr %d size %d\n", fs->fs_sblkno, fs->fs_sbsize); printf("\tclean %d modified %d read-only %d unused %d\n", fs->fs_clean, fs->fs_fmod, fs->fs_ronly, fs->fs_flags); printf("\tSizes: Partition %d (block %dB) = %dMB, frags %d * %d\n", fs->fs_dsize, fs->fs_bsize, fs->fs_dsize / 0x400, fs->fs_frag, fs->fs_fsize); if (opts & 1) return; printf("Disk geometry: %d/%d = %d s/c, %drpm minfree %d delay %d\n", fs->fs_ntrak, fs->fs_nsect, fs->fs_spc, fs->fs_rps * 60, fs->fs_minfree, fs->fs_rotdelay); printf("\tInterleave %d skew %d\n", fs->fs_interleave, fs->fs_trackskew); printf("Cylinders: cyl-block offset %d group offset in cyl. %d\n", fs->fs_cblkno, fs->fs_cgoffset); printf("\tMax Contiguous blocks %d per cylinder %d\n", fs->fs_maxcontig, fs->fs_maxbpg); printf("\tNINDIR %d INOPB %d NSPF %d\n", fs->fs_nindir, fs->fs_inopb, fs->fs_nspf); printf("Per-Group: Inodes %d cylinders %d blocks %d\n", fs->fs_ipg, fs->fs_cpg, fs->fs_fpg); printf("\tOptimize by %s\n", fs->fs_optim ? "space" : "time"); printf("# Directories %d, free: blocks %d inodes %d frags %d\n", fs->fs_cstotal.cs_ndir, fs->fs_cstotal.cs_nbfree, fs->fs_cstotal.cs_nifree, fs->fs_cstotal.cs_nffree); } From owner-freebsd-hackers Tue Sep 10 08:46:09 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA23540 for hackers-outgoing; Tue, 10 Sep 1996 08:46:09 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA23535 for ; Tue, 10 Sep 1996 08:46:06 -0700 (PDT) Received: from ultra.iafrica.com (ultra.iafrica.com [196.31.1.74]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id IAA06904 for ; Tue, 10 Sep 1996 08:46:03 -0700 (PDT) Received: from copernicus.iafrica.com [196.31.1.15] (khetan) by ultra.iafrica.com with smtp (Exim 0.55 #1) id E0v0Uut-00045P-00; Tue, 10 Sep 1996 17:39:59 +0200 Date: Tue, 10 Sep 1996 17:40:44 +0200 (SAT) From: Khetan Gajjar To: "Ron G. Minnich" cc: freebsd-hackers@freebsd.org Subject: Re: any experiences with cyrix 6x86? any infant mortalities? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 10 Sep 1996, Ron G. Minnich wrote: > the 166 mhz. 6x86 cards sure look like a sweet deal. But how's the > lifetime? I hear rumors of early death with these parts? any recommended > vendors? Works fine on mine, and I've been pushing it quite hard. Works great for me, and I haven't switched the PC off for about 6 weeks now. --- Khetan Gajjar [ http://www.iafrica.com/~khetan ] UUNet Internet Africa [ 0800-030-002 & help@iafrica.com ] Get rid of Telkom.... [ http://www.ispa.org.za ] I'm a FreeBSD User! [ http://www.freebsd.org ] Any opinions stated in this message are personal. UIA's official policy may not be reflected in this message. From owner-freebsd-hackers Tue Sep 10 09:38:52 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA26372 for hackers-outgoing; Tue, 10 Sep 1996 09:38:52 -0700 (PDT) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA26363 for ; Tue, 10 Sep 1996 09:38:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.5/8.6.5) with SMTP id GAA18135; Tue, 10 Sep 1996 06:29:21 -0700 (PDT) Message-Id: <199609101329.GAA18135@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Lars Gerhard Kuehl cc: msmith@atrad.adelaide.edu.au, Duncan.Barclay@pa-consulting.com, hackers@FreeBSD.org Subject: Re: undocumented kernel priority changing In-reply-to: Your message of "Tue, 10 Sep 1996 13:43:29 +0200." <9609101143.AA06822@elbe.desy.de> From: David Greenman Reply-To: dg@root.com Date: Tue, 10 Sep 1996 06:29:21 -0700 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > >Michael Smith: >>> (10 minutes cpu time even on a 100 MHz 586 is pretty a lot ;) > >> It's peanuts for long-lived processes in any sort of 'embedded' application: > >DG: >} FreeBSD already has a sophisticated mechanism for controlling process >} priorities (not nice value) for CPU hungry processes. The code in mi_switch() > >Well, I'm somewhat familiar with long term jobs: some 10 to 4 hours cpu time >a year (simulating transport phenomena in inductivle coupled plasmas). >The 'base scheduling priority' usually hasn't any effect regarding their >overall run time, unless there are more jobs running with very different >base priorities. Yes, that's the way it is supposed to work - changing the nice value has no effect unless there are competing processes at other nice levels. > In the latter case the 'sophisticated mechanism' simply >doesn't suffice. Actually, it has a great effect on interactive performance. The algorithm for priority calculation in FreeBSD is significantly different from the one in 4.4BSD. For one thing, we take into account the CPU consumption of all of the processes in the job. >Since the 'nice value' is lowered only if the user hasn't cared for it >at all, changing it automagically is not that bad, though it should be >possible that at(1) can inform the user and perhaps it could depend on >whether the process is connected to a terminal. I disagree. If you want to raise or lower it, the user or superuser should do this intentionally so that they can select a proper value. The FreeBSD algorithm already gives priority to interactive processes, causing heavy CPU consumers to run in the 'background'. Thus the nice value only affects the ratio of CPU given to 'background' processes - and there is no way that the kernel can make any good arbitrary decision about this. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Tue Sep 10 10:12:14 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA27860 for hackers-outgoing; Tue, 10 Sep 1996 10:12:14 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA27847 for ; Tue, 10 Sep 1996 10:12:05 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id CAA30895; Wed, 11 Sep 1996 02:55:25 +1000 Date: Wed, 11 Sep 1996 02:55:25 +1000 From: Bruce Evans Message-Id: <199609101655.CAA30895@godzilla.zeta.org.au> To: freebsd-hackers@FreeBSD.ORG, fwmiller@cs.UMD.EDU Subject: Re: kernel performance Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >For lack of a better place to start, I chose this mailing list. > >I am curious if there are any performance monitoring facilities built >into the kernel. Start with `apropos performance monitoring features built into the kernel'. This gives among other things: perfmon(4) - CPU performance-monitoring interface gprof(1) - display call graph profile data kernbb(8) - generate a dump of the kernels basic-block profile buffers kgmon(8) - generate a dump of the operating system's profile buffers kgmon is the most relevant. It only matched the keyword `the' in the above apropos command :-). Bruce From owner-freebsd-hackers Tue Sep 10 10:37:01 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA29773 for hackers-outgoing; Tue, 10 Sep 1996 10:37:01 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA29750 for ; Tue, 10 Sep 1996 10:36:54 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA03032; Tue, 10 Sep 1996 10:34:40 -0700 From: Terry Lambert Message-Id: <199609101734.KAA03032@phaeton.artisoft.com> Subject: Re: namei performance (was Re: FreeBSD vs. Linux 96 (my impressions)) To: michaelh@cet.co.jp (Michael Hancock) Date: Tue, 10 Sep 1996 10:34:40 -0700 (MST) Cc: terry@lambert.org, hackers@freebsd.org In-Reply-To: from "Michael Hancock" at Sep 10, 96 09:30:49 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I like the pre-parsing of the pathname into components idea for all these > reasons. Freeing the code from delimiter processing is definitely a win. I can't take credit; there's a lot of prior art for doing things this way. Microsfot does things this way in Win95 and NT, and they were not the first to do it (path cannonization). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Sep 10 10:44:12 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA00347 for hackers-outgoing; Tue, 10 Sep 1996 10:44:12 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA00341 for ; Tue, 10 Sep 1996 10:44:09 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA03054; Tue, 10 Sep 1996 10:43:01 -0700 From: Terry Lambert Message-Id: <199609101743.KAA03054@phaeton.artisoft.com> Subject: Re: kernel performance To: fwmiller@cs.UMD.EDU (Frank W. Miller) Date: Tue, 10 Sep 1996 10:43:00 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG, fwmiller@cs.UMD.EDU In-Reply-To: <199609092229.SAA01670@yangtze.cs.UMD.EDU> from "Frank W. Miller" at Sep 9, 96 06:29:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > For lack of a better place to start, I chose this mailing list. > > I am curious if there are any performance monitoring facilities built > into the kernel. In particular, I am interested in obtaining > timings of the execution of the read() and write() system calls. > I want to break the measurements down according to how much time > is spent in various areas of the kernel code, how much is spent > waiting for I/O device hardware, etc. There are performance figure you can get via gprof. These are statistical in nature, so it will be impossible to make a reasonable distinction between cache/non-cache cases (which is why statistical profiling sucks). I have non-statistical profiling data starting from the VFS consumer layer, and working its way down through the supporting code, but excluding some VM and driver effects... it was collected on Win95 using the Pentium instruction clock using highly modified gprof code and compiler generated function entry points + stack hacking to get function exit counters. The Win95 code had all of the gross architectural modifications I've been discussing for the past two years, so there are some functional bottlenecks removed. The data is proprietary to my employer. Statistical profiling operates by dividing the address space into "count buckets" and sampling the PC at intervals. This is not a higly reliable mechanism, but barring a lot of hacking, you will probably not be able to easily get more useful numbers. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Sep 10 10:48:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA00628 for hackers-outgoing; Tue, 10 Sep 1996 10:48:07 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA00622 for ; Tue, 10 Sep 1996 10:48:04 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA03079; Tue, 10 Sep 1996 10:46:28 -0700 From: Terry Lambert Message-Id: <199609101746.KAA03079@phaeton.artisoft.com> Subject: Re: iname() To: e8917523@linf.unb.br Date: Tue, 10 Sep 1996 10:46:28 -0700 (MST) Cc: hackers@freefall.freebsd.org In-Reply-To: <9609100135.AA0141@DANIEL.sobral> from "Daniel C. Sobral" at Sep 10, 96 04:35:53 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > This fails for VFAT/VFAT32/HPFS/NTFS, all of which have "long names" > > > and 8.3 names for each file. For the Mac FS, it fails because of the > > Err... This does not seem to be the case for HPFS. At least, OS/2 > makes names that don't fall into 8.3 convention invisible to DOS > sessions and can't even copy those files to FAT (you have to provide > a new, acceptable, name). Of course, not knowing the internals of > OS/2, it may be just that IBM is too stupid to provide a useful > resource already coded into the system available to its users... :-) It is a limitation of the broswer and the INT 21 supporting code, not an inherent limitation of the HPFS itself. Sorry I didn't make this clear. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Sep 10 11:07:31 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA02197 for hackers-outgoing; Tue, 10 Sep 1996 11:07:31 -0700 (PDT) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA02182 for ; Tue, 10 Sep 1996 11:07:16 -0700 (PDT) Received: from dialup-usr11.etinc.com (dialup-usr11.etinc.com [204.141.95.132]) by etinc.com (8.6.12/8.6.9) with SMTP id OAA26771; Tue, 10 Sep 1996 14:12:44 -0400 Date: Tue, 10 Sep 1996 14:12:44 -0400 Message-Id: <199609101812.OAA26771@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Mark Patterson From: dennis@etinc.com (Dennis) Subject: Re: T1 offc. resell config Cc: hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Hi Folks, > >Looking for suggestions on how i might handle the following: >We're considering having a full T1 dropped into a 13-story office building. >Serveral of the tennents have expressed interest in getting access from us >already. So we want to sell portions (fractionalize?) our T1 _within_ >the office bldg. Outside the building a little later ;-) > >Initially, what's the *least* expensive way to go about this? We only have >an initial budget of $10k. More if we can show a profit to the investors. > >Current equipment - an ET/5025 Router card (I think this card will do T1) >in a x386-Linux box; a 56/64k Adtran CSU/DSU (with buy back option); >FreeBSD P5/120mhz 32MB RAM, SCSI 2-1Gb HDD, 3Com-509 ethercard; >and a x486-66 w/16mb RAM. > >Don't know if the building is wired to handle a T1. > >What equip. do i use to break up our T1 into resellable portions for >potential clients ranging in need from 56kb - 128kb and above? > >Any and all suggestions appreciated. >Thanks!!! Why not run Ethernet and use our bandwidth limiter to limit the hosts traffic? How you wire it is another issue. dennis From owner-freebsd-hackers Tue Sep 10 11:24:19 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA03714 for hackers-outgoing; Tue, 10 Sep 1996 11:24:19 -0700 (PDT) Received: from yangtze.cs.UMD.EDU (yangtze.cs.umd.edu [128.8.128.118]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA03704 for ; Tue, 10 Sep 1996 11:24:15 -0700 (PDT) Received: by yangtze.cs.UMD.EDU (8.7.5/UMIACS-0.9/04-05-88) id OAA03213; Tue, 10 Sep 1996 14:22:51 -0400 (EDT) From: fwmiller@cs.UMD.EDU (Frank W. Miller) Message-Id: <199609101822.OAA03213@yangtze.cs.UMD.EDU> Subject: Re: kernel performance To: terry@lambert.org (Terry Lambert) Date: Tue, 10 Sep 1996 14:22:50 -0400 (EDT) Cc: fwmiller@cs.UMD.EDU (Frank W. Miller), freebsd-hackers@FreeBSD.ORG In-Reply-To: <199609101743.KAA03054@phaeton.artisoft.com> from "Terry Lambert" at Sep 10, 96 10:43:00 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > There are performance figure you can get via gprof. These are > statistical in nature, so it will be impossible to make a reasonable > distinction between cache/non-cache cases (which is why statistical > profiling sucks). > Statistical should be fine for my purpose. I am interested in the performance trends for a large number of reads from disk followed by writes to UDP. By large number, we're talking in the 10s of millions, i. e. moving a half-hour mpeg from disk to network. I have made some very gross measurements at the system call level. As you might expect, the numbers indicate dramatic variance in latency and jitter. I am seeking to breakdown these measurement further to determine what elements of the kernel play the largest role in the variance. I thank all who responded, it looks like configuring the gprof sections of the kernel is going to be a good place to start. > I have non-statistical profiling data starting from the VFS consumer > layer, and working its way down through the supporting code, but > excluding some VM and driver effects... it was collected on Win95 > using the Pentium instruction clock using highly modified gprof code > and compiler generated function entry points + stack hacking to get > function exit counters. The Win95 code had all of the gross > architectural modifications I've been discussing for the past two > years, so there are some functional bottlenecks removed. The data > is proprietary to my employer. > Fortunately, I'm working with FreeBSD and BSD/OS. :P > Statistical profiling operates by dividing the address space into > "count buckets" and sampling the PC at intervals. This is not a > higly reliable mechanism, but barring a lot of hacking, you will > probably not be able to easily get more useful numbers. > We'll see how much hacking my advisor wants me to do. ;) Later, FM -- Frank W. Miller Department of Computer Science fwmiller@cs.umd.edu University of Maryland, College Park http://www.cs.umd.edu/~fwmiller College Park, Maryland 20742 From owner-freebsd-hackers Tue Sep 10 11:31:37 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA04323 for hackers-outgoing; Tue, 10 Sep 1996 11:31:37 -0700 (PDT) Received: from orion.webspan.net (root@orion.webspan.net [206.154.70.41]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA04318 for ; Tue, 10 Sep 1996 11:31:34 -0700 (PDT) Received: from localhost (gpalmer@localhost [127.0.0.1]) by orion.webspan.net (8.7.5/8.6.12) with SMTP id OAA25810; Tue, 10 Sep 1996 14:31:27 -0400 (EDT) X-Authentication-Warning: orion.webspan.net: Host gpalmer@localhost [127.0.0.1] didn't use HELO protocol To: "Greg Rowe" cc: hackers@FreeBSD.org From: "Gary Palmer" Subject: Re: Bind Version ? In-reply-to: Your message of "Mon, 09 Sep 1996 08:10:52 CDT." <9609090810.ZM23757@nevis.oss.uswest.net> Date: Tue, 10 Sep 1996 14:31:27 -0400 Message-ID: <25806.842380287@orion.webspan.net> Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk "Greg Rowe" wrote in message ID <9609090810.ZM23757@nevis.oss.uswest.net>: > Is there an easy way to determine the version of Bind running on > FreeBSD tha t somehow corresponds to Paul's version naming scheme > (4.9.X) ? I'm interested in knowing the version/patch level for > 2.1.5. Thanks. Look in the CVS logs unfortunately :-( 4.8.3BETA24 I believe. Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info From owner-freebsd-hackers Tue Sep 10 11:59:33 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA06227 for hackers-outgoing; Tue, 10 Sep 1996 11:59:33 -0700 (PDT) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA06222 for ; Tue, 10 Sep 1996 11:59:30 -0700 (PDT) Received: by gvr.win.tue.nl (8.6.13/1.53) id UAA27144; Tue, 10 Sep 1996 20:58:27 +0200 From: guido@gvr.win.tue.nl (Guido van Rooij) Message-Id: <199609101858.UAA27144@gvr.win.tue.nl> Subject: Re: vx device broken in 21.1.5? To: ache@nagual.ru (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Tue, 10 Sep 1996 20:58:26 +0200 (MET DST) Cc: dfr@render.com, roberto@keltia.freenix.fr, freebsd-hackers@freebsd.org In-Reply-To: <199609091605.UAA00484@nagual.ru> from "[______ ______]" at "Sep 9, 96 08:05:15 pm" X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk [______ ______] wrote: > > Has anyone tried the patch? Does it work for you? Does it make things > > worse? > > It not makes things worse, but not help the problem too. > My problem was not performance decrease but complete card hang > until reboot. > Try ifconfig vx0 down; ifconfig.vx0 up. Then it works again ;-() -Guido From owner-freebsd-hackers Tue Sep 10 13:13:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA10361 for hackers-outgoing; Tue, 10 Sep 1996 13:13:02 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA10349 for ; Tue, 10 Sep 1996 13:12:58 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id FAA01711; Wed, 11 Sep 1996 05:53:49 +1000 Date: Wed, 11 Sep 1996 05:53:49 +1000 From: Bruce Evans Message-Id: <199609101953.FAA01711@godzilla.zeta.org.au> To: fwmiller@cs.UMD.EDU, terry@lambert.org Subject: Re: kernel performance Cc: freebsd-hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >There are performance figure you can get via gprof. These are ^^^^^ `config -p' and kgmon. kgmon is just the messenger and gprof is just the interpreter. >statistical in nature, so it will be impossible to make a reasonable >distinction between cache/non-cache cases (which is why statistical >profiling sucks). Actually, FreeBSD-current has had non-statistical profiling using `config -pp', kgmon and gprof for 5 months. E.g., the following script: --- sync kgmon -rB dd if=/dev/zero of=/dev/null bs=1 count=100000 kgmon -hp gprof4 -u /kernel >zp --- gives accurate timing for the parts of the system exercised by per-char i/o to /dev/zero and /dev/null. The gprof output is standard, except the times are more accurate, e.g.: --- granularity: each sample hit covers 4 byte(s) for 0.00% of 8.75 seconds % cumulative self self total time seconds seconds calls ns/call ns/call name 33.6 2.937 2.937 _mcount (1987) 14.8 4.235 1.298 _mexitcount [4] 12.7 5.342 1.107 _cputime [5] 7.7 6.013 0.671 _user [9] 4.2 6.378 0.365 200121 1822 12468 _syscall [3] 2.6 6.604 0.227 200000 1134 2339 _mmrw [14] 2.4 6.815 0.210 400106 525 525 _ufs_lock [17] 2.1 7.002 0.187 400136 468 468 _ufs_unlock [18] 2.0 7.178 0.176 100007 1762 9471 _read [7] 2.0 7.353 0.175 100003 1750 8434 _vn_write [8] 2.0 7.527 0.174 100003 1738 5077 _spec_write [12] 2.0 7.698 0.171 100003 1712 10146 _write [6] 1.9 7.868 0.170 100007 1702 7709 _vn_read [10] 1.8 8.027 0.159 100046 1591 1591 _copyout [19] 1.8 8.184 0.157 200137 784 784 _copyin [20] 1.5 8.314 0.130 100000 1302 4635 _spec_read [15] 1.4 8.438 0.123 202201 609 663 _doreti [21] 0.9 8.520 0.082 100010 821 2411 _uiomove [16] 0.9 8.594 0.074 200121 372 12840 _Xsyscall [2] 0.7 8.655 0.061 100003 613 5690 _ufsspec_write [11] 0.4 8.693 0.038 100000 377 5011 _ufsspec_read [13] --- The above uses the Pentium timestamp count and was run on a P133. The version in -current is not quite as accurate. It doesn't compensate for the profiling overheads properly, especially at leaf nodes like ufs_unlock(). My current version is accurate to within a one or two cpu cycles (after compensating for the entire profiling overhead) in simple cases when there are no cache misses. >I have non-statistical profiling data starting from the VFS consumer >layer, and working its way down through the supporting code, but >excluding some VM and driver effects... it was collected on Win95 >using the Pentium instruction clock using highly modified gprof code >and compiler generated function entry points + stack hacking to get >function exit counters. The Win95 code had all of the gross >architectural modifications I've been discussing for the past two >years, so there are some functional bottlenecks removed. The data >is proprietary to my employer. In FreeBSD-current, gprof is essentially unchanged; function entry points are handled normally (compiling with cc -pg generates calls to mcount) and extra code is generated by compiling with cc -mprofiler-epilogue. The stack isn't modified (modifying it might be faster but I thought it would be too hard to implement). Interrupt entry and exit points and cross-jumping between functions is handled specially. Neither the code nor the data is propietary :-). Future versions will support non-statistical profiling using any available counter. My version currently supports the following counters: - standard i8254 counter. The default in -current on non-Pentiums. Its overhead is very high. - Pentium performance-monitoring counters. The code for this was mostly written by Garrett Wollman. I have used it mainly to debug the high variance in the overhead of the profiling routines. It turned out that two often used globals and a stack variable sometimes collided in the Pentium cache, causing several cache misses in the profiling routines. The cache misses doubled the overheads. Bruce From owner-freebsd-hackers Tue Sep 10 13:20:47 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA10968 for hackers-outgoing; Tue, 10 Sep 1996 13:20:47 -0700 (PDT) Received: from gatekeeper.ctron.com (ctron.com [134.141.197.25]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA10963 for ; Tue, 10 Sep 1996 13:20:44 -0700 (PDT) Received: (from news@localhost) by gatekeeper.ctron.com (8.6.12/8.6.9) id QAA03923 for ; Tue, 10 Sep 1996 16:20:42 -0400 Received: from stealth.ctron.com(134.141.5.107) by gatekeeper via smap (V1.3mjr) id sma003911; Tue Sep 10 16:20:19 1996 Received: from thoth.ctron.com by stealth.ctron.com (4.1/SMI-4.1) id AA29152; Tue, 10 Sep 96 16:17:39 EDT Received: from thoth (localhost [127.0.0.1]) by thoth.ctron.com (8.6.12/8.6.12) with SMTP id QAA29510 for ; Tue, 10 Sep 1996 16:21:27 -0400 Message-Id: <3235CDC7.56B6@ctron.com> Date: Tue, 10 Sep 1996 16:21:27 -0400 From: Alexander Seth Jones Organization: Cabletron Systems, Inc. X-Mailer: Mozilla 3.0b5aGold (X11; I; SunOS 5.4 sun4m) Mime-Version: 1.0 To: hackers@freefall.freebsd.org Subject: shared libg++2.7.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Anyone gotten the libg++2.7.2 libraries built shared? I keep getting this error: ld: No reference to __DYNAMIC Where should this be defined? -- Alex Jones | ajones@ctron.com Cabletron Systems, Inc. Durham, NH USA 03824 From owner-freebsd-hackers Tue Sep 10 13:24:28 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA11250 for hackers-outgoing; Tue, 10 Sep 1996 13:24:28 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA11243 for ; Tue, 10 Sep 1996 13:24:18 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA03450; Tue, 10 Sep 1996 13:23:05 -0700 From: Terry Lambert Message-Id: <199609102023.NAA03450@phaeton.artisoft.com> Subject: Re: kernel performance To: fwmiller@cs.UMD.EDU (Frank W. Miller) Date: Tue, 10 Sep 1996 13:23:05 -0700 (MST) Cc: terry@lambert.org, fwmiller@cs.UMD.EDU, freebsd-hackers@FreeBSD.org In-Reply-To: <199609101822.OAA03213@yangtze.cs.UMD.EDU> from "Frank W. Miller" at Sep 10, 96 02:22:50 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Statistical should be fine for my purpose. I am interested in the > performance trends for a large number of reads from disk followed by > writes to UDP. By large number, we're talking in the 10s of millions, > i. e. moving a half-hour mpeg from disk to network. > I have made some very gross measurements at the system call level. > As you might expect, the numbers indicate dramatic variance in latency > and jitter. I am seeking to breakdown these measurement further to > determine what elements of the kernel play the largest role in the > variance. [ ... ] > Fortunately, I'm working with FreeBSD and BSD/OS. :P One thing to consider is that without a cache unification, BSD/OS must call bmap() for copy address ranges for copying data to/from kernel/user space. Another thing to consider is copying the data from kernel space to user space at all. One method which should speed both of these up is to mmap() the file which you will be sending. This will save you one or two copies, depending on which OS you are running it on, since the address of the data in the mapped region can be sent down, and you will trade read+copy for a fault generated by the UDP write reference. This isn't the optimal soloution (which would be to load a system call and turn around the wire requests entirely in kernel space), but it is probably the "best fit" for a user space server. If you were using reliable stream delivery, I would suggest the "team" approach. Testing (by Ed Lane) achieved an ~3X performance improvement on GIF downloads from an HTTP server by replacing the reference with a CGI that ran "team" or "ddd" to stream the GIF data down the connection interleaving the file and network I/O. Unless you are planning on letting the client overflow (limiting factor: the client), then you may want to consider trying a reliable stream delivery mechanism. Getting data from a server to a client is Ed's specialty. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Tue Sep 10 13:37:18 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA12299 for hackers-outgoing; Tue, 10 Sep 1996 13:37:18 -0700 (PDT) Received: from ns.eu.org (valerian.glou.eu.org [193.56.58.251]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA12288 for ; Tue, 10 Sep 1996 13:37:12 -0700 (PDT) Received: (from uucp@localhost) by ns.eu.org (8.7.3/8.7.1/951117) with UUCP id WAA03088 for hackers@freebsd.org; Tue, 10 Sep 1996 22:37:07 +0200 (MET DST) Received: (from regnauld@localhost) by tetard.glou.eu.org (8.7.5/8.7.3/tetard-uucp-2.7) id TAA02302 for hackers@freebsd.org; Tue, 10 Sep 1996 19:00:51 +0200 (MET DST) From: Philippe Regnauld Message-Id: <199609101700.TAA02302@tetard.glou.eu.org> Subject: single-user console in 2.1.5 To: hackers@freebsd.org (hackers) Date: Tue, 10 Sep 1996 19:00:51 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This probably shoudn't go in hackers but... I changed 'secure' to insecure in /etc/ttys for the console : console none unknown off insecure This is so that the root password is asked when going to single-user mode. Unfortunately, it doesn't work (refused every time). I'm using DES on a stock 2.1.5. Haven't tried w/ current yet. -- Phil -- -[ Philippe Regnauld / regnauld@eu.org / +55.4N +11.3E @ Sol3 / +45 31241690 ]- -[ "To kårve or nøt to kårve, that is the qvestion..." -- My sister ]- From owner-freebsd-hackers Tue Sep 10 13:43:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA12568 for hackers-outgoing; Tue, 10 Sep 1996 13:43:04 -0700 (PDT) Received: from orion.webspan.net (root@orion.webspan.net [206.154.70.41]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA12549; Tue, 10 Sep 1996 13:42:58 -0700 (PDT) Received: from localhost (gpalmer@localhost [127.0.0.1]) by orion.webspan.net (8.7.5/8.6.12) with SMTP id QAA10991; Tue, 10 Sep 1996 16:42:50 -0400 (EDT) X-Authentication-Warning: orion.webspan.net: Host gpalmer@localhost [127.0.0.1] didn't use HELO protocol To: hackers@freebsd.org cc: chat@freebsd.org, dave@webspan.net From: "Gary Palmer" Subject: Job for system & network admin open Date: Tue, 10 Sep 1996 16:42:50 -0400 Message-ID: <10988.842388170@orion.webspan.net> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sorry for the `spam', but it's the easiest way to reach you :-) (hit `d' now if you like :-) ) The company I work for (an ISP) is in need of a new system / network administrator. Based out of Lakewood (or Howell when we move), NJ, on the east coast of the USA. You *MUST* know FreeBSD well (all out major servers are FreeBSD 2.1.5-stable or 2.2-current), and a knowledge of Cisco IOS along with IP routing and telecomms (sync serial, FR, etc) is also an definite advantage. Apache (www), INN, squid, qpop (popper), sendmail, etc knowledge all advantageous. Applications / questions (in private mail) to me please, indicating availability. Thanks, Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info From owner-freebsd-hackers Tue Sep 10 13:44:08 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA12702 for hackers-outgoing; Tue, 10 Sep 1996 13:44:08 -0700 (PDT) Received: from etinc.com (et-gw-fr1.etinc.com [204.141.244.98]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA12646 for ; Tue, 10 Sep 1996 13:44:00 -0700 (PDT) Received: from dialup-usr11.etinc.com (dialup-usr11.etinc.com [204.141.95.132]) by etinc.com (8.6.12/8.6.9) with SMTP id QAA27662 for ; Tue, 10 Sep 1996 16:49:33 -0400 Date: Tue, 10 Sep 1996 16:49:33 -0400 Message-Id: <199609102049.QAA27662@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: hackers@freebsd.org From: dennis@etinc.com (Dennis) Subject: Re: vx device broken in 21.1.5? Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >[______ ______] wrote: >> > Has anyone tried the patch? Does it work for you? Does it make things >> > worse? >> >> It not makes things worse, but not help the problem too. >> My problem was not performance decrease but complete card hang >> until reboot. >> > >Try ifconfig vx0 down; ifconfig.vx0 up. Then it works again ;-() > Is version 21.1.5 out already! Boy am I behind! :-) db From owner-freebsd-hackers Tue Sep 10 13:44:46 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA12775 for hackers-outgoing; Tue, 10 Sep 1996 13:44:46 -0700 (PDT) Received: from paris.CS.Berkeley.EDU (paris.CS.Berkeley.EDU [128.32.34.47]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA12763 for ; Tue, 10 Sep 1996 13:44:40 -0700 (PDT) Received: from paris.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by paris.CS.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id NAA00567; Tue, 10 Sep 1996 13:44:37 -0700 From: Josh MacDonald Message-Id: <199609102044.NAA00567@paris.CS.Berkeley.EDU> To: Alexander Seth Jones Cc: freebsd-hackers@freebsd.org Subject: Re: shared libg++2.7.2 In-reply-to: Your message of "Tue, 10 Sep 1996 16:21:27 EDT." <3235CDC7.56B6@ctron.com> Date: Tue, 10 Sep 1996 13:44:36 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there any news on when gcc 2.7.2.1 will be imported into the source tree? It seems as if several months ago it was about to happen. It is still a big problem for c++ users. -josh > Anyone gotten the libg++2.7.2 libraries built shared? I keep getting > this error: > > ld: No reference to __DYNAMIC > > Where should this be defined? > > -- > Alex Jones | ajones@ctron.com > Cabletron Systems, Inc. > Durham, NH USA 03824 From owner-freebsd-hackers Tue Sep 10 14:42:39 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA16730 for hackers-outgoing; Tue, 10 Sep 1996 14:42:39 -0700 (PDT) Received: from ekeberg.sn.no (ekeberg.sn.no [194.143.8.8]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA16723 for ; Tue, 10 Sep 1996 14:42:32 -0700 (PDT) Received: from ralingen111.telepost.no (ralingen111.telepost.no [193.212.209.90]) by ekeberg.sn.no (8.7.5/8.7.3/on4) with SMTP id ; Tue, 10 Sep 1996 23:38:17 +0200 (MET DST) X-Authentication-Warning: ekeberg.sn.no: Host ralingen111.telepost.no [193.212.209.90] didn't use HELO protocol Message-ID: <32365C0A.B12@sn.no> Date: Tue, 10 Sep 1996 23:28:26 -0700 From: Arve Ronning Reply-To: arver@sn.no, Arve.Ronning@alcatel.no X-Mailer: Mozilla 2.0 (Win16; I) MIME-Version: 1.0 To: Bruce Evans CC: Arve.Ronning@alcatel.no, freebsd-hackers@freebsd.org Subject: Re: Support for fixed-scan monitors References: <199609091752.DAA23576@godzilla.zeta.org.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Bruce Evans wrote: > > [Arve wrote:] > > >However, what if the screen used by BIOS is on a monitor which doesn't accept the > >default scan rates (my situation) ? During boot, we would not see : > >a) the BIOS messages > >b) the '>> FreeBSD....Boot:' prompt > >In this case, there is little we can do about a) (except perhaps hack the BIOS :(. > >But we *can* do something about b) by hacking the bootblocks (which is what I did:). > > How do you stop the BIOS from blowing up the monitor that doesn't accept > normal scan rates? :-). Don't switch on the monitors main power until *after* X has been started. (there's a MDA/Hercules monitor where I can see what I'm doing, remember:). > > I deleted your mail with the bootblock changes. How does it set to mono > mode? Does it just set mode 7? I'm surprised that you can't set the > value in the CMOS. > It does: byte *(0:0x410) |= 0x30; Then uses int 0x10 to set mode 7, cursor position & shape. I'm surprised too that this can't be done simply by entering setup and telling BIOS to use the MDA/Herc. But (as I've said in an earlier mail), the BIOSes I've tried failed either by silently reverting to VGA or by failing to initialize both screen adapters properly on the next power-on boot. Now, this may just be caused by my bad luck, but I tried it with two different MDAs and a ISA VGA on two different BIOSes and with one of the MDAs and a PCI VGA on a third BIOS. No go :(. I'm not complaining about BIOSes. What I'm saying is simply : don't expect any BIOS to function properly in this area. Regards - Arve From owner-freebsd-hackers Tue Sep 10 15:15:36 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA18890 for hackers-outgoing; Tue, 10 Sep 1996 15:15:36 -0700 (PDT) Received: from panda.hilink.com.au (panda.hilink.com.au [203.2.144.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA18874 for ; Tue, 10 Sep 1996 15:15:30 -0700 (PDT) Received: (from danny@localhost) by panda.hilink.com.au (8.7.5/8.7.3) id IAA19360; Wed, 11 Sep 1996 08:15:05 +1000 (EST) Date: Wed, 11 Sep 1996 08:15:05 +1000 (EST) From: "Daniel O'Callaghan" To: David Greenman cc: hackers@freebsd.org Subject: Re: undocumented kernel priority changing In-Reply-To: <199609101329.GAA18135@root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 10 Sep 1996, David Greenman wrote: > > > >Michael Smith: > >>> (10 minutes cpu time even on a 100 MHz 586 is pretty a lot ;) > > > >DG: > >} FreeBSD already has a sophisticated mechanism for controlling process > > > > Actually, it has a great effect on interactive performance. The algorithm > for priority calculation in FreeBSD is significantly different from the one in > 4.4BSD. For one thing, we take into account the CPU consumption of all of the > processes in the job. [snipped] > ratio of CPU given to 'background' processes - and there is no way that the > kernel can make any good arbitrary decision about this. Hmm, I actually like the automatic renicing when programs such as vi and pine run away with the CPU when their tty disappears. The machine is still usable interactively. Danny From owner-freebsd-hackers Tue Sep 10 16:07:18 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA21943 for hackers-outgoing; Tue, 10 Sep 1996 16:07:18 -0700 (PDT) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA21935; Tue, 10 Sep 1996 16:07:16 -0700 (PDT) Received: from gra.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 10 Sep 1996 16:07:11 -0700 Posted-Date: Tue, 10 Sep 1996 16:05:26 -0700 (PDT) Received: from localhost by gra.isi.edu (5.65c/4.0.3-6) id ; Tue, 10 Sep 1996 16:05:26 -0700 Date: Tue, 10 Sep 1996 16:05:26 -0700 (PDT) From: Subramaniam Vincent To: hackers@freebsd.org Cc: questions@freebsd.org Subject: Sun code port to freebsd - Makefile issues Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Can anyone give me some advice on how make a *clean* port of code from sun to freebsd, where the sun Makefile contains include files not there in the freebsd distbn. *clean* concerns the dependency lines at the bottom of the Makefile. When I move over the code & Makefile to the freebsd platform, I need to manually remove dependency lines the correspond to non existent include files (sun) , before doing a gmake or make. gmake depend creates a correct .depend file, but that doesnt help. is there some mkdep stuff I am missing here? thanks Vince From owner-freebsd-hackers Tue Sep 10 16:26:05 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA23105 for hackers-outgoing; Tue, 10 Sep 1996 16:26:05 -0700 (PDT) Received: from srv1-bsb.GNS.com.br ([200.239.56.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA23098 for ; Tue, 10 Sep 1996 16:25:57 -0700 (PDT) Received: (from mail@localhost) by srv1-bsb.GNS.com.br (8.7.5/8.7.5) id UAA01944; Tue, 10 Sep 1996 20:25:21 -0300 (EST) Received: from dl0102-bsb.gns.com.br(200.239.56.102) by srv1-bsb.GNS.com.br via smap (V1.3) id sma001841; Tue Sep 10 20:24:45 1996 Received: by DANIEL.sobral (IBM OS/2 SENDMAIL VERSION 1.3.14/2.12um) id AA0059; Tue, 10 Sep 96 19:49:42 +0300 Message-Id: <9609101649.AA0059@DANIEL.sobral> Date: Tue, 10 Sep 96 19:49:41 +0300 From: "Daniel C. Sobral" Subject: No hostname? To: hackers@freefall.freebsd.org Reply-To: e8917523@linf.unb.br In-Reply-To: <199609101147.EAA11290@freefall.freebsd.org> from "owner-hackers-digest@freefall.freebsd.org" at Sep 10 96 4:47 am X-Disclaimer: Klaatu Barada Nikto! X-Mailer: ELM [version 2.3 PL11] for OS/2 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Hm, maybe a computer name in the URLs? :-) They won't work like that... > > [without a hostname] > > Actually, some do, at least with Netscrape. Try these URLs: [stuff] > That's right: you don't need http://, www., or even .com/. Netscrape > assumes all that. Heck, even For that matter, Lynx does that too, and it's configurable, so I can set it to search for things in my country, for example. But neither Netscape nor Lynx would be able to figure out to what computer a directory belongs! (i.e., no *hostname*) -- Daniel C. Sobral (8-DCS) dcs@gns.com.br e8917523@linf.unb.br From owner-freebsd-hackers Tue Sep 10 16:35:45 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA23692 for hackers-outgoing; Tue, 10 Sep 1996 16:35:45 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA23687 for ; Tue, 10 Sep 1996 16:35:42 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id XAA09589; Tue, 10 Sep 1996 23:35:31 GMT Date: Wed, 11 Sep 1996 08:35:31 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: hackers@freebsd.org Subject: Re: namei performance (was Re: FreeBSD vs. Linux 96 (my impressions)) In-Reply-To: <199609101734.KAA03032@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 10 Sep 1996, Terry Lambert wrote: > > I like the pre-parsing of the pathname into components idea for all these > > reasons. Freeing the code from delimiter processing is definitely a win. > > I can't take credit; there's a lot of prior art for doing things this > way. Microsfot does things this way in Win95 and NT, and they were not > the first to do it (path cannonization). Microsoft, Japan Inc., and other successful organizations aren't caught up with the originality of ideas, neither should we. Anyway, I didn't mean to imply credit for the prior art, just for the idea of using it in this case. 8-) 8-) Regards, Mike Hancock From owner-freebsd-hackers Tue Sep 10 19:15:52 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA01325 for hackers-outgoing; Tue, 10 Sep 1996 19:15:52 -0700 (PDT) Received: from nexgen.ampr.org (max14-130.HiWAAY.net [206.104.17.130]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA01313 for ; Tue, 10 Sep 1996 19:15:41 -0700 (PDT) Received: (from dkelly@localhost) by nexgen.ampr.org (8.7.5/8.6.12) id VAA12315; Tue, 10 Sep 1996 21:14:25 -0500 (CDT) Message-ID: X-Mailer: XFMail 0.5-alpha [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Tue, 10 Sep 1996 20:30:38 -0500 (CDT) Organization: Amateur Radio N4HHE, Madison, AL. From: David Kelly To: hackers@freebsd.org Subject: pty's and slattach Cc: Jim Durham , John Perry Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In the amateur radio world where Linux dominates amateur radio operators have their (our) own suite of network protocols, namely AX.25. Linux developers have built AX.25 support into Linux kernels, yet there are many Linux users that don't use that mode for one reason or another. One of many derivatives of Phil Karn KA9Q's NET/NOS is usually run in DOS to produce an advanced network node. There are two (that I know of) derivatives for Un*x, WAMPES (out of Germany?) and TNOS (out of Tampa, FL) that continue the DOS tradition under Un*x... until something better comes along. Ok, so far we've got a single large do-everything binary that implements a BBS, telnet, ftp, nntp, smtp, slip, ppp, etc, over AX.25. But no connection back to the Un*x kernel. Whats currently used in Linux is a SL/IP connection thru a pty/tty pair. In TNOS an attach line to the kernal migh look like this if connecting to a host named "bsd": attach asy ttypf - slip bsd 2048 1024 38400 And you'd like to catch that slip connection (on the FreeBSD side) with: slattach -l -L /dev/ptypf or similar. Of course you should realize by now it works somewhere else but not in FreeBSD. What we get in /var/log/messages is: Sep 10 19:53:08 nexgen slattach[11472]: ioctl(TIOCSCTTY): Operation not permitted No telling what will break next when we get that fixed. :-) Studying /usr/src/sys/kern/tty_pty.c I find no mention of TIOCSCTTY. No wonder its not permitted. Studying /usr1/src/sbin/slattach/slattach.c we find: /* acquire the serial line as a controling terminal. */ if (ioctl(fd, TIOCSCTTY, 0) < 0) { syslog(LOG_ERR,"ioctl(TIOCSCTTY): %m"); exit_handler(1); } I don't know how to run gdb thru a daemon(0,0), but I'm quite sure this is where the error message originates and slattach quits. A bandaid approach would be to bypass the above in slattach. But I don't know enough about *why* the author of slattach.c wants to be a controlling terminal to be confident about skipping the ioctl(). And I don't know enough about the operation of the pty driver to be able to add support for TIOCSCTTY or answer the question, "why isn't it in there already?" Am going to start digging thru my texts and see what I can learn about terminal I/O. Gotta figure out what a "controlling terminal" is. And this other stuff about "process groups". Obviously lots of stuff works very well thru pty's. The most correct fix would be to take the amateur radio code and teach it to connect to the tun device directly. Or the sl devices. But for now I'd like to get this other stuff working thru pty. Oh, and before I forget to mention I'm running something between 2.1.0R and 2.1.5R.... if it makes any difference. Should I grab -current? Any suggestions? -- David Kelly N4HHE, dkelly@tomcat1.tbe.com (wk), dkelly@hiwaay.net (hm) ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-hackers Tue Sep 10 19:57:59 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA03279 for hackers-outgoing; Tue, 10 Sep 1996 19:57:59 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA03267 for ; Tue, 10 Sep 1996 19:57:32 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id MAA11723; Wed, 11 Sep 1996 12:27:05 +0930 From: Michael Smith Message-Id: <199609110257.MAA11723@genesis.atrad.adelaide.edu.au> Subject: Re: pty's and slattach To: dkelly@hiwaay.net (David Kelly) Date: Wed, 11 Sep 1996 12:27:04 +0930 (CST) Cc: hackers@freebsd.org, durham@w2xo.pgh.pa.us, perry@alpha.jpunix.com In-Reply-To: from "David Kelly" at Sep 10, 96 08:30:38 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk David Kelly stands accused of saying: > > Studying /usr/src/sys/kern/tty_pty.c I find no mention of TIOCSCTTY. No > wonder its not permitted. Studying /usr1/src/sbin/slattach/slattach.c we > find: It's probably not handled there 8) However it must be possible to make a pty your controlling terminal. You might want to look at things like 'xdm' and 'screen' to see how they do it (if they do...). > /* acquire the serial line as a controling terminal. */ > if (ioctl(fd, TIOCSCTTY, 0) < 0) { > syslog(LOG_ERR,"ioctl(TIOCSCTTY): %m"); > exit_handler(1); > } > > I don't know how to run gdb thru a daemon(0,0), but I'm quite sure this is > where the error message originates and slattach quits. A bandaid approach > would be to bypass the above in slattach. But I don't know enough about > *why* the author of slattach.c wants to be a controlling terminal to be > confident about skipping the ioctl(). You do this so that when the line drops (wrt. a tty) you get a HUP, so that you don't have to poll line status in a device-specific fashion. > Obviously lots of stuff works very well thru pty's. The most correct fix > would be to take the amateur radio code and teach it to connect to the tun > device directly. Or the sl devices. But for now I'd like to get this other > stuff working thru pty. 'tun' devices are deliriously easy to talk to. If you think you can work well with them, then do it! > David Kelly N4HHE, dkelly@tomcat1.tbe.com (wk), dkelly@hiwaay.net (hm) -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Tue Sep 10 20:15:23 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA04091 for hackers-outgoing; Tue, 10 Sep 1996 20:15:23 -0700 (PDT) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA04086 for ; Tue, 10 Sep 1996 20:15:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.5/8.6.5) with SMTP id UAA20331; Tue, 10 Sep 1996 20:15:35 -0700 (PDT) Message-Id: <199609110315.UAA20331@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: "Daniel O'Callaghan" cc: hackers@freebsd.org Subject: Re: undocumented kernel priority changing In-reply-to: Your message of "Wed, 11 Sep 1996 08:15:05 +1000." From: David Greenman Reply-To: dg@root.com Date: Tue, 10 Sep 1996 20:15:35 -0700 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> >Michael Smith: >> >>> (10 minutes cpu time even on a 100 MHz 586 is pretty a lot ;) >> > >> >DG: >> >} FreeBSD already has a sophisticated mechanism for controlling process >> > >> >> Actually, it has a great effect on interactive performance. The algorithm >> for priority calculation in FreeBSD is significantly different from the one in >> 4.4BSD. For one thing, we take into account the CPU consumption of all of the >> processes in the job. >[snipped] >> ratio of CPU given to 'background' processes - and there is no way that the >> kernel can make any good arbitrary decision about this. > >Hmm, I actually like the automatic renicing when programs such as vi and >pine run away with the CPU when their tty disappears. The machine is >still usable interactively. As I've already said, it's not the 'renicing' that makes the machine continue to be usable interactively, but rather the other parts of the dynamic scheduling algorithm. Removing the 'renicing' should have little or no affect on the problems you've mentioned. I should also point out that run-away pine processes are caused by bugs in pine and should be fixed, not smoothed over with some kernel hacks. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Tue Sep 10 20:29:06 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA04895 for hackers-outgoing; Tue, 10 Sep 1996 20:29:06 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA04886 for ; Tue, 10 Sep 1996 20:29:03 -0700 (PDT) Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.7.5/8.7.5) with SMTP id WAA18342; Tue, 10 Sep 1996 22:28:43 -0500 (CDT) Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.5) id ; Tue, 10 Sep 96 22:28 CDT Received: (from karl@localhost) by Jupiter.mcs.net (8.7.5/8.7.5) id WAA09083; Tue, 10 Sep 1996 22:28:35 -0500 (CDT) From: Karl Denninger Message-Id: <199609110328.WAA09083@Jupiter.mcs.net> Subject: Re: undocumented kernel priority changing To: dg@root.com Date: Tue, 10 Sep 1996 22:28:35 -0500 (CDT) Cc: danny@panda.hilink.com.au, hackers@FreeBSD.org In-Reply-To: <199609110315.UAA20331@root.com> from "David Greenman" at Sep 10, 96 08:15:35 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > >Hmm, I actually like the automatic renicing when programs such as vi and > >pine run away with the CPU when their tty disappears. The machine is > >still usable interactively. > > As I've already said, it's not the 'renicing' that makes the machine > continue to be usable interactively, but rather the other parts of the > dynamic scheduling algorithm. Removing the 'renicing' should have little > or no affect on the problems you've mentioned. > I should also point out that run-away pine processes are caused by bugs in > pine and should be fixed, not smoothed over with some kernel hacks. > > -DG > > David Greenman > Core-team/Principal Architect, The FreeBSD Project That depends. BSDI had a habit of not delivering a SIGHUP to the process when the control terminal was de-allocated (ie: a "dirty" close of a telnet connection). FreeBSD doesn't seem to do this in the testing that we've run here. Or at least, if it does, its nowhere near as frequent. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1 from $600 monthly; speeds to DS-3 available | 23 Chicagoland Prefixes, 13 ISDN, much more Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | Home of Chicago's only FULL Clarinet feed! From owner-freebsd-hackers Tue Sep 10 20:38:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA05308 for hackers-outgoing; Tue, 10 Sep 1996 20:38:10 -0700 (PDT) Received: from w2xo.pgh.pa.us (w2xo.pgh.pa.us [206.210.70.5]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA05302 for ; Tue, 10 Sep 1996 20:38:06 -0700 (PDT) Received: (from durham@localhost) by w2xo.pgh.pa.us (8.6.12/8.6.9) id XAA08421; Tue, 10 Sep 1996 23:37:38 -0400 Date: Tue, 10 Sep 1996 23:37:37 -0400 (EDT) From: Jim Durham X-Sender: durham@w2xo.pgh.pa.us To: David Kelly cc: hackers@freebsd.org, John Perry Subject: Re: pty's and slattach In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 10 Sep 1996, David Kelly wrote: > > attach asy ttypf - slip bsd 2048 1024 38400 > > And you'd like to catch that slip connection (on the FreeBSD side) with: > > slattach -l -L /dev/ptypf > > or similar. Of course you should realize by now it works somewhere else but > not in FreeBSD. What we get in /var/log/messages is: > > Sep 10 19:53:08 nexgen slattach[11472]: ioctl(TIOCSCTTY): Operation > not permitted > You're getting this because something has the port open as a controlling terminal. This is not a bug. I ran into this when I had two copies of slattach running. Try ps -ax | grep slattach For every process group there must be a "controlling terminal", unless it's a daemon process, runnin in the background. If one process has the tty device as a controlling terminal, the second one trying to open that tty device fails the TIOCSCTTY ioctl call. > No telling what will break next when we get that fixed. :-) It's not broken. > > Studying /usr/src/sys/kern/tty_pty.c I find no mention of TIOCSCTTY. No > wonder its not permitted. Studying /usr1/src/sbin/slattach/slattach.c we > find: Look in /usr/include/sys/ioctl.h . > David Kelly N4HHE, dkelly@tomcat1.tbe.com (wk), dkelly@hiwaay.net (hm) > ===================================================================== > The human mind ordinarily operates at only ten percent of its > capacity -- the rest is overhead for the operating system. > 73 -Jim Durham, W2XO From owner-freebsd-hackers Tue Sep 10 21:00:22 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA06523 for hackers-outgoing; Tue, 10 Sep 1996 21:00:22 -0700 (PDT) Received: from w2xo.pgh.pa.us (w2xo.pgh.pa.us [206.210.70.5]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA06506 for ; Tue, 10 Sep 1996 21:00:13 -0700 (PDT) Received: (from durham@localhost) by w2xo.pgh.pa.us (8.6.12/8.6.9) id AAA08473; Wed, 11 Sep 1996 00:00:03 -0400 Date: Tue, 10 Sep 1996 23:55:26 -0400 (EDT) From: Jim Durham To: hackers@freebsd.org Subject: Thanks Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Thanks to all who replied to my question regarding where NOSHARED is set true. Got it. -Jim Durham From owner-freebsd-hackers Tue Sep 10 22:23:38 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA11918 for hackers-outgoing; Tue, 10 Sep 1996 22:23:38 -0700 (PDT) Received: from mx.serv.net (mx.serv.net [199.201.191.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA11911 for ; Tue, 10 Sep 1996 22:23:33 -0700 (PDT) Received: from MindBender.serv.net by mx.serv.net (8.7.5/SERV Revision: 2.30 † id WAA14011; Tue, 10 Sep 1996 22:22:36 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.serv.net (8.7.5/8.7.3) with SMTP id TAA17846; Tue, 10 Sep 1996 19:48:12 -0700 (PDT) Message-Id: <199609110248.TAA17846@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: David Kelly cc: hackers@freebsd.org, Jim Durham , John Perry Subject: Re: pty's and slattach In-reply-to: Your message of Tue, 10 Sep 96 20:30:38 -0500. Date: Tue, 10 Sep 1996 19:48:11 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > slattach -l -L /dev/ptypf >or similar. Of course you should realize by now it works somewhere else but >not in FreeBSD. What we get in /var/log/messages is: > Sep 10 19:53:08 nexgen slattach[11472]: ioctl(TIOCSCTTY): Operation > not permitted [...] >Studying /usr/src/sys/kern/tty_pty.c I find no mention of TIOCSCTTY. No >wonder its not permitted. Studying /usr1/src/sbin/slattach/slattach.c we >find: > /* acquire the serial line as a controling terminal. */ > if (ioctl(fd, TIOCSCTTY, 0) < 0) { > syslog(LOG_ERR,"ioctl(TIOCSCTTY): %m"); > exit_handler(1); > } I don't remember the explanation of why this was done, but it was fixed in NetBSD many months ago. I don't think there was much involved (maybe it was just removing that condition check -- but my vague recollection was that there was slightly more to it). Anyway, there is precedent in the *BSD community... ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@MindBender.serv.net --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... ----------------------------------------------------------------------------- From owner-freebsd-hackers Wed Sep 11 01:37:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA21218 for hackers-outgoing; Wed, 11 Sep 1996 01:37:07 -0700 (PDT) Received: from abel.pdmi.ras.ru ([194.88.2.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA21208 for ; Wed, 11 Sep 1996 01:37:00 -0700 (PDT) Received: (from pialkin@localhost) by abel.pdmi.ras.ru (8.7.5/8.7.3) id MAA00354 for hackers@freebsd.org; Wed, 11 Sep 1996 12:36:53 +0400 (MSD) From: Alexey Pialkin Message-Id: <199609110836.MAA00354@abel.pdmi.ras.ru> Subject: ATAPI patch To: hackers@freebsd.org Date: Wed, 11 Sep 1996 12:36:52 +0400 (MSD) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi ! I made some small ATAPI patch for FreeBSD 2.1.5 - it solves my problems with Panasonic 572B & GoldStar GCD-R542 CDROM's. I hope it will help somone to. This patch trying to solve IMHO to very common problems with ATAPI cdrom's - unknown phase problem & to slow report on commands. (it's rather hack then patch - but it will help somebody as help me.... :) Any comments ? *** ./atapi.c Sat Sep 30 03:11:15 1995 --- /usr/src/sys/i386/isa/atapi.c Wed Sep 11 12:19:25 1996 *************** *** 130,135 **** --- 130,137 ---- #define PHASE_DATAOUT ARS_DRQ #define PHASE_COMPLETED (ARI_IN | ARI_CMD) #define PHASE_ABORTED 0 /* nonstandard - for NEC 260 */ + #define PHASE_COMPL ARI_IN + #define PHASE_COMPL2 ARI_CMD struct atapicmd { /* ATAPI command block */ struct atapicmd *next; /* next command in queue */ *************** *** 247,252 **** --- 249,255 ---- free (ap, M_TEMP); return; } + switch (ap->devtype) { default: /* unknown ATAPI device */ *************** *** 327,333 **** --- 330,338 ---- /* Issue ATAPI IDENTIFY command. */ outb (port + AR_DRIVE, unit ? ARD_DRIVE1 : ARD_DRIVE0); + DELAY(10); outb (port + AR_COMMAND, ATAPIC_IDENTIFY); + DELAY(10); /* Check that device is present. */ if (inb (port + AR_STATUS) == 0xff) { *************** *** 335,340 **** --- 340,346 ---- if (unit == 1) /* Select unit 0. */ outb (port + AR_DRIVE, ARD_DRIVE0); + DELAY(10); return (0); } *************** *** 345,353 **** --- 351,361 ---- if (unit == 1) /* Select unit 0. */ outb (port + AR_DRIVE, ARD_DRIVE0); + DELAY(10); return (0); } + DELAY(40); /* Obtain parameters. */ insw (port + AR_DATA, tb, sizeof(tb) / sizeof(short)); *************** *** 510,515 **** --- 518,524 ---- ac->result.status = 0; outb (ata->port + AR_DRIVE, ac->unit ? ARD_DRIVE1 : ARD_DRIVE0); + DELAY(10); if (atapi_wait (ata->port, 0) < 0) { printf ("atapi%d.%d: controller not ready for cmd\n", ata->ctrlr, ac->unit); *************** *** 519,530 **** /* Set up the controller registers. */ outb (ata->port + AR_FEATURES, 0); outb (ata->port + AR_IREASON, 0); outb (ata->port + AR_TAG, 0); outb (ata->port + AR_CNTLO, ac->count & 0xff); outb (ata->port + AR_CNTHI, ac->count >> 8); outb (ata->port + AR_COMMAND, ATAPIC_PACKET); ! if (ata->debug) printf ("atapi%d.%d: start\n", ata->ctrlr, ac->unit); return (0); --- 528,544 ---- /* Set up the controller registers. */ outb (ata->port + AR_FEATURES, 0); + DELAY(10); outb (ata->port + AR_IREASON, 0); + DELAY(10); outb (ata->port + AR_TAG, 0); + DELAY(10); outb (ata->port + AR_CNTLO, ac->count & 0xff); + DELAY(10); outb (ata->port + AR_CNTHI, ac->count >> 8); + DELAY(10); outb (ata->port + AR_COMMAND, ATAPIC_PACKET); ! DELAY(30); if (ata->debug) printf ("atapi%d.%d: start\n", ata->ctrlr, ac->unit); return (0); *************** *** 550,558 **** --- 564,574 ---- ac->result.error = inb (ata->port + AR_ERROR); return (-1); } + DELAY(40); return (0); } + /* * Send packet cmd. */ *************** *** 613,622 **** } ac->result.status = inb (ata->port + AR_STATUS); ac->result.error = inb (ata->port + AR_ERROR); len = inb (ata->port + AR_CNTLO); len |= inb (ata->port + AR_CNTHI) << 8; - ireason = inb (ata->port + AR_IREASON); if (ata->debug) { printf ("atapi%d.%d: intr ireason=0x%x, len=%d, status=%b, error=%b\n", --- 629,642 ---- } ac->result.status = inb (ata->port + AR_STATUS); + DELAY(10); ac->result.error = inb (ata->port + AR_ERROR); + DELAY(70); + ireason = inb (ata->port + AR_IREASON); + DELAY(10); len = inb (ata->port + AR_CNTLO); + DELAY(10); len |= inb (ata->port + AR_CNTHI) << 8; if (ata->debug) { printf ("atapi%d.%d: intr ireason=0x%x, len=%d, status=%b, error=%b\n", *************** *** 687,706 **** ac->count -= len; return (1); case PHASE_ABORTED: case PHASE_COMPLETED: if (ac->result.status & (ARS_CHECK | ARS_DF)) ac->result.code = RES_ERR; ! else if (ac->count < 0) { ! print (("atapi%d.%d: send data overrun, %d bytes left\n", ! ata->ctrlr, ac->unit, -ac->count)); ! ac->result.code = RES_OVERRUN; ! } else if (ac->count > 0) { ! print (("atapi%d.%d: recv data underrun, %d bytes left\n", ! ata->ctrlr, ac->unit, ac->count)); ! ac->result.code = RES_UNDERRUN; ! bzero (ac->addr, ac->count); ! } else ac->result.code = RES_OK; break; } --- 707,720 ---- ac->count -= len; return (1); + case PHASE_COMPL: + case PHASE_COMPL2: case PHASE_ABORTED: case PHASE_COMPLETED: + if (ac->result.status & (ARS_CHECK | ARS_DF)) ac->result.code = RES_ERR; ! else ac->result.code = RES_OK; break; } *************** *** 837,843 **** if (atapi_start_cmd (ata, ac) >= 0 && atapi_wait_cmd (ata, ac) >= 0) { /* Send packet command. */ atapi_send_cmd (ata, ac); ! /* Wait for data i/o phase. */ for (cnt=20000; cnt>0; --cnt) if (((inb (ata->port + AR_IREASON) & (ARI_CMD | ARI_IN)) | --- 851,857 ---- if (atapi_start_cmd (ata, ac) >= 0 && atapi_wait_cmd (ata, ac) >= 0) { /* Send packet command. */ atapi_send_cmd (ata, ac); ! DELAY(40); /* Wait for data i/o phase. */ for (cnt=20000; cnt>0; --cnt) if (((inb (ata->port + AR_IREASON) & (ARI_CMD | ARI_IN)) | Alexey Pialkin From owner-freebsd-hackers Wed Sep 11 01:46:23 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA21530 for hackers-outgoing; Wed, 11 Sep 1996 01:46:23 -0700 (PDT) Received: from ra.dkuug.dk (ra.dkuug.dk [193.88.44.193]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA21525 for ; Wed, 11 Sep 1996 01:46:19 -0700 (PDT) Received: (from sos@localhost) by ra.dkuug.dk (8.6.12/8.6.12) id KAA27653; Wed, 11 Sep 1996 10:45:01 +0200 Message-Id: <199609110845.KAA27653@ra.dkuug.dk> Subject: Re: ATAPI patch To: pialkin@abel.pdmi.ras.ru (Alexey Pialkin) Date: Wed, 11 Sep 1996 10:45:00 +0200 (MET DST) Cc: hackers@FreeBSD.org In-Reply-To: <199609110836.MAA00354@abel.pdmi.ras.ru> from "Alexey Pialkin" at Sep 11, 96 12:36:52 pm From: sos@FreeBSD.org Reply-to: sos@FreeBSD.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In reply to Alexey Pialkin who wrote: > > Hi ! > I made some small ATAPI patch for FreeBSD 2.1.5 - it solves my problems with > Panasonic 572B & GoldStar GCD-R542 CDROM's. I hope it will help somone to. > This patch trying to solve IMHO to very common problems with ATAPI cdrom's - > unknown phase problem & to slow report on commands. > > (it's rather hack then patch - but it will help somebody as help me.... :) > Any comments ? I'll take it into my collection of patched to the atapi driver, someday we might even have one that works... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team So much code to hack -- so little time. From owner-freebsd-hackers Wed Sep 11 01:58:29 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA21893 for hackers-outgoing; Wed, 11 Sep 1996 01:58:29 -0700 (PDT) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.225.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA21884 for ; Wed, 11 Sep 1996 01:58:25 -0700 (PDT) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id KAA01012 for ; Wed, 11 Sep 1996 10:53:26 +0200 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id LAA08284 for freebsd-hackers@freefall.cdrom.com; Wed, 11 Sep 1996 11:05:42 +0200 Date: Wed, 11 Sep 1996 11:05:42 +0200 From: Christoph Kukulies Message-Id: <199609110905.LAA08284@gilberto.physik.rwth-aachen.de> To: freebsd-hackers@freefall.FreeBSD.org Subject: IDE and ASUS P/I-P6NP5 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The Pentium Pro ASUS P/I-P6NP5 board claims to support onboard IDE (bus master) at 17 MB/s in PIO mode and 22MB/s in DMA mode. How useful is this under FreeBSD-current? Does the IDE driver support this? Are there any IDE disk drives allowing for transfer rates in the range of those achieved by SCSI drives? Would that rule out SCSI as the choice when you want to have really fast disk access? --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Wed Sep 11 02:01:11 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA22056 for hackers-outgoing; Wed, 11 Sep 1996 02:01:11 -0700 (PDT) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.225.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA22047 for ; Wed, 11 Sep 1996 02:00:59 -0700 (PDT) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id KAA01053 for ; Wed, 11 Sep 1996 10:56:05 +0200 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id LAA08303 for freebsd-hackers@freefall.cdrom.com; Wed, 11 Sep 1996 11:08:21 +0200 Date: Wed, 11 Sep 1996 11:08:21 +0200 From: Christoph Kukulies Message-Id: <199609110908.LAA08303@gilberto.physik.rwth-aachen.de> To: freebsd-hackers@freefall.FreeBSD.org Subject: atapi on second controller Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Somehow I had no luck yet to get a -current machine working with an ATAPI CDROM drive attached to the second controller as master. What would be the kernel option/driver lines for this? --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Wed Sep 11 02:09:46 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA22329 for hackers-outgoing; Wed, 11 Sep 1996 02:09:46 -0700 (PDT) Received: from ra.dkuug.dk (ra.dkuug.dk [193.88.44.193]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA22323 for ; Wed, 11 Sep 1996 02:09:40 -0700 (PDT) Received: (from sos@localhost) by ra.dkuug.dk (8.6.12/8.6.12) id LAA27764; Wed, 11 Sep 1996 11:06:44 +0200 Message-Id: <199609110906.LAA27764@ra.dkuug.dk> Subject: Re: IDE and ASUS P/I-P6NP5 To: kuku@gilberto.physik.rwth-aachen.de (Christoph Kukulies) Date: Wed, 11 Sep 1996 11:06:44 +0200 (MET DST) Cc: freebsd-hackers@freefall.freebsd.org In-Reply-To: <199609110905.LAA08284@gilberto.physik.rwth-aachen.de> from "Christoph Kukulies" at Sep 11, 96 11:05:42 am From: sos@FreeBSD.org Reply-to: sos@FreeBSD.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In reply to Christoph Kukulies who wrote: > > > The Pentium Pro ASUS P/I-P6NP5 board claims to support > onboard IDE (bus master) at 17 MB/s in PIO mode and 22MB/s in > DMA mode. Sounds about right.. > How useful is this under FreeBSD-current? Does the IDE driver support > this? Are there any IDE disk drives allowing for transfer rates > in the range of those achieved by SCSI drives? Would that rule out > SCSI as the choice when you want to have really fast disk access? Hmm, I still think that SCSI would be best in highdemand situations, however it should be possible with some pretty good figures using EIDE/ATA drives. And no our current ide (more wdc) driver has no support for this, that situation could change though given the right circumstances..... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team So much code to hack -- so little time. From owner-freebsd-hackers Wed Sep 11 02:11:01 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA22436 for hackers-outgoing; Wed, 11 Sep 1996 02:11:01 -0700 (PDT) Received: from ra.dkuug.dk (ra.dkuug.dk [193.88.44.193]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA22431 for ; Wed, 11 Sep 1996 02:10:57 -0700 (PDT) Received: (from sos@localhost) by ra.dkuug.dk (8.6.12/8.6.12) id LAA27778; Wed, 11 Sep 1996 11:09:38 +0200 Message-Id: <199609110909.LAA27778@ra.dkuug.dk> Subject: Re: atapi on second controller To: kuku@gilberto.physik.rwth-aachen.de (Christoph Kukulies) Date: Wed, 11 Sep 1996 11:09:38 +0200 (MET DST) Cc: freebsd-hackers@freefall.freebsd.org In-Reply-To: <199609110908.LAA08303@gilberto.physik.rwth-aachen.de> from "Christoph Kukulies" at Sep 11, 96 11:08:21 am From: sos@FreeBSD.org Reply-to: sos@FreeBSD.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In reply to Christoph Kukulies who wrote: > > > Somehow I had no luck yet to get a -current machine > working with an ATAPI CDROM drive attached to the second > controller as master. > > What would be the kernel option/driver lines for this? something like: controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr #disk wd2 at wdc1 drive 0 #disk wd3 at wdc1 drive 1 options ATAPI options ATAPI_STATIC device wcd0 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team So much code to hack -- so little time. From owner-freebsd-hackers Wed Sep 11 04:46:13 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA27627 for hackers-outgoing; Wed, 11 Sep 1996 04:46:13 -0700 (PDT) Received: from ki1.chemie.fu-berlin.de (ki1.Chemie.FU-Berlin.DE [160.45.24.21]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA27593 for ; Wed, 11 Sep 1996 04:45:48 -0700 (PDT) Received: by ki1.chemie.fu-berlin.de (Smail3.1.28.1) from mail.hanse.de (193.174.9.9) with smtp id ; Wed, 11 Sep 96 11:14 MEST Received: from wavehh.UUCP by mail.hanse.de with UUCP for freebsd-hackers@freebsd.org id ; Wed, 11 Sep 96 11:14 MET DST Received: by wavehh.hanse.de (4.1/SMI-4.1) id AA00524; Wed, 11 Sep 96 11:13:57 +0200 From: cracauer@wavehh.hanse.de (Martin Cracauer) Message-Id: <9609110913.AA00524@wavehh.hanse.de> Subject: Network load caused by source transmission - some numbers To: freebsd-hackers@freebsd.org Date: Wed, 11 Sep 1996 11:13:57 +0200 (MET DST) Reply-To: cracauer@wavehh.hanse.de X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Some of you might be interested in these numbers. I tried to figure out how much traffic is triggered by getting or updating sources with different distribution systems. You know, in Germany we have to pay *very* much for international IP :-) Getting a checked-out FreeBSD-2.0.5_ALPHA src/sys tree, either using remote CVS or transferring a checked-out Tree (including CVS admin files in checkout-out tree). Traffic in bytes: tar/gzip/rsh: 3308551 tar/gzip/rcp: 3311960 tar/gzip/ftp: 3333930 CVS/checkout/gzip: 4778158 rsync/gzip: 5362880 rsync/checksum/gzip: 5461213 CVS/checkout: 12450324 rsync: 14285078 rsync/checksum: 14361141 tar: 14719214 rdist: 15602175 rcp: 15817651 More on the commands used (gzip is always -9): tar/gzip/rsh: tar fc - usr/src | gzip | rsh target sh -c 'gzip | tar fx -' tar/gzip/rcp: tar fc foo usr/src ; gzip foo ; rcp foo.gz target:. tar/gzip/ftp: tar fc foo usr/src ; gzip foo ; ftp target...put foo.gz CVS/checkout/gzip: cvs -z 9 -d source:/CVS checkout usr/src rsync/gzip: rsync -prz usr/src target:. rsync/checksum/gzip: rsync -cprz usr/src target:. CVS/checkout: cvs -d source:/CVS checkout usr/src rsync: rsync -pr usr/src target:. rsync/checksum: rsync -prc usr/src target:. tar: tar fc - | rsh target tar fx - rdist: rdist -q -c usr/src target: rcp: rcp -rp usr/src target Updating the FreeBSD-2.0.5_ALPHA tree to 2.0.5-RELEASE. UP:CVS/rdiff/gzip: 340238 UP:CVS/update/gzip: 1339099 UP:rsync/checksum/gzip: 3592445 UP:rsync/gzip: 3597499 UP:CVS/update: 3875360 UP:CVS/rdiff: 4133802 UP:rsync/checksum: 4944287 UP:rsync: 5618247 UP:rdist: 15684857 UP:CVS/rdiff/gzip: cvs rdiff | gzip | rsh target sh -c 'zcat | patch -p -s' UP:CVS/update/gzip: cvs -z 9 update ... UP:rsync/checksum/gzip: rsync -crpz ... UP:rsync/gzip: rsync -rpz UP:CVS/update: cvs update ... UP:CVS/rdiff: cvs rdiff | rsh target patch -p -s UP:rsync/checksum: rsync -crp UP:rsync: rsync -rp UP:rdist: rdist -q -c ... NOTES: ------ 1) I can't really believe the number for CVS/rdiff/gzip update 1b)The rdiff produced by cvs didn't really fit into the former tree on the target, some (few) rejects occurred. 2) The update with rdist transfers the whole tree again. The is because I had the the releases in two different trees on the source machine. rsync obviously recognizes unchanged files even when when the date differs, rdist doesn't. 3) Versions: Source machine is NetBSD-1.1/i386 Target machine is NetBSD-1.1/sparc CVS is 1.8.1 rsync is 1.5 rdist is whatever is in NetBSD-1.1 4) The tool to measure the traffic is : `tcpdump -s 2000 -w - ... | wc -c` That means: The numbers include IP and TCP headers. The medium is 10-Mbit/sec Ethernet. IMPRESSIONS: ------------ - CVS is a good one! - rdist seems rather pointless. The only thing I miss in rsync is an option to preserve the directory structure. When doing `rsync -rp usr/src target:`, the directory on the target machine is 'src', not 'usr/src'. Should be switchable. FEEDBACK: --------- I'm going to do a next run of these tests. Please let me know if: - You want more protocols (which one?) - You want to know the run time (which medium?, what machines) - You want to know the load caused (on client, on server?) - You want more information on the commands used - You want this test suite Happy Hacking Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.bik-gmbh.de/~cracauer Fax +49 40 522 85 36 From owner-freebsd-hackers Wed Sep 11 05:26:30 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA29367 for hackers-outgoing; Wed, 11 Sep 1996 05:26:30 -0700 (PDT) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.225.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id FAA29359 for ; Wed, 11 Sep 1996 05:26:26 -0700 (PDT) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id OAA06399; Wed, 11 Sep 1996 14:21:25 +0200 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id OAA08767; Wed, 11 Sep 1996 14:33:27 +0200 Message-Id: <199609111233.OAA08767@gilberto.physik.rwth-aachen.de> Date: Wed, 11 Sep 1996 14:33:26 +0200 From: kuku@gilberto.physik.rwth-aachen.de (Christoph P. Kukulies) To: sos@FreeBSD.org Cc: kuku@gilberto.physik.rwth-aachen.de (Christoph Kukulies), freebsd-hackers@freefall.freebsd.org Subject: Re: atapi on second controller In-Reply-To: <199609110909.LAA27778@ra.dkuug.dk>; from sos@FreeBSD.org on Sep 11, 1996 11:09:38 +0200 References: <199609110909.LAA27778@ra.dkuug.dk> X-Mailer: Mutt 0.42 Mime-Version: 1.0 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk sos@FreeBSD.org writes: > In reply to Christoph Kukulies who wrote: > > > > > > Somehow I had no luck yet to get a -current machine > > working with an ATAPI CDROM drive attached to the second > > controller as master. > > > > What would be the kernel option/driver lines for this? > > something like: > > controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr > #disk wd2 at wdc1 drive 0 > #disk wd3 at wdc1 drive 1 > > options ATAPI > options ATAPI_STATIC > device wcd0 Is it this ordering that assures that wcd0 is attached to controller wdc1? > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team > So much code to hack -- so little time. -- --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-hackers Wed Sep 11 05:31:59 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA29700 for hackers-outgoing; Wed, 11 Sep 1996 05:31:59 -0700 (PDT) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id FAA29694 for ; Wed, 11 Sep 1996 05:31:55 -0700 (PDT) Received: from minnow.render.com (minnow.render.com [193.195.178.1]) by minnow.render.com (8.6.12/8.6.9) with SMTP id NAA02423; Wed, 11 Sep 1996 13:30:05 +0100 Date: Wed, 11 Sep 1996 13:30:05 +0100 (BST) From: Doug Rabson To: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= cc: Guido van Rooij , roberto@keltia.freenix.fr, freebsd-hackers@freebsd.org Subject: Re: vx device broken in 21.1.5? In-Reply-To: <199609091604.UAA00469@nagual.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 9 Sep 1996, [KOI8-R] =E1=CE=C4=D2=C5=CA =FE=C5=D2=CE=CF=D7 wrote: > > One update on the problem where it dies when youflood ping another mach= ine. > >=20 > > Basically, I found out that it hangs in OACTIVE mode. Input still works= (as > > canbe seen by netstat -I). Output is just dead. >=20 > Yes, I saw it too, with new patch and without it, nothing changed... Hum. My card doesn't have this (I have the 10/100Mb version). I will have another look at the OpenBSD driver. Feel free to do the same since I have no easy way to test a fix for this problem. -- Doug Rabson, Microsoft RenderMorphics Ltd.=09Mail: dfr@render.com =09=09=09=09=09=09Phone: +44 171 734 3761 =09=09=09=09=09=09FAX: +44 171 734 6426 From owner-freebsd-hackers Wed Sep 11 05:42:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA00551 for hackers-outgoing; Wed, 11 Sep 1996 05:42:51 -0700 (PDT) Received: from ra.dkuug.dk (ra.dkuug.dk [193.88.44.193]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id FAA00546 for ; Wed, 11 Sep 1996 05:42:46 -0700 (PDT) Received: (from sos@localhost) by ra.dkuug.dk (8.6.12/8.6.12) id OAA28368; Wed, 11 Sep 1996 14:34:28 +0200 Message-Id: <199609111234.OAA28368@ra.dkuug.dk> Subject: Re: atapi on second controller To: kuku@gilberto.physik.rwth-aachen.de (Christoph P. Kukulies) Date: Wed, 11 Sep 1996 14:34:28 +0200 (MET DST) Cc: sos@FreeBSD.org, kuku@gilberto.physik.rwth-aachen.de, freebsd-hackers@freefall.freebsd.org In-Reply-To: <199609111233.OAA08767@gilberto.physik.rwth-aachen.de> from "Christoph P. Kukulies" at Sep 11, 96 02:33:26 pm From: sos@FreeBSD.org Reply-to: sos@FreeBSD.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In reply to Christoph P. Kukulies who wrote: > > > > Somehow I had no luck yet to get a -current machine > > > working with an ATAPI CDROM drive attached to the second > > > controller as master. > > > > > > What would be the kernel option/driver lines for this? > > > > something like: > > > > controller wdc1 at isa? port "IO_WD2" bio irq 15 vector wdintr > > #disk wd2 at wdc1 drive 0 > > #disk wd3 at wdc1 drive 1 > > > > options ATAPI > > options ATAPI_STATIC > > device wcd0 > > Is it this ordering that assures that wcd0 is attached to controller wdc1? It works for me that way, but I have no atapi devices on the first wdc0 controller... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team So much code to hack -- so little time. From owner-freebsd-hackers Wed Sep 11 07:17:39 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA04963 for hackers-outgoing; Wed, 11 Sep 1996 07:17:39 -0700 (PDT) Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA04953 for ; Wed, 11 Sep 1996 07:17:28 -0700 (PDT) Received: from sol1.gud.siemens.co.at (root@firix [10.1.143.100]) by zwei.siemens.at (8.7.4/8.7.3) with SMTP id QAA08851 for ; Wed, 11 Sep 1996 16:16:14 +0200 (MET DST) Received: from ws2301.gud.siemens.co.at by sol1.gud.siemens.co.at with smtp (Smail3.1.28.1 #7 for ) id m0v0q61-00020EC; Wed, 11 Sep 96 16:16 MET DST Received: by ws2301.gud.siemens.co.at (1.37.109.16/1.37) id AA238531140; Wed, 11 Sep 1996 16:12:20 +0200 From: "Hr.Ladavac" Message-Id: <199609111412.AA238531140@ws2301.gud.siemens.co.at> Subject: Re: NFS locking (fwd) To: hackers@freebsd.org Date: Wed, 11 Sep 1996 16:12:20 +0200 (MESZ) X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ----- Forwarded message from Jos Vissers ----- >From Jos.Vissers@telebyte.nl Wed Sep 11 15:23:18 MES 1996 From: Jos Vissers Message-Id: <199609111327.PAA14170@monet.telebyte.nl> Subject: Re: NFS locking To: lada@ws2301.gud.siemens.co.at (Hr.Ladavac) Date: Wed, 11 Sep 1996 15:27:07 +0200 (MET DST) In-Reply-To: <199609111314.AA227477684@ws2301.gud.siemens.co.at> from "Hr.Ladavac" at Sep 11, 96 03:14:44 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hr.Ladavac wrote: > It will probably have to wait until Sun (SMI) people release the specs or > someone reverse engineers the NFS remote locking protocol. > > I guess you wouldn't be happy with NFS locking only among FreeBSD machines. I heard that Linux will be or is supporting it, and personally I'd rather stay with FreeBSD, but my employer is convinced that Linux is better. Jos -- Jos Vissers, System administrator Telebyte ----- End of forwarded message from Jos Vissers ----- Anyone knows anything about Linux NFS locking. Last I've heard it was rather confusing: client only/server grants the lock to everyone. Somewhat contradictory, indeed. /Marino From owner-freebsd-hackers Wed Sep 11 08:10:09 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA08486 for hackers-outgoing; Wed, 11 Sep 1996 08:10:09 -0700 (PDT) Received: (from jmb@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA08474; Wed, 11 Sep 1996 08:10:05 -0700 (PDT) From: "Jonathan M. Bresler" Message-Id: <199609111510.IAA08474@freefall.freebsd.org> Subject: Re: Network load caused by source transmission - some numbers To: cracauer@wavehh.hanse.de Date: Wed, 11 Sep 1996 08:10:05 -0700 (PDT) Cc: freebsd-hackers@freebsd.org In-Reply-To: <9609110913.AA00524@wavehh.hanse.de> from "Martin Cracauer" at Sep 11, 96 11:13:57 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Martin, please try cvsup by john polstra (sp?) you will be *VERY* surprised. i was ;) used to feel guilty doing a sup and loading the sup servers. cvsup is so good i not only dont feel guilty i feel righteous! jmb ps. expect to see a 99% decrease in bytes transferred when updating a sup tree using cvsup. -- Jonathan M. Bresler FreeBSD Postmaster jmb@FreeBSD.ORG FreeBSD--4.4BSD Unix for PC clones, source included. http://www.freebsd.org/ PGP 2.6.2 Fingerprint: 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB From owner-freebsd-hackers Wed Sep 11 08:44:01 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA10365 for hackers-outgoing; Wed, 11 Sep 1996 08:44:01 -0700 (PDT) Received: from beauty.nacamar.de (root@beauty.nacamar.de [194.112.16.36]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA10354; Wed, 11 Sep 1996 08:43:55 -0700 (PDT) Received: from petzi (petzi.nacamar.de [194.162.54.13]) by beauty.nacamar.de (8.7.3/8.7.3) with SMTP id RAA21861; Wed, 11 Sep 1996 17:48:21 +0200 Message-Id: <2.2.32.19960911134348.002d3f28@mail.nacamar.de> X-Sender: petzi@mail.nacamar.de X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Sep 1996 15:43:48 +0200 To: isp@freebsd.org, hackers@freebsd.org From: Michael Beckmann Subject: INN trouble with too many files open Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, I have made a news installation with the 2.2-960801-SNAP and INN 1.4unoff4 . I am receiving a streaming feed from one site, and whenever that site starts to feed me, my innd throttles after a while, with a message: Server throttled Too many open files writing article file -- throttling The weird thing is, that I have already compiled a kernel with maxusers set to 256, and that I have used sysctl and set the maximum number of files to 20.000 , but it didn't help. I must have overlooked something. Here is the output from sysctl: news: {154} sysctl -a kern.ostype: FreeBSD kern.osrelease: 2.2-960801-SNAP kern.osrevision: 199506 kern.version: FreeBSD 2.2-960801-SNAP #0: Wed Sep 11 16:08:03 MET DST 1996 petzi@peanuts.nacamar.de:/usr/src/sys/compile/NEWSCONF kern.maxvnodes: 7900 kern.maxproc: 4116 kern.maxfiles: 20000 kern.argmax: 65536 kern.securelevel: -1 kern.hostname: news.nacamar.de kern.hostid: 0 kern.clockrate: { hz = 100, tick = 10000, profhz = 1024, stathz = 128 } kern.posix1version: 198808 kern.ngroups: 16 kern.job_control: 1 kern.saved_ids: 1 kern.boottime: { sec = 842451193, usec = 525989 } Wed Sep 11 16:13:13 1996 kern.domainname: kern.update: 30 kern.osreldate: 199608 kern.bootfile: /kernel kern.maxfilesperproc: 8232 kern.maxprocperuid: 4115 kern.dumpdev: -1 kern.somaxconn: 128 kern.maxsockbuf: 262144 kern.ps_strings: -272637968 kern.usrstack: -272637952 kern.acct_suspend: 2 kern.acct_resume: 4 kern.acct_chkfreq: 15 kern.sockbuf_waste_factor: 8 .... Any ideas ? All help is appreciated. Michael Beckmann From owner-freebsd-hackers Wed Sep 11 09:16:58 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA12066 for hackers-outgoing; Wed, 11 Sep 1996 09:16:58 -0700 (PDT) Received: from sovcom.kiae.su (sovcom.kiae.su [193.125.152.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA12058 for ; Wed, 11 Sep 1996 09:16:51 -0700 (PDT) Received: by sovcom.kiae.su id AA28326 (5.65.kiae-1 ); Wed, 11 Sep 1996 19:09:37 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Wed, 11 Sep 96 19:09:37 +0300 Received: (from ache@localhost) by nagual.ru (8.7.5/8.7.3) id UAA00657; Wed, 11 Sep 1996 20:05:42 +0400 (MSD) Message-Id: <199609111605.UAA00657@nagual.ru> Subject: Re: ATAPI patch In-Reply-To: <199609110836.MAA00354@abel.pdmi.ras.ru> from "Alexey Pialkin" at "Sep 11, 96 12:36:52 pm" To: pialkin@abel.pdmi.ras.ru (Alexey Pialkin) Date: Wed, 11 Sep 1996 20:05:42 +0400 (MSD) Cc: hackers@freebsd.org From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (Andrey A. Chernov) Organization: self X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL25 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I made some small ATAPI patch for FreeBSD 2.1.5 - it solves my problems with > Panasonic 572B & GoldStar GCD-R542 CDROM's. I hope it will help somone to. > This patch trying to solve IMHO to very common problems with ATAPI cdrom's - > unknown phase problem & to slow report on commands. > > (it's rather hack then patch - but it will help somebody as help me.... :) > Any comments ? Are you shure that _all_ those delays are neccessary? Could you try to remove some of them, one by one? -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-hackers Wed Sep 11 09:17:54 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA12143 for hackers-outgoing; Wed, 11 Sep 1996 09:17:54 -0700 (PDT) Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA12125 for ; Wed, 11 Sep 1996 09:17:48 -0700 (PDT) Received: by gvr.win.tue.nl (8.6.13/1.53) id SAA29599; Wed, 11 Sep 1996 18:16:09 +0200 From: guido@gvr.win.tue.nl (Guido van Rooij) Message-Id: <199609111616.SAA29599@gvr.win.tue.nl> Subject: Re: vx device broken in 21.1.5? To: dfr@render.com (Doug Rabson) Date: Wed, 11 Sep 1996 18:16:07 +0200 (MET DST) Cc: ache@nagual.ru, roberto@keltia.freenix.fr, freebsd-hackers@freebsd.org In-Reply-To: from Doug Rabson at "Sep 11, 96 01:30:05 pm" X-Mailer: ELM [version 2.4ME+ PL17 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Doug Rabson wrote: > On Mon, 9 Sep 1996, [KOI8-R] áÎÄÒÅÊ þÅÒÎÏ× wrote: > > > > One update on the problem where it dies when youflood ping another machine. > > > > > > Basically, I found out that it hangs in OACTIVE mode. Input still works (as > > > canbe seen by netstat -I). Output is just dead. > > > > Yes, I saw it too, with new patch and without it, nothing changed... > > Hum. My card doesn't have this (I have the 10/100Mb version). I will > have another look at the OpenBSD driver. Feel free to do the same since I > have no easy way to test a fix for this problem. I am completely rewriting the vx driver based on the current Net/OpenBSD driver. -Guido From owner-freebsd-hackers Wed Sep 11 09:33:21 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA13393 for hackers-outgoing; Wed, 11 Sep 1996 09:33:21 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.eu.org [193.56.58.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA13388 for ; Wed, 11 Sep 1996 09:33:15 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.eu.org [193.56.58.33]) by mexico.brainstorm.eu.org (8.7.5/8.7.3) with ESMTP id SAA05464 for ; Wed, 11 Sep 1996 18:33:08 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.6.12/8.6.12) with UUCP id SAA04149 for hackers@FreeBSD.org; Wed, 11 Sep 1996 18:32:26 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.Beta.1/keltia-uucp-2.9) id GAA00499; Wed, 11 Sep 1996 06:47:13 +0200 (MET DST) Message-Id: <199609110447.GAA00499@keltia.freenix.fr> Date: Wed, 11 Sep 1996 06:47:13 +0200 From: roberto@keltia.freenix.fr (Ollivier Robert) To: hackers@FreeBSD.org (hackers) Subject: Re: single-user console in 2.1.5 In-Reply-To: <199609101700.TAA02302@tetard.glou.eu.org>; from Philippe Regnauld on Sep 10, 1996 19:00:51 +0200 References: <199609101700.TAA02302@tetard.glou.eu.org> X-Mailer: Mutt 0.42 Mime-Version: 1.0 X-Operating-System: FreeBSD 2.2-CURRENT ctm#2443 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk According to Philippe Regnauld: > This is so that the root password is asked when going to > single-user mode. Unfortunately, it doesn't work (refused every > time). I'm using DES on a stock 2.1.5. Haven't tried w/ current > yet. You may need to recompile init(8)... (wild guess). -- Ollivier ROBERT -=- The daemon is FREE! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 2.2-CURRENT #21: Sun Sep 8 14:35:00 MET DST 1996 From owner-freebsd-hackers Wed Sep 11 10:51:54 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA17872 for hackers-outgoing; Wed, 11 Sep 1996 10:51:54 -0700 (PDT) Received: from sensi.pu.ru ([194.85.122.40]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA17852 for ; Wed, 11 Sep 1996 10:51:47 -0700 (PDT) Received: (from vadik@localhost) by sensi.pu.ru (8.7.5/8.7.3) id VAA02574 for hackers@freebsd.org; Wed, 11 Sep 1996 21:53:20 +0400 (MSD) Message-ID: X-Mailer: XFMail 0.5-alpha [p0] on FreeBSD Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Wed, 11 Sep 1996 21:50:56 +0400 (MSD) Organization: SPb State University From: vadik likholetov To: hackers@freebsd.org Subject: Maxpeed SS8 serial card Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi! Has anyone wrote driver for Maxpeed SS8? Or I have to write my own? --- vadik likholetov 218-9478 Key fingerprint = 41 5C 7C 4B F4 03 40 B9 57 81 0E EF F0 2E 96 A6 From owner-freebsd-hackers Wed Sep 11 10:54:24 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA18468 for hackers-outgoing; Wed, 11 Sep 1996 10:54:24 -0700 (PDT) Received: from alaska.net (root@calvino.alaska.net [206.149.65.3]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA18440 for ; Wed, 11 Sep 1996 10:54:17 -0700 (PDT) Received: from hmmm.alaska.net by alaska.net (5.x/SMI-SVR4) id AA25977; Wed, 11 Sep 1996 09:53:50 -0800 Message-Id: <3236ECBD.53AD@alaska.net> Date: Wed, 11 Sep 1996 09:45:49 -0700 From: hmmm X-Mailer: Mozilla 2.02 (Win16; I) Mime-Version: 1.0 To: "Hr.Ladavac" Cc: hackers@freebsd.org Subject: Re: NFS locking (fwd) References: <199609111412.AA238531140@ws2301.gud.siemens.co.at> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I heard that Linux will be or is supporting it, and personally I'd > rather stay with FreeBSD, but my employer is convinced that > Linux is better. > > Jos these idle Freebsd THREATS ARE MAKING ME SICK! please stop! does anyone really think they're going to get better responses via threats to throw away something that's free? From owner-freebsd-hackers Wed Sep 11 11:12:21 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA19263 for hackers-outgoing; Wed, 11 Sep 1996 11:12:21 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA19258 for ; Wed, 11 Sep 1996 11:12:18 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.7.5/8.7.3) with ESMTP id LAA00317 for ; Wed, 11 Sep 1996 11:12:16 -0700 (PDT) Message-Id: <199609111812.LAA00317@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: hackers@freebsd.org Subject: clock drift and clock.c Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Sep 1996 11:12:15 -0700 From: Amancio Hasty Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Assuming that xntpd gives over a 24 hour period a clock drift of 122, what are the mods to clock.c to eliminate the clock drift. In my case, I think that my clock drift is fix. Tnks, Amancio From owner-freebsd-hackers Wed Sep 11 11:17:39 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA19520 for hackers-outgoing; Wed, 11 Sep 1996 11:17:39 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA19515 for ; Wed, 11 Sep 1996 11:17:37 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA05138; Wed, 11 Sep 1996 11:16:35 -0700 From: Terry Lambert Message-Id: <199609111816.LAA05138@phaeton.artisoft.com> Subject: Re: shared libg++2.7.2 To: ajones@ctron.com (Alexander Seth Jones) Date: Wed, 11 Sep 1996 11:16:35 -0700 (MST) Cc: hackers@freefall.freebsd.org In-Reply-To: <3235CDC7.56B6@ctron.com> from "Alexander Seth Jones" at Sep 10, 96 04:21:27 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Anyone gotten the libg++2.7.2 libraries built shared? I keep getting > this error: > > ld: No reference to __DYNAMIC > > Where should this be defined? Are you sure this is what it says exactly? "no reference to" means no one imports the symbol. Typically, this would mean you are linking against the wrong ctr0; try explicitly referencing it on the ld line instead of letting the compiler call the ld for you. This is probably just a config bug in the GCC distribution. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Sep 11 11:21:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA19708 for hackers-outgoing; Wed, 11 Sep 1996 11:21:07 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA19685; Wed, 11 Sep 1996 11:21:02 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA05158; Wed, 11 Sep 1996 11:20:01 -0700 From: Terry Lambert Message-Id: <199609111820.LAA05158@phaeton.artisoft.com> Subject: Re: Sun code port to freebsd - Makefile issues To: svincent@ISI.EDU (Subramaniam Vincent) Date: Wed, 11 Sep 1996 11:20:00 -0700 (MST) Cc: hackers@freebsd.org, questions@freebsd.org In-Reply-To: from "Subramaniam Vincent" at Sep 10, 96 04:05:26 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Can anyone give me some advice on how make a *clean* port of code from > sun to freebsd, where the sun Makefile contains include files not there in > the freebsd distbn. *clean* concerns the dependency lines at the > bottom of the Makefile. > > When I move over the code & Makefile to the freebsd platform, I need to > manually remove dependency lines the correspond to non existent include > files (sun) , before doing a gmake or make. > gmake depend creates a correct .depend file, but that doesnt help. > is there some mkdep stuff I am missing here? In general, a depended makefile will have been auto-generated by a "make depend". Another "make depend" on the target system should fix it, assuming the comments in the file have been left intact. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Sep 11 11:28:05 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA20060 for hackers-outgoing; Wed, 11 Sep 1996 11:28:05 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA20054 for ; Wed, 11 Sep 1996 11:28:03 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA05182; Wed, 11 Sep 1996 11:26:00 -0700 From: Terry Lambert Message-Id: <199609111826.LAA05182@phaeton.artisoft.com> Subject: Re: IDE and ASUS P/I-P6NP5 To: kuku@gilberto.physik.rwth-aachen.de (Christoph Kukulies) Date: Wed, 11 Sep 1996 11:26:00 -0700 (MST) Cc: freebsd-hackers@freefall.freebsd.org In-Reply-To: <199609110905.LAA08284@gilberto.physik.rwth-aachen.de> from "Christoph Kukulies" at Sep 11, 96 11:05:42 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > The Pentium Pro ASUS P/I-P6NP5 board claims to support > onboard IDE (bus master) at 17 MB/s in PIO mode and 22MB/s in > DMA mode. > > How useful is this under FreeBSD-current? Does the IDE driver support > this? Are there any IDE disk drives allowing for transfer rates > in the range of those achieved by SCSI drives? Would that rule out > SCSI as the choice when you want to have really fast disk access? DMA mode isn't supported AFAIK. I think the problem is still that it is impossible to reliably detect support for the mode without crashing older (WD1007, etc.?) hardware. The wonderful think about the ATAPI standard is that there are so many non-interoperable implementations to choose from! Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Sep 11 11:31:27 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA20247 for hackers-outgoing; Wed, 11 Sep 1996 11:31:27 -0700 (PDT) Received: from pinky.junction.net (pinky.junction.net [199.166.227.12]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA20242 for ; Wed, 11 Sep 1996 11:31:23 -0700 (PDT) Received: from sidhe.memra.com (sidhe.memra.com [199.166.227.105]) by pinky.junction.net (8.6.12/8.6.12) with ESMTP id KAA17278 for ; Wed, 11 Sep 1996 10:44:40 -0700 Received: from localhost (michael@localhost) by sidhe.memra.com (8.6.12/8.6.12) with SMTP id LAA23779 for ; Wed, 11 Sep 1996 11:28:58 -0700 Date: Wed, 11 Sep 1996 11:28:57 -0700 (PDT) From: Michael Dillon To: freebsd-hackers@freebsd.org Subject: SYN Resisting (fwd) Message-ID: Organization: Memra Software Inc. - Internet consulting MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is FreeBSD resistant to this kind of SYN attack? Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com ---------- Forwarded message ---------- Date: Wed, 11 Sep 1996 14:08:56 -0400 From: Avi Freedman To: nanog@merit.edu Cc: alexis@panix.com, freedman@netaxs.com Subject: SYN Resisting I know this may not be strictly on-topic here because it deals with "host-stuff" rather than "router-stuff", but here goes... I will have some comments on how to track where SYN storms are coming from a bit later. In order to build a SYN-resistant BSD kernel, you need to modify one file in src/sys/os, uipc_socket2.c, and you also need to modify src/sys/netinet/tcp_timer.h and you have to rebuild tcp_usrreq.c and tcp_input.c in the netinet directory. For those without SunOS source, I will get Sun4c (Sparc 1/1+/2/IPC/IPX/ ELC/SLC) binaries online; for those running BSD on other platforms, you probably have source. >From the bottom level up, change TCPTV_KEEP_INIT from 75*PR_SLOWHZ to 7*PR_SLOWHZ (or whatever # you want). This timeout (the 75) is the number of seconds that the kernel will keep un-established TCP PCB/sockets around for... When the SYN is received, it is acknowledged and the PCB && socket are set up for the embryonic session; the goal is to rip those things out of any queues they're in more aggressively. At the top (socket) level, instead of modifying SOMAXCONN, I decided to just see what happened if I removed the limit. What you do is up to your own personal taste. I commented out: if (head->so_qlen + head->so_q0len > 3 * head->so_qlimit / 2) goto bad; in src/sys/os/uipc_socket2.c. Head in this case points to a 'server' socket (the socket for your web, mail, news, ... server). so_qlimit is set to the min of either what the listen() system call inside of it requested or SOMAXCONN. I had some funkiness increasing SOMAXCONN to 8096 or so when I was playing with it - and didn't want to recompile inetd, sendmail, etc... to ask for more slots in the listen() queue (just a linked list or two), so I figured I'd *try* to make the queue size infinite and see what happened. so_qlen and so_q0len are the linked lists of sockets waiting to be accept()ed and the sockets of the embryonic (not established) TCP connections that were aimed at this server socket, respectively. The code uses a 3/2 fudge factor to make the comparison, and is saying "if the number of queued requests is > 3/2 times the limit for this socket, don't stick this requesting socket in the queue - just destroy it and exit". I just commented those two lines out. On a Sparc 1+ w/ 4.1.4, I could sustain a 200-400 SYN-packet/sec attack and still remain functional (and quick for a 1+), but the machine didn't normally run web servers... Even when I nailed it with 1000 SYNs/sec, the machine continued functioning but I couldn't connect to the socket being nailed. A second after stopping the heavier attack, I could. I've had trouble compiling and getting these modified modules to work on a Sun4m architecture (Sparc 5 and 10) but may play more with that today. The best solution is to implement a better data structure than a linked list for storing the embryonic connections per socket. A large-ish array with appropriate hashing, perhaps. Either per socket or for the whole kernel. If anyone wants to attack that problem, please do; otherwise, I'll blow BSD on a laptop so I can play with it when I'm next on a plane/ train. Avi From owner-freebsd-hackers Wed Sep 11 12:33:39 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA23797 for hackers-outgoing; Wed, 11 Sep 1996 12:33:39 -0700 (PDT) Received: from frig.mt.cs.keio.ac.jp (frig.mt.cs.keio.ac.jp [131.113.32.7]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA23778; Wed, 11 Sep 1996 12:33:32 -0700 (PDT) Received: (from hosokawa@localhost) by frig.mt.cs.keio.ac.jp (8.6.12+2.4W/3.4Wbeta3) id EAA28692; Thu, 12 Sep 1996 04:33:28 +0900 Date: Thu, 12 Sep 1996 04:33:28 +0900 Message-Id: <199609111933.EAA28692@frig.mt.cs.keio.ac.jp> To: freebsd-mobile@freebsd.org, freebsd-hackers@freebsd.org Subject: PAO-960911 From: hosokawa@mt.cs.keio.ac.jp (HOSOKAWA Tatsumi) X-Mailer: mnews [version 1.18PL3] 1994-08/01(Mon) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Now I'm merging Nate Williams' changes for APM and pccard stuff into PAO. PAO-960911 is the interim release of this work. ftp://ryukyu.mt.cs.keio.ac.jp/pub/FreeBSD/PAO/PAO-960911.tar.gz This package is for 2.2-960801-SNAP only. -- HOSOKAWA, Tatsumi E-mail: hosokawa@mt.cs.keio.ac.jp WWW homepage: http://www.mt.cs.keio.ac.jp/person/hosokawa.html Department of Computer Science, Keio University, Yokohama, Japan From owner-freebsd-hackers Wed Sep 11 12:40:20 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA24006 for hackers-outgoing; Wed, 11 Sep 1996 12:40:20 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA24000 for ; Wed, 11 Sep 1996 12:40:17 -0700 (PDT) Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.7.5/8.7.5) with SMTP id OAA20821; Wed, 11 Sep 1996 14:40:00 -0500 (CDT) Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.5) id ; Wed, 11 Sep 96 14:39 CDT Received: (from karl@localhost) by Jupiter.mcs.net (8.7.5/8.7.5) id OAA02328; Wed, 11 Sep 1996 14:39:57 -0500 (CDT) From: Karl Denninger Message-Id: <199609111939.OAA02328@Jupiter.mcs.net> Subject: Re: SYN Resisting (fwd) To: michael@memra.com (Michael Dillon) Date: Wed, 11 Sep 1996 14:39:57 -0500 (CDT) Cc: freebsd-hackers@freebsd.org In-Reply-To: from "Michael Dillon" at Sep 11, 96 11:28:57 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Diffs to implement this patch are enclosed. These are against -CURRENT, but these files haven't changed much in recent months, so they may work against any of the FreeBSD releases with slight offsets. This changes the startup connection timeout to 10 seconds, which should be more than enough on the Internet of today to prevent dropped links. 75 seconds is only needed if you're running across two pieces of wet string. Index: uipc_socket2.c =================================================================== RCS file: /usr/cvs/src/sys/kern/uipc_socket2.c,v retrieving revision 1.13 diff -r1.13 uipc_socket2.c 165a166 > #ifndef SYN_FLOOD_RESIST 167a169 > #endif Index: tcp_timer.h =================================================================== RCS file: /usr/cvs/src/sys/netinet/tcp_timer.h,v retrieving revision 1.9 diff -r1.9 tcp_timer.h 98a99,101 > #ifdef SYN_FLOOD_RESIST > #define TCPTV_KEEP_INIT ( 10*PR_SLOWHZ) /* initial connect keep alive */ > #else 99a103 > #endif Patch, define "options SYN_FLOOD_RESIST" in your config file and recompile the kernel to implement. If you leave the option off, the diffs enclosed do nothing. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1 from $600 monthly; speeds to DS-3 available | 23 Chicagoland Prefixes, 13 ISDN, much more Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | Home of Chicago's only FULL Clarinet feed! > > Is FreeBSD resistant to this kind of SYN attack? > > Michael Dillon - ISP & Internet Consulting > Memra Software Inc. - Fax: +1-604-546-3049 > http://www.memra.com - E-mail: michael@memra.com > > ---------- Forwarded message ---------- > Date: Wed, 11 Sep 1996 14:08:56 -0400 > From: Avi Freedman > To: nanog@merit.edu > Cc: alexis@panix.com, freedman@netaxs.com > Subject: SYN Resisting > > I know this may not be strictly on-topic here because it deals with > "host-stuff" rather than "router-stuff", but here goes... > > I will have some comments on how to track where SYN storms are coming > from a bit later. > > In order to build a SYN-resistant BSD kernel, you need to modify one > file in src/sys/os, uipc_socket2.c, and you also need to modify > src/sys/netinet/tcp_timer.h and you have to rebuild tcp_usrreq.c and > tcp_input.c in the netinet directory. > > For those without SunOS source, I will get Sun4c (Sparc 1/1+/2/IPC/IPX/ > ELC/SLC) binaries online; for those running BSD on other platforms, you > probably have source. > > >From the bottom level up, change TCPTV_KEEP_INIT from 75*PR_SLOWHZ > to 7*PR_SLOWHZ (or whatever # you want). This timeout (the 75) is > the number of seconds that the kernel will keep un-established TCP > PCB/sockets around for... When the SYN is received, it is acknowledged > and the PCB && socket are set up for the embryonic session; the goal > is to rip those things out of any queues they're in more aggressively. > > At the top (socket) level, instead of modifying SOMAXCONN, I decided to > just see what happened if I removed the limit. What you do is up to your > own personal taste. I commented out: > > if (head->so_qlen + head->so_q0len > 3 * head->so_qlimit / 2) > goto bad; > > in src/sys/os/uipc_socket2.c. > > Head in this case points to a 'server' socket (the socket for your > web, mail, news, ... server). so_qlimit is set to the min of either > what the listen() system call inside of it requested or SOMAXCONN. > I had some funkiness increasing SOMAXCONN to 8096 or so when I was > playing with it - and didn't want to recompile inetd, sendmail, etc... > to ask for more slots in the listen() queue (just a linked list or two), > so I figured I'd *try* to make the queue size infinite and see what > happened. so_qlen and so_q0len are the linked lists of sockets waiting > to be accept()ed and the sockets of the embryonic (not established) > TCP connections that were aimed at this server socket, respectively. > The code uses a 3/2 fudge factor to make the comparison, and is saying > "if the number of queued requests is > 3/2 times the limit for this > socket, don't stick this requesting socket in the queue - just destroy > it and exit". > > I just commented those two lines out. > > On a Sparc 1+ w/ 4.1.4, I could sustain a 200-400 SYN-packet/sec attack > and still remain functional (and quick for a 1+), but the machine didn't > normally run web servers... Even when I nailed it with 1000 SYNs/sec, > the machine continued functioning but I couldn't connect to the socket > being nailed. A second after stopping the heavier attack, I could. > > I've had trouble compiling and getting these modified modules to work on a > Sun4m architecture (Sparc 5 and 10) but may play more with that today. > > The best solution is to implement a better data structure than a linked > list for storing the embryonic connections per socket. A large-ish array > with appropriate hashing, perhaps. Either per socket or for the whole > kernel. If anyone wants to attack that problem, please do; otherwise, > I'll blow BSD on a laptop so I can play with it when I'm next on a plane/ > train. > > Avi > > From owner-freebsd-hackers Wed Sep 11 12:44:08 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA24181 for hackers-outgoing; Wed, 11 Sep 1996 12:44:08 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA24176 for ; Wed, 11 Sep 1996 12:44:03 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id FAA09143; Thu, 12 Sep 1996 05:41:46 +1000 Date: Thu, 12 Sep 1996 05:41:46 +1000 From: Bruce Evans Message-Id: <199609111941.FAA09143@godzilla.zeta.org.au> To: hackers@freebsd.org, hasty@rah.star-gate.com Subject: Re: clock drift and clock.c Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Assuming that xntpd gives over a 24 hour period a clock drift of 122, >what are the mods to clock.c to eliminate the clock drift. In my >case, I think that my clock drift is fix. In -current you can adjust the clock frequency using `sysctl machdep.i8254_freq=whatever'. In all versions you can do the same using `options TIMER_FREQ=whatever' in the kernel config file. However, this is only good for adjusting to the nearest 50 ppm. I will commit some changes to make this work better RSN. I guess it's easier to just use xntpd without any network connections or clocks. Put `122.000 1' or `-122.000 1' in /etc/ntp.drift, start xntpd, then kill xntpd (no point in keeping it running since it won't do anything other than initialization). The `1' in ntp.drift is a flag that tells xntpd to use the kernel PLL. It will start the kernel PLL and won't stop it when it is killed. Bruce From owner-freebsd-hackers Wed Sep 11 12:59:46 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA24944 for hackers-outgoing; Wed, 11 Sep 1996 12:59:46 -0700 (PDT) Received: from gatekeeper.ctron.com (ctron.com [134.141.197.25]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA24938 for ; Wed, 11 Sep 1996 12:59:41 -0700 (PDT) Received: (from news@localhost) by gatekeeper.ctron.com (8.6.12/8.6.9) id PAA24905; Wed, 11 Sep 1996 15:58:22 -0400 Received: from stealth.ctron.com(134.141.5.107) by gatekeeper via smap (V1.3mjr) id sma024879; Wed Sep 11 15:57:57 1996 Received: from thoth.ctron.com by stealth.ctron.com (4.1/SMI-4.1) id AB18055; Wed, 11 Sep 96 15:55:15 EDT Received: from thoth (localhost [127.0.0.1]) by thoth.ctron.com (8.6.12/8.6.12) with SMTP id PAA05975; Wed, 11 Sep 1996 15:59:06 -0400 Message-Id: <32371A09.451E@ctron.com> Date: Wed, 11 Sep 1996 15:59:05 -0400 From: Alexander Seth Jones Organization: Cabletron Systems, Inc. X-Mailer: Mozilla 3.0b5aGold (X11; I; SunOS 5.4 sun4m) Mime-Version: 1.0 To: Terry Lambert Cc: hackers@freefall.freebsd.org Subject: Re: shared libg++2.7.2 References: <199609111816.LAA05138@phaeton.artisoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert wrote: > > > Anyone gotten the libg++2.7.2 libraries built shared? I keep getting > > this error: > > > > ld: No reference to __DYNAMIC > > > > Where should this be defined? > > Are you sure this is what it says exactly? > > "no reference to" means no one imports the symbol. > > Typically, this would mean you are linking against the wrong ctr0; > try explicitly referencing it on the ld line instead of letting the > compiler call the ld for you. This is probably just a config bug > in the GCC distribution. > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. Well, I'm getting a little further along... It does seem as though there's a problem with the GCC distribution of 2.7.2.1. It won't make shared libs for libg++2.7.2 out of the box. I end up doing: ld -Bshareable -o libxxx.so.2.7.2 /usr/lib/c++rt0.o `cat piclist` and this works fine; the ld error goes away. But, there seems to be another problem. When compiling exceptioni.cc from the stdc++ lib, I get the following warning from the assembler: /var/tmp/cc000339.s: Assembler messages: /var/tmp/cc000339.s:603: Warning: GOT relocation burb: `___EXCEPTION_TABLE__' should be global and I then create the shared lib as above. But linking just a little program that cout's "hi", core dumps in __register_exceptions before main is called. I know the exception handling code is sketchy right now, but ... Any compiler gurus care to offer some insight? Is this a compiler problem, an assembler problem, or has anyone actually gotten the libs built shared and I'm doing something outlandishly dumb? I'd like to see if other people are running into this problem before I report it to the GNU people. -- Alex Jones | ajones@ctron.com Cabletron Systems, Inc. Durham, NH USA 03824 From owner-freebsd-hackers Wed Sep 11 13:10:53 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA26600 for hackers-outgoing; Wed, 11 Sep 1996 13:10:53 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA26590 for ; Wed, 11 Sep 1996 13:10:49 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA05436; Wed, 11 Sep 1996 13:09:43 -0700 From: Terry Lambert Message-Id: <199609112009.NAA05436@phaeton.artisoft.com> Subject: Re: shared libg++2.7.2 To: ajones@ctron.com (Alexander Seth Jones) Date: Wed, 11 Sep 1996 13:09:43 -0700 (MST) Cc: terry@lambert.org, hackers@freefall.freebsd.org In-Reply-To: <32371A09.451E@ctron.com> from "Alexander Seth Jones" at Sep 11, 96 03:59:05 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > But, there seems to be another problem. When compiling exceptioni.cc > from the stdc++ lib, I get the following warning from the assembler: > > /var/tmp/cc000339.s: Assembler messages: > /var/tmp/cc000339.s:603: Warning: GOT relocation burb: > `___EXCEPTION_TABLE__' should be global > > and I then create the shared lib as above. But linking just a little > program that cout's "hi", core dumps in __register_exceptions before > main is called. I know the exception handling code is sketchy right > now, but ... IO believe it relies on use of weak symbols for the subclassing. Our assembler does not support weak symbols. One possible approach would be to install John Polstra's "ELFKit"; this presumes you are running -current, and so have an execution class loader for BSD ELF binaries. You would then use the newer binutils and avoid the problem. I don't know of another fix in the context of the current build tools. Alternately, there were a number of weak symbol fixes that went into 2.7.2.1 -- which is the release you should be running instead of 2.7.2; it is a set of patches against 2.7.2. They have been promising to integrate the patches with some other fixes and rerelease as 2.7.3 for about 3 months now; I would not hold my breath. > Any compiler gurus care to offer some insight? Is this a compiler > problem, an assembler problem, or has anyone actually gotten the libs > built shared and I'm doing something outlandishly dumb? > > I'd like to see if other people are running into this problem before I > report it to the GNU people. I don't know anyone who is successfully running the 2.7.2 code. You should check the GCC mailing lists, since I remember someone claiming to use them with a couple of patches on top of the 2.7.2.1 patches (sorry, I have no more information than that; I get the lists bridged, and I only read them occasionally to keep on top of things, so I don't save stuff off other than release announcements). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Sep 11 13:25:19 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA27469 for hackers-outgoing; Wed, 11 Sep 1996 13:25:19 -0700 (PDT) Received: from scooter.quickweb.com (scooter.quickweb.com [199.212.134.8]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA27463 for ; Wed, 11 Sep 1996 13:25:14 -0700 (PDT) Received: from localhost (mark@localhost) by scooter.quickweb.com (8.6.12/8.6.12) with SMTP id QAA25800 for ; Wed, 11 Sep 1996 16:27:15 -0400 Date: Wed, 11 Sep 1996 16:27:15 -0400 (EDT) From: Mark Mayo To: hackers@freebsd.org Subject: forking program ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I remember some time back someone posted a little piece of code that forked and allocated memory until the OS gave up.. and the same program appeared with an NT version (using CreateThread instead of fork()). I wanted to take a closer look at it, but it seems I can't find any mention of where to get it anywhere in my mail folders.. :-( If anyone know of its location, please forward me the URL ! TIA, -mark ------------------------------------------- | Mark Mayo mark@quickweb.com | | C-Soft www.quickweb.com | ------------------------------------------- "To iterate is human, to recurse divine." - L. Peter Deutsch From owner-freebsd-hackers Wed Sep 11 13:25:26 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA27490 for hackers-outgoing; Wed, 11 Sep 1996 13:25:26 -0700 (PDT) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA27477; Wed, 11 Sep 1996 13:25:21 -0700 (PDT) Received: from localhost (tom@localhost) by misery.sdf.com (8.7.5/8.7.3) with SMTP id NAA24710; Wed, 11 Sep 1996 13:45:20 -0700 (PDT) Date: Wed, 11 Sep 1996 13:45:18 -0700 (PDT) From: Tom Samplonius To: Gary Palmer cc: Greg Rowe , hackers@FreeBSD.org Subject: Re: Bind Version ? In-Reply-To: <25806.842380287@orion.webspan.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 10 Sep 1996, Gary Palmer wrote: > "Greg Rowe" wrote in message ID > <9609090810.ZM23757@nevis.oss.uswest.net>: > > > Is there an easy way to determine the version of Bind running on > > FreeBSD tha t somehow corresponds to Paul's version naming scheme > > (4.9.X) ? I'm interested in knowing the version/patch level for > > 2.1.5. Thanks. > > Look in the CVS logs unfortunately :-( > > 4.8.3BETA24 I believe. No, I think it is 4.9.3 BETA 9 4.8.3 is *very* old. I believe BSD4.4 came with 4.8.3 RELEASE. Tom From owner-freebsd-hackers Wed Sep 11 13:36:33 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA28398 for hackers-outgoing; Wed, 11 Sep 1996 13:36:33 -0700 (PDT) Received: from orion.webspan.net (root@orion.webspan.net [206.154.70.41]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA28392 for ; Wed, 11 Sep 1996 13:36:30 -0700 (PDT) Received: from localhost (gpalmer@localhost [127.0.0.1]) by orion.webspan.net (8.7.5/8.6.12) with SMTP id QAA11887; Wed, 11 Sep 1996 16:36:04 -0400 (EDT) X-Authentication-Warning: orion.webspan.net: Host gpalmer@localhost [127.0.0.1] didn't use HELO protocol To: Tom Samplonius cc: Greg Rowe , hackers@FreeBSD.org From: "Gary Palmer" Subject: Re: Bind Version ? In-reply-to: Your message of "Wed, 11 Sep 1996 13:45:18 PDT." Date: Wed, 11 Sep 1996 16:36:03 -0400 Message-ID: <11883.842474163@orion.webspan.net> Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Tom Samplonius wrote in message ID : > > 4.8.3BETA24 I believe. > No, I think it is 4.9.3 BETA 9 Whoops. Typo. I meant 4.9.3. And from the CVS log: revision 1.2.4.1 date: 1995/08/30 04:07:23; author: davidg; state: Exp; lines: +9 -14 Brought in changes from main branch: update to BIND 4.9.3-beta24 So it was BETA24 that went into 2.1.5 Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info From owner-freebsd-hackers Wed Sep 11 13:55:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA29584 for hackers-outgoing; Wed, 11 Sep 1996 13:55:02 -0700 (PDT) Received: from mail.cs.utexas.edu (root@mail.cs.utexas.edu [128.83.139.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA29572 for ; Wed, 11 Sep 1996 13:54:55 -0700 (PDT) Received: from opus.cs.utexas.edu (miker@opus.cs.utexas.edu [128.83.143.208]) by mail.cs.utexas.edu (8.7.1/8.7.1) with ESMTP id PAA19531; Wed, 11 Sep 1996 15:54:53 -0500 (CDT) From: Hung Michael Nguyen Received: by opus.cs.utexas.edu (8.7.1/Client-1.4) id PAA57036; Wed, 11 Sep 1996 15:54:52 -0500 Message-Id: <199609112054.PAA57036@opus.cs.utexas.edu> Subject: Re: shared libg++2.7.2 To: ajones@ctron.com (Alexander Seth Jones) Date: Wed, 11 Sep 1996 15:54:52 -0500 (CDT) Cc: terry@lambert.org, hackers@freefall.freebsd.org In-Reply-To: <32371A09.451E@ctron.com> from "Alexander Seth Jones" at Sep 11, 96 03:59:05 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Well, I'm getting a little further along... > > It does seem as though there's a problem with the GCC distribution of > 2.7.2.1. It won't make shared libs for libg++2.7.2 out of the box. I > end up doing: > > ld -Bshareable -o libxxx.so.2.7.2 /usr/lib/c++rt0.o `cat piclist` > > and this works fine; the ld error goes away. You must have run libg++'s or g++'s configure wrong, I ran it with no options and it worked. See below. > > But, there seems to be another problem. When compiling exceptioni.cc > from the stdc++ lib, I get the following warning from the assembler: > > /var/tmp/cc000339.s: Assembler messages: > /var/tmp/cc000339.s:603: Warning: GOT relocation burb: > `___EXCEPTION_TABLE__' should be global > > and I then create the shared lib as above. But linking just a little > program that cout's "hi", core dumps in __register_exceptions before > main is called. I know the exception handling code is sketchy right > now, but ... > > Any compiler gurus care to offer some insight? Is this a compiler > problem, an assembler problem, or has anyone actually gotten the libs > built shared and I'm doing something outlandishly dumb? > > I'd like to see if other people are running into this problem before I > report it to the GNU people. Well, it just so happens that I built gcc 2.7.2.1 and libg++ 2.7.2 on my 2.1.5 based system. All I did for gcc was #./configure #make LANGUAGE=c #make stage1 #make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O2" #make install Before doing libg++, I renamed gcc, g++, and c++ in /usr/bin to gcc-2.6.3, g++-2.6.3, and c++-2.6.3, respectively, so that I was sure the new compiler was used. For libg++: #./configure #make #make install Worked like a charm. Note that passing --enable-shared to configure will fail. It built the ppc601 simulator which I worked on for a class this summer, written in c++ with lots of iostream stuff. Also, I haven't gotten the latest pgcc (which seems to be based on a pre-release 2.8.0 now, at least it seems so looking at the release notes) to build itself (it emits an instruction as doesn't grok), much less libg++. Anybody have insights on that? Mike. From owner-freebsd-hackers Wed Sep 11 14:14:18 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA01547 for hackers-outgoing; Wed, 11 Sep 1996 14:14:18 -0700 (PDT) Received: from clipper.cs.kiev.ua (root@cs-demon.ua.net [193.124.48.251]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA01537 for ; Wed, 11 Sep 1996 14:14:11 -0700 (PDT) Received: from dog by clipper.cs.kiev.ua with uucp id m0v0wUm-000szZC; Thu, 12 Sep 96 00:06 WET DST Received: (from dk@localhost) by dog.farm.org (8.7.5/dk#3) id MAA14991; Wed, 11 Sep 1996 12:21:06 -0700 (PDT) Date: Wed, 11 Sep 1996 12:21:06 -0700 (PDT) From: Dmitry Kohmanyuk Message-Id: <199609111921.MAA14991@dog.farm.org> To: regnauld@tetard.glou.eu.org (Philippe Regnauld) Cc: freebsd-hackers@freebsd.org Subject: Re: single-user console in 2.1.5 Newsgroups: cs-monolit.gated.lists.freebsd.hackers Organization: FARM Computing Association Reply-To: dk+@ua.net X-Newsreader: TIN [version 1.2 PL2] Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199609101700.TAA02302@tetard.glou.eu.org> you wrote: > This probably shoudn't go in hackers but... =20 > I changed 'secure' to insecure in /etc/ttys for the console : > console none unknown off insecure > This is so that the root password is asked when going to > single-user mode. Unfortunately, it doesn't work (refused every I bet you've installed securedist (DES), but your init haven't been updated. unpack sbin sources are recompile init (there are also some other programs which use -lcrypt and are compiled statically, bdes, smth else?), but only init is important here. > time). I'm using DES on a stock 2.1.5. Haven't tried w/ current > yet.=20 -- The President is not in his office at this time. Please leave your name, phone number, the name of the country you wish to invade, and the secret password. From owner-freebsd-hackers Wed Sep 11 14:35:34 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA02734 for hackers-outgoing; Wed, 11 Sep 1996 14:35:34 -0700 (PDT) Received: from FileServ1.MI.Uni-Koeln.DE (FileServ1.MI.Uni-Koeln.DE [134.95.212.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA02720 for ; Wed, 11 Sep 1996 14:35:21 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr2-43.slip.Uni-Koeln.DE) by FileServ1.MI.Uni-Koeln.DE with SMTP id AA06179 (5.67b/IDA-1.5 for ); Wed, 11 Sep 1996 23:35:11 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.7.5/8.6.9) id WAA03498; Wed, 11 Sep 1996 22:29:54 +0200 (MET DST) Date: Wed, 11 Sep 1996 22:29:54 +0200 (MET DST) Message-Id: <199609112029.WAA03498@x14.mi.uni-koeln.de> From: Stefan Esser To: Peter Hawkins Cc: hackers@freebsd.org Subject: Re: PCI PnP question In-Reply-To: <199609070837.SAA17623@palin.cc.monash.edu.au> References: <199609070837.SAA17623@palin.cc.monash.edu.au> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Peter Hawkins writes: Hi Peter! I'm feeling responsible for the PCI code in FreeBSD, so I'll try to get you going ... :) > I'm writing a driver for a pci card, but every time I plug it in (regardless > of whether I load the kernal with the driver) I see that ed1 (my ethernet card) > fails at boottime (can't clear memory c8000). I'm not really a PC person so Is this ed1 an ISA or another PCI card ? The ED driver supports a number of different cards, some of which need a memory region, others don't (they use rep inw/outw for the data transfer to the cards SRAM buffer). Best if you do a VERBOSE boot (enter "-v" at the boot prompt, and send me the output as written to /var/log/messages). > the vagaries of it's memory management are not things I follow well. I can't > find any way to adjust the way the bios allocates windows to pci devices > so I have to assume it doesn't overlap isa. I know this particular card requires The PCI BIOS assigns non-overlapping port and memory addresses to each card, as required by the hardware. If an ISA compatible PCI card needs memory in the >640K hole, then it is the card BIOS or driver that knows about this. PCI generally uses attach addresses higher than 256MB, most often in the >3GB quadrant, in order to not overlap with any legacy device. > 16k of memory. Can anyone enlighten me here and tell me how to avoid conflicts > (other than moving the card to another slot). Please boot without the card (and send me the verbose boot log as described above). Then insert the new PCI card and boot again, possibly with the Ethernet card removed (hoping the boot will succeed, then), again with "-v". If the boot fails, then you'll have to write down the corresponding probe line, something like: pci0:15:6: vendor=0x1234, device=0x0008, class=0x01, subclass=0x00 [no driver assigned] map(10): mem32(fec01008) map(14): io(4100) > Also does anyone know what the bios uses as a memory mapping strategy? This is generally not of any interest (and not published, nor guaranteed to be the same between BIOS releases), since it suffices to have non- overlapping regions for each device. The PCI specs describe how the map registers decode the size of the mapping, and the BIOS generally scans a PCI bus in either ascending or descending slot number, giving each device found a memory or port range adjusted to its size (i.e. a 4KB mapping will start on an address that is a multiple of 4KB) ascending or descending from a known unused physical address. In my system slots appear to be scanned from low to high numbers, and addresses are assigned going down from mem addr 0xfbfff000 and port 0xf000 (don't know why the port addresses assigned are so far apart): Probing for devices on PCI bus 0: configuration mode 2 allows 16 devices. chip0 rev 4 on pci0:0 ncr0 rev 1 int a irq 9 on pci0:1 mapreg[10] type=1 addr=0000e800 size=0100. mapreg[14] type=0 addr=fbfef000 size=0100. reg20: virtual=0xf4288000 physical=0xfbfef000 size=0x100 chip1 rev 3 on pci0:2 vga0 rev 0 on pci0:5 mapreg[10] type=0 addr=fb000000 size=800000. ed1 rev 0 int a irq 12 on pci0:6 mapreg[10] type=1 addr=0000e400 size=0020. pci0: uses 8388864 bytes of memory from fb000000 upto fbfef0ff. pci0: uses 288 bytes of I/O space from e400 upto e8ff. Regards, STefan From owner-freebsd-hackers Wed Sep 11 14:45:32 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA04070 for hackers-outgoing; Wed, 11 Sep 1996 14:45:32 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA04053; Wed, 11 Sep 1996 14:45:27 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id XAA08985; Wed, 11 Sep 1996 23:17:07 +0200 From: Luigi Rizzo Message-Id: <199609112117.XAA08985@labinfo.iet.unipi.it> Subject: Changing default TCP window size ? To: hackers@freebsd.org Date: Wed, 11 Sep 1996 23:17:07 +0200 (MET DST) Cc: wollman@lcs.mit.edu, phk@freebsd.org X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk How do I force TCP (or the OS) to use a window size different from the default 16K ? The following code mywin=DESIRED_WINDOW_SIZE; setsockopt(f, SOL_SOCKET, SO_SNDBUF, (char *)&mywin, sizeof mywin) appears to set the value correctly (it can be read back with getsockopt) but then it appears not to have any effect on TCP (monitoring the connection with netstat -na always shows a Send-Q around 16KB, and the throughput in window-limited configurations remains unchanged). I have also tried to alter net.inet.tcp.sendspace but with no effect. I am asking because I would really like to try out large windows and check if RFC1323 extensions really work (I have been told there are some unspecified problems). Thanks Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ==================================================================== From owner-freebsd-hackers Wed Sep 11 15:07:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA06551 for hackers-outgoing; Wed, 11 Sep 1996 15:07:35 -0700 (PDT) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA06531; Wed, 11 Sep 1996 15:07:26 -0700 (PDT) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id QAA07690; Wed, 11 Sep 1996 16:07:11 -0600 (MDT) Date: Wed, 11 Sep 1996 16:07:11 -0600 (MDT) Message-Id: <199609112207.QAA07690@rocky.mt.sri.com> From: Nate Williams To: hosokawa@mt.cs.keio.ac.jp (HOSOKAWA Tatsumi) Cc: freebsd-mobile@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: PAO-960911 In-Reply-To: <199609111933.EAA28692@frig.mt.cs.keio.ac.jp> References: <199609111933.EAA28692@frig.mt.cs.keio.ac.jp> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk HOSOKAWA Tatsumi writes: > Now I'm merging Nate Williams' changes for APM and pccard stuff into > PAO. PAO-960911 is the interim release of this work. > > ftp://ryukyu.mt.cs.keio.ac.jp/pub/FreeBSD/PAO/PAO-960911.tar.gz > > This package is for 2.2-960801-SNAP only. THANK YOU! (When I get back from my business trip we can discuss this some more, but my initial look at this cheers me up. :) Nate From owner-freebsd-hackers Wed Sep 11 15:32:50 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA08265 for hackers-outgoing; Wed, 11 Sep 1996 15:32:50 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA08251 for ; Wed, 11 Sep 1996 15:32:48 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.6.12/8.6.12) with SMTP id PAA11515 for ; Wed, 11 Sep 1996 15:32:43 -0700 Date: Wed, 11 Sep 1996 15:32:43 -0700 (PDT) From: Jaye Mathisen Reply-To: Jaye Mathisen To: hackers@freebsd.org Subject: Routed issues, and some questions on the routed code. Looks flaky. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have FreeBSD acting as a router on several boxes here, and for some weird reason, it's broadcasting itself as the default route on all interfaces, even ones where is doesn't make sense. ie: Net A + --- +-----------+ | FBSD1 | Cisco to rest of world Net B + --- +-----------+ \ / Net C / \ Net D + --- +-----------+ Node X | FBSD2 | Net E + --- +-----------+ The Cisco is kicking out RIP packets saying it has the default route. So far so good. But routed running on FBSD1 is broadcasting to Net A, Net B, and Net C that it has the default route. So Node X running routed -q sees first the Cisco as the default, then FBSD1, then FBSD2. Everything works, because they get redirected when the packets for off-site get to FBSD1 then the static route apparently takes over and it sends them to the Cisco, and so on. But I want FBSD1 to advertise via RIP that it has Net A and B, and on the Net A/B side I want it to advertise itself as the default, but on the C side, I want it to just send out that it's the router for A and B and STFU about the default. Similar things apply to FBSD2. I'm running the -current routed on everything, but no luck so far. On the Cisco I can put a distribute list to tell it not to blab some of this stuff (or rather the second cisco not shown going off to the FR cloud). But I don't see that functionality. I mucked with putting stuff in /etc/gateways, but routed hollers if the Cisco is marked passive, since it actually kicks out routing info. There appears to be some funkyness in the parms.c file for routed as well. "active" is listed on the man page as a valid parameter, but when going through the code, it doesn't appear to be valid. Also, the test for active implies that somehow you can get a "null" (\0) in the field and that's used to determine remote gateways, but I can't see how you can even get to the if statement, since you have to match 5 parameters in the scanf above, and with nothing after the metric number, you only get 4. SO I think there's some flakiness in the code. From owner-freebsd-hackers Wed Sep 11 17:29:26 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA17076 for hackers-outgoing; Wed, 11 Sep 1996 17:29:26 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA17055; Wed, 11 Sep 1996 17:29:20 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.6.12/8.6.12) with SMTP id RAA23952; Wed, 11 Sep 1996 17:29:18 -0700 Date: Wed, 11 Sep 1996 17:29:17 -0700 (PDT) From: Jaye Mathisen To: hackers@freebsd.org, current@freebsd.org Subject: -current and perl5.003? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A box supped as of yesterday is not passing 1 test for perl5.003. The following fails: (op/exec) if ((system "/bin/sh -c 'exit 1'") != 256) { print "not "; } print "ok 5\n"; It's got me. It passes just fine on everything supped before then, but nothing in the sup looked like it could have the remotest effect. From owner-freebsd-hackers Wed Sep 11 17:51:06 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA18358 for hackers-outgoing; Wed, 11 Sep 1996 17:51:06 -0700 (PDT) Received: from spiff.cc.iastate.edu (spiff.cc.iastate.edu [129.186.142.89]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA18350 for ; Wed, 11 Sep 1996 17:51:03 -0700 (PDT) Received: by spiff.cc.iastate.edu with sendmail-5.65 id ; Wed, 11 Sep 1996 19:51:02 -0500 Message-Id: <9609120051.AA08227@spiff.cc.iastate.edu> To: hackers@freebsd.org Reply-To: graphix@iastate.edu Subject: OpenBSD <-> FreeBSD Date: Wed, 11 Sep 1996 19:51:02 CDT From: Kent Vander Velden Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there anyone tracking the changes that are made to the 4.4 source in NetBSD/OpenBSD and incorporating the changes into the FreeBSD tree on a regular basis? If not, what is the common feeling of if this would be a do-able and useful contribution to FreeBSD in general for a person that is generally already fairly taxed but wants to help? Perhaps the changes are too extreme but my original thought was that the trees would be similar enough that finding and understanding the changes would be possible. Thanks. --- Kent Vander Velden graphix@iastate.edu From owner-freebsd-hackers Wed Sep 11 17:51:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA18382 for hackers-outgoing; Wed, 11 Sep 1996 17:51:10 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA18348 for ; Wed, 11 Sep 1996 17:51:01 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id KAA05838; Thu, 12 Sep 1996 10:20:45 +0930 From: Michael Smith Message-Id: <199609120050.KAA05838@genesis.atrad.adelaide.edu.au> Subject: Re: NFS locking (fwd) To: lada@ws2301.gud.siemens.co.at (Hr.Ladavac) Date: Thu, 12 Sep 1996 10:20:44 +0930 (CST) Cc: hackers@freebsd.org In-Reply-To: <199609111412.AA238531140@ws2301.gud.siemens.co.at> from "Hr.Ladavac" at Sep 11, 96 04:12:20 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >From Jos.Vissers@telebyte.nl Wed Sep 11 15:23:18 MES 1996 > > I heard that Linux will be or is supporting it, and personally I'd > rather stay with FreeBSD, but my employer is convinced that > Linux is better. FreeBSD provides as much (if not more) support for the NFS protocol as Linux does. (ie. they both spoof it). If you're serious about making something happen, or you (like me) believe that your employer is a fool, then hop on the bandwagon behind Terry; offer to help test his code changes that relate to it & help agitate for its inclusion. I'm fairly sure that both the user-space and kernel-space changes to support it exist in at least an alpha stage. -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Wed Sep 11 18:42:47 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA21001 for hackers-outgoing; Wed, 11 Sep 1996 18:42:47 -0700 (PDT) Received: from ottawa.net (ppp-91.ottawa.net [205.211.4.91]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA20992 for ; Wed, 11 Sep 1996 18:42:38 -0700 (PDT) Received: (from brianc@localhost) by ottawa.net (8.7.5/8.7.3) id VAA00555 for freebsd-hackers@FreeBSD.org; Wed, 11 Sep 1996 21:41:35 -0400 (EDT) From: Brian Campbell Message-Id: <199609120141.VAA00555@ottawa.net> Subject: Re: IDE and ASUS P/I-P6NP5 To: freebsd-hackers@FreeBSD.org (FreeBSD Hackers) Date: Wed, 11 Sep 1996 21:41:35 -0400 (EDT) In-Reply-To: <199609111826.LAA05182@phaeton.artisoft.com> from Terry Lambert at "Sep 11, 96 11:26:00 am" Reply-to: brianc@pobox.com X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > The Pentium Pro ASUS P/I-P6NP5 board claims to support > > onboard IDE (bus master) at 17 MB/s in PIO mode and 22MB/s in > > DMA mode. > > > > How useful is this under FreeBSD-current? Does the IDE driver support > > this? Are there any IDE disk drives allowing for transfer rates > > in the range of those achieved by SCSI drives? Would that rule out > > SCSI as the choice when you want to have really fast disk access? In my experience it makes a noticeable difference. If there's support for it available you should take advantage of it. > DMA mode isn't supported AFAIK. > > I think the problem is still that it is impossible to reliably detect > support for the mode without crashing older (WD1007, etc.?) hardware. And Terry clearly has a problem with IDE in general. Nonetheless I'd really love to have a bus-mastering IDE driver available. I could care less if it automatically detects older hardware, although other operating systems manage to do this. I'd be happy to manually specify that my IDE chipset and drive were "DMA capable" for the dual benefit of freeing up the CPU for more useful tasks and increased throughput. Now if we can just find someone capable of doing the work ;-) From owner-freebsd-hackers Wed Sep 11 18:54:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA21536 for hackers-outgoing; Wed, 11 Sep 1996 18:54:10 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA21531; Wed, 11 Sep 1996 18:54:07 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id LAA19415; Thu, 12 Sep 1996 11:50:16 +1000 Date: Thu, 12 Sep 1996 11:50:16 +1000 From: Bruce Evans Message-Id: <199609120150.LAA19415@godzilla.zeta.org.au> To: current@freebsd.org, hackers@freebsd.org, mrcpu@cdsnet.net Subject: Re: -current and perl5.003? Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >A box supped as of yesterday is not passing 1 test for perl5.003. > >The following fails: > >(op/exec) > >if ((system "/bin/sh -c 'exit 1'") != 256) { print "not "; } >print "ok 5\n"; > > > >It's got me. It passes just fine on everything supped before then, but >nothing in the sup looked like it could have the remotest effect. `exit 1' in a shell script now exits with status 0 :-(. Yesterday's change obviously broke it. Bruce Index: main.c =================================================================== RCS file: /a/ncvs/src/bin/sh/main.c,v retrieving revision 1.6 retrieving revision 1.5 diff -c -2 -r1.6 -r1.5 *** main.c 1996/09/08 03:12:22 1.6 --- main.c 1996/09/01 10:20:38 1.5 *************** *** 340,350 **** char **argv; { - extern int oexitstatus; - if (stoppedjobs()) return 0; if (argc > 1) exitstatus = number(argv[1]); ! exitshell(oexitstatus); /*NOTREACHED*/ return 0; --- 340,348 ---- char **argv; { if (stoppedjobs()) return 0; if (argc > 1) exitstatus = number(argv[1]); ! exitshell(exitstatus); /*NOTREACHED*/ return 0; From owner-freebsd-hackers Wed Sep 11 19:05:47 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA22112 for hackers-outgoing; Wed, 11 Sep 1996 19:05:47 -0700 (PDT) Received: from mx.serv.net (mx.serv.net [199.201.191.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA22105 for ; Wed, 11 Sep 1996 19:05:36 -0700 (PDT) Received: from MindBender.serv.net by mx.serv.net (8.7.5/SERV Revision: 2.30 † id TAA05857; Wed, 11 Sep 1996 19:00:16 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.serv.net (8.7.5/8.7.3) with SMTP id TAA23852; Wed, 11 Sep 1996 19:00:02 -0700 (PDT) Message-Id: <199609120200.TAA23852@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: Mark Mayo cc: hackers@freebsd.org Subject: Re: forking program ? In-reply-to: Your message of Wed, 11 Sep 96 16:27:15 -0400. Date: Wed, 11 Sep 1996 19:00:00 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I remember some time back someone posted a little piece of code that >forked and allocated memory until the OS gave up.. and the same program >appeared with an NT version (using CreateThread instead of fork()). Appended first is the original article that started the thread. Appended second is the NT version that I wrote. You should be able to find anything else by searching the FreeBSD archives using the information in these two messages... ---------- >8 ----- Begin article ----- 8< ---------- (Message freebsd/hackers:3826) Return-Path: owner-freebsd-hackers@freefall.freebsd.org Received: from smyrno.sol.net (smyrno.sol.net [206.55.64.117]) by MindBender.HeadCandy.com (8.7.5/8.7.3) with SMTP id LAA00987 for ; Thu, 8 Aug 1996 11:54:43 -0700 (PDT) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.4]) by smyrno.sol.net (8.6.11/8.6.12) with ESMTP id NAA29676; Thu, 8 Aug 1996 13:50:13 -0500 Received: from localhost (daemon@localhost) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA04359; Thu, 8 Aug 1996 11:35:10 -0700 (PDT) Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA04161 for hackers-outgoing; Thu, 8 Aug 1996 11:32:20 -0700 (PDT) Received: from cmr.kiev.ua (cmr.kiev.ua [193.193.193.50]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA04130 for ; Thu, 8 Aug 1996 11:31:09 -0700 (PDT) Received: (archer@localhost) by cmr.kiev.ua (Sendmail 8.who.cares/5) id TAA15058; Thu, 8 Aug 1996 19:19:17 GMT Date: Thu, 8 Aug 1996 22:19:17 +0300 (EET DST) From: "Litvin Alexander B. " To: hackers@freebsd.org Subject: "Panick" - help needed... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, All! I was advised by J.K.Habbard to send this into freebsd.hackers, so here my "problem" goes... I tried to figure out how would FreeBSD behave under heavy load. For this purpose I wrote the simple program. It creates 200 copies of itself, and then each copy tries to give system some work, that is opens a file and writes into it randomly and also allocates memory, uses it and frees memory afterwards. Here it is: #include #include #include int main() { int incarnation; /* Program incarnation */ int i,j; /* Counters */ int descriptor; /* File descriptor */ int PID,status; /* Self-explaining */ char buffer[512]; /* Buffer for file operations */ int written; /* Bytes written */ char name[10]; /* For file name */ double t; /* Temporary */ char* p=NULL; /* Dinamic allocated memory pointer */ for(incarnation=0;incarnation<200;incarnation++) { PID=fork(); /* Let's create another incarnation */ if(PID==-1) { printf("Cannot create another process, %d\n",incarnation); break; } if(!PID) break; } sprintf(name,"%d",getpid()); descriptor=open(name,O_CREAT|O_WRONLY,0777); /* Create temporary file */ if(descriptor==-1) { printf("Cannot create another file, %d\n",incarnation); exit(-1); } srand(incarnation); /* Make some randomization */ for(i=0;i<1000;i++) /* Do some work */ { written=write(descriptor,buffer,512); if(written!=512) { printf("Cannot write file, %d\n",incarnation); close(descriptor); if(p) free(p); exit(-1); } /* We'll write into file at random position */ t=((double)rand()/(double)RAND_MAX)*32255.; lseek(descriptor,(int)t,SEEK_SET); if(p) /* Use some VM as well */ { for(j=0;j<0xffff;j++) p[j]='Z'; free(p); p=NULL; } else { p=(char*)malloc(0xffff*sizeof(char)); if(!p) { printf("Cannot allocate memory, %d\n",incarnation); close(descriptor); exit(-1); } for(j=0;j<0xffff;j++) p[j]='z'; } } close(descriptor); if(p) free(p); wait(&status); return 0; } I ran at at one 2.1 box: AMD 5x86-133, ISA/PCI, 24M ram, 1.2G IDE hard disk, and at two 2.1.5 boxes: Pentium 100, ISA/PCI, 16M ram, Adaptec 7850 SCSI adapter, Seagate 2G SCSI hard disk, and Pentium 75, ISA/PCI, 16M ram, 1.2G hard disk. Each system crashes with message like: kernel page directory invalid pdir=0x52e063 va=0xc000 ^^^^^^^^ actual numbers may differ panic: invalid page directory Crash is more or less severe from time to time. Sometimes system will work well with 200 processes, but crash with 300 - it depends. I don't see any reason for such system behaviour. I'm not sure it's melfunction, but will be grateful to hear any comments. For we would like to use FreeBSD as a server for http, ftp, nntp, and other services, and we're very concerned with it's stability. I of course know that ftp.freebsd.org sustains very heavy load, but... At least, system should refuse to give servicies when overloaded, but (from my point of view) it shouldn't crash! P.S. May be the program is simply buggy - forgive the dummy in that case. -- Litvin Alexander +--------------------+ |"Must-die" must die!| +--------------------+ ---------- >8 ----- End article ----- 8< ---------- ---------- >8 ----- Begin NT code ----- 8< ---------- (Message carbons:1943) To: "Ron G. Minnich" , "Litvin Alexander B. " cc: hackers@freebsd.org Subject: Re: "Panick" - help needed... In-reply-to: Your message of Thu, 08 Aug 96 16:45:42 -0400. Date: Fri, 09 Aug 1996 01:17:55 -0700 From: "Michael L. VanLoon -- HeadCandy.com" >i just tried this on linux 1.3.99 for grins. It does not crash the >system. It just makes the system totally unusable. X locks up, my 'top' >window stops updating, etc. [details of Linux biting for anything other than benchmarks, deleted...] >If anyone runs this on a freebsd desktop i'd be interested in what you >observe -- how does interactive response function as this program runs. >Does the system become unusable for interactive use as does linux or does >the system just keep plugging along. Same for NT if anyone wants to fool >with it. I ran it on my NetBSD system. NetBSD-current (1.2_BETA), AMD 5x86 133MHz, 24MB RAM, BusLogic BT747s EISA SCSI, filesystem on a two SCSI drive ccd, etc. It ran for fifteen minutes, approximately with no noticeable weirdness. Response was *very* sluggish, taking a few minutes to log into another PCVT virtual terminal. This is probably partially because 200 processes were writing non-stop on the same disks it was trying to swap my process back in off of. I have a feeling it would have responded much quicker if the tmp files were written to a disk that had none of my swap allocated on it. At around fifteen minutes, I got a panic: vm_map_entry_create: out of map entries. Note that this is not exactly a bug. It's just a design deficiency in the old mach memory system NetBSD still uses. I. e. pmap entries are allocated in a fixed table, and I just plain ran out of them. The FreeBSD VM system has an advantage in this particular area. I also ran a modified version of this program on NT Server 4.0 Beta 2 (haven't upgraded to the release bits at home, yet), ASUS Pentium 100MHz, BusLogic BT956c PCI SCSI controller, etc. It ran for twenty minutes straight before I finally killed it. Absolutely nothing bad happened, as I had expected (we push NT machines a *lot* harder than this in the Exchange stress labs). The machine, like NetBSD, was very sluggish while the whole thing was in progress, taking from 30 to 60 seconds to switch back to a program that had gotten pushed out to swap. Since the filesystem and the swap, once again, were on the same drive, that probably was a significant impact. Here is my NT version of your program: -------------------------------------------------------------------- #include #include #include #include #define MAX_THREADS 200 int thrash(int iParam) { DWORD dwThreadID = 0; int i, j; /* Counters */ HANDLE hFile; DWORD dwStatus; BOOL bRet; char buffer[512]; /* Buffer for file operations */ int written; /* Bytes written */ char name[256]; /* For file name */ double t; /* Temporary */ char* p = NULL; /* Dinamic allocated memory pointer */ Sleep(rand() * 9000 / RAND_MAX + 1000); // 1 to 10 seconds printf("Starting thread %d.\n", iParam); dwThreadID = GetCurrentThreadId(); sprintf(name, "thrasher-tmp-%d", dwThreadID); hFile = CreateFile(name, GENERIC_WRITE, FILE_SHARE_WRITE, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); if (hFile == INVALID_HANDLE_VALUE) { dwStatus = GetLastError(); printf("Cannot create another file, %d: 0x%08x/%d\n", dwThreadID, dwStatus, dwStatus); goto Exit; } for (i = 0; i < 1000; i++) /* Do some work */ { bRet = WriteFile(hFile, buffer, 512, &written, NULL); if (!bRet || written != 512) { dwStatus = GetLastError(); printf("Cannot write file, %d: 0x%08x/%d\n", dwThreadID, dwStatus, dwStatus); goto Exit; } /* We'll write into file at random position */ t = ((double)rand() / (double)RAND_MAX) * 32255.; dwStatus = SetFilePointer(hFile, (LONG)t, NULL, FILE_BEGIN); if (dwStatus < 0) { dwStatus = GetLastError(); printf("Cannot seek file, %d: 0x%08x/%d\n", dwThreadID, dwStatus, dwStatus); goto Exit; } /* Use some VM as well */ if (p) { for (j = 0; j < 0xffff; j++) p[j] = (char)j; free(p); p = NULL; } else { p = (char*)malloc(0xffff * sizeof(char)); if (!p) { dwStatus = GetLastError(); printf("Cannot allocate memory, %d: 0x%08x/%d\n", dwThreadID, dwStatus, dwStatus); goto Exit; } for (j = 0; j < 0xffff; j++) p[j] = ~(char)j; } } dwStatus = 0; Exit: if (hFile != INVALID_HANDLE_VALUE) { CloseHandle(hFile); hFile = INVALID_HANDLE_VALUE; } if (p) { free(p); p = NULL; } return dwStatus; } int main() { int nThreads; HANDLE hThread; DWORD dwStatus; srand(GetTickCount()); for (nThreads = 0; nThreads < MAX_THREADS; nThreads++) { hThread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)thrash, (LPVOID)nThreads, 0, NULL); if (hThread == NULL) { dwStatus = GetLastError(); printf("Cannot create another thread, %d: 0x%08x/%d\n", nThreads, dwStatus, dwStatus); break; } } thrash(nThreads); return 0; } -------------------------------------------------------------------- ---------- >8 ----- End NT code ----- 8< ---------- ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@MindBender.serv.net --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... ----------------------------------------------------------------------------- From owner-freebsd-hackers Wed Sep 11 20:22:16 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA27083 for hackers-outgoing; Wed, 11 Sep 1996 20:22:16 -0700 (PDT) Received: from srv1-bsb.GNS.com.br ([200.239.56.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA27001 for ; Wed, 11 Sep 1996 20:21:41 -0700 (PDT) Received: (from mail@localhost) by srv1-bsb.GNS.com.br (8.7.5/8.7.5) id AAA00324; Thu, 12 Sep 1996 00:21:04 -0300 (EST) Received: from dl0109-bsb.gns.com.br(200.239.56.109) by srv1-bsb.GNS.com.br via smap (V1.3) id sma000315; Thu Sep 12 00:20:46 1996 Received: by DANIEL.sobral (IBM OS/2 SENDMAIL VERSION 1.3.14/2.12um) id AA0227; Thu, 12 Sep 96 00:16:21 +0300 Message-Id: <9609112116.AA0227@DANIEL.sobral> Date: Thu, 12 Sep 96 0:16:20 +0300 From: "Daniel C. Sobral" Subject: IDE and DMA To: hackers@freefall.freebsd.org Reply-To: e8917523@linf.unb.br In-Reply-To: <199609111828.LAA20070@freefall.freebsd.org> from "owner-hackers-digest@freefall.freebsd.org" at Sep 11 96 11:28 am X-Disclaimer: Klaatu Barada Nikto! X-Mailer: ELM [version 2.3 PL11] for OS/2 Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > From: Terry Lambert > Date: Wed, 11 Sep 1996 11:26:00 -0700 (MST) > Subject: Re: IDE and ASUS P/I-P6NP5 > > > The Pentium Pro ASUS P/I-P6NP5 board claims to support > > onboard IDE (bus master) at 17 MB/s in PIO mode and 22MB/s in > > DMA mode. > > > > How useful is this under FreeBSD-current? Does the IDE driver support > > this? Are there any IDE disk drives allowing for transfer rates > > DMA mode isn't supported AFAIK. > > I think the problem is still that it is impossible to reliably detect > support for the mode without crashing older (WD1007, etc.?) hardware. option??? Not meant as a criticism, nor as a request. I would like to know how easy/difficult it would be to add this as an "option" in the config, and what would be the problems in doing this. Also, please define "crash" in more technical terms. :-) -- Daniel C. Sobral (8-DCS) dcs@gns.com.br e8917523@linf.unb.br From owner-freebsd-hackers Wed Sep 11 20:27:36 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA27709 for hackers-outgoing; Wed, 11 Sep 1996 20:27:36 -0700 (PDT) Received: from hp.com (hp.com [15.255.152.4]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA27692 for ; Wed, 11 Sep 1996 20:27:32 -0700 (PDT) Received: from fakir.india.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA096318843; Wed, 11 Sep 1996 20:27:27 -0700 Received: from localhost by fakir.india.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA058320686; Thu, 12 Sep 1996 08:58:06 +0500 Message-Id: <199609120358.AA058320686@fakir.india.hp.com> To: Karl Denninger Subject: Re: SYN Resisting (fwd) Cc: freebsd-hackers@freebsd.org In-Reply-To: Your message of "Wed, 11 Sep 1996 14:39:57 EST." <199609111939.OAA02328@Jupiter.mcs.net> Date: Thu, 12 Sep 1996 08:58:06 +0500 From: A JOSEPH KOSHY Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>> "Karl Denninger" writes Hi Karl, > This changes the startup connection timeout to 10 seconds, which should be > more than enough on the Internet of today to prevent dropped links. 75 > seconds is only needed if you're running across two pieces of wet string. I've seen very large startup times when attempting to connect to sundry corners of the globe (> 30-45 seconds). I think reducing the connection timeout isn't a good idea as it would impact the ability of FreeBSD to connect to distant sites / sites accessible thru the congested links. Koshy From owner-freebsd-hackers Wed Sep 11 20:31:24 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA28207 for hackers-outgoing; Wed, 11 Sep 1996 20:31:24 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA28195 for ; Wed, 11 Sep 1996 20:31:21 -0700 (PDT) Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.7.5/8.7.5) with SMTP id WAA10895; Wed, 11 Sep 1996 22:28:48 -0500 (CDT) Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15) id ; Wed, 11 Sep 96 22:28 CDT Received: (from karl@localhost) by Jupiter.mcs.net (8.7.5/8.7.5) id WAA09803; Wed, 11 Sep 1996 22:28:46 -0500 (CDT) From: Karl Denninger Message-Id: <199609120328.WAA09803@Jupiter.mcs.net> Subject: Re: SYN Resisting (fwd) To: koshy@india.hp.com (A JOSEPH KOSHY) Date: Wed, 11 Sep 1996 22:28:46 -0500 (CDT) Cc: karl@Mcs.Net, freebsd-hackers@freebsd.org In-Reply-To: <199609120358.AA058320686@fakir.india.hp.com> from "A JOSEPH KOSHY" at Sep 12, 96 08:58:06 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > >>>> "Karl Denninger" writes > > Hi Karl, > > > This changes the startup connection timeout to 10 seconds, which should be > > more than enough on the Internet of today to prevent dropped links. 75 > > seconds is only needed if you're running across two pieces of wet string. > > I've seen very large startup times when attempting to connect to sundry > corners of the globe (> 30-45 seconds). I think reducing the connection > timeout isn't a good idea as it would impact the ability of FreeBSD to > connect to distant sites / sites accessible thru the congested links. > > Koshy Well, unless someone has a better idea, you can choose between that problem and the SYN floods..... I haven't seen that kind of connect time in a long, long while on the net backbones... but then again, I may be better connected here than most. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1 from $600 monthly; speeds to DS-3 available | 23 Chicagoland Prefixes, 13 ISDN, much more Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | Home of Chicago's only FULL Clarinet feed! From owner-freebsd-hackers Wed Sep 11 21:11:57 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA02876 for hackers-outgoing; Wed, 11 Sep 1996 21:11:57 -0700 (PDT) Received: from mx.serv.net (mx.serv.net [199.201.191.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA02868 for ; Wed, 11 Sep 1996 21:11:53 -0700 (PDT) Received: from MindBender.serv.net by mx.serv.net (8.7.5/SERV Revision: 2.30 † id VAA08516; Wed, 11 Sep 1996 21:11:59 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.serv.net (8.7.5/8.7.3) with SMTP id VAA24398; Wed, 11 Sep 1996 21:11:43 -0700 (PDT) Message-Id: <199609120411.VAA24398@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: brianc@pobox.com cc: freebsd-hackers@freebsd.org (FreeBSD Hackers) Subject: Re: IDE and ASUS P/I-P6NP5 In-reply-to: Your message of Wed, 11 Sep 96 21:41:35 -0400. <199609120141.VAA00555@ottawa.net> Date: Wed, 11 Sep 1996 21:11:43 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> I think the problem is still that it is impossible to reliably detect >> support for the mode without crashing older (WD1007, etc.?) hardware. >And Terry clearly has a problem with IDE in general. Well, Terry isn't the only one... >Nonetheless I'd really love to have a bus-mastering IDE driver >available. I could care less if it automatically detects older >hardware, although other operating systems manage to do this. Yes, I agree this would be great. We should make the most of all our hardware... >I'd be happy to manually specify that my IDE chipset and drive were >"DMA capable" for the dual benefit of freeing up the CPU for more >useful tasks and increased throughput. But you still shouldn't kid yourself that it would be "as good as" SCSI. All the design deficiencies of IDE aside, the single most important benefit to asynchronous high speed drive through-put that I have found in my testing, is tagged-command-queuing. Even over the same high end SCSI board (AHC-2940UW or BT956c) on the same drives, with tagged-command-queuing simply disabled. I may be mistaken, but I don't believe I have heard of EIDE even attempting to address something on that level. So, once again, I agree that it would be a really great win to have this EIDE functionality (especially for all the existing hardware already out there), but I still recommend that you stick to SCSI from the start, if there is any way you can do so. ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@MindBender.serv.net --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... ----------------------------------------------------------------------------- From owner-freebsd-hackers Wed Sep 11 21:44:39 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA04684 for hackers-outgoing; Wed, 11 Sep 1996 21:44:39 -0700 (PDT) Received: from carbonero.udem.edu.co (root@[157.253.130.6]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA04673 for ; Wed, 11 Sep 1996 21:44:30 -0700 (PDT) Received: from Shibumi.crack.net (nobody@urapan.udem.edu.co [157.253.130.4]) by carbonero.udem.edu.co (8.6.12/8.6.9) with SMTP id XAA00845; Wed, 11 Sep 1996 23:44:22 -0500 Message-ID: <323794EF.63AF@carbonero.udem.edu.co> Date: Wed, 11 Sep 1996 23:43:28 -0500 From: Lucas Adrián Gómez Blandón Reply-To: lgomez@carbonero.udem.edu.co Organization: Universidad de Medellín (University of Medellín) X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: Hackers@Freebsd.org, Bugs@Freebsb.rg Subject: Problem installing 2.0-950412 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@Freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi everyone. I have a 486 DX/4 100MHz, 8 MB RAM, and a Quantum Firewall 1039 MB, in the BIOS data of HDD is: Cyl Head Sec 528 64 63 => 1040 MB This HDD is accesing to 32Bits and I have MS-DOS (60%) I'm try install FreeBSD-950412 (I have this in a CD-ROM) and I make a floppies (Free of errors) and this booting the machine, i will create BDS4.2 space and swap space, but when I (P)roced, i look this bug: wd0g: wdstart: timeout waiting to give command writing fsbn 862207 (wd0 bn 2095999; cn 519 tn 53 sn 52)wd0: status 0 error 1. Please, help me, I'm very interested in install FreeBSD. Thanks for all. Bye From owner-freebsd-hackers Wed Sep 11 21:46:32 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA04853 for hackers-outgoing; Wed, 11 Sep 1996 21:46:32 -0700 (PDT) Received: from ottawa.net (ppp-91.ottawa.net [205.211.4.91]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA04847 for ; Wed, 11 Sep 1996 21:46:28 -0700 (PDT) Received: (from brianc@localhost) by ottawa.net (8.7.5/8.7.3) id AAA08120 for freebsd-hackers@FreeBSD.org; Thu, 12 Sep 1996 00:45:26 -0400 (EDT) From: Brian Campbell Message-Id: <199609120445.AAA08120@ottawa.net> Subject: Re: IDE and ASUS P/I-P6NP5 To: freebsd-hackers@FreeBSD.org (FreeBSD Hackers) Date: Thu, 12 Sep 1996 00:45:26 -0400 (EDT) In-Reply-To: <199609120411.VAA24398@MindBender.serv.net> from "Michael L. VanLoon -- HeadCandy.com" at "Sep 11, 96 09:11:43 pm" Reply-to: brianc@pobox.com X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > >Nonetheless I'd really love to have a bus-mastering IDE driver > >available. I could care less if it automatically detects older > >hardware, although other operating systems manage to do this. > > Yes, I agree this would be great. We should make the most of all our > hardware... > > >I'd be happy to manually specify that my IDE chipset and drive were > >"DMA capable" for the dual benefit of freeing up the CPU for more > >useful tasks and increased throughput. > > But you still shouldn't kid yourself that it would be "as good as" > SCSI. All the design deficiencies of IDE aside, the single most > important benefit to asynchronous high speed drive through-put that I > have found in my testing, is tagged-command-queuing. Even over the > same high end SCSI board (AHC-2940UW or BT956c) on the same drives, > with tagged-command-queuing simply disabled. Unless things have changed since I last bought a machine, it's cheaper to buy a machine with an IDE drive than SCSI drive. Perhaps because the IDE (dual) controller is built into the motherboard chipset, or perhaps because IDE drives are often cheaper (regardless of whether this is changing). Mine came with both an IDE hard drive and an IDE cdrom. I don't imagine this changes much, given the builtin IDE support, even if you're building your own system. Which isn't to say I don't agree SCSI is a better all-round solution. I also have a 2940U, a SCSI drive and two SCSI cdroms. But having SCSI doesn't mean I don't want to take the best advantage I can of the cheap, common IDE controller/drive I've got as well. From owner-freebsd-hackers Wed Sep 11 22:05:09 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA05962 for hackers-outgoing; Wed, 11 Sep 1996 22:05:09 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA05957 for ; Wed, 11 Sep 1996 22:05:06 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id WAA06174; Wed, 11 Sep 1996 22:03:52 -0700 From: Terry Lambert Message-Id: <199609120503.WAA06174@phaeton.artisoft.com> Subject: Re: IDE and DMA To: e8917523@linf.unb.br Date: Wed, 11 Sep 1996 22:03:52 -0700 (MST) Cc: hackers@freefall.freebsd.org In-Reply-To: <9609112116.AA0227@DANIEL.sobral> from "Daniel C. Sobral" at Sep 12, 96 00:16:20 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > DMA mode isn't supported AFAIK. > > > > I think the problem is still that it is impossible to reliably detect > > support for the mode without crashing older (WD1007, etc.?) hardware. > > option??? Not meant as a criticism, nor as a request. I would like to > know how easy/difficult it would be to add this as an "option" in the > config, and what would be the problems in doing this. It would take pleading with Soren; he already said he could be talked into it. As an option-not-enabled-by-default, it's unobtrusive. > Also, please define "crash" in more technical terms. :-) Cease functioning until you rebbot (at which time the probe crashes it yet again, since code doesn't mutate. 8-)). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Sep 11 22:11:30 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA06231 for hackers-outgoing; Wed, 11 Sep 1996 22:11:30 -0700 (PDT) Received: from nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA06216 for ; Wed, 11 Sep 1996 22:11:27 -0700 (PDT) Received: from localhost (localhost.efn.org [127.0.0.1]) by nike.efn.org (8.7.5/8.7.3) with SMTP id WAA01283 for ; Wed, 11 Sep 1996 22:11:48 -0700 (PDT) Date: Wed, 11 Sep 1996 22:11:48 -0700 (PDT) From: John-Mark Gurney Reply-To: John-Mark Gurney To: FreeBSD Hackers Subject: wait doesn't exist... what we can't?? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk well... I found the wait man page but there doesn't seem to be a program that matches the man page... is there a reason? just wondering... ttyl.. John-Mark gurney_j@efn.org http://resnet.uoregon.edu/~gurney_j/ Modem/FAX: (541) 683-6954 (FreeBSD Box) Live in Peace, destroy Micro$oft, support free software, run FreeBSD (unix) From owner-freebsd-hackers Wed Sep 11 22:17:58 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA06722 for hackers-outgoing; Wed, 11 Sep 1996 22:17:58 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA06715 for ; Wed, 11 Sep 1996 22:17:55 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id WAA06208; Wed, 11 Sep 1996 22:16:44 -0700 From: Terry Lambert Message-Id: <199609120516.WAA06208@phaeton.artisoft.com> Subject: Re: IDE and ASUS P/I-P6NP5 To: brianc@pobox.com Date: Wed, 11 Sep 1996 22:16:43 -0700 (MST) Cc: freebsd-hackers@FreeBSD.org In-Reply-To: <199609120141.VAA00555@ottawa.net> from "Brian Campbell" at Sep 11, 96 09:41:35 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > DMA mode isn't supported AFAIK. > > > > I think the problem is still that it is impossible to reliably detect > > support for the mode without crashing older (WD1007, etc.?) hardware. > > And Terry clearly has a problem with IDE in general. Not clear from this post; the only thing this post makes clear is that I have a problem with crashing older hardware to benefit newer hardware when it's reasonable to expect new hardware to take the old hardware into account when designing a standards compliant probe sequence. So, per se, I have a problem with some IDE hardware manufacturers, and a problem with the ATAPI specification allowing leeway to them to implement badly behaved hardware. So while I'm adverse to sloppy implementations, it doesn't mean that I believe it's impossible to have a non-sloppy implementation. On the other hand, I have yet to see one, so my expectations for one are pretty low. > Nonetheless I'd really love to have a bus-mastering IDE driver > available. I could care less if it automatically detects older > hardware, although other operating systems manage to do this. Windows 95 does this by allowing the user to reset "if the hardware probe hangs for an 'unreasonable' amount of time". It logs using sync writes going into each probe, and so it is possible to recover from destructive probes for nonexistant hardware (the failure case I'm complaining about here) by restarting, skipping the erroroneous probe. I have had to occasionally rebot five times on some sensitive hardware configurations during a Windows 95 install. I have suggested that BSD needs a fallback driver mechanism and a similar probe/install mechanism... without one, what you are asking is not going to happen because the underlying technology just isn't there. For what it's worth, NT has the VM86() capability to support fallback, yet does not support it. Clearly, Microsoft is attempting to force hardware manufacturers to build cleaner hardware by not filling in the cracks with Windows 95-like putty. > I'd be happy to manually specify that my IDE chipset and drive were > "DMA capable" for the dual benefit of freeing up the CPU for more > useful tasks and increased throughput. A perfectly reasonable way to implement it: an option, not enable by default. Feel free to implement the driver changes, since I certainly don't own any IDE hardware to enable me to help you out. > Now if we can just find someone capable of doing the work ;-) Sounded like you were volunteering... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Wed Sep 11 22:49:15 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA10546 for hackers-outgoing; Wed, 11 Sep 1996 22:49:15 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA10541 for ; Wed, 11 Sep 1996 22:49:13 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id WAA00334 for ; Wed, 11 Sep 1996 22:49:12 -0700 (PDT) To: hackers@freebsd.org Subject: DOC CDs all gone, thanks.. Date: Wed, 11 Sep 1996 22:49:12 -0700 Message-ID: <332.842507352@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk U.C. Berkeley got 'em all on account of they got the formalities over with before anyone else did. Thanks to all who responded! Jordan From owner-freebsd-hackers Wed Sep 11 23:12:59 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA13180 for hackers-outgoing; Wed, 11 Sep 1996 23:12:59 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA13174 for ; Wed, 11 Sep 1996 23:12:57 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id XAA00469; Wed, 11 Sep 1996 23:12:50 -0700 (PDT) To: graphix@iastate.edu cc: hackers@freebsd.org Subject: Re: OpenBSD <-> FreeBSD In-reply-to: Your message of "Wed, 11 Sep 1996 19:51:02 CDT." <9609120051.AA08227@spiff.cc.iastate.edu> Date: Wed, 11 Sep 1996 23:12:50 -0700 Message-ID: <467.842508770@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Is there anyone tracking the changes that are made to the 4.4 source > in NetBSD/OpenBSD and incorporating the changes into the FreeBSD tree on > a regular basis? If not, what is the common feeling of if this would be No, and we really wish there were more people willing to do that! It's one of our #1 wish-list items, since we're essentially throwing away free fixes and enhancements otherwise. > a do-able and useful contribution to FreeBSD in general for a person > that is generally already fairly taxed but wants to help? Perhaps the We'd be very supportive of this. > changes are too extreme but my original thought was that the trees would > be similar enough that finding and understanding the changes would be > possible. I think that's generally true, especially for userland stuff. Jordan From owner-freebsd-hackers Wed Sep 11 23:33:58 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA14504 for hackers-outgoing; Wed, 11 Sep 1996 23:33:58 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA14497 for ; Wed, 11 Sep 1996 23:33:54 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id XAA00523; Wed, 11 Sep 1996 23:33:51 -0700 (PDT) To: brianc@pobox.com cc: freebsd-hackers@freebsd.org (FreeBSD Hackers) Subject: Re: IDE and ASUS P/I-P6NP5 In-reply-to: Your message of "Thu, 12 Sep 1996 00:45:26 EDT." <199609120445.AAA08120@ottawa.net> Date: Wed, 11 Sep 1996 23:33:51 -0700 Message-ID: <521.842510031@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hey, folks, I think this whole SCSI vs IDE debate sort of misses the fundamental point, which has nothing at all to do with "which is better." We're in the business of providing an operating system with FreeBSD, which means that the decision making process should always go like this: 1. Evaluate what the market is using, paying particular attention to what the existing and potential FreeBSD segments of it are inclined to buy. 2. Assign development priorities based on this data. 3. Identify existing human resources. 4. Match resources to projects. Of course I say "should" because we're a volunteer project, and we don't get to do everything the way the commercial boys do, so steps 3 and 4 get a lot more creative, usually more like: 3. Identify appropriate mailing lists to whine into, the volume and frequency of said whining being directly proportional to the importance of the task. 4. Wait for resources to match themselves to projects. :-) So when you sum it all up, I guess this means that IDE should be considered very important and dealt with accordingly as a large segment of the existing and potential market. At the same time, however, our volunteer nature brings it all down to who'll do the work, and step 4 in our modified list is what needs to happen now if any progress is to be made here. :-) Jordan From owner-freebsd-hackers Wed Sep 11 23:58:11 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA16373 for hackers-outgoing; Wed, 11 Sep 1996 23:58:11 -0700 (PDT) Received: from ra.dkuug.dk (ra.dkuug.dk [193.88.44.193]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA16361 for ; Wed, 11 Sep 1996 23:58:07 -0700 (PDT) Received: (from sos@localhost) by ra.dkuug.dk (8.6.12/8.6.12) id IAA04005; Thu, 12 Sep 1996 08:56:42 +0200 Message-Id: <199609120656.IAA04005@ra.dkuug.dk> Subject: Re: IDE and DMA To: terry@lambert.org (Terry Lambert) Date: Thu, 12 Sep 1996 08:56:42 +0200 (MET DST) Cc: e8917523@linf.unb.br, hackers@freefall.freebsd.org In-Reply-To: <199609120503.WAA06174@phaeton.artisoft.com> from "Terry Lambert" at Sep 11, 96 10:03:52 pm From: sos@FreeBSD.org Reply-to: sos@FreeBSD.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In reply to Terry Lambert who wrote: > > > > DMA mode isn't supported AFAIK. > > > > > > I think the problem is still that it is impossible to reliably detect > > > support for the mode without crashing older (WD1007, etc.?) hardware. > > > > option??? Not meant as a criticism, nor as a request. I would like to > > know how easy/difficult it would be to add this as an "option" in the > > config, and what would be the problems in doing this. > > It would take pleading with Soren; he already said he could be talked > into it. As an option-not-enabled-by-default, it's unobtrusive. Erhm, did I say that ? :), well I allso said that our ide/atapi code should be rewritten, so it is more modular, and has the provisions for handling this proberly. I'd really hate this put into the existing code as just another ugly hack. What we need is not the occasional hack, we need a person (or team) that takes on RESPONSIBILITY for that particualr piece of code, and I have plenty on my platter allready .... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team So much code to hack -- so little time. From owner-freebsd-hackers Thu Sep 12 00:05:52 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA17999 for hackers-outgoing; Thu, 12 Sep 1996 00:05:52 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA17987 for ; Thu, 12 Sep 1996 00:05:50 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id AAA00719 for ; Thu, 12 Sep 1996 00:05:49 -0700 (PDT) To: hackers@freebsd.org Subject: spatter now supports ssh logins. Date: Thu, 12 Sep 1996 00:05:48 -0700 Message-ID: <717.842511948@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Those who need to know what that means, will. :-) Jordan From owner-freebsd-hackers Thu Sep 12 01:12:29 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA21097 for hackers-outgoing; Thu, 12 Sep 1996 01:12:29 -0700 (PDT) Received: from cmr.kiev.ua (root@cmr.kiev.ua [193.193.193.50]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA21070 for ; Thu, 12 Sep 1996 01:12:00 -0700 (PDT) Received: (archer@localhost) by cmr.kiev.ua (Sendmail 8.who.cares/5) id HAA28281; Thu, 12 Sep 1996 07:55:32 GMT Date: Thu, 12 Sep 1996 10:55:31 +0300 (EET DST) From: "Litvin Alexander B." To: Mark Mayo cc: hackers@FreeBSD.org Subject: Re: forking program ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 11 Sep 1996, Mark Mayo wrote: > I remember some time back someone posted a little piece of code that > forked and allocated memory until the OS gave up.. and the same program > appeared with an NT version (using CreateThread instead of fork()). > > I wanted to take a closer look at it, but it seems I can't find any > mention of where to get it anywhere in my mail folders.. :-( > I posted original message about forking program for FreeBSD 2.1.x. Now, as I see, you have it already, as well as NT version. I may add, that I tested the same program with 2.2-960801-SNAP - it works "better" - it doesn't crash even with >500 processes, but (and it was also noticed by J.Wunsch), after attempting to remove temporary files (which program creates, but doesn't take care to remove), system crashes with: panic: vm_page_free: invalid wire count ... :-? Unfortunately, I don't have time at the moment to dig into problem. Best regards! -- Litvin Alexander From owner-freebsd-hackers Thu Sep 12 03:20:19 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA26645 for hackers-outgoing; Thu, 12 Sep 1996 03:20:19 -0700 (PDT) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA26529 for ; Thu, 12 Sep 1996 03:17:34 -0700 (PDT) Message-Id: <199609121017.DAA26529@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA129922774; Thu, 12 Sep 1996 20:06:14 +1000 From: Darren Reed Subject: Re: SYN Resisting (fwd) To: karl@Mcs.Net (Karl Denninger) Date: Thu, 12 Sep 1996 20:06:14 +1000 (EST) Cc: koshy@india.hp.com, karl@Mcs.Net, freebsd-hackers@freebsd.org In-Reply-To: <199609120328.WAA09803@Jupiter.mcs.net> from "Karl Denninger" at Sep 11, 96 10:28:46 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Karl Denninger, sie said: > > > > > >>>> "Karl Denninger" writes > > > > Hi Karl, > > > > > This changes the startup connection timeout to 10 seconds, which should be > > > more than enough on the Internet of today to prevent dropped links. 75 > > > seconds is only needed if you're running across two pieces of wet string. > > > > I've seen very large startup times when attempting to connect to sundry > > corners of the globe (> 30-45 seconds). I think reducing the connection > > timeout isn't a good idea as it would impact the ability of FreeBSD to > > connect to distant sites / sites accessible thru the congested links. > > > > Koshy > > Well, unless someone has a better idea, you can choose between that problem > and the SYN floods..... > > I haven't seen that kind of connect time in a long, long while on the net > backbones... but then again, I may be better connected here than most. I heard someone mention 25% packet loss on an Australia-USA line (packets were being dropped in the USA). From owner-freebsd-hackers Thu Sep 12 04:13:40 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA00608 for hackers-outgoing; Thu, 12 Sep 1996 04:13:40 -0700 (PDT) Received: from ra.dkuug.dk (ra.dkuug.dk [193.88.44.193]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA00581; Thu, 12 Sep 1996 04:13:26 -0700 (PDT) Received: (from sos@localhost) by ra.dkuug.dk (8.6.12/8.6.12) id NAA05113; Thu, 12 Sep 1996 13:13:22 +0200 Message-Id: <199609121113.NAA05113@ra.dkuug.dk> Subject: ATA/ATAPI (EIDE) driver commitment... To: hackers@freebsd.org (FreeBSD hackers), current@freebsd.org (FreeBSD current) Date: Thu, 12 Sep 1996 13:13:22 +0200 (MET DST) Cc: core@freebsd.org (FreeBSD core) From: sos@freebsd.org Reply-to: sos@freebsd.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Given all the talk about EIDE/ATA/ATAPI support that has taken place on these lists over the last couble of month, I have decided to do something about it: I'm taking on the task of rewriting our EIDE/ATA/ATAPI driver, so it lives up to the current level of "sofistication". I will also try to maintain it afterwards, much like I do with syscons & the linux emu today. I can not and will not set any date on which this is to be finished as I have only so many hours in a day, but this is a statement that it will be done, and a signal to others that if they should be working on the same thing, they should coordinate their work with me. So folks, in summary, please: DO: *) Send me any hardware you'd like me to take special care to try and support. If you're a computer dealer or serious user and there's a [E]IDE disk or atapi device you're having problems with, *send me one*! I only need one of each model to support it reasonably. Send me email beforehand, of course, to make sure I haven't already got one. *) Volunteer to help by testing and/or developing this with me! :) *) Bear over with me not having more than 24 hours/day, a real job, wife and 2 kids that needs time too. DON'T: *) Expect me to send any of the hardware back! I'm in Denmark, which means shipping can easily exceed the value of the drive, plus I've got to have the drive for testing new releases and making sure nothing's broken anyway. *) Flood me with email asking when this is going to be done! I'll inform when I have something major to say to the world about the project. If you want to make things go faster, see the DO list above! That's it, back to work.... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team So much code to hack -- so little time. From owner-freebsd-hackers Thu Sep 12 07:57:47 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA09366 for hackers-outgoing; Thu, 12 Sep 1996 07:57:47 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA09358 for ; Thu, 12 Sep 1996 07:57:44 -0700 (PDT) Received: from muggsy.lkg.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id KAA02983; Thu, 12 Sep 1996 10:31:22 -0400 (EDT) Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA02666; Thu, 12 Sep 1996 10:31:20 -0400 Received: from localhost.lkg.dec.com (localhost.lkg.dec.com [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id KAA20501; Thu, 12 Sep 1996 10:34:26 GMT Message-Id: <199609121034.KAA20501@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost.lkg.dec.com didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: Luigi Rizzo Cc: hackers@freebsd.org Subject: Re: Changing default TCP window size ? In-Reply-To: Your message of "Wed, 11 Sep 1996 23:17:07 +0200." <199609112117.XAA08985@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 12 Sep 1996 10:34:21 +0000 From: Matt Thomas Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk You can't do it in -current (as I found on FDDI). The TCP code forces the buffser to what is in the route and does not allow one to override them. About a month I sent a set of patches which allows SO_SNDBUF/ SO_RCVBUF to work. -- Matt Thomas Internet: matt@3am-software.com 3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt.html Westford, MA Disclaimer: I disavow all knowledge of this message From owner-freebsd-hackers Thu Sep 12 08:00:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA09557 for hackers-outgoing; Thu, 12 Sep 1996 08:00:35 -0700 (PDT) Received: from cyclone.degnet.baynet.de (cyclone.degnet.baynet.de [194.95.214.129]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA09544; Thu, 12 Sep 1996 08:00:28 -0700 (PDT) Received: from neuron.bsd.uni-passau.de (ppp6 [194.95.214.136]) by cyclone.degnet.baynet.de (8.6.12/8.6.9) with SMTP id RAA22842; Thu, 12 Sep 1996 17:02:30 +0200 Message-ID: <3238406E.B4C@degnet.baynet.de> Date: Thu, 12 Sep 1996 16:55:10 +0000 From: Darius Moos Reply-To: moos@degnet.baynet.de X-Mailer: Mozilla 3.0b8Gold (Win95; I) MIME-Version: 1.0 To: FreeBSD-questions CC: freebsd-hackers Subject: Looking for ipfw-accounting-scripts Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi all, i am looking for some scripts to do ipfw-accounting and -summaries. I need it for dialin-user accounting. Any pointers and suggestions are highly appreciated. Thanks a lot Darius Moos. -- email: moos@degnet.baynet.de From owner-freebsd-hackers Thu Sep 12 08:27:48 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA10933 for hackers-outgoing; Thu, 12 Sep 1996 08:27:48 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA10876 for ; Thu, 12 Sep 1996 08:26:25 -0700 (PDT) Received: from mailbox.mcs.com (Mailbox.mcs.com [192.160.127.87]) by Kitten.mcs.com (8.7.5/8.7.5) with SMTP id KAA03655; Thu, 12 Sep 1996 10:23:26 -0500 (CDT) Received: by mailbox.mcs.com (/\==/\ Smail3.1.28.1 #28.15) id ; Thu, 12 Sep 96 10:23 CDT Received: (from karl@localhost) by Jupiter.mcs.net (8.7.5/8.7.5) id KAA16744; Thu, 12 Sep 1996 10:23:24 -0500 (CDT) From: Karl Denninger Message-Id: <199609121523.KAA16744@Jupiter.mcs.net> Subject: Re: SYN Resisting (fwd) To: avalon@coombs.anu.edu.au (Darren Reed) Date: Thu, 12 Sep 1996 10:23:23 -0500 (CDT) Cc: karl@Mcs.Net, koshy@india.hp.com, freebsd-hackers@freebsd.org In-Reply-To: from "Darren Reed" at Sep 12, 96 08:06:14 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > In some mail from Karl Denninger, sie said: > > > > > > > > >>>> "Karl Denninger" writes > > > > > > Hi Karl, > > > > > > > This changes the startup connection timeout to 10 seconds, which should be > > > > more than enough on the Internet of today to prevent dropped links. 75 > > > > seconds is only needed if you're running across two pieces of wet string. > > > > > > I've seen very large startup times when attempting to connect to sundry > > > corners of the globe (> 30-45 seconds). I think reducing the connection > > > timeout isn't a good idea as it would impact the ability of FreeBSD to > > > connect to distant sites / sites accessible thru the congested links. > > > > > > Koshy > > > > Well, unless someone has a better idea, you can choose between that problem > > and the SYN floods..... > > > > I haven't seen that kind of connect time in a long, long while on the net > > backbones... but then again, I may be better connected here than most. > > I heard someone mention 25% packet loss on an Australia-USA line (packets were > being dropped in the USA). With a 25% packet loss rate you've got bigger problems. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1 from $600 monthly; speeds to DS-3 available | 23 Chicagoland Prefixes, 13 ISDN, much more Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ Fax: [+1 312 248-9865] | Home of Chicago's only FULL Clarinet feed! From owner-freebsd-hackers Thu Sep 12 08:44:59 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA11646 for hackers-outgoing; Thu, 12 Sep 1996 08:44:59 -0700 (PDT) Received: from al.imforei.apana.org.au (pjchilds@al.imforei.apana.org.au [202.12.89.41]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA11628 for ; Thu, 12 Sep 1996 08:44:53 -0700 (PDT) Received: (from pjchilds@localhost) by al.imforei.apana.org.au (8.7.5/8.7.3) id BAA03948; Fri, 13 Sep 1996 01:14:44 GMT Date: Fri, 13 Sep 1996 01:14:44 GMT From: Peter Childs Message-Id: <199609130114.BAA03948@al.imforei.apana.org.au> To: jkh@time.cdrom.com, freebsd-hackers@freebsd.org Subject: Re: IDE and ASUS P/I-P6NP5 X-Newsreader: TIN [version 1.2 PL2] Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <521.842510031@time.cdrom.com> you wrote: : Hey, folks, I think this whole SCSI vs IDE debate sort of misses the : fundamental point, which has nothing at all to do with "which is But we have to have it... along with the usual "FreeBSD vs. Linux", "Why not to buy Matrox", and "Willows Windows Emulator?" threads :) [cut] : So when you sum it all up, I guess this means that IDE should be : considered very important and dealt with accordingly as a large : segment of the existing and potential market. At the same time, : however, our volunteer nature brings it all down to who'll do the : work, and step 4 in our modified list is what needs to happen now if : any progress is to be made here. :-) Unfortunately the people most likely to be technically capable of doing this sort of work won't because they probably run SCSI, and hence have _zero_ motivation for doing this. When someone decides to produce more than hot air on this issue then we'll probably see something. I'm quite happy with the situation because I run SCSI with one large IDE for some bulk storage... Keep up the good work! :) Peter -- Peter Childs --- http://www.imforei.apana.org.au/~pjchilds Finger pjchilds@al.imforei.apana.org.au for public PGP key Drag me, drop me, treat me like an object! From owner-freebsd-hackers Thu Sep 12 09:54:14 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA15520 for hackers-outgoing; Thu, 12 Sep 1996 09:54:14 -0700 (PDT) Received: from ns.eu.org (valerian.glou.eu.org [193.56.58.251]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA15508 for ; Thu, 12 Sep 1996 09:54:08 -0700 (PDT) Received: (from uucp@localhost) by ns.eu.org (8.7.3/8.7.1/951117) with UUCP id SAA07954; Thu, 12 Sep 1996 18:53:33 +0200 (MET DST) Received: (from regnauld@localhost) by tetard.glou.eu.org (8.7.5/8.7.3/tetard-uucp-2.7) id SAA03132; Thu, 12 Sep 1996 18:21:17 +0200 (MET DST) From: Philippe Regnauld Message-Id: <199609121621.SAA03132@tetard.glou.eu.org> Subject: Re: single-user console in 2.1.5 To: dk+@ua.net Date: Thu, 12 Sep 1996 18:21:17 +0200 (MET DST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199609111921.MAA14991@dog.farm.org> from Dmitry Kohmanyuk at "Sep 11, 96 12:21:06 pm" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Dmitry Kohmanyuk écrit / writes: > I bet you've installed securedist (DES), but your init haven't been updated. > unpack sbin sources are recompile init (there are also some other programs which > use -lcrypt and are compiled statically, bdes, smth else?), but only init is > important here. Worked. Should have thought about that :-) Probably worth mentioning in the handbook/FAQ (at least I haven't seen it there). -- Phil -- -[ Philippe Regnauld / regnauld@eu.org / +55.4N +11.3E @ Sol3 / +45 31241690 ]- -[ "To kårve or nøt to kårve, that is the qvestion..." -- My sister ]- From owner-freebsd-hackers Thu Sep 12 09:59:08 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA15821 for hackers-outgoing; Thu, 12 Sep 1996 09:59:08 -0700 (PDT) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA15816 for ; Thu, 12 Sep 1996 09:59:07 -0700 (PDT) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15671(2)>; Thu, 12 Sep 1996 09:58:19 PDT Received: from localhost ([127.0.0.1]) by crevenia.parc.xerox.com with SMTP id <177595>; Thu, 12 Sep 1996 09:57:59 -0700 X-Mailer: exmh version 1.6.7 5/3/96 To: Jaye Mathisen cc: hackers@freebsd.org Subject: Re: Routed issues, and some questions on the routed code. Looks flaky. In-reply-to: Your message of "Wed, 11 Sep 1996 15:32:43 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 12 Sep 1996 09:57:50 PDT From: Bill Fenner Message-Id: <96Sep12.095759pdt.177595@crevenia.parc.xerox.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message you write: >I have FreeBSD acting as a router on several boxes here, and for some >weird reason, it's broadcasting itself as the default route on all >interfaces, even ones where is doesn't make sense. Are you using the "-g" flag? Have you tried turning tracing on with "-T /tmp/routed.trace -t" to see if it says why it's sending default on net C? Bill From owner-freebsd-hackers Thu Sep 12 10:16:00 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA16797 for hackers-outgoing; Thu, 12 Sep 1996 10:16:00 -0700 (PDT) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA16772 for ; Thu, 12 Sep 1996 10:15:58 -0700 (PDT) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15737(4)>; Thu, 12 Sep 1996 10:14:21 PDT Received: from localhost ([127.0.0.1]) by crevenia.parc.xerox.com with SMTP id <177595>; Thu, 12 Sep 1996 10:13:49 -0700 X-Mailer: exmh version 1.6.7 5/3/96 To: Karl Denninger cc: michael@memra.com (Michael Dillon), freebsd-hackers@freebsd.org Subject: Re: SYN Resisting (fwd) In-reply-to: Your message of "Wed, 11 Sep 1996 12:39:57 PDT." <199609111939.OAA02328@Jupiter.mcs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 12 Sep 1996 10:13:34 PDT From: Bill Fenner Message-Id: <96Sep12.101349pdt.177595@crevenia.parc.xerox.com> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I think that TCPTV_KEEP_INIT should be a sysctl variable, so that when someone is syn flooding you you can reduce it as low as you want, but when they're not you can leave it high so that people far away can connect to you. Perhaps the "unlimited so_q0len" should also be a sysctl ('tho "unlimited" is probably pretty dangerous in itself...). Bill From owner-freebsd-hackers Thu Sep 12 10:49:34 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA18814 for hackers-outgoing; Thu, 12 Sep 1996 10:49:34 -0700 (PDT) Received: from csla.csl.sri.com (csla.csl.sri.com [192.12.33.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA18809; Thu, 12 Sep 1996 10:49:32 -0700 (PDT) Received: from impulse.csl.sri.com (impulse.csl.sri.com [130.107.15.11]) by csla.csl.sri.com (8.7.3/8.7.3) with ESMTP id KAA26715; Thu, 12 Sep 1996 10:49:01 -0700 (PDT) Received: from impulse.csl.sri.com (localhost [127.0.0.1]) by impulse.csl.sri.com (8.7.3/8.7.3) with ESMTP id KAA02137; Thu, 12 Sep 1996 10:46:38 -0700 (PDT) Message-Id: <199609121746.KAA02137@impulse.csl.sri.com> To: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Subject: 2.2-960801-SNAP--Problem with SMC 10/100 card and SMC 100mb `tiger hub' Date: Thu, 12 Sep 1996 10:46:38 -0700 From: Fred Gilham Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've noticed that running the 2.2-960801 snap causes the de driver to fail to link up to the 100mb SMC tiger hub that we're experimenting with. It always reports de0: enabling 10baseT port and then gives timeout errors. However, the de driver in 2.1.5R works with this setup (I was able to establish communication with an ultrasparc at 100mb just fine). I actually ran both versions on the same system to eliminate the possibility of hardware differences causing the problem. If whoever looks at this wants any more information please contact me. -Fred Gilham gilham@csl.sri.com From owner-freebsd-hackers Thu Sep 12 11:19:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA20388 for hackers-outgoing; Thu, 12 Sep 1996 11:19:04 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA20380 for ; Thu, 12 Sep 1996 11:19:02 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA07211; Thu, 12 Sep 1996 11:16:59 -0700 From: Terry Lambert Message-Id: <199609121816.LAA07211@phaeton.artisoft.com> Subject: Re: OpenBSD <-> FreeBSD To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 12 Sep 1996 11:16:59 -0700 (MST) Cc: graphix@iastate.edu, hackers@freebsd.org In-Reply-To: <467.842508770@time.cdrom.com> from "Jordan K. Hubbard" at Sep 11, 96 11:12:50 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Is there anyone tracking the changes that are made to the 4.4 source > > in NetBSD/OpenBSD and incorporating the changes into the FreeBSD tree on > > a regular basis? If not, what is the common feeling of if this would be > > No, and we really wish there were more people willing to do that! > It's one of our #1 wish-list items, since we're essentially throwing > away free fixes and enhancements otherwise. Just a note: OpenBSD is not the only source of fixes being discarded. Hint: have you integrated the patches I sent you to add remote system semantics for flock for support of NFS server locking yet? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Sep 12 11:22:44 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA20687 for hackers-outgoing; Thu, 12 Sep 1996 11:22:44 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA20682 for ; Thu, 12 Sep 1996 11:22:41 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA07228; Thu, 12 Sep 1996 11:20:41 -0700 From: Terry Lambert Message-Id: <199609121820.LAA07228@phaeton.artisoft.com> Subject: Re: IDE and ASUS P/I-P6NP5 To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Thu, 12 Sep 1996 11:20:41 -0700 (MST) Cc: brianc@pobox.com, freebsd-hackers@freebsd.org In-Reply-To: <521.842510031@time.cdrom.com> from "Jordan K. Hubbard" at Sep 11, 96 11:33:51 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Hey, folks, I think this whole SCSI vs IDE debate sort of misses the > fundamental point, which has nothing at all to do with "which is > better." We're in the business of providing an operating system > with FreeBSD, which means that the decision making process should > always go like this: > > 1. Evaluate what the market is using, paying particular attention to > what the existing and potential FreeBSD segments of it are inclined to buy. > > 2. Assign development priorities based on this data. > > 3. Identify appropriate mailing lists to whine into, the volume and > frequency of said whining being directly proportional to the importance > of the task. > > 4. Wait for resources to match themselves to projects. :-) Clearly, no one wants to match themselves to "advanced" IDE, with the possible exception of Soren, who is arguably insane. 8-). People who want it should match themselves, or it won't get done, no matter how much #3 is pounded upon ("I cut it off 3 times and it's still too short"). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Sep 12 11:23:17 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA20752 for hackers-outgoing; Thu, 12 Sep 1996 11:23:17 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA20745 for ; Thu, 12 Sep 1996 11:23:15 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id LAA04279; Thu, 12 Sep 1996 11:21:46 -0700 (PDT) To: Terry Lambert cc: graphix@iastate.edu, hackers@freebsd.org Subject: Re: OpenBSD <-> FreeBSD In-reply-to: Your message of "Thu, 12 Sep 1996 11:16:59 PDT." <199609121816.LAA07211@phaeton.artisoft.com> Date: Thu, 12 Sep 1996 11:21:46 -0700 Message-ID: <4277.842552506@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Just a note: OpenBSD is not the only source of fixes being discarded. > Hint: have you integrated the patches I sent you to add remote system > semantics for flock for support of NFS server locking yet? No, because I don't know enough about the VFS system to even verify that they work properly. I'd be a lot happier if someone with half a clue about NFS, like Doug, did the integration. Jordan From owner-freebsd-hackers Thu Sep 12 11:26:56 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA21016 for hackers-outgoing; Thu, 12 Sep 1996 11:26:56 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA21010 for ; Thu, 12 Sep 1996 11:26:54 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA07246; Thu, 12 Sep 1996 11:23:35 -0700 From: Terry Lambert Message-Id: <199609121823.LAA07246@phaeton.artisoft.com> Subject: Re: IDE and DMA To: sos@FreeBSD.org Date: Thu, 12 Sep 1996 11:23:34 -0700 (MST) Cc: terry@lambert.org, e8917523@linf.unb.br, hackers@freefall.freebsd.org In-Reply-To: <199609120656.IAA04005@ra.dkuug.dk> from "sos@FreeBSD.org" at Sep 12, 96 08:56:42 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > What we need is not the occasional hack, we need a person > (or team) that takes on RESPONSIBILITY for that particualr > piece of code, and I have plenty on my platter allready .... Like Richard wanted to take responsibility for the build system? 8^) 8-) 8-O 8-( 8~( Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Sep 12 11:30:15 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA21244 for hackers-outgoing; Thu, 12 Sep 1996 11:30:15 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA21154 for ; Thu, 12 Sep 1996 11:28:53 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA07267; Thu, 12 Sep 1996 11:26:05 -0700 From: Terry Lambert Message-Id: <199609121826.LAA07267@phaeton.artisoft.com> Subject: Re: SYN Resisting (fwd) To: karl@Mcs.Net (Karl Denninger) Date: Thu, 12 Sep 1996 11:26:05 -0700 (MST) Cc: avalon@coombs.anu.edu.au, karl@Mcs.Net, koshy@india.hp.com, freebsd-hackers@freebsd.org In-Reply-To: <199609121523.KAA16744@Jupiter.mcs.net> from "Karl Denninger" at Sep 12, 96 10:23:23 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I heard someone mention 25% packet loss on an Australia-USA line (packets > > were being dropped in the USA). > > With a 25% packet loss rate you've got bigger problems. Like you are probably ignoring source quench. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Sep 12 12:05:12 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA23047 for hackers-outgoing; Thu, 12 Sep 1996 12:05:12 -0700 (PDT) Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA23039; Thu, 12 Sep 1996 12:05:09 -0700 (PDT) Received: by halloran-eldar.lcs.mit.edu; (5.65v3.2/1.1.8.2/19Aug95-0530PM) id AA29311; Thu, 12 Sep 1996 15:05:04 -0400 Date: Thu, 12 Sep 1996 15:05:04 -0400 From: Garrett Wollman Message-Id: <9609121905.AA29311@halloran-eldar.lcs.mit.edu> To: Luigi Rizzo Cc: hackers@freebsd.org, wollman@lcs.mit.edu, phk@freebsd.org Subject: Changing default TCP window size ? In-Reply-To: <199609112117.XAA08985@labinfo.iet.unipi.it> References: <199609112117.XAA08985@labinfo.iet.unipi.it> Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk < said: > How do I force TCP (or the OS) to use a window size different from the > default 16K ? > The following code > mywin=DESIRED_WINDOW_SIZE; > setsockopt(f, SOL_SOCKET, SO_SNDBUF, (char *)&mywin, sizeof mywin) > appears to set the value correctly (it can be read back with > getsockopt) but then it appears not to have any effect on TCP > (monitoring the connection with netstat -na always shows a Send-Q > around 16KB, and the throughput in window-limited configurations > remains unchanged). This is a conflict that needs to be resolved between the option-processing code and the code that attempts to set the socket buffer size based on what's in the route. I can't give you a fully-fleshed-out solution, but essentially the code needs to check if there is a buffer size specified via setsockopt, and if there is, then it should ignore the values in the route (or perhaps it should use the lock bits in the route to indicate some sort of clamping). I have a long-standing bug report form Matthew Dillon about this, but it has not had a sufficiently high priority to get done. Come up with a good fix and I'll take it. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, ANA, or NSA| - Susan Aglukark and Chad Irschick From owner-freebsd-hackers Thu Sep 12 14:10:24 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA03637 for hackers-outgoing; Thu, 12 Sep 1996 14:10:24 -0700 (PDT) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA03614 for ; Thu, 12 Sep 1996 14:10:19 -0700 (PDT) Message-Id: <199609122110.OAA03614@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA286602596; Fri, 13 Sep 1996 07:09:56 +1000 From: Darren Reed Subject: Re: Changing default TCP window size ? To: matt@lkg.dec.com (Matt Thomas) Date: Fri, 13 Sep 1996 07:09:56 +1000 (EST) Cc: luigi@labinfo.iet.unipi.it, hackers@freebsd.org In-Reply-To: <199609121034.KAA20501@whydos.lkg.dec.com> from "Matt Thomas" at Sep 12, 96 10:34:21 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Matt Thomas, sie said: > > > You can't do it in -current (as I found on FDDI). The TCP code forces > the buffser to what is in the route and does not allow one to override > them. About a month I sent a set of patches which allows SO_SNDBUF/ > SO_RCVBUF to work. sounds like something else there, I've watched ftp connections with tcpdump and in that case, the window grows during the data connection from 4k to 16k. From owner-freebsd-hackers Thu Sep 12 14:15:53 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA04139 for hackers-outgoing; Thu, 12 Sep 1996 14:15:53 -0700 (PDT) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA04129 for ; Thu, 12 Sep 1996 14:15:49 -0700 (PDT) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <15909(1)>; Thu, 12 Sep 1996 14:13:15 PDT Received: by crevenia.parc.xerox.com id <177595>; Thu, 12 Sep 1996 14:12:52 -0700 From: Bill Fenner To: karl@mcs.net, terry@lambert.org Subject: Re: SYN Resisting (fwd) Cc: avalon@coombs.anu.edu.au, freebsd-hackers@freebsd.org, koshy@india.hp.com Message-Id: <96Sep12.141252pdt.177595@crevenia.parc.xerox.com> Date: Thu, 12 Sep 1996 14:12:50 PDT Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Like you are probably ignoring source quench. Source quenches are deprecated by RFC1812. RFC1122 is still the host requirements RFC so technically hosts must still pay attention to them, but routers are not supposed to send them. 4.3.3.3 Source Quench A router SHOULD NOT originate ICMP Source Quench messages. ... DISCUSSION Research seems to suggest that Source Quench consumes network bandwidth but is an ineffective (and unfair) antidote to congestion. See, for example, [INTERNET:9] and [INTERNET:10]. Section [5.3.6] discusses the current thinking on how routers ought to deal with overload and network congestion. Bill From owner-freebsd-hackers Thu Sep 12 14:20:48 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA04371 for hackers-outgoing; Thu, 12 Sep 1996 14:20:48 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA04365 for ; Thu, 12 Sep 1996 14:20:44 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id WAA10840; Thu, 12 Sep 1996 22:51:05 +0200 From: Luigi Rizzo Message-Id: <199609122051.WAA10840@labinfo.iet.unipi.it> Subject: Re: Changing default TCP window size ? To: avalon@coombs.anu.edu.au (Darren Reed) Date: Thu, 12 Sep 1996 22:51:05 +0200 (MET DST) Cc: matt@lkg.dec.com, hackers@freebsd.org In-Reply-To: <199609122042.WAA10821@labinfo.iet.unipi.it> from "Darren Reed" at Sep 13, 96 07:09:37 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > In some mail from Matt Thomas, sie said: > > > > You can't do it in -current (as I found on FDDI). The TCP code forces > > the buffser to what is in the route and does not allow one to override > > them. About a month I sent a set of patches which allows SO_SNDBUF/ > > SO_RCVBUF to work. > > sounds like something else there, I've watched ftp connections with > tcpdump and in that case, the window grows during the data connection from > 4k to 16k. Have played a little bit with Matt's patch (which is quite simple, in tcp_input.c the two blocks of code conditioned to RTV_SPIPE and RTV_RPIPE must be changed as follows: #ifdef RTV_SPIPE if ((bufsize = rt->rt_rmx.rmx_sendpipe) == 0 || /* XXX Matt Thomas fix to enable larger windows */ so->so_snd.sb_hiwat != tcp_sendspace ) #endif ... #ifdef RTV_RPIPE if ((bufsize = rt->rt_rmx.rmx_recvpipe) == 0 || /* XXX Matt Thomas fix to enable larger windows */ so->so_rcv.sb_hiwat != tcp_recvspace) #endif and this works, in principle. The problem is, you have to recompile applications to call setsockopt() with SO_SNDBUF and SO_RCVBUF, or you need to alter tcp_sendspace and tcp_recvspace (don't know if they can be modified with sysctl.) After this, things work up to a window of 65535. For larger windows, using scaling options, I think there is some problem with option negotiation, so that if both values are not above 65535 they end up negotiating the default value (16K) instead of the min() of the two values. Still looking at this... Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ==================================================================== From owner-freebsd-hackers Thu Sep 12 14:55:38 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA05999 for hackers-outgoing; Thu, 12 Sep 1996 14:55:38 -0700 (PDT) Received: from seagull.rtd.com (root@seagull.rtd.com [198.102.68.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA05989 for ; Thu, 12 Sep 1996 14:55:33 -0700 (PDT) Received: (from dgy@localhost) by seagull.rtd.com (8.7.5/8.7.3) id OAA11557 for freebsd-hackers@freefall.cdrom.com; Thu, 12 Sep 1996 14:55:31 -0700 (MST) From: Don Yuniskis Message-Id: <199609122155.OAA11557@seagull.rtd.com> Subject: CVS posers To: freebsd-hackers@freefall.FreeBSD.org (FreeBSD hackers) Date: Thu, 12 Sep 1996 14:55:31 -0700 (MST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Greetings! A couple of CVS related queries, if I could impose upon you all... I'm trying to hack together a kludgey tree of past FreeBSD releases. Presumably, I can just grab the sources for each release and piece it together from them? If so, I presume I would *import* each release using a tag similar to X.X-RELEASE? Then, to *extract* the sources pertinent to a particular release, I would select only those files associated with that tag? If, however, I merely did a "checkout", I would end up with the most recent versions of *all* files, correct? Even those no longer present in "the most recent" X.X-RELEASE?? Also, is is possible to glue CVS around an existing RCS tree? I imagine I would NOT be able to reconstruct the "log" for that tree, though?? Again, sorry for the "bother" but every time I think I understand CVS, it finds some new way of confusing me (I suspect CONCURRENT is *not* what the "C" stands for... :-( Thanks! --don From owner-freebsd-hackers Thu Sep 12 15:04:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA06524 for hackers-outgoing; Thu, 12 Sep 1996 15:04:02 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA06509 for ; Thu, 12 Sep 1996 15:03:55 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA07685; Thu, 12 Sep 1996 15:02:21 -0700 From: Terry Lambert Message-Id: <199609122202.PAA07685@phaeton.artisoft.com> Subject: Re: SYN Resisting (fwd) To: fenner@parc.xerox.com (Bill Fenner) Date: Thu, 12 Sep 1996 15:02:21 -0700 (MST) Cc: karl@mcs.net, terry@lambert.org, avalon@coombs.anu.edu.au, freebsd-hackers@freebsd.org, koshy@india.hp.com In-Reply-To: <96Sep12.141252pdt.177595@crevenia.parc.xerox.com> from "Bill Fenner" at Sep 12, 96 02:12:50 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >Like you are probably ignoring source quench. > > Source quenches are deprecated by RFC1812. RFC1122 is still the host > requirements RFC so technically hosts must still pay attention to them, > but routers are not supposed to send them. > > 4.3.3.3 Source Quench > > A router SHOULD NOT originate ICMP Source Quench messages. > ... > DISCUSSION > Research seems to suggest that Source Quench consumes network > bandwidth but is an ineffective (and unfair) antidote to > congestion. See, for example, [INTERNET:9] and [INTERNET:10]. > Section [5.3.6] discusses the current thinking on how routers > ought to deal with overload and network congestion. I don't know the wire protocol in use, but I would suspect that if it's LD cable transport, that it's ATM without a committed rate. This would be, by definition, unreliable small datagram delivery (aka "leaky bucket"). ATM manages loss conditions not by committing rates, but by issueing source quench base on dropped packet counters. Yes, I know, ATM is annoying, but it is what the phone companies use for large links, and we are stuck with it. Other than that, I was a little peeved at blaming the US with the blanket statement that the loss was on the US end of things. Ignoring perfectly valid source quench requests (from *non*-ICMP ATM routers) is only one of the possibilites that could be considered before calling everyone managing NSP in the US incompetent. Frame Relay has the same source quench issues as ATM (or IPV6, for that matter), so it;s not clear where the blame lies. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Sep 12 15:04:47 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA06618 for hackers-outgoing; Thu, 12 Sep 1996 15:04:47 -0700 (PDT) Received: from ns.eu.org (valerian.glou.eu.org [193.56.58.251]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA06588 for ; Thu, 12 Sep 1996 15:04:27 -0700 (PDT) Received: (from uucp@localhost) by ns.eu.org (8.7.3/8.7.1/951117) with UUCP id AAA08594; Fri, 13 Sep 1996 00:03:22 +0200 (MET DST) Received: (from regnauld@localhost) by tetard.glou.eu.org (8.7.5/8.7.3/tetard-uucp-2.7) id AAA08366; Fri, 13 Sep 1996 00:00:25 +0200 (MET DST) From: Philippe Regnauld Message-Id: <199609122200.AAA08366@tetard.glou.eu.org> Subject: Re: A complaint about procedure. To: rkw@dataplex.net (Richard Wackerbarth) Date: Fri, 13 Sep 1996 00:00:24 +0200 (MET DST) Cc: regnauld@tetard.glou.eu.org (Philippe Regnauld), hackers@freebsd.org (hackers) In-Reply-To: from Richard Wackerbarth at "Sep 11, 96 07:32:04 am" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Richard Wackerbarth écrit / writes: > My attempts to "verify" that -current is buildable have led me to observe > that the precise concern that I previously expressed is a reality. Possibly along your concept, yes. > There are individuals who are making fundamental changes to the structure > of the Makefiles which are not coompatible with the changes that I am > making. I cannot possibly create a working system to hand to you if I am > having to shoot at such a moving target. What about creating a working prototype for your system based, say on 2.1.5, and present it to the core team. Since this is already not an easy task, accomplishing it would buy you several things: 1) Credit in the eyes of the core team. If you get this working, you will indeed impress many people out there. 2) With 1), you will most probably get support from the core team for further development, i.e.: 2a) Hopefully committers and others will see the benefit and will make an effort to slow down the "moving target" 2b) Even better, some might offer to integrate your efforts back into -current, if it's so valuable. > That is why I feel that it is NECESSARY to have some planning rather than > the present anarchy. Why do you allow some individuals the right to do > things which become direct roadblocks to other efforts? Who is 'you', and in what way can 'he/they' allow/not allow individuals some 'right', a concept which I believe doesn't (and can't) exist in the FreeBSD project ? I think it has been said many times by different people that what you ask for implies an infrastructure which is *not* that of the FreeBSD project. People here are working: - because it's fun ; - because it's useful ; - because it's fun I.e.: if it becomes a pain in the *ss to them, as in too many constraints, etc..., then they will stop contributing or come close to it, which I think has almost happened to some core team members. Were this Microsoft, your 'team partners' would be waiting and/or cooperating in the way you expect, because the boss or some microBill *told* them to. > If we cannot create an atmosphere wherein there is coordination as to the > direction of changes, I cannot contribute in this area. I would be tempted to say : "Tough luck" You've been given MANY hints by many different people about how to do it. It may be that they are all wrong an you're right about doing it, but the fact is: 'they' have it working this way, they most probably have some idea which way to proceed. > Frankly, it still appears to me that you have a double standard and, with > respect to the FreeBSD project, intend to prevent me from accomplishing > anything of significance. Again, who is 'you' ? Jordan ? I doubt Jordan has enough time to spare to setup machiavelic schemes to shortfuse your plans. > I cannot get you to implement suggested improvements which are completely > defined and the code for them exists. Neither can I make improvements to Hrmm, what code ? > the make system because the incremental steps are of no value to those who > do not understand the bigger picture. Nor can I "demonstrate" the finished Then draw the whole picture and push the paper under the door. > product because I have to shoot at a moving target and will never be able > to catch up. That I suggested a solution to. Short of implementing job control on humans (Terry probably has some outline for this :-) and suspending them, I don't see another. > HOW CAN I contribute? By contributing ? :-) -- Phil -- -[ Philippe Regnauld / regnauld@eu.org / +55.4N +11.3E @ Sol3 / +45 31241690 ]- -[ "To kårve or nøt to kårve, that is the qvestion..." -- My sister ]- From owner-freebsd-hackers Thu Sep 12 16:20:24 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA11419 for hackers-outgoing; Thu, 12 Sep 1996 16:20:24 -0700 (PDT) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA11411 for ; Thu, 12 Sep 1996 16:20:19 -0700 (PDT) Message-Id: <199609122320.QAA11411@freefall.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA035840320; Fri, 13 Sep 1996 09:18:40 +1000 From: Darren Reed Subject: Re: SYN Resisting (fwd) To: terry@lambert.org (Terry Lambert) Date: Fri, 13 Sep 1996 09:18:40 +1000 (EST) Cc: fenner@parc.xerox.com, karl@mcs.net, terry@lambert.org, avalon@coombs.anu.edu.au, freebsd-hackers@FreeBSD.org, koshy@india.hp.com In-Reply-To: <199609122202.PAA07685@phaeton.artisoft.com> from "Terry Lambert" at Sep 12, 96 03:02:21 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In some mail from Terry Lambert, sie said: > > Other than that, I was a little peeved at blaming the US with the blanket > statement that the loss was on the US end of things. Ignoring perfectly > valid source quench requests (from *non*-ICMP ATM routers) is only one > of the possibilites that could be considered before calling everyone > managing NSP in the US incompetent. I think that some people are unaware of congestion at/in points such as their West Coast (i.e. LA/Bay Area) where multiple, full, pipes start for international destinations. On the other hand, our local telco is probably no better than Sprint/MCI. I suspect that most NSP's in the USA don't provide international access. The point being, when your network is all peachy from end to end, having low timeouts is (maybe) acceptable, but when your endpoints are in diverse locations and throughput is not 100%, who is really winning ? If the attacker is trying to cause denial of service, then it may be achieved by the other end when they make it harder for real users to connect quick enough. To my thinking, this is a silly solution (but a reasonable patch for the sysctl :) to the SYN problem. The problem must and can only be fixed with correct filtering by all ISPs so long as we use the current IP. Darren From owner-freebsd-hackers Thu Sep 12 16:42:25 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA13165 for hackers-outgoing; Thu, 12 Sep 1996 16:42:25 -0700 (PDT) Received: from austin.polstra.com (austin.polstra.com [206.213.73.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA13155 for ; Thu, 12 Sep 1996 16:42:21 -0700 (PDT) Received: from austin.polstra.com (jdp@localhost) by austin.polstra.com (8.7.5/8.7.3) with ESMTP id QAA08296 for ; Thu, 12 Sep 1996 16:42:19 -0700 (PDT) Message-Id: <199609122342.QAA08296@austin.polstra.com> To: freebsd-hackers@freebsd.org Subject: CVSup 13.4 is now available Date: Thu, 12 Sep 1996 16:42:18 -0700 From: John Polstra Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Announcing CVSup 13.4 --------------------- Release 13.4 of CVSup, the CVS-aware network distribution system, is now available. Where to Get CVSup ------------------ CVSup is free software. It is available from the following FTP sites: ftp://freefall.freebsd.org/pub/CVSup/ ftp://ftp.freebsd.org/pub/FreeBSD/incoming/ ftp://ftp.polstra.com/pub/FreeBSD/CVSup/ (slow; avoid if possible) Full sources as well as FreeBSD binaries are available: cvsup-bin-13.4.tar.gz FreeBSD binaries for the client cvsupd-bin-13.4.tar.gz FreeBSD binaries for the server cvsup-13.4.tar.gz Sources ** MD5 signatures for these files are: MD5 (cvsup-bin-13.4.tar.gz) = d22feb17efbfbb53fbb1da03162216d5 MD5 (cvsupd-bin-13.4.tar.gz) = 0c5b90c7534e9a1591d99a93b236aa21 MD5 (cvsup-13.4.tar.gz) = d6c5aef96a01f657e7d884f6d2185232 An updated port will appear in the FreeBSD ports and packages collections soon: ftp:://ftp.freebsd.org/pub/FreeBSD/ports-current/net/cvsup/ ftp:://ftp.freebsd.org/pub/FreeBSD/packages-current/net/cvsup-13.4.tgz ** If you wish to build CVSup from the sources, be sure to read the discussion further on in this announcement. What Has Changed Since the Previous Release? -------------------------------------------- Detect and send changes to the RCS keyword expansion mode. Formerly, these (rare) changes were ignored. That caused checksum mismatches, which slowed down updates because the whole files had to be sent as fixups. Report 0-byte appends as what they really are, i.e., touches. Add a new statistics line for them. Make the command line option handling comply better with POSIX. Fix supconv to handle recent changes to the example "ports-supfile" in FreeBSD-current. Add a timeout to kill a server process when it has been inactive too long (15 minutes). This replaces the TCP keepalives that were added in the previous release. Add a hack to the server to make it easier to shut it down in a controlled manner. If a file "cvsupd-HALT" exists in the directory from which the server was started, and if it is newer than the time when the server was started, then the server will reject all new incoming connection requests. Make some changes to the zlib interface to eliminate the potential for an unsafe interaction with the garbage collector. FreeBSD binary releases are now built with a new version of the Modula-3 runtime that has a thread-safe version of malloc built into it. This cures some vexing core dumps that had been happening from time to time. Add work-arounds for the worst of the problems associated with malloc packages that are not thread-safe. These are not complete, however. I will probably incorporate a (hopefully portable) thread-safe malloc in the next release. Eliminate several FreeBSD-specific constructs that caused portability problems on other platforms. There is a good chance now that this software will compile and run out-of-the-box on most POSIX systems with standard SRC Modula-3 installations. What Is CVSup? -------------- CVSup is a software package for distributing and updating collections of files across a network. CVSup is specifically tailored to distributing CVS repositories. By taking advantage of the special properties of the files contained in CVS repositories, CVSup is able to perform updates much faster than traditional systems. It is especially valuable for people with slow Internet connections. CVSup parses and understands the RCS files making up a CVS repository. When updates occur, CVSup extracts new deltas directly from the RCS files on the server and edits them into the client's RCS files. Likewise, CVSup notes the addition of new symbolic tags to the files on the server and sends only the new tags to the client. CVSup is able to merge new deltas and tags from the server with deltas and tags added locally on the client machine. This makes it possible for the client to check local modifications into his repository without their being obliterated by subsequent updates from the server. Note: Although this feature is fully implemented in CVSup, it will probably not be practical to use it until some small changes have been made to CVS. In addition to distributing the RCS files themselves, CVSup is able to distribute specific checked-out versions. The client can specify a symbolic tag, a date, or both and CVSup will extract the appropriate versions from the server's CVS repository. Checked-out versions do not need to be stored on the server since CVSup can extract any version directly from the CVS repository. If the client has an existing checked-out tree, CVSup will apply the appropriate edits to update the tree or transform it into the requested version. Only the differences between the existing version and the desired version are sent across the network. CVSup uses lightweight processes (threads) to implement a streaming protocol across the network. This completely eliminates the delays associated with the lock-step, request-reply form of communication used by many existing protocols, such as sup and NNTP. Information is transferred at the full available speed of the network in both directions at once. Network latency and server response delays are rendered practically irrelevant. CVSup uses the "zlib" compression package to optionally compress all communications. This provides an additional 65-75% compression, on top of the diff-based compression already built into CVSup. For efficiency, all processing is built into the CVSup package itself. Neither the client nor the server executes any other programs. For further information about how CVSup works, see the "Blurb" document in the CVSup distribution. Using CVSup to Maintain FreeBSD Sources --------------------------------------- CVSup servers are currently running at the following FreeBSD mirror sites: USA: cvsup.freebsd.org cvsup2.freebsd.org The Netherlands: cvsup.nl.freebsd.org Using CVSup, you can easily receive or update any of the standard FreeBSD source releases, namely, "cvs", "current", and "stable". The manual page for cvsup(1) describes how to do that. If all goes well, additional servers will come on-line soon. Building CVSup from the Sources ------------------------------- CVSup is written in Modula-3, a modern, compiled, object-oriented language. Modula-3 integrates threads, exceptions, and garbage collection, providing an ideal vehicle for this sort of application. Without Modula-3, CVSup would almost certainly not exist today. If you wish to build CVSup from the sources, you will first need to install the free Modula-3 compiler and runtime libraries from DEC SRC. A port is available in the FreeBSD ports collection, in "lang/modula-3". The corresponding package is, of course, available in the packages collection. You will also need version 1.0.4 or later of the "zlib" library. In recent versions of FreeBSD-2.2-current, this library has been incorporated into the system sources, in "src/sys/lib/libz". Prior to that, a FreeBSD port was available in "devel/libz" of the FreeBSD ports collection. For other sources of this library, see the "Install" file. Do not try to use versions earlier than 1.0.4. You will also need Poul-Henning Kamp's "libmd" library. It is a standard library on FreeBSD systems. Portability Issues ------------------ I intend for CVSup to be portable to most POSIX systems. The present release has only been tested under FreeBSD versions 2.1 and later. Primarily because of packaging problems, this release of CVSup probably won't build out-of-the-box on other systems. Among other things, it relies on Poul-Henning Kamp's "libmd" encapsulation of the MD5 subroutines. The library itself appears to be quite portable, but its Makefiles are BSD-specific. There are probably some other FreeBSD-specific things in CVSup that have not been found yet. Anybody who succeeds in porting CVSup to other systems is encouraged to send his changes to . As long as the changes are reasonably palatable, they will be incorporated into future CVSup releases. CVSup uses several POSIX-specific functions which may make it more of an effort to port the package to non-POSIX systems such as Win32. These functions include mmap, fork, syslog, stat, and chmod, among others. Status of this Release ---------------------- CVSup has been in alpha testing since mid-May. This should be considered a beta release. Please be prepared to find bugs -- without a doubt, there are some. Please report bugs to . John Polstra, Copyright 1996 John D. Polstra $Id: Announce,v 1.9 1996/09/12 22:43:05 jdp Exp $ $Name: REL_13_4 $ From owner-freebsd-hackers Thu Sep 12 17:14:55 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA14715 for hackers-outgoing; Thu, 12 Sep 1996 17:14:55 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA14710 for ; Thu, 12 Sep 1996 17:14:52 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA07902; Thu, 12 Sep 1996 17:13:14 -0700 From: Terry Lambert Message-Id: <199609130013.RAA07902@phaeton.artisoft.com> Subject: Re: SYN Resisting (fwd) To: avalon@coombs.anu.edu.au (Darren Reed) Date: Thu, 12 Sep 1996 17:13:14 -0700 (MST) Cc: terry@lambert.org, fenner@parc.xerox.com, karl@mcs.net, avalon@coombs.anu.edu.au, freebsd-hackers@FreeBSD.org, koshy@india.hp.com In-Reply-To: <199609122319.QAA05189@coyote.Artisoft.COM> from "Darren Reed" at Sep 13, 96 09:18:40 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I suspect that most NSP's in the USA don't provide international access. All NSP's in the US connect to a NAP, or they aren't NSP's. So there are international interconnects for all of them, since you gointernational at the NAP's as well. Neither here nor there for the discussion, though. 8-). > The point being, when your network is all peachy from end to end, having > low timeouts is (maybe) acceptable, but when your endpoints are in > diverse locations and throughput is not 100%, who is really winning ? > > If the attacker is trying to cause denial of service, then it may be > achieved by the other end when they make it harder for real users to > connect quick enough. > > To my thinking, this is a silly solution (but a reasonable patch for the > sysctl :) to the SYN problem. The problem must and can only be fixed > with correct filtering by all ISPs so long as we use the current IP. Here we agree. If the point of your argument about bad traffic was that the SYN "patch" didn't consider all of the larger issues, then I agree 100%. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Thu Sep 12 17:40:18 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA16017 for hackers-outgoing; Thu, 12 Sep 1996 17:40:18 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA16011 for ; Thu, 12 Sep 1996 17:40:14 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id KAA13686; Fri, 13 Sep 1996 10:08:15 +0930 From: Michael Smith Message-Id: <199609130038.KAA13686@genesis.atrad.adelaide.edu.au> Subject: Re: SYN Resisting (fwd) To: terry@lambert.org (Terry Lambert) Date: Fri, 13 Sep 1996 10:08:15 +0930 (CST) Cc: fenner@parc.xerox.com, karl@mcs.net, terry@lambert.org, avalon@coombs.anu.edu.au, freebsd-hackers@FreeBSD.org, koshy@india.hp.com In-Reply-To: <199609122202.PAA07685@phaeton.artisoft.com> from "Terry Lambert" at Sep 12, 96 03:02:21 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert stands accused of saying: > > Other than that, I was a little peeved at blaming the US with the blanket > statement that the loss was on the US end of things. Ignoring perfectly > valid source quench requests (from *non*-ICMP ATM routers) is only one > of the possibilites that could be considered before calling everyone > managing NSP in the US incompetent. Ok, let's sink this right here and now. The major source of problems with the US <-> Australia link is and has been for some time the equipment/configuration/administration at the US end of things. You can see this for yourself (from here) by pinging/tracerouting across the link; everything's fine until you're several hops _off_ the wire at the US end. For all that we cuss Telstra, they actually do a tolerably good job. Last I heard source quench was being blocked at most places around australia anyway, so the whole issue is moot. > Terry Lambert -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[ From owner-freebsd-hackers Thu Sep 12 17:43:19 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA16221 for hackers-outgoing; Thu, 12 Sep 1996 17:43:19 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA16216 for ; Thu, 12 Sep 1996 17:43:17 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id AAA27149; Fri, 13 Sep 1996 00:42:44 GMT Date: Fri, 13 Sep 1996 09:42:44 +0900 (JST) From: Michael Hancock To: Darren Reed cc: Terry Lambert , fenner@parc.xerox.com, karl@mcs.net, freebsd-hackers@freebsd.org, koshy@india.hp.com Subject: Re: SYN Resisting (fwd) In-Reply-To: <199609122320.QAA11411@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 13 Sep 1996, Darren Reed wrote: > > Other than that, I was a little peeved at blaming the US with the blanket > > statement that the loss was on the US end of things. Ignoring perfectly > > valid source quench requests (from *non*-ICMP ATM routers) is only one > > of the possibilites that could be considered before calling everyone > > managing NSP in the US incompetent. > > I think that some people are unaware of congestion at/in points such as > their West Coast (i.e. LA/Bay Area) where multiple, full, pipes start > for international destinations. IIJ has a T3 into Mae-west and another one into NY-NAP. > On the other hand, our local telco is probably no better than Sprint/MCI. > > I suspect that most NSP's in the USA don't provide international access. MCI and ATT WorldNet each have a T3 link to Japan. > The point being, when your network is all peachy from end to end, having > low timeouts is (maybe) acceptable, but when your endpoints are in > diverse locations and throughput is not 100%, who is really winning ? The ones that can throw money at it. > If the attacker is trying to cause denial of service, then it may be > achieved by the other end when they make it harder for real users to > connect quick enough. > > To my thinking, this is a silly solution (but a reasonable patch for the > sysctl :) to the SYN problem. The problem must and can only be fixed > with correct filtering by all ISPs so long as we use the current IP. I'm not sure what's easier, to get all ISP's to do correct filtering or to get everyone to move to a new IP. Regards, Mike Hancock From owner-freebsd-hackers Thu Sep 12 20:35:01 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA13428 for hackers-outgoing; Thu, 12 Sep 1996 20:35:01 -0700 (PDT) Received: from mail.think.com (Mail1.Think.COM [131.239.33.245]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA13380 for ; Thu, 12 Sep 1996 20:34:58 -0700 (PDT) Received: from Early-Bird.Think.COM (Early-Bird-1.Think.COM [131.239.146.105]) by mail.think.com (8.7.5/m3) with ESMTP id XAA17766; Thu, 12 Sep 1996 23:34:46 -0400 (EDT) Received: from compound.Think.COM (fergus-27.dialup.prtel.com [206.10.99.158]) by Early-Bird.Think.COM (8.7.5/e1) with ESMTP id XAA28774; Thu, 12 Sep 1996 23:34:43 -0400 (EDT) Received: (from alk@localhost) by compound.Think.COM (8.7.5/8.7.3) id WAA25622; Thu, 12 Sep 1996 22:34:51 -0500 (CDT) Date: Thu, 12 Sep 1996 22:34:51 -0500 (CDT) From: Tony Kimball Message-Id: <199609130334.WAA25622@compound.Think.COM> To: avalon@coombs.anu.edu.au Cc: hackers@freebsd.org Subject: Re: SYN Resisting (fwd) Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Quoth Darren Reed on Thu, 12 September: : : > I haven't seen that kind of connect time in a long, long while on the net : > backbones... but then again, I may be better connected here than most. : : I heard someone mention 25% packet loss on an Australia-USA line (packets were : being dropped in the USA). : Hah, I've seen MCI drop 66% at WillowSprings for hours at a time, and Sprint drop 50% at MAE-East for similarly protracted times. It's like tin-cans on yo-yo strings out there. From owner-freebsd-hackers Thu Sep 12 20:35:56 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA13864 for hackers-outgoing; Thu, 12 Sep 1996 20:35:56 -0700 (PDT) Received: from onyx.bios.unc.edu (onyx.bios.unc.edu [152.2.94.52]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA13849 for ; Thu, 12 Sep 1996 20:35:53 -0700 (PDT) Received: from localhost (walter@localhost) by onyx.bios.unc.edu (8.7.5/8.6.12) with SMTP id XAA22184 for ; Thu, 12 Sep 1996 23:38:52 -0400 (EDT) X-Authentication-Warning: onyx.bios.unc.edu: walter owned process doing -bs Date: Thu, 12 Sep 1996 23:38:51 -0400 (EDT) From: Bruce Walter To: hackers@freebsd.org Subject: NFS/mount bug??? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello all! Just noticed an interesting thing... I typed mount -a twice (don't ask why) and all-of-a-sudden, mount shows the following: /dev/wd0a on / (local) /dev/wd0s1f on /usr (local) /dev/wd0s1e on /var (local) /dev/wd1s1e on /var/tmp (local) /dev/wd1s1f on /home (local) procfs on /proc (local) biostat:/home/sources/tarfiles on /tarfiles biostat:/home/sources/tarfiles on /tarfiles biostat:/home/sources/tarfiles on /tarfiles Now, to actually unmount /tarfiles, you have to do *three* umounts... INFO: FreeBSD 2.2-960612-SNAP #0: Wed Jul 24 16:25:16 EDT 1996 walter@onyx.bios.unc.edu:/usr/src/sys/compile/ONYX i386 Pentium 90 CPU 16 Mb RAM Any takers? - Bruce ======================================================================== || Bruce Walter || CB #7400 McGavran-Greenberg Hall || || Information Technology Support || Chapel Hill, NC 27599-7400 || || Department of Biostatistics || Tel: 919-966-7279 || || University of North Carolina || Fax: 919-966-3804 || ======================================================================== || BSD Unix -- It's not just a job, it's a way of life! || ======================================================================== From owner-freebsd-hackers Thu Sep 12 21:39:15 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA10719 for hackers-outgoing; Thu, 12 Sep 1996 21:39:15 -0700 (PDT) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA10683 for ; Thu, 12 Sep 1996 21:39:12 -0700 (PDT) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA19445; Fri, 13 Sep 1996 00:20:03 -0400 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Fri, 13 Sep 1996 00:20 EDT Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.7.5/8.7.3) with ESMTP id WAA00734 for ; Thu, 12 Sep 1996 22:49:34 -0400 (EDT) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id WAA00644 for freebsd-hackers@freebsd.org; Thu, 12 Sep 1996 22:50:14 -0400 (EDT) Date: Thu, 12 Sep 1996 22:50:14 -0400 (EDT) From: Thomas David Rivers Message-Id: <199609130250.WAA00644@lakes.water.net> To: ponds!freebsd.org!freebsd-hackers Subject: Back from the hurricane, and into the PnP storm... Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Well - I've finally got the power back on, and the machines rebooted :-) It was really something over here in Raleigh, NC. Anyway, I took this opportunity to replace an old 486 with a new PCI pentium-133 (Triton II-VX chip set, not the fastest, but hey...) Now - I've got an interesting plug-and-play problem. If I tell the BIOS (Award, PnP support version 1.0A dated 1996) it has no DRQs or IRQs it can assign to PnP/PCI devices, everything _except_ the Sound-Blaster PNP card I have will work. If I tell the BIOS it has any DRQs - the old ne2000 I have (not PnP) quits working... something weird there. Also, I should add, this is 2.1.5-RELEASE, with the PnP patches that were applicable to 2.1. What I assumed would happen is that the BIOS should give-up on assigning any values to the PnP sound card, then FreeBSD should pick up the pieces here... apparently, that's not what's going on. Also, I'm running a Trident 9680 PCI video card - could it be conflicting somehow? [I'm using the XFree86 'G' beta...] - Dave Rivers - From owner-freebsd-hackers Thu Sep 12 21:45:01 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA13472 for hackers-outgoing; Thu, 12 Sep 1996 21:45:01 -0700 (PDT) Received: from super-g.inch.com (spork@super-g.com [204.178.32.161]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA13447 for ; Thu, 12 Sep 1996 21:44:59 -0700 (PDT) Received: from localhost (spork@localhost) by super-g.inch.com (8.6.12/8.6.9) with SMTP id WAA02646; Thu, 12 Sep 1996 22:44:28 -0500 Date: Thu, 12 Sep 1996 22:44:28 -0500 (CDT) From: "S(pork)" X-Sender: spork@super-g.inch.com To: Bruce Walter cc: hackers@FreeBSD.ORG Subject: Re: NFS/mount bug??? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Just as a little aside, I've seen this on Linux and NetBSD as well... On NetBSD it seems trouble is not far behind when you go to umount them... Charles On Thu, 12 Sep 1996, Bruce Walter wrote: > Hello all! > > Just noticed an interesting thing... I typed mount -a twice (don't ask > why) and all-of-a-sudden, mount shows the following: > > /dev/wd0a on / (local) > /dev/wd0s1f on /usr (local) > /dev/wd0s1e on /var (local) > /dev/wd1s1e on /var/tmp (local) > /dev/wd1s1f on /home (local) > procfs on /proc (local) > biostat:/home/sources/tarfiles on /tarfiles > biostat:/home/sources/tarfiles on /tarfiles > biostat:/home/sources/tarfiles on /tarfiles > > Now, to actually unmount /tarfiles, you have to do *three* umounts... > > INFO: > > FreeBSD 2.2-960612-SNAP #0: Wed Jul 24 16:25:16 EDT 1996 > walter@onyx.bios.unc.edu:/usr/src/sys/compile/ONYX i386 > > Pentium 90 CPU > 16 Mb RAM > > Any takers? > > - Bruce > > ======================================================================== > || Bruce Walter || CB #7400 McGavran-Greenberg Hall || > || Information Technology Support || Chapel Hill, NC 27599-7400 || > || Department of Biostatistics || Tel: 919-966-7279 || > || University of North Carolina || Fax: 919-966-3804 || > ======================================================================== > || BSD Unix -- It's not just a job, it's a way of life! || > ======================================================================== > From owner-freebsd-hackers Thu Sep 12 22:15:42 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA25406 for hackers-outgoing; Thu, 12 Sep 1996 22:15:42 -0700 (PDT) Received: from ceres.bios.unc.edu (ceres.bios.unc.edu [152.2.94.225]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA25376 for ; Thu, 12 Sep 1996 22:15:37 -0700 (PDT) Received: from localhost (walter@localhost) by ceres.bios.unc.edu (8.7.5/8.6.12) with SMTP id BAA17000 for ; Fri, 13 Sep 1996 01:16:17 -0400 (EDT) X-Authentication-Warning: ceres.bios.unc.edu: walter owned process doing -bs Date: Fri, 13 Sep 1996 01:16:17 -0400 (EDT) From: Bruce Walter To: hackers@FreeBSD.ORG Subject: Re: NFS/mount bug??? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 12 Sep 1996, S(pork) wrote: > Just as a little aside, I've seen this on Linux and NetBSD as well... On > NetBSD it seems trouble is not far behind when you go to umount them... > > > > Just noticed an interesting thing... I typed mount -a twice (don't ask > > why) and all-of-a-sudden, mount shows the following: So far, after a couple-or-ten experiments, no troubles have arisen from the multiple mounts/umounts, so it appears we're a click better off than NetBSD. I seem to remember the NFS code being a real bear though, so I'll leave it up to the experts... ;) - Bruce ======================================================================== || Bruce Walter || CB #7400 McGavran-Greenberg Hall || || Information Technology Support || Chapel Hill, NC 27599-7400 || || Department of Biostatistics || Tel: 919-966-7279 || || University of North Carolina || Fax: 919-966-3804 || ======================================================================== || BSD Unix -- It's not just a job, it's a way of life! || ======================================================================== From owner-freebsd-hackers Thu Sep 12 22:51:46 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA13069 for hackers-outgoing; Thu, 12 Sep 1996 22:51:46 -0700 (PDT) Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA13043 for ; Thu, 12 Sep 1996 22:51:42 -0700 (PDT) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.7.5/8.7.3) with SMTP id BAA11521; Fri, 13 Sep 1996 01:47:39 -0400 (EDT) Message-Id: <199609130547.BAA11521@whizzo.transsys.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Terry Lambert cc: karl@Mcs.Net (Karl Denninger), avalon@coombs.anu.edu.au, koshy@india.hp.com, freebsd-hackers@FreeBSD.org From: "Louis A. Mamakos" Subject: Re: SYN Resisting (fwd) References: <199609121826.LAA07267@phaeton.artisoft.com> In-reply-to: Your message of "Thu, 12 Sep 1996 11:26:05 PDT." <199609121826.LAA07267@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Sep 1996 01:47:39 -0400 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > > I heard someone mention 25% packet loss on an Australia-USA line (packets > > > were being dropped in the USA). > > > > With a 25% packet loss rate you've got bigger problems. Yeah, you should price trans-Pacific DS3 circuits. It's quite an astonishing number of dollars per month. And there are 6 digits in the number. > Like you are probably ignoring source quench. The routers on those links (or pretty much any these days) don't generate source quench. It's death to the fast-forwarding path in the router, plus the packet being dropped may not be the one which is inducing congestion. Source quench is pretty much depricated these days since it really hasn't been demonstrated to actually help. With modern TCP's these days, your best approach is to not take up additional network capacity, but just drop the packet. TCP with VJ slow-start will back-off and Do The Right Thing. The lack of the packet (or it's ACK) will be the notification of the congestion event. Sort of like a virtual "DEC-bit"/"congestion experienced" bit in CLNS and FECN/BECN in Frame Relay. The real problem are applications using transport protocols which don't respect congestion events in the network, and reduce their offered load. Things like the some internet telephony packages running over UDP, that just Blast and Lose. Soon you'll see Random Early Drop (RED) implemented in backbone-class routers which will drop packets in router output queues at the onset of congestions. They get chosen at random which does the right thing - if you're misbehaving, then you'll have more packets stacked up in the output queue, and be more likely to get nailed. Grief is conserved, and infliction of pain is a closed loop - cause pain (congestion) and you experience pain (and lose). louie From owner-freebsd-hackers Thu Sep 12 23:39:02 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA24803 for hackers-outgoing; Thu, 12 Sep 1996 23:39:02 -0700 (PDT) Received: from pinky.junction.net (pinky.junction.net [199.166.227.12]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA24683 for ; Thu, 12 Sep 1996 23:37:19 -0700 (PDT) Received: from sidhe.memra.com (sidhe.memra.com [199.166.227.105]) by pinky.junction.net (8.6.12/8.6.12) with ESMTP id WAA08859 for ; Thu, 12 Sep 1996 22:50:42 -0700 Received: from localhost (michael@localhost) by sidhe.memra.com (8.6.12/8.6.12) with SMTP id XAA12953; Thu, 12 Sep 1996 23:33:40 -0700 Date: Thu, 12 Sep 1996 23:33:39 -0700 (PDT) From: Michael Dillon To: server-linux@netscape.org cc: freebsd-hackers@freebsd.org Subject: Re: SYN floods - possible solution? (fwd) Message-ID: Organization: Memra Software Inc. - Internet consulting MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Now here is something that could be used by sites to protect against SYN flood attacke assuming that they can build a special custom box with enough RAM to buffer the sockets for 30 seconds or more. How high a rate can SYN floods come in at? I've heard of 1,000 per sec which implies that this box needs to hold open 30,000 to 75,000 potential sockets. Is there any problem within IPv4 (seq #'s?) that would make this inherently impossible? Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com ---------- Forwarded message ---------- Date: Fri, 13 Sep 1996 01:36:54 -0400 (EDT) From: "Roderick Murchison, Jr." To: firewall-1@applicom.co.il Cc: firewalls@GreatCircle.COM Subject: Re: SYN floods - possible solution? On Thu, 12 Sep 1996, Blast wrote: > This problem has kept me awake more than coffee. :-) Ditto... I just woke up *again* with a kludgy but potential defense... sorry if this is totally out of whack, but I'm really beat! Ok. say you have a firewall between your network and you Internet connection. If that firewall could detect and *detain* a segment with the SYN option set, then see if the set source IP answers an ICMP echo request, we could effectively determine whether or not the SYN could be dropped at the firewall and not sent through to spam our hosts. If the source responds, release the SYN and let it pass through to the intended host. If it does not, trash the SYN and log the failure. Some moderate tracking and aging methods could be employed to intelligently quick drop sources we know are recently offline, and lessen the amount of echo requests we send out. Could this be a potential defense? If so, what products would be best suited to implement this? hope this helps, -r Roderick Murchison, Jr. murchiso@vivid.newbridge.com Newbridge Networks, Inc. office: (703) 708-5930 Product Manager - VIVID ACS fax: (703) 708-5937 Herndon, VA 22070-5241 http://www.vivid.newbridge.com From owner-freebsd-hackers Thu Sep 12 23:39:03 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA24809 for hackers-outgoing; Thu, 12 Sep 1996 23:39:03 -0700 (PDT) Received: from pinky.junction.net (pinky.junction.net [199.166.227.12]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA24798 for ; Thu, 12 Sep 1996 23:39:01 -0700 (PDT) Received: from sidhe.memra.com (sidhe.memra.com [199.166.227.105]) by pinky.junction.net (8.6.12/8.6.12) with ESMTP id WAA08883 for ; Thu, 12 Sep 1996 22:52:25 -0700 Received: from localhost (michael@localhost) by sidhe.memra.com (8.6.12/8.6.12) with SMTP id XAA12991 for ; Thu, 12 Sep 1996 23:36:46 -0700 Date: Thu, 12 Sep 1996 23:36:45 -0700 (PDT) From: Michael Dillon To: freebsd-hackers@freebsd.org Subject: Re: SYN floods - possible solution? (fwd) Message-ID: Organization: Memra Software Inc. - Internet consulting MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk If you really want to crosspost a reply to that last message of mine I made a typo in the Linux address. It should be server-linux@netspace.org Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com From owner-freebsd-hackers Thu Sep 12 23:40:17 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA25025 for hackers-outgoing; Thu, 12 Sep 1996 23:40:17 -0700 (PDT) Received: from abel.pdmi.ras.ru ([194.88.2.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA24941 for ; Thu, 12 Sep 1996 23:40:02 -0700 (PDT) Received: (from pialkin@localhost) by abel.pdmi.ras.ru (8.7.5/8.7.3) id KAA27799; Fri, 13 Sep 1996 10:41:01 +0400 (MSD) From: Alexey Pialkin Message-Id: <199609130641.KAA27799@abel.pdmi.ras.ru> Subject: Re: ATAPI patch To: ache@nagual.ru (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Date: Fri, 13 Sep 1996 10:41:00 +0400 (MSD) Cc: spblug@tsctube.spb.su, hackers@freebsd.org In-Reply-To: <199609111605.UAA00657@nagual.ru> from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Sep 11, 96 08:05:42 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I made some small ATAPI patch for FreeBSD 2.1.5 - it solves my problems with > > Panasonic 572B & GoldStar GCD-R542 CDROM's. I hope it will help somone to. > > This patch trying to solve IMHO to very common problems with ATAPI cdrom's - > > unknown phase problem & to slow report on commands. > > > > (it's rather hack then patch - but it will help somebody as help me.... :) > > Any comments ? > > Are you shure that _all_ those delays are neccessary? > Could you try to remove some of them, one by one? I don't sure about anything :) For example - my Panasonic 572B doesn't need any delays at all.But GoldStar does.So i don't realy know which one are neccessary and which not :( Also IMHO this delays will not make things worse - may be they will help someone ... But if you whant to probably profile this patch - you can try to delete all DELAYs that are not in atapi_probe(). Alexey Pialkin From owner-freebsd-hackers Fri Sep 13 00:29:31 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA29713 for hackers-outgoing; Fri, 13 Sep 1996 00:29:31 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA29708 for ; Fri, 13 Sep 1996 00:29:30 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id AAA13050; Fri, 13 Sep 1996 00:28:22 -0700 (PDT) To: Alexey Pialkin cc: ache@nagual.ru (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=), spblug@tsctube.spb.su, hackers@FreeBSD.ORG Subject: Re: ATAPI patch In-reply-to: Your message of "Fri, 13 Sep 1996 10:41:00 +0400." <199609130641.KAA27799@abel.pdmi.ras.ru> Date: Fri, 13 Sep 1996 00:28:22 -0700 Message-ID: <13048.842599702@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I don't sure about anything :) For example - my Panasonic 572B doesn't need > any delays at all.But GoldStar does.So i don't realy know which one are > neccessary and which not :( I think what he was wondering was whether you'd managed to make the GoldStar work with any *less* delays, e.g. is each and every one of them known to be necessary? Jordan From owner-freebsd-hackers Fri Sep 13 00:45:05 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA00131 for hackers-outgoing; Fri, 13 Sep 1996 00:45:05 -0700 (PDT) Received: from trapdoor.dstc.edu.au (root@trapdoor.dstc.edu.au [130.102.176.12]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA00114 for ; Fri, 13 Sep 1996 00:44:59 -0700 (PDT) Received: from foxtail.dstc.edu.au (foxtail.dstc.edu.au [130.102.176.14]) by trapdoor.dstc.edu.au (8.6.9/8.6.12) with ESMTP id RAA28263; Fri, 13 Sep 1996 17:44:43 +1000 Received: (from leonard@localhost) by foxtail.dstc.edu.au (8.6.10/8.6.10) id RAA07560; Fri, 13 Sep 1996 17:44:39 +1000 From: David Leonard Message-Id: <199609130744.RAA07560@foxtail.dstc.edu.au> Subject: Re: wait doesn't exist... what we can't?? To: gurney_j@resnet.uoregon.edu Date: Fri, 13 Sep 1996 17:44:39 +1000 (EST) Cc: hackers@freebsd.org Reply-To: leonard@dstc.edu.au X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In dstc.mail.freebsd.hackers you write: > well... I found the wait man page but there doesn't seem to be a program > that matches the man page... is there a reason? just wondering... ttyl.. there is no program called 'cd' either :) -- David Leonard Developer, DSTC The University of Queensland david.leonard@dstc.edu.au http://www.dstc.edu.au/~leonard/ "What is contemplation but laxative for the mind?" - T.A.Casady (?) From owner-freebsd-hackers Fri Sep 13 00:47:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA00243 for hackers-outgoing; Fri, 13 Sep 1996 00:47:04 -0700 (PDT) Received: from mailh1a.cyberway.com.sg (mailh1a.cyberway.com.sg [203.116.1.29]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA00236 for ; Fri, 13 Sep 1996 00:47:02 -0700 (PDT) Received: from iou.cyberway.com.sg ([203.116.2.190]) by mailh1a.cyberway.com.sg (8.7.3/8.7.3) with SMTP id PAA30558 for ; Fri, 13 Sep 1996 15:46:27 +0800 (SST) Message-ID: <323910FA.ABD@cyberway.com.sg> Date: Fri, 13 Sep 1996 15:44:58 +0800 From: Srikanth Organization: Digital Equipment Corporation X-Mailer: Mozilla 3.0b7 (X11; I; OSF1 V3.2 alpha) MIME-Version: 1.0 To: hackers@FreeBSD.org Subject: HELP REQUESTED... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Sir(s), I am interested in learning device drivers. Can you please suggest me any introductory books on them? Also, I want to know the differences between different buses: SCSI, PCI, EISA, etc. Is there any book or any site where I can learn more about? I am in the process of career advancement. Please help me. Regards Srikanth From owner-freebsd-hackers Fri Sep 13 01:03:53 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA01134 for hackers-outgoing; Fri, 13 Sep 1996 01:03:53 -0700 (PDT) Received: from al.imforei.apana.org.au (pjchilds@al.imforei.apana.org.au [202.12.89.41]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA01108 for ; Fri, 13 Sep 1996 01:03:41 -0700 (PDT) Received: (from pjchilds@localhost) by al.imforei.apana.org.au (8.7.5/8.7.3) id RAA02244; Fri, 13 Sep 1996 17:33:28 GMT Date: Fri, 13 Sep 1996 17:33:28 GMT From: Peter Childs Message-Id: <199609131733.RAA02244@al.imforei.apana.org.au> To: michael@memra.com, freebsd-hackers@freebsd.org Subject: Re: SYN floods - possible solution? (fwd) X-Newsreader: TIN [version 1.2 PL2] Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article you wrote: : Now here is something that could be used by sites to protect against SYN : flood attacke assuming that they can build a special custom box with : enough RAM to buffer the sockets for 30 seconds or more. How high a rate I don't think its going to work too well. Say your getting flooded with a stack of IP spoofed SYN connections... and your "super-spoof-protection-box" grabs 'em and sends off ICMP pings to the origin addresses.... and then those addresses all reply. Nothing stops the attackers using IP's that _are_ valid, and then the pings will succeed... One way of helping to insulate against denial of service attacks like these is to have your "inside" network with hosts for pop, telnet, etc, and then have a different machine servicing requests from the _big_bad_internet_ ... so if it gets trashed... well.. life goes on. Doing this with creative DNS and some well placed firewalls could be an idea. Peter -- Peter Childs --- http://www.imforei.apana.org.au/~pjchilds Finger pjchilds@al.imforei.apana.org.au for public PGP key Drag me, drop me, treat me like an object! From owner-freebsd-hackers Fri Sep 13 01:33:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA02910 for hackers-outgoing; Fri, 13 Sep 1996 01:33:07 -0700 (PDT) Received: from pinky.junction.net (pinky.junction.net [199.166.227.12]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA02903 for ; Fri, 13 Sep 1996 01:33:03 -0700 (PDT) Received: from sidhe.memra.com (sidhe.memra.com [199.166.227.105]) by pinky.junction.net (8.6.12/8.6.12) with ESMTP id AAA10270; Fri, 13 Sep 1996 00:46:25 -0700 Received: from localhost (michael@localhost) by sidhe.memra.com (8.6.12/8.6.12) with SMTP id BAA13884; Fri, 13 Sep 1996 01:30:46 -0700 Date: Fri, 13 Sep 1996 01:30:45 -0700 (PDT) From: Michael Dillon To: nanog@merit.edu cc: freebsd-hackers@freebsd.org Subject: Re: SYN floods - possible solution? (fwd) In-Reply-To: <199609130820.EAA06157@panix.com> Message-ID: Organization: Memra Software Inc. - Internet consulting MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 13 Sep 1996, Alexis Rosen wrote: > But... I still don't believe that this is a good global solution. Most ISPs > can't cope with this. The clue level I've been seeing among many of the > ISP "engineers" and "systems administrators" who have called in the last > few days to ask for help ("is your problem happening to me too???") is > astonishingly low. :-( Tell me about it. But if this kind of solution could be packaged up in a single box with two ethernet interfaces then a lot of less clueful ISP's could easily install such a thing and protect their whole network. If the box also provided default filters on source addresses that could help solve another problem as well. The fear of attack may well be the force which overcomes inertia here and gets more ISP's up to speed on these issues just like AIDS brought the issues of safe sex to the forefront. > I also have no clue what I'd choose to implement this on. It *could* be > done in a unix kernel but that's probably a really *bad* choice. I'm sure > plenty of people out there know some good possibilities, though. Well, the advantage to using something like FreeBSD is that it is freely available, well-documented, and eleigible for creating commercial products as long as you check copyrights carefully. Most parts of FreeBSD have no commercial use restrictions like GNU does. And FreeBSD already has the basic functionality in it including support for readily available hardware including 10baseT and 100baseTx and FDDI interfaces. Building this kind of box would be mostly an excercise in subtraction and it may well be possible to strip enough stuff out that it can all be booted off a 1.44 megabyte diskette into a diskless 486 or Pentium box with a RAMdisk. At that point all an ISP needs to do is download a file, a disk writing utility (RAWRITE.EXE) and assemble a box with certain standard components like their choice of 3 types of network card as mentioned above. If the box included ssh for the admin interface maybe it could create a precedent for router manufacturers? NOTE: I copied this one to freebsd-hackers Michael Dillon - ISP & Internet Consulting Memra Software Inc. - Fax: +1-604-546-3049 http://www.memra.com - E-mail: michael@memra.com From owner-freebsd-hackers Fri Sep 13 02:16:16 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA07325 for hackers-outgoing; Fri, 13 Sep 1996 02:16:16 -0700 (PDT) Received: from isbalham (isbalham.ist.co.uk [192.31.26.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA07313 for ; Fri, 13 Sep 1996 02:16:12 -0700 (PDT) Received: from gid.co.uk (uucp@localhost) by isbalham (8.6.12/8.6.12) with UUCP id KAA12974; Fri, 13 Sep 1996 10:06:29 +0100 Received: from [194.32.164.2] by seagoon.gid.co.uk; Fri, 13 Sep 1996 09:20:13 +0100 X-Sender: rb@194.32.164.1 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Sep 1996 09:21:25 +0100 To: Michael Smith , terry@lambert.org (Terry Lambert) From: rb@gid.co.uk (Bob Bishop) Subject: Re: SYN Resisting (fwd) Cc: fenner@parc.xerox.com, karl@mcs.net, avalon@coombs.anu.edu.au, freebsd-hackers@freebsd.org, koshy@india.hp.com Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 10:08 am 13/9/96, Michael Smith wrote: >Terry Lambert stands accused of saying: >>[things] > >Ok, let's sink this right here and now. The major source of problems >with the US <-> Australia link is and has been for some time the >equipment/configuration/administration at the US end of things. You can >see this for yourself (from here) by pinging/tracerouting across the link; >everything's fine until you're several hops _off_ the wire at the US >end. For all that we cuss Telstra, they actually do a tolerably good >job. FWIW, whenever we have some problem talking from UK to some site on the west coast, it's usually breaking at the handoff between and . -- Bob Bishop (0118) 977 4017 international code +44 118 rb@gid.co.uk fax (0118) 989 4254 between 0800 and 1800 UK From owner-freebsd-hackers Fri Sep 13 02:18:16 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA07519 for hackers-outgoing; Fri, 13 Sep 1996 02:18:16 -0700 (PDT) Received: from abel.pdmi.ras.ru ([194.88.2.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA07499 for ; Fri, 13 Sep 1996 02:18:01 -0700 (PDT) Received: (from pialkin@localhost) by abel.pdmi.ras.ru (8.7.5/8.7.3) id NAA00968; Fri, 13 Sep 1996 13:17:06 +0400 (MSD) From: Alexey Pialkin Message-Id: <199609130917.NAA00968@abel.pdmi.ras.ru> Subject: Re: ATAPI patch To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Fri, 13 Sep 1996 13:17:06 +0400 (MSD) Cc: ache@nagual.ru, spblug@tsctube.spb.su, hackers@FreeBSD.ORG In-Reply-To: <13048.842599702@time.cdrom.com> from "Jordan K. Hubbard" at Sep 13, 96 00:28:22 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I don't sure about anything :) For example - my Panasonic 572B doesn't need > > any delays at all.But GoldStar does.So i don't realy know which one are > > neccessary and which not :( > > I think what he was wondering was whether you'd managed to make the > GoldStar work with any *less* delays, e.g. is each and every one of them > known to be necessary? Ugh. Got a point. Yeah - i think it is possible to stay DELAYs only in atapi_probe() - all others are not so neccesary. P.S. sorry for such unended patch - but as i said before it's just a hack to get work CDROM. I hope someone sometime will able to write complet ATAPI driver and we will remeber this prolems just as a nightmare that have passed :) Alexey Pialkin From owner-freebsd-hackers Fri Sep 13 02:19:55 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA07658 for hackers-outgoing; Fri, 13 Sep 1996 02:19:55 -0700 (PDT) Received: from relay.philips.nl (ns.philips.nl [130.144.65.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA07651 for ; Fri, 13 Sep 1996 02:19:51 -0700 (PDT) Received: (from smap@localhost) by relay.philips.nl (8.6.9/8.6.9-950414) id LAA13103 for ; Fri, 13 Sep 1996 11:19:03 +0200 Received: from unknown(192.26.173.32) by ns.philips.nl via smap (V1.3+ESMTP) with ESMTP id sma010328; Fri Sep 13 11:01:05 1996 Received: from spooky.lss.cp.philips.com (spooky.lss.cp.philips.com [130.144.199.105]) by smtp.nl.cis.philips.com (8.6.10/8.6.10-0.9z-02May95) with ESMTP id LAA08337; Fri, 13 Sep 1996 11:03:45 +0200 Received: (from guido@localhost) by spooky.lss.cp.philips.com (8.6.10/8.6.10-0.991c-08Nov95) id LAA03640; Fri, 13 Sep 1996 11:00:48 +0200 From: Guido van Rooij Message-Id: <199609130900.LAA03640@spooky.lss.cp.philips.com> Subject: Re: vx device broken in 21.1.5? To: Guido.vanRooij@nl.cis.philips.com Date: Fri, 13 Sep 1996 11:00:47 +0200 (MET DST) Cc: freebsd-hackers@freebsd.org Reply-To: Guido.vanRooij@nl.cis.philips.com In-Reply-To: from guido at "Sep 6, 96 11:08:36 am" X-Mailer: ELM [version 2.4ME+ PL19 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I just ported the current Open/NetBSD if_vx driver to FreeBSD 2.1.5 and I am seeeing the exact same problems. I've ben assured that these drivers do work. What happens in FreeBSD is when vxstart() is called and there is not enough space free in the fifos, a treshold is set so the board will give an interrupt when the amount of free space in the fifos pass the treshold. Unfortunately, there is *never* one single interrupts given for this event. It just doesn't happen. Therefor OACTIVE stays set. Accoring to me, everything is done by the book (read: the OpenBSD driver): RD_0_MASK and INTR_MASK both contain TX_AVAIL at the interrupt time so TX_AVAIL should be set. I also printed the actuial free space in the interrupts handler. It started lower then the treshold and ended higher but there was *no* interrupt given where the status had the TX_AVAIL flag set. Any hints? -Guido From owner-freebsd-hackers Fri Sep 13 02:35:39 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA08750 for hackers-outgoing; Fri, 13 Sep 1996 02:35:39 -0700 (PDT) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA08736 for ; Fri, 13 Sep 1996 02:35:22 -0700 (PDT) Received: (from narvi@localhost) by haldjas.folklore.ee (8.7.5/8.6.12) id MAA01108; Fri, 13 Sep 1996 12:27:16 +0300 (EET DST) Date: Fri, 13 Sep 1996 12:27:16 +0300 (EET DST) From: Narvi To: Karl Denninger cc: A JOSEPH KOSHY , karl@Mcs.Net, freebsd-hackers@freebsd.org Subject: Re: SYN Resisting (fwd) In-Reply-To: <199609120328.WAA09803@Jupiter.mcs.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 11 Sep 1996, Karl Denninger wrote: > > > > >>>> "Karl Denninger" writes > > > > Hi Karl, > > > > > This changes the startup connection timeout to 10 seconds, which should be > > > more than enough on the Internet of today to prevent dropped links. 75 > > > seconds is only needed if you're running across two pieces of wet string. > > > > I've seen very large startup times when attempting to connect to sundry > > corners of the globe (> 30-45 seconds). I think reducing the connection > > timeout isn't a good idea as it would impact the ability of FreeBSD to > > connect to distant sites / sites accessible thru the congested links. > > > > Koshy > > Well, unless someone has a better idea, you can choose between that problem > and the SYN floods..... > > I haven't seen that kind of connect time in a long, long while on the net > backbones... but then again, I may be better connected here than most. And people in those corners have similar troubles connecting to the big world :-( How about making it to an otion which allows you to *specify* the timeout value? The approach of allowing only two modes of operation (the present and flood protected) is not too flexible. Sander > > -- > -- > Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity > http://www.mcs.net/~karl | T1 from $600 monthly; speeds to DS-3 available > | 23 Chicagoland Prefixes, 13 ISDN, much more > Voice: [+1 312 803-MCS1 x219]| Email to "info@mcs.net" WWW: http://www.mcs.net/ > Fax: [+1 312 248-9865] | Home of Chicago's only FULL Clarinet feed! > From owner-freebsd-hackers Fri Sep 13 02:49:27 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA09581 for hackers-outgoing; Fri, 13 Sep 1996 02:49:27 -0700 (PDT) Received: from ra.dkuug.dk (ra.dkuug.dk [193.88.44.193]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA09576 for ; Fri, 13 Sep 1996 02:49:24 -0700 (PDT) Received: (from sos@localhost) by ra.dkuug.dk (8.6.12/8.6.12) id LAA10504; Fri, 13 Sep 1996 11:45:54 +0200 Message-Id: <199609130945.LAA10504@ra.dkuug.dk> Subject: Re: ATAPI patch To: pialkin@abel.pdmi.ras.ru (Alexey Pialkin) Date: Fri, 13 Sep 1996 11:45:54 +0200 (MET DST) Cc: jkh@time.cdrom.com, ache@nagual.ru, spblug@tsctube.spb.su, hackers@FreeBSD.org In-Reply-To: <199609130917.NAA00968@abel.pdmi.ras.ru> from "Alexey Pialkin" at Sep 13, 96 01:17:06 pm From: sos@FreeBSD.org Reply-to: sos@FreeBSD.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In reply to Alexey Pialkin who wrote: > > > > I think what he was wondering was whether you'd managed to make the > > GoldStar work with any *less* delays, e.g. is each and every one of them > > known to be necessary? > > Ugh. Got a point. > Yeah - i think it is possible to stay DELAYs only in atapi_probe() - all others > are not so neccesary. > > P.S. sorry for such unended patch - but as i said before it's just a hack to get work CDROM. I hope someone sometime will able to write complet ATAPI driver and we will remeber this prolems just as a nightmare that have passed :) As I have allready stated, I'm on to it, but given the gigantic (!NOT) response I have gotten so far, NOONE really seems to care about it, SO GUYS IF YOU WANT A FUNCTIONAL ATA/ATAPI DRIVER READ MY POSTING !!! I will spend what I have of time on it, but I don't have a budget that allows me to go out and buy zillions of different devices.... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team So much code to hack -- so little time. From owner-freebsd-hackers Fri Sep 13 02:58:45 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA09794 for hackers-outgoing; Fri, 13 Sep 1996 02:58:45 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA09786 for ; Fri, 13 Sep 1996 02:58:42 -0700 (PDT) Received: from whale.gu.kiev.ua (whale.gu.kiev.ua [193.124.51.77]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id CAA12599 for ; Fri, 13 Sep 1996 02:55:13 -0700 (PDT) Received: from creator.gu.kiev.ua (stesin@creator.gu.kiev.ua [193.124.51.73]) by whale.gu.kiev.ua (8.7.5/8.7.3) with SMTP id MAA44164; Fri, 13 Sep 1996 12:32:01 +0300 Date: Fri, 13 Sep 1996 12:32:26 +0300 (EET DST) From: Andrew Stesin X-Sender: stesin@creator.gu.kiev.ua To: Michael Dillon cc: firewalls@greatcircle.com, freebsd-hackers@freebsd.org Subject: Re: SYN floods - possible solution? (fwd) In-Reply-To: Message-ID: X-NCC-RegID: ua.gu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Date: Thu, 12 Sep 1996 23:33:39 -0700 (PDT) > From: Michael Dillon > > Now here is something that could be used by sites to protect against SYN > flood attacke assuming that they can build a special custom box with > enough RAM to buffer the sockets for 30 seconds or more. How high a rate > can SYN floods come in at? I think ICMP-based solutions won't work. But assume the following: we take a PC with a plenty of RAM and customized BSD kernel, which works as a packet filter. What we can do with it -- we T can teach it to do "spoofing+buffering" of TCP handshakes for i a whole network behind it. The following chain of events will m take place in time: e | ------------------- "Acting persons" -------------------------- | | Client "Spoofer" Protected V (attacker?) firewall server 1. Sends SYN to protected Queues SYN as it Knows nothing :) server. was destined to it (just to another queue?) Sends SYN/ACK to client claiming to be a server, sets a timeout to wait for responce. #if (client is valid) 2. Continues with TCP Sends SYN to server, Gets 1st SYN connection. claiming to be a client. sends SYN/ACK to client. 3. Waits Silently "eats" SYN/ACK Waits server sent, caches connection as "valid,established" for passing it through later on. Passed continuation packet to server. 4. Works as usual Passed valid connection Works as usual through. #else /* SYN/flood attack -- queue timeout expired */ 2'. ??? (who cares?) Drops bad SYN away Still knows nothing #endif How to implement this? I'm just starting to check out exactly this, but as far as I know, Darren Reed's latest IPfilter is able to do some really sophisticated filtering, and (!) is able today to pass packets to an external user-space program. Some time coding that external program for your pet FreeBSD box -- and you may even store all that nasty-SYNs to a disk queue file! 8-) (Berkeley DB comes to mind -- very suitable for the purpose!) > I've heard of 1,000 per sec which implies that > this box needs to hold open 30,000 to 75,000 potential sockets. Is there > any problem within IPv4 (seq #'s?) that would make this inherently > impossible? 200MHz P5, 2 PCI NICs, 256+ Mb RAM, fast SCSI disk subsystem, + intelligent OS with intelligent packet filter. That's a today's firewall of choice for many people, anyway. What do you people think? This should (might?) work... > > Michael Dillon - ISP & Internet Consulting > Memra Software Inc. - Fax: +1-604-546-3049 > http://www.memra.com - E-mail: michael@memra.com > Best, Andrew Stesin From owner-freebsd-hackers Fri Sep 13 04:11:11 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA13688 for hackers-outgoing; Fri, 13 Sep 1996 04:11:11 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA13683 for ; Fri, 13 Sep 1996 04:11:08 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id EAA04697; Fri, 13 Sep 1996 04:08:13 -0700 (PDT) To: Alexey Pialkin cc: ache@nagual.ru, spblug@tsctube.spb.su, hackers@FreeBSD.ORG Subject: Re: ATAPI patch In-reply-to: Your message of "Fri, 13 Sep 1996 13:17:06 +0400." <199609130917.NAA00968@abel.pdmi.ras.ru> Date: Fri, 13 Sep 1996 04:08:13 -0700 Message-ID: <4695.842612893@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Ugh. Got a point. > Yeah - i think it is possible to stay DELAYs only in atapi_probe() - all othe rs > are not so neccesary. Erm, this is engineering here, no one will hurt you for being more precise. :-) Can you perhaps do some testing and verify this by more scientific methods? Jordan From owner-freebsd-hackers Fri Sep 13 04:11:53 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA13733 for hackers-outgoing; Fri, 13 Sep 1996 04:11:53 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA13725; Fri, 13 Sep 1996 04:11:50 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id EAA04726; Fri, 13 Sep 1996 04:11:48 -0700 (PDT) To: sos@FreeBSD.org cc: pialkin@abel.pdmi.ras.ru (Alexey Pialkin), ache@nagual.ru, spblug@tsctube.spb.su, hackers@FreeBSD.org Subject: Re: ATAPI patch In-reply-to: Your message of "Fri, 13 Sep 1996 11:45:54 +0200." <199609130945.LAA10504@ra.dkuug.dk> Date: Fri, 13 Sep 1996 04:11:47 -0700 Message-ID: <4724.842613107@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > SO GUYS IF YOU WANT A FUNCTIONAL ATA/ATAPI DRIVER READ MY POSTING !!! And folks, just so you don't think we're not trying here, I've got 3 drives I'm currently trying to get purchased and shipped on to Soren, but I can't do it all. Please, if you've a failing drive then please consider donating it to Soren so that we can get the ATAPI/IDE drivers working like they should be. Jordan From owner-freebsd-hackers Fri Sep 13 04:46:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA14977 for hackers-outgoing; Fri, 13 Sep 1996 04:46:35 -0700 (PDT) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA14970 for ; Fri, 13 Sep 1996 04:46:28 -0700 (PDT) Received: from minnow.render.com (minnow.render.com [193.195.178.1]) by minnow.render.com (8.6.12/8.6.9) with SMTP id MAA08787; Fri, 13 Sep 1996 12:40:09 +0100 Date: Fri, 13 Sep 1996 12:40:09 +0100 (BST) From: Doug Rabson To: Guido van Rooij cc: freebsd-hackers@freebsd.org Subject: Re: vx device broken in 21.1.5? In-Reply-To: <199609130900.LAA03640@spooky.lss.cp.philips.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 13 Sep 1996, Guido van Rooij wrote: > I just ported the current Open/NetBSD if_vx driver to FreeBSD 2.1.5 and > I am seeeing the exact same problems. > > I've ben assured that these drivers do work. > > What happens in FreeBSD is when vxstart() is called and there is not > enough space free in the fifos, a treshold is set so the board will > give an interrupt when the amount of free space in the fifos pass > the treshold. > > Unfortunately, there is *never* one single interrupts given for this event. > It just doesn't happen. Therefor OACTIVE stays set. > > Accoring to me, everything is done by the book (read: the OpenBSD driver): > RD_0_MASK and INTR_MASK both contain TX_AVAIL at the > interrupt time so TX_AVAIL should be set. I also printed the actuial free > space in the interrupts handler. It started lower then the treshold and > ended higher but there was *no* interrupt given where the status had the > TX_AVAIL flag set. > > Any hints? No idea. Sounds like busted hardware to me. You could always try to patch it up with some kind of timeout instead of waiting for TX_AVAIL. Surely the card should at least deliver a transmit-complete interrupt for the packet which was in the fifo. Maybe you could use that to restart transmission. -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 734 3761 FAX: +44 171 734 6426 From owner-freebsd-hackers Fri Sep 13 04:53:25 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA15304 for hackers-outgoing; Fri, 13 Sep 1996 04:53:25 -0700 (PDT) Received: from cet.cet.com (root@cet.cet.com [206.96.91.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id EAA15299 for ; Fri, 13 Sep 1996 04:53:23 -0700 (PDT) Received: from cet.cet.com (roberth@cet.cet.com [206.96.91.1]) by cet.cet.com (8.6.12/8.6.12) with SMTP id EAA01686; Fri, 13 Sep 1996 04:39:14 -0700 Date: Fri, 13 Sep 1996 04:39:14 -0700 (PDT) From: Robert Hanson To: Andrew Stesin cc: firewalls@GreatCircle.COM, freebsd-hackers@freebsd.org Subject: Re: SYN floods - possible solution? (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 13 Sep 1996, Andrew Stesin wrote: > > > #else /* SYN/flood attack -- queue timeout expired */ > > 2'. ??? (who cares?) Drops bad SYN away Still knows > nothing snip > > I've heard of 1,000 per sec which implies that > > this box needs to hold open 30,000 to 75,000 potential sockets. Is there > > any problem within IPv4 (seq #'s?) that would make this inherently > > impossible? > > 200MHz P5, 2 PCI NICs, 256+ Mb RAM, > fast SCSI disk subsystem, + intelligent OS with > intelligent packet filter. That's a today's firewall > of choice for many people, anyway. > > What do you people think? This should (might?) work... > > Andrew Stesin im thinking dec alpha with 64 bit OS... is there 64 bit FreeBSD coming? Evidently Linus is working on Linux/Alpha... IMHO pentiums are consumer class product (read affordable for most).... my observations are that other than "basic" affordability pentium stuff isnt really scalable... every new chip only affords "price" hosabilty cycle all over again for the mfgs.... what makes pentiums fly is good BSD and Linux hackers... go with the idea if it is fairly easily implementable though... good luck nuff said... ---> Robert H. Hanson LAN/WAN Consultant - Internet Service Provider Otis Orchards, Wa. Cutting Edge Communications www.cet.com (509) 927-9541 finger: info@cet.com or email: roberth@cet.com From owner-freebsd-hackers Fri Sep 13 05:01:59 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA15582 for hackers-outgoing; Fri, 13 Sep 1996 05:01:59 -0700 (PDT) Received: from itesec.hsc.fr (root@itesec.hsc.fr [192.70.106.33]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA15554 for ; Fri, 13 Sep 1996 05:00:01 -0700 (PDT) Received: from sidhe.hsc.fr (pb@sidhe.hsc.fr [192.70.106.44]) by itesec.hsc.fr (8.7.5/8.7.3/itesec-1.8) with ESMTP id NAA18115; Fri, 13 Sep 1996 13:59:14 +0200 (MET DST) Received: (from pb@localhost) by sidhe.hsc.fr (8.8.Alpha.4/sidhe-new-1.7) id NAA04610; Fri, 13 Sep 1996 13:59:13 +0200 (MET DST) Message-Id: <199609131159.NAA04610@sidhe.hsc.fr> Date: Fri, 13 Sep 1996 13:59:12 +0200 From: pb@hsc.fr (Pierre Beyssac) To: Guido.vanRooij@nl.cis.philips.com Cc: freebsd-hackers@freebsd.org Subject: Re: vx device broken in 21.1.5? In-Reply-To: <199609130900.LAA03640@spooky.lss.cp.philips.com>; from Guido van Rooij on Sep 13, 1996 11:00:47 +0200 References: <199609130900.LAA03640@spooky.lss.cp.philips.com> X-Mailer: Mutt 0.41 Mime-Version: 1.0 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to Guido van Rooij: > I just ported the current Open/NetBSD if_vx driver to FreeBSD 2.1.5 and > I am seeeing the exact same problems. > > I've ben assured that these drivers do work. I can say that I've experienced similar problems with the 2.1.5 vx driver in an installation just a few days ago. Some of the 3C595 series might be buggy: the vx driver (sometimes but not always) prints a "early defective adapter" at boot time. In addition to that, the reseller of the card told us that it was to be discontinued and replaced with the 3C905... That's all the information I have. We replaced it with a 3C509 and lived happily ever after. -- Pierre Beyssac pb@hsc.fr From owner-freebsd-hackers Fri Sep 13 05:39:50 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA17487 for hackers-outgoing; Fri, 13 Sep 1996 05:39:50 -0700 (PDT) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id FAA17472; Fri, 13 Sep 1996 05:39:40 -0700 (PDT) Received: from minnow.render.com (minnow.render.com [193.195.178.1]) by minnow.render.com (8.6.12/8.6.9) with SMTP id NAA08906; Fri, 13 Sep 1996 13:39:16 +0100 Date: Fri, 13 Sep 1996 13:39:13 +0100 (BST) From: Doug Rabson To: sos@FreeBSD.org cc: Alexey Pialkin , jkh@time.cdrom.com, ache@nagual.ru, spblug@tsctube.spb.su, hackers@FreeBSD.org Subject: Re: ATAPI patch In-Reply-To: <199609130945.LAA10504@ra.dkuug.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 13 Sep 1996 sos@FreeBSD.org wrote: > In reply to Alexey Pialkin who wrote: > > > > > > I think what he was wondering was whether you'd managed to make the > > > GoldStar work with any *less* delays, e.g. is each and every one of them > > > known to be necessary? > > > > Ugh. Got a point. > > Yeah - i think it is possible to stay DELAYs only in atapi_probe() - all others > > are not so neccesary. > > > > P.S. sorry for such unended patch - but as i said before it's just a hack to get work CDROM. I hope someone sometime will able to write complet ATAPI driver and we will remeber this prolems just as a nightmare that have passed :) > > As I have allready stated, I'm on to it, but given the gigantic > (!NOT) response I have gotten so far, NOONE really seems to care > about it, > > SO GUYS IF YOU WANT A FUNCTIONAL ATA/ATAPI DRIVER READ MY POSTING !!! > > I will spend what I have of time on it, but I don't have a budget > that allows me to go out and buy zillions of different devices.... I have a Mitsumi FX004 and a Goldstar of some kind which I can test on. -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 734 3761 FAX: +44 171 734 6426 From owner-freebsd-hackers Fri Sep 13 05:41:01 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA17656 for hackers-outgoing; Fri, 13 Sep 1996 05:41:01 -0700 (PDT) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA17647 for ; Fri, 13 Sep 1996 05:40:59 -0700 (PDT) Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with ESMTP id FAA25458; Fri, 13 Sep 1996 05:39:58 -0700 (PDT) Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id WAA21836; Fri, 13 Sep 1996 22:39:14 +1000 From: Julian Assange Message-Id: <199609131239.WAA21836@suburbia.net> Subject: Re: SYN floods - possible solution? (fwd) To: pjchilds@imforei.apana.org.au (Peter Childs) Date: Fri, 13 Sep 1996 22:39:14 +1000 (EST) Cc: michael@memra.com, freebsd-hackers@freebsd.org In-Reply-To: <199609131733.RAA02244@al.imforei.apana.org.au> from "Peter Childs" at Sep 13, 96 05:33:28 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > In article you wrote: > > : Now here is something that could be used by sites to protect against SYN > : flood attacke assuming that they can build a special custom box with > : enough RAM to buffer the sockets for 30 seconds or more. How high a rate > > I don't think its going to work too well. Say your getting flooded > with a stack of IP spoofed SYN connections... and your > "super-spoof-protection-box" grabs 'em and sends off ICMP pings to > the origin addresses.... and then those addresses all reply. > > Nothing stops the attackers using IP's that _are_ valid, and then > the pings will succeed... If the IP's are valid then the SYN|ACK's will be RST'd immediately. Although, you could choose valid addresses behind a filtering firewall that allows ICMP ECHO's through, but not SYN|ACK's ;) -- "Of all tyrannies a tyranny sincerely exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies, The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for own good will torment us without end, for they do so with the approval of their own conscience." - C.S. Lewis, _God in the Dock_ +---------------------+--------------------+----------------------------------+ |Julian Assange RSO | PO Box 2031 BARKER | Secret Analytic Guy Union | |proff@suburbia.net | VIC 3122 AUSTRALIA | finger for PGP key hash ID = | |proff@gnu.ai.mit.edu | FAX +61-3-98199066 | 0619737CCC143F6DEA73E27378933690 | +---------------------+--------------------+----------------------------------+ From owner-freebsd-hackers Fri Sep 13 06:24:29 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA19317 for hackers-outgoing; Fri, 13 Sep 1996 06:24:29 -0700 (PDT) Received: from mail.Clark.Net (mail.clark.net [168.143.0.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA19309 for ; Fri, 13 Sep 1996 06:24:26 -0700 (PDT) Received: from clark.net (proberts@clark.net [168.143.0.7]) by mail.Clark.Net (8.7.3/8.6.5) with ESMTP id JAA23097; Fri, 13 Sep 1996 09:24:12 -0400 (EDT) Received: from localhost (proberts@localhost) by clark.net (8.7.1/8.7.1) with SMTP id JAA01135; Fri, 13 Sep 1996 09:24:10 -0400 (EDT) X-Authentication-Warning: clark.net: proberts owned process doing -bs Date: Fri, 13 Sep 1996 09:24:10 -0400 (EDT) From: "Paul D. Robertson" To: Robert Hanson cc: Andrew Stesin , firewalls@GreatCircle.COM, freebsd-hackers@freebsd.org Subject: Re: SYN floods - possible solution? (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 13 Sep 1996, Robert Hanson wrote: > im thinking dec alpha with 64 bit OS... > > is there 64 bit FreeBSD coming? Evidently Linus is working on > Linux/Alpha... Linux/Alpha is real now, not "being worked on", and is pretty much merged into the current devel. tree, Sparc/Linux is very close to being officially part of the source tree as well. RedHat sells a Linux distribution for the Alpha on CD, though as of 2.0, any distribution should be find, and you can always FTP it. > > IMHO pentiums are consumer class product (read affordable for most).... my > observations are that other than "basic" affordability pentium stuff isnt > really scalable... every new chip only affords "price" hosabilty cycle all > over again for the mfgs.... It's still I/O speed for the most part, and the AXP systems have PCI buses just like the Pentiums. Paul ----------------------------------------------------------------------------- Paul D. Robertson "My statements in this message are personal opinions proberts@clark.net which may have no basis whatsoever in fact." PSB#9280 From owner-freebsd-hackers Fri Sep 13 06:36:34 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA19881 for hackers-outgoing; Fri, 13 Sep 1996 06:36:34 -0700 (PDT) Received: from relay.philips.nl (ns.philips.nl [130.144.65.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA19873 for ; Fri, 13 Sep 1996 06:36:29 -0700 (PDT) Received: (from smap@localhost) by relay.philips.nl (8.6.9/8.6.9-950414) id PAA24899; Fri, 13 Sep 1996 15:35:03 +0200 Received: from unknown(192.26.173.32) by ns.philips.nl via smap (V1.3+ESMTP) with ESMTP id sma023289; Fri Sep 13 15:25:05 1996 Received: from spooky.lss.cp.philips.com (spooky.lss.cp.philips.com [130.144.199.105]) by smtp.nl.cis.philips.com (8.6.10/8.6.10-0.9z-02May95) with ESMTP id PAA11831; Fri, 13 Sep 1996 15:27:54 +0200 Received: (from guido@localhost) by spooky.lss.cp.philips.com (8.6.10/8.6.10-0.991c-08Nov95) id PAA17480; Fri, 13 Sep 1996 15:24:57 +0200 From: Guido van Rooij Message-Id: <199609131324.PAA17480@spooky.lss.cp.philips.com> Subject: Re: vx device broken in 21.1.5? To: dfr@render.com (Doug Rabson) Date: Fri, 13 Sep 1996 15:24:57 +0200 (MET DST) Cc: freebsd-hackers@freebsd.org Reply-To: Guido.vanRooij@nl.cis.philips.com In-Reply-To: from Doug Rabson at "Sep 13, 96 12:40:09 pm" X-Mailer: ELM [version 2.4ME+ PL19 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Doug Rabson wrote: > No idea. Sounds like busted hardware to me. You could always try to > patch it up with some kind of timeout instead of waiting for TX_AVAIL. > Surely the card should at least deliver a transmit-complete interrupt for > the packet which was in the fifo. Maybe you could use that to restart > transmission. > I don't beleive it is the hardware. Lot's of FreeBSD ppl see this while the author of the driver for NetBSD doesn't know this behaviour. Indeed I patched it that way. Though unfortunately it will give less perfomance. -Guido From owner-freebsd-hackers Fri Sep 13 06:42:11 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA20112 for hackers-outgoing; Fri, 13 Sep 1996 06:42:11 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id GAA20107 for ; Fri, 13 Sep 1996 06:42:10 -0700 (PDT) Received: from Guard.PolyNet.Lviv.UA by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0v1YV6-0008tgC; Fri, 13 Sep 96 06:41 PDT Received: (from smap@localhost) by Guard.PolyNet.Lviv.UA (8.6.12/8.6.12) id QAA28485 for ; Fri, 13 Sep 1996 16:37:25 +0300 Received: from netsurfer.lp.lviv.ua(192.168.0.3) by Guard.PolyNet.Lviv.UA via smap (V2.0alpha) id xma028483; Fri, 13 Sep 96 16:37:20 +0300 Received: (from smap@localhost) by NetSurfer.lp.lviv.ua (8.6.12/8.6.12) id QAA11405 for ; Fri, 13 Sep 1996 16:37:19 +0300 Received: from nova.lp.lviv.ua(192.168.0.6) by NetSurfer.lp.lviv.ua via smap (V2.0alpha) id xma011402; Fri, 13 Sep 96 16:36:57 +0300 Message-ID: <32396377.41C6@polynet.lviv.ua> Date: Fri, 13 Sep 1996 16:36:56 +0300 From: Terletsky Slavik Organization: State University "Lvivska Polytechnicka" X-Mailer: Mozilla 3.0 (X11; I; OSF1 V3.2 alpha) MIME-Version: 1.0 To: FreeBSD Hackers mailing list Subject: How to read /dev/console's messages Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi I use different log files for different events but want to feed system monitoring program (swatch) by all of them. Suppose I direct all messages to /dev/console Is it possible to read them from /dev/console ? because swatch can take only piped or tailed -f input. What device can I use and how to read it? Any suggestions? -- # Terletsky Slavik # University "Lvivska Poytechnica" # # Network Administrator # mailto:ts@polynet.lviv.ua # From owner-freebsd-hackers Fri Sep 13 06:53:10 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA20481 for hackers-outgoing; Fri, 13 Sep 1996 06:53:10 -0700 (PDT) Received: from mx.serv.net (mx.serv.net [199.201.191.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA20476 for ; Fri, 13 Sep 1996 06:53:07 -0700 (PDT) Received: from MindBender.serv.net by mx.serv.net (8.7.5/SERV Revision: 2.30 † id GAA14332; Fri, 13 Sep 1996 06:53:02 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.serv.net (8.7.5/8.7.3) with SMTP id GAA02501; Fri, 13 Sep 1996 06:52:35 -0700 (PDT) Message-Id: <199609131352.GAA02501@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: Robert Hanson cc: Andrew Stesin , firewalls@greatcircle.com, freebsd-hackers@freebsd.org Subject: Re: SYN floods - possible solution? (fwd) In-reply-to: Your message of Fri, 13 Sep 96 04:39:14 -0700. Date: Fri, 13 Sep 1996 06:52:35 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> > I've heard of 1,000 per sec which implies that >> > this box needs to hold open 30,000 to 75,000 potential sockets. Is there >> > any problem within IPv4 (seq #'s?) that would make this inherently >> > impossible? >> 200MHz P5, 2 PCI NICs, 256+ Mb RAM, >> fast SCSI disk subsystem, + intelligent OS with >> intelligent packet filter. That's a today's firewall >> of choice for many people, anyway. >> What do you people think? This should (might?) work... A P6 should give you much better through-put than a 200MHz P5 (and it still has room to grow). Not only that, but 200MHz P6s are cheaper than 200MHz P5s right now. I've also heard that a 200MHz P5 doesn't really run any faster than a 166MHz P5, because the bus is mostly saturated. >im thinking dec alpha with 64 bit OS... >is there 64 bit FreeBSD coming? Evidently Linus is working on >Linux/Alpha... That is an alternative. While Alphas are great, really fast CPUs, they also cost a lot more per MIPS than a decent Intel box. On the other hand, a really good Alpha (read expensive) can scale way beyond an Intel box, if you need the absolute fastest processing you can get. NetBSD/Alpha exists, and is mostly 64-bit from top to bottom. I don't believe Linux/Alpha is truly 64-bit. You might also consider going commercial, if you're going to buy such high-end hardware. Digital Unix (aka OSF/1) isn't as "sexy" as Net/FreeBSD, but it works, is stable, and actually will support multi-processor Alphas reliably. ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@MindBender.serv.net --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... ----------------------------------------------------------------------------- From owner-freebsd-hackers Fri Sep 13 07:32:27 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA23172 for hackers-outgoing; Fri, 13 Sep 1996 07:32:27 -0700 (PDT) Received: from gryf.szc.ternet.pl ([194.204.187.130]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA23156 for ; Fri, 13 Sep 1996 07:32:17 -0700 (PDT) Received: from localhost (servbsd@localhost) by gryf.szc.ternet.pl (8.7.5/8.6.12) with SMTP id QAA03289 for ; Fri, 13 Sep 1996 16:31:59 +0200 (MET DST) Date: Fri, 13 Sep 1996 16:31:59 +0200 (MET DST) From: Darek Misiak X-Sender: servbsd@gryf To: hackers@FreeBSD.org Subject: private network Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi there ! I have got following problem. Our firm has got its own private network. In this network we have got two servers that we want to use as www serwer and ftp serwer. Our gateway has got "normal" IP, and these two ones have "ubnormal" (private). How can we make them to be visible in Internet ? Best regards to all of You Darek From owner-freebsd-hackers Fri Sep 13 07:50:38 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA24500 for hackers-outgoing; Fri, 13 Sep 1996 07:50:38 -0700 (PDT) Received: from whale.gu.kiev.ua (whale.gu.kiev.ua [193.124.51.77]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA24158 for ; Fri, 13 Sep 1996 07:45:07 -0700 (PDT) Received: from creator.gu.kiev.ua (stesin@creator.gu.kiev.ua [193.124.51.73]) by whale.gu.kiev.ua (8.7.5/8.7.3) with SMTP id RAA46792; Fri, 13 Sep 1996 17:28:52 +0300 Date: Fri, 13 Sep 1996 17:28:51 +0300 (EET DST) From: Andrew Stesin X-Sender: stesin@creator.gu.kiev.ua To: "Michael L. VanLoon -- HeadCandy.com" cc: firewalls@greatcircle.com, freebsd-hackers@freebsd.org Subject: Re: SYN floods - possible solution? (fwd) In-Reply-To: <199609131352.GAA02501@MindBender.serv.net> Message-ID: X-NCC-RegID: ua.gu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, be it Alpha or Intel, the most interesting question lays in another area: would Panix pay someone (Darren ?) for the implementation of such a BSDaemonish "spoof-buff" device 8-) for them -- or not? The answer will have a direct consequence of -- will we see it working in reality or not? Otherwise the whole hardware discussion is pointless. BTW as I was pointed already, I overlooked at least one very important (but hopefully not critical) technical detail... Best, Andrew Stesin nic-hdl: ST73-RIPE On Fri, 13 Sep 1996, Michael L. VanLoon -- HeadCandy.com wrote: > A P6 should give you much better through-put than a 200MHz P5 (and it > still has room to grow). Not only that, but 200MHz P6s are cheaper [...] From owner-freebsd-hackers Fri Sep 13 08:26:46 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA27066 for hackers-outgoing; Fri, 13 Sep 1996 08:26:46 -0700 (PDT) Received: from ns.pa-consulting.com (ns.pa-consulting.com [193.118.224.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA27059 for ; Fri, 13 Sep 1996 08:26:42 -0700 (PDT) Received: from SMTPGATE.PA-CONSULTING.COM by ns.pa-consulting.com (8.6.4) id QAA01508; Fri, 13 Sep 1996 16:36:38 +0100 Received: by SMTPGATE.PA-CONSULTING.COM with Microsoft Mail id <3239F0B3@SMTPGATE.PA-CONSULTING.COM>; Fri, 13 Sep 96 16:39:31 PDT From: Duncan Barclay To: freebsd-hackers Subject: Re: ATAPI patch Date: Fri, 13 Sep 96 16:17:00 PDT Message-ID: <3239F0B3@SMTPGATE.PA-CONSULTING.COM> Encoding: 41 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 13 Sep 1996 sos@FreeBSD.org wrote: > In reply to Alexey Pialkin who wrote: > > > > > > I think what he was wondering was whether you'd managed to make the > > > GoldStar work with any *less* delays, e.g. is each and every one of them > > > known to be necessary? > > > > Ugh. Got a point. > > Yeah - i think it is possible to stay DELAYs only in atapi_probe() - all others > > are not so neccesary. > > > > P.S. sorry for such unended patch - but as i said before it's just a hack to get work CDROM. I hope someone sometime will able to write complet ATAPI driver and we will remeber this prolems just as a nightmare that have passed :) > > As I have allready stated, I'm on to it, but given the gigantic > (!NOT) response I have gotten so far, NOONE really seems to care > about it, > > SO GUYS IF YOU WANT A FUNCTIONAL ATA/ATAPI DRIVER READ MY POSTING !!! > > I will spend what I have of time on it, but I don't have a budget > that allows me to go out and buy zillions of different devices.... I have a Sony CD76 which I will happily test on. It does seem to work fine in 2.1, even as the master on the second ide channel. It does not consistently report the same information when probed but this doesn't seem to matter. Duncan From owner-freebsd-hackers Fri Sep 13 09:40:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA01316 for hackers-outgoing; Fri, 13 Sep 1996 09:40:51 -0700 (PDT) Received: from nightflight.com (nightflight.com [207.135.216.194]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA01309; Fri, 13 Sep 1996 09:40:44 -0700 (PDT) Received: from DTIHOST.datatrek.com (gcrutcher.datatrek.com [204.33.81.150]) by nightflight.com (8.6.12/8.6.9) with SMTP id JAA10039; Fri, 13 Sep 1996 09:38:49 -0700 Message-Id: <2.2.32.19960913163622.0068c274@nightflight.com> X-Sender: gcrutchr@nightflight.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 13 Sep 1996 09:36:22 -0700 To: freebsd-questions@freebsd.org From: Gary Crutcher Subject: Excite Search engine Cc: freebsd-hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Has anyone sucessfully installed the Excite search engine for BSDI 2.0? I get a core dump during installation when it executes the following line: architextSearch -v Any suggestions how to overcome this. I am using FreeBSD v2.1 and have 64MB ram on a Pentium P133. Thanks, Gary ------------------------------------------------------------- Gary Crutcher E-mail: gcrutchr@nightflight.com Webmaster URL: http://www.nightflight.com Member of the Internet Developers Association ------------------------------------------------------------- From owner-freebsd-hackers Fri Sep 13 09:45:22 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA01622 for hackers-outgoing; Fri, 13 Sep 1996 09:45:22 -0700 (PDT) Received: from glacier.cold.org (glacier.sunrem.com [206.81.134.54]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA01614 for ; Fri, 13 Sep 1996 09:45:19 -0700 (PDT) Received: (from brandon@localhost) by glacier.cold.org (8.7.5/8.7.3) id KAA00214; Fri, 13 Sep 1996 10:45:58 -0600 (MDT) Date: Fri, 13 Sep 1996 10:45:57 -0600 (MDT) From: Brandon Gillespie To: freebsd-hackers@freebsd.org Subject: Install: panic: ufs_lock [...] HELP? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On nearly all systems where I have an IDE boot disk and a second SCSI disk. I seem to have this same problem when attempting to install. Basically at the first of the commit phase it panics with: panic: ufs_lock: unable to aquire lock, pid 1 (or something to that effect) Sometimes I've managed to get around this by having it do a bad block scan on the IDE disk. I really dont like doing this, what I would like to do is figure out WHY its doing this. Any ideas?? -Brandon From owner-freebsd-hackers Fri Sep 13 10:00:36 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA02389 for hackers-outgoing; Fri, 13 Sep 1996 10:00:36 -0700 (PDT) Received: from dns2.noc.best.net (dns2.noc.best.net [206.86.0.21]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA02366; Fri, 13 Sep 1996 10:00:31 -0700 (PDT) Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id KAA25281; Fri, 13 Sep 1996 10:00:28 -0700 Date: Fri, 13 Sep 1996 10:00:28 -0700 (PDT) From: Amanda Chou To: questions@FreeBSD.org, hackers@FreeBSD.org, hardware@FreeBSD.org Subject: Q: Tyan Tomcat I with > 64MB RAM Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Has anyone used Tyan Tomcat I with more than 64MB RAM? We ran into some weird problems; it works fine when we just put 64MB EDO RAM, but it got panicked at booting or some other random time when we put more than 64MB EDO RAM. We followed the manual and changed its jumper setting, added one more 32K X 8K SRAM; we changed the Award BIOS to make it able to recongnize the memory up to 512MB; we added an option so it'll work with 128MB RAM. Any idea? Thanks a bunch! Amanda ------ achou@best.com From owner-freebsd-hackers Fri Sep 13 12:01:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA08893 for hackers-outgoing; Fri, 13 Sep 1996 12:01:04 -0700 (PDT) Received: from red.jnx.com ([208.197.169.254]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA08888 for ; Fri, 13 Sep 1996 12:01:02 -0700 (PDT) Received: from base.jnx.com (base.jnx.com [208.197.169.238]) by red.jnx.com (8.7.5/8.7.3) with ESMTP id MAA06989; Fri, 13 Sep 1996 12:00:19 -0700 (PDT) Received: (from pst@localhost) by base.jnx.com (8.7.5/8.7.3) id LAA01650; Fri, 13 Sep 1996 11:59:58 -0700 (PDT) To: dkelly@hiwaay.net (David Kelly) cc: hackers@freebsd.org Subject: Re: pty's and slattach References: From: Paul Traina Date: 13 Sep 1996 11:59:57 -0700 In-Reply-To: dkelly@hiwaay.net's message of 11 Sep 96 01:30:38 GMT Message-ID: <7ysp8mfdg2.fsf@base.jnx.com> Lines: 3 X-Mailer: Gnus v5.2.25/XEmacs 19.14 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As a side note, you should really use the if_tun driver with *nos instead of running slip between the two machines over the PTY port. It's *much* more efficient. From owner-freebsd-hackers Fri Sep 13 12:05:24 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA09199 for hackers-outgoing; Fri, 13 Sep 1996 12:05:24 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA09192 for ; Fri, 13 Sep 1996 12:05:22 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA09364; Fri, 13 Sep 1996 12:02:57 -0700 From: Terry Lambert Message-Id: <199609131902.MAA09364@phaeton.artisoft.com> Subject: Re: NFS/mount bug??? To: walter@bios.unc.edu (Bruce Walter) Date: Fri, 13 Sep 1996 12:02:57 -0700 (MST) Cc: hackers@FreeBSD.org In-Reply-To: from "Bruce Walter" at Sep 13, 96 01:16:17 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > Just as a little aside, I've seen this on Linux and NetBSD as well... On > > NetBSD it seems trouble is not far behind when you go to umount them... > > > > > > Just noticed an interesting thing... I typed mount -a twice (don't ask > > > why) and all-of-a-sudden, mount shows the following: > > So far, after a couple-or-ten experiments, no troubles have arisen from > the multiple mounts/umounts, so it appears we're a click better off than > NetBSD. I seem to remember the NFS code being a real bear though, so > I'll leave it up to the experts... ;) Mount points are allowed to be reused. This is intentional, and should work for NetBSD as well (or they need to fix it). This is part of the stacking architecture. Consider: 1) Mount msdosfs on /dos 2) Mount umsdos stacking layer on /dos as a consumer of the msdosfs previously mounted on /dos Voila, umsdos support in a stacking layer instead of as a bunch of conditional hacks to msdosfs. It's an error for mount -a to cause this, though, since the fstab mounts should be considered an "instance" for the purposes of comparison, and the remount (effectively from the same input) should have been ignored ("this fstab line is already a mount instance"). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Sep 13 12:10:37 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA09536 for hackers-outgoing; Fri, 13 Sep 1996 12:10:37 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA09529 for ; Fri, 13 Sep 1996 12:10:34 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA09377; Fri, 13 Sep 1996 12:07:29 -0700 From: Terry Lambert Message-Id: <199609131907.MAA09377@phaeton.artisoft.com> Subject: Re: ATAPI patch To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Fri, 13 Sep 1996 12:07:29 -0700 (MST) Cc: pialkin@abel.pdmi.ras.ru, ache@nagual.ru, spblug@tsctube.spb.su, hackers@FreeBSD.ORG In-Reply-To: <13048.842599702@time.cdrom.com> from "Jordan K. Hubbard" at Sep 13, 96 00:28:22 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I don't sure about anything :) For example - my Panasonic 572B doesn't need > > any delays at all.But GoldStar does.So i don't realy know which one are > > neccessary and which not :( > > I think what he was wondering was whether you'd managed to make the > GoldStar work with any *less* delays, e.g. is each and every one of them > known to be necessary? You seem to be asking: o Is there a CDROM drive for which the set of all possible delays is the smallest possible set required for it to operate? o If yes, is the drive named "GoldStar"? 8-). I suspect that there is no way of knowing the answer without empirically testing, for n delay locations, 2^n kernels against all commercially available hardware. The standard simply does not dictate implementation sufficiently narrow to make it a deterministic problem that can be "figured" without empirically testing all hardware. Stupid standard... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Sep 13 12:15:17 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA09912 for hackers-outgoing; Fri, 13 Sep 1996 12:15:17 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA09904 for ; Fri, 13 Sep 1996 12:15:14 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA09402; Fri, 13 Sep 1996 12:12:11 -0700 From: Terry Lambert Message-Id: <199609131912.MAA09402@phaeton.artisoft.com> Subject: Re: ATAPI patch To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Fri, 13 Sep 1996 12:12:11 -0700 (MST) Cc: pialkin@abel.pdmi.ras.ru, ache@nagual.ru, spblug@tsctube.spb.su, hackers@FreeBSD.ORG In-Reply-To: <4695.842612893@time.cdrom.com> from "Jordan K. Hubbard" at Sep 13, 96 04:08:13 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Ugh. Got a point. > > Yeah - i think it is possible to stay DELAYs only in atapi_probe() > > - all others are not so neccesary. > > Erm, this is engineering here, no one will hurt you for being more > precise. :-) Can you perhaps do some testing and verify this by more > scientific methods? So if you have 16 different delays, it should only take you 2^16 or 65536 reboots (per ATAPI device per IDE controller) to determine. Or 2^16 - 2^15 + 2^14 - 2^13 ... if you btree your testing... 8^). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Sep 13 12:17:03 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA10098 for hackers-outgoing; Fri, 13 Sep 1996 12:17:03 -0700 (PDT) Received: from alpo.whistle.com (s205m1.whistle.com [207.76.205.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA10050 for ; Fri, 13 Sep 1996 12:16:29 -0700 (PDT) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.7.5/8.7.3) with SMTP id MAA10050; Fri, 13 Sep 1996 12:05:16 -0700 (PDT) Message-ID: <3239B015.167EB0E7@whistle.com> Date: Fri, 13 Sep 1996 12:03:49 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0b6 (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Michael Dillon CC: server-linux@netscape.org, freebsd-hackers@freebsd.org Subject: Re: SYN floods - possible solution[ALT]? (fwd) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Michael Dillon wrote: > > Now here is something that could be used by sites to protect against SYN > flood attacke assuming that they can build a special custom box with > enough RAM to buffer the sockets for 30 seconds or more. How high a rate > can SYN floods come in at? I've heard of 1,000 per sec which implies that > this box needs to hold open 30,000 to 75,000 potential sockets. Is there > any problem within IPv4 (seq #'s?) that would make this inherently > impossible? > > Michael Dillon - ISP & Internet Consulting > Memra Software Inc. - Fax: +1-604-546-3049 > http://www.memra.com - E-mail: michael@memra.com > > ---------- Forwarded message ---------- > Date: Fri, 13 Sep 1996 01:36:54 -0400 (EDT) > From: "Roderick Murchison, Jr." > To: firewall-1@applicom.co.il > Cc: firewalls@GreatCircle.COM > Subject: Re: SYN floods - possible solution? > > On Thu, 12 Sep 1996, Blast wrote: > > This problem has kept me awake more than coffee. :-) > > Ditto... I just woke up *again* with a kludgy but potential defense... > sorry if this is totally out of whack, but I'm really beat! > > Ok. say you have a firewall between your network and you Internet > connection. If that firewall could detect and *detain* a segment with the > SYN option set, then see if the set source IP answers an ICMP echo > request, we could effectively determine whether or not the SYN could be > dropped at the firewall and not sent through to spam our hosts. If the > source responds, release the SYN and let it pass through to the intended > host. If it does not, trash the SYN and log the failure. As an optimisation, what about the following.. there is no need to ping the following sites. 1/ A site for which this is the FIRST (or even second) SYN 2/ A site for which we already have a verified connection the weakness in 1/ is that the hackers could use sequentially incrementing source addresses, It might not be neccesary to even switch on this mode if there are < N syn requests per second, or < N Incomplete channels.. > > Some moderate tracking and aging methods could be employed to > intelligently quick drop sources we know are recently offline, and lessen > the amount of echo requests we send out. > > Could this be a potential defense? If so, what products would be best > suited to implement this? > > hope this helps, > -r > > Roderick Murchison, Jr. murchiso@vivid.newbridge.com > Newbridge Networks, Inc. office: (703) 708-5930 > Product Manager - VIVID ACS fax: (703) 708-5937 > Herndon, VA 22070-5241 http://www.vivid.newbridge.com From owner-freebsd-hackers Fri Sep 13 12:33:13 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA11343 for hackers-outgoing; Fri, 13 Sep 1996 12:33:13 -0700 (PDT) Received: from alpo.whistle.com (s205m1.whistle.com [207.76.205.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA11338; Fri, 13 Sep 1996 12:33:09 -0700 (PDT) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.7.5/8.7.3) with SMTP id MAA10177; Fri, 13 Sep 1996 12:21:50 -0700 (PDT) Message-ID: <3239B3F7.446B9B3D@whistle.com> Date: Fri, 13 Sep 1996 12:20:23 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0b6 (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Gary Crutcher CC: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Excite Search engine References: <2.2.32.19960913163622.0068c274@nightflight.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Gary Crutcher wrote: you probably need to be running 2.2 > > Hi, > > Has anyone sucessfully installed the Excite > search engine for BSDI 2.0? > > I get a core dump during installation when > it executes the following line: > > architextSearch -v > > Any suggestions how to overcome this. > I am using FreeBSD v2.1 and have 64MB ram > on a Pentium P133. > > Thanks, > Gary > ------------------------------------------------------------- > Gary Crutcher E-mail: gcrutchr@nightflight.com > Webmaster URL: http://www.nightflight.com > Member of the Internet Developers Association > ------------------------------------------------------------- From owner-freebsd-hackers Fri Sep 13 12:35:39 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA11496 for hackers-outgoing; Fri, 13 Sep 1996 12:35:39 -0700 (PDT) Received: from sovcom.kiae.su (sovcom.kiae.su [193.125.152.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA11488 for ; Fri, 13 Sep 1996 12:35:33 -0700 (PDT) Received: by sovcom.kiae.su id AA10927 (5.65.kiae-1 ); Fri, 13 Sep 1996 22:30:52 +0300 Received: by sovcom.KIAE.su (UUMAIL/2.0); Fri, 13 Sep 96 22:30:52 +0300 Received: (from ache@localhost) by nagual.ru (8.7.5/8.7.3) id XAA00410; Fri, 13 Sep 1996 23:27:46 +0400 (MSD) Message-Id: <199609131927.XAA00410@nagual.ru> Subject: Re: vx device broken in 21.1.5? In-Reply-To: <199609131159.NAA04610@sidhe.hsc.fr> from "Pierre Beyssac" at "Sep 13, 96 01:59:12 pm" To: pb@hsc.fr (Pierre Beyssac) Date: Fri, 13 Sep 1996 23:27:46 +0400 (MSD) Cc: Guido.vanRooij@nl.cis.philips.com, freebsd-hackers@freebsd.org From: =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (Andrey A. Chernov) Organization: self X-Class: Fast X-Mailer: ELM [version 2.4ME+ PL25 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > According to Guido van Rooij: > > I just ported the current Open/NetBSD if_vx driver to FreeBSD 2.1.5 and > > I am seeeing the exact same problems. > > > > I've ben assured that these drivers do work. > > I can say that I've experienced similar problems with > the 2.1.5 vx driver in an installation just a few days ago. > > Some of the 3C595 series might be buggy: the vx driver (sometimes > but not always) prints a "early defective adapter" at boot time. > In addition to that, the reseller of the card told us that it was to > be discontinued and replaced with the 3C905... That's all the information > I have. > > We replaced it with a 3C509 and lived happily ever after. I have 3C509 and 1) Have "early defective..." diagnostic too 2) Hangs on output, ifconfig down/up heals it. -- Andrey A. Chernov http://www.nagual.ru/~ache/ From owner-freebsd-hackers Fri Sep 13 13:50:46 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA16353 for hackers-outgoing; Fri, 13 Sep 1996 13:50:46 -0700 (PDT) Received: (from jmb@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA16337 for hackers; Fri, 13 Sep 1996 13:50:43 -0700 (PDT) From: "Jonathan M. Bresler" Message-Id: <199609132050.NAA16337@freefall.freebsd.org> Subject: hardare only scsi raid controller? To: hackers Date: Fri, 13 Sep 1996 13:50:42 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk NOT a FreeBSD question, but rather a shot in the dark i am looking for a scsi RAID controller that appears to be a plain-old scsi controller. RAID 1 (disk mirroring) is sufficient for my application. the target machine is SCO 3.2 version 4.2. anyone know of a suitable controller jmb From owner-freebsd-hackers Fri Sep 13 14:26:31 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA18545 for hackers-outgoing; Fri, 13 Sep 1996 14:26:31 -0700 (PDT) Received: from time.cdrom.com (time.cdrom.com [204.216.27.226]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA18537 for ; Fri, 13 Sep 1996 14:26:28 -0700 (PDT) Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with ESMTP id OAA00591; Fri, 13 Sep 1996 14:25:27 -0700 (PDT) To: Terry Lambert cc: pialkin@abel.pdmi.ras.ru, ache@nagual.ru, spblug@tsctube.spb.su, hackers@FreeBSD.ORG Subject: Re: ATAPI patch In-reply-to: Your message of "Fri, 13 Sep 1996 12:12:11 PDT." <199609131912.MAA09402@phaeton.artisoft.com> Date: Fri, 13 Sep 1996 14:25:27 -0700 Message-ID: <589.842649927@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > So if you have 16 different delays, it should only take you 2^16 or > 65536 reboots (per ATAPI device per IDE controller) to determine. I suspect it'd be more like a combination binary and exhaustive search - do I need them in *this* section? OK, how many? Next section... Or you could work backwards and simply start removing them until something broke, assuming that eliminating even one unnecessary delay is worth the effort. Jordan From owner-freebsd-hackers Fri Sep 13 15:18:15 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA22055 for hackers-outgoing; Fri, 13 Sep 1996 15:18:15 -0700 (PDT) Received: from glacier.cold.org (glacier.sunrem.com [206.81.134.54]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA22048 for ; Fri, 13 Sep 1996 15:18:08 -0700 (PDT) Received: (from brandon@localhost) by glacier.cold.org (8.7.5/8.7.3) id QAA00850; Fri, 13 Sep 1996 16:18:47 -0600 (MDT) Date: Fri, 13 Sep 1996 16:18:46 -0600 (MDT) From: Brandon Gillespie To: freebsd-hackers@freebsd.org Subject: newfs: panic: ufs_lock: recursive lock not expected, pid 1 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk During install of 2.1.5-R from the CDROM I receive this error, just after it does 'newfs' on the disk. I doubt its this specific disk as a problem, as this problem randomly seems to crop up on any IDE disk I try to use. Help!? -Brandon Gillespie (The IDE controller is an on-board controller on a Triton-II MB, p150 processor, the drive is a conner peripherals). From owner-freebsd-hackers Fri Sep 13 15:46:50 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA23721 for hackers-outgoing; Fri, 13 Sep 1996 15:46:50 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA23701; Fri, 13 Sep 1996 15:46:44 -0700 (PDT) Received: from mail.cdsnet.net (mail.cdsnet.net [204.118.244.5]) by mail.cdsnet.net (8.6.12/8.6.12) with SMTP id PAA00132; Fri, 13 Sep 1996 15:46:43 -0700 Date: Fri, 13 Sep 1996 15:46:42 -0700 (PDT) From: Jaye Mathisen To: hackers@freebsd.org, ports@freebsd.org Subject: lang/expect port seems broken Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I re-supped ports today at 3:55 Pacific time, went to lang/expect and: # make >> expect.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from ftp://ftp.cme.nist.gov/pub/expect/. tribble FTP server (Version 2.0WU(22) Mon May 10 15:54:07 EDT 1993) ready. Guest login ok, send your complete e-mail address as password. Welcome to the MSID public archive at the National Institute of Standards. [stuff deleted]. Don Libes, Thu Dec 7 15:08:47 EST 1995 Guest login ok, access restrictions apply. Receiving expect.tar.gz (398858 bytes): 100% 398858 bytes transfered in 16.4 seconds (23.68 K/s) >> Checksum mismatch for expect.tar.gz *** Error code 1 Stop. From owner-freebsd-hackers Fri Sep 13 16:07:35 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA24845 for hackers-outgoing; Fri, 13 Sep 1996 16:07:35 -0700 (PDT) Received: from Gatekeeper.Lamb.net (ulf@cat-food.Melmac.org [206.169.44.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA24837; Fri, 13 Sep 1996 16:07:31 -0700 (PDT) Received: (from ulf@localhost) by Gatekeeper.Lamb.net (8.7.5/8.7.3) id QAA26116; Fri, 13 Sep 1996 16:07:28 -0700 (PDT) From: Ulf Zimmermann Message-Id: <199609132307.QAA26116@Gatekeeper.Lamb.net> Subject: Re: hardare only scsi raid controller? To: jmb@freefall.freebsd.org (Jonathan M. Bresler) Date: Fri, 13 Sep 1996 16:07:28 -0700 (PDT) Cc: hackers@freefall.freebsd.org In-Reply-To: <199609132050.NAA16337@freefall.freebsd.org> from "Jonathan M. Bresler" at "Sep 13, 96 01:50:42 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Several companies make one: Mylex, CDC are 2 of them. Ulf. > NOT a FreeBSD question, but rather a shot in the dark > > i am looking for a scsi RAID controller that appears to be a plain-old > scsi controller. RAID 1 (disk mirroring) is sufficient for my application. > > the target machine is SCO 3.2 version 4.2. > > anyone know of a suitable controller > > jmb > -------------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 Lamb Art Internet Services | http://www.Lamb.net/ | http://www.Alameda.net From owner-freebsd-hackers Fri Sep 13 16:24:27 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA25711 for hackers-outgoing; Fri, 13 Sep 1996 16:24:27 -0700 (PDT) Received: from po1.glue.umd.edu (po1.glue.umd.edu [129.2.128.44]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA25705; Fri, 13 Sep 1996 16:24:25 -0700 (PDT) Received: from carrier.eng.umd.edu (carrier.eng.umd.edu [129.2.98.188]) by po1.glue.umd.edu (8.7.5/8.7.3) with ESMTP id TAA23598; Fri, 13 Sep 1996 19:24:22 -0400 (EDT) Received: from localhost (chuckr@localhost) by carrier.eng.umd.edu (8.7.5/8.7.3) with SMTP id TAA23252; Fri, 13 Sep 1996 19:24:22 -0400 (EDT) X-Authentication-Warning: carrier.eng.umd.edu: chuckr owned process doing -bs Date: Fri, 13 Sep 1996 19:24:21 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@carrier.eng.umd.edu To: Jaye Mathisen cc: hackers@freebsd.org, ports@freebsd.org Subject: Re: lang/expect port seems broken In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 13 Sep 1996, Jaye Mathisen wrote: > > > I re-supped ports today at 3:55 Pacific time, went to lang/expect and: > > # make > >> expect.tar.gz doesn't seem to exist on this system. > >> Attempting to fetch from ftp://ftp.cme.nist.gov/pub/expect/. > tribble FTP server (Version 2.0WU(22) Mon May 10 15:54:07 EDT 1993) ready. > Guest login ok, send your complete e-mail address as password. > > Welcome to the MSID public archive at the National Institute of > Standards. > > [stuff deleted]. > > Don Libes, Thu Dec 7 15:08:47 EST 1995 > > Guest login ok, access restrictions apply. > Receiving expect.tar.gz (398858 bytes): 100% > 398858 bytes transfered in 16.4 seconds (23.68 K/s) > >> Checksum mismatch for expect.tar.gz > *** Error code 1 Thanks, Jaye, I checked the archive site, you're right, so I updated our md5 file. You know this is the old one, dependent on tcl 7.3, right? What we need is a port of the new one, what they call beta.tar.gz, at the archive site. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and n3lxx, both FreeBSD (301) 220-2114 | version 2.2 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-hackers Fri Sep 13 16:41:31 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA26796 for hackers-outgoing; Fri, 13 Sep 1996 16:41:31 -0700 (PDT) Received: from red.jnx.com ([208.197.169.254]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA26791 for ; Fri, 13 Sep 1996 16:41:29 -0700 (PDT) Received: from base.jnx.com (base.jnx.com [208.197.169.238]) by red.jnx.com (8.7.5/8.7.3) with ESMTP id QAA08828; Fri, 13 Sep 1996 16:40:58 -0700 (PDT) Received: (from pst@localhost) by base.jnx.com (8.7.5/8.7.3) id QAA01919; Fri, 13 Sep 1996 16:40:57 -0700 (PDT) To: terry@lambert.org (Terry Lambert) cc: hackers@freebsd.org Subject: Re: Build is complete References: <199609130805.KAA19112@allegro.lemis.de> <199609131929.MAA09439@phaeton.artisoft.com> From: Paul Traina Date: 13 Sep 1996 16:40:57 -0700 In-Reply-To: terry@lambert.org's message of 13 Sep 96 19:29:53 GMT Message-ID: <7ypw3qf0fq.fsf@base.jnx.com> Lines: 4 X-Mailer: Gnus v5.2.25/XEmacs 19.14 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Why do you think that GENERIC = BUILD? We could solve this by building a config file that has any/all excess crap for folks who want to build releases, all 5 of us. From owner-freebsd-hackers Fri Sep 13 17:05:33 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA29512 for hackers-outgoing; Fri, 13 Sep 1996 17:05:33 -0700 (PDT) Received: from main.gbdata.com (Main.GBData.COM [207.90.222.20]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA29502 for ; Fri, 13 Sep 1996 17:05:28 -0700 (PDT) Received: (from gclarkii@localhost) by main.gbdata.com (8.7.5/8.6.9) id TAA17734 for freebsd-hackers@freebsd.org; Fri, 13 Sep 1996 19:05:26 -0500 (CDT) From: Gary Clark II Message-Id: <199609140005.TAA17734@main.gbdata.com> Subject: Help..! (Networking) To: freebsd-hackers@freebsd.org Date: Fri, 13 Sep 1996 19:05:26 -0500 (CDT) X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, I've ran into a really strange problem here. Ok, here is the setup. 3 FreeBSD machines (1 2.1.0 and 2 2.1.5) 1 Cisco 2500 series Ok, here is the problem: All local (machine to machine) work fine. All inbounds work fairly well. All outbounds on the 2.1.5 machines lock up if over a certain size. The 2.1.0 machine works fine. If I first rlogin to the 2.1.0 machine then goto the 2.1.5 machines it works fine. Any ideas? This things has me pulling my hair out... Gary -- Gary Clark II (N5VMF) | I speak only for myself and "maybe" my company gclarkii@GBData.COM | Member of the FreeBSD Doc Team Providing Internet and ISP startups mail info@GBData.COM for information FreeBSD FAQ at ftp://ftp.FreeBSD.ORG/pub/FreeBSD/docs/freebsd-faq.ascii From owner-freebsd-hackers Fri Sep 13 17:08:47 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA29816 for hackers-outgoing; Fri, 13 Sep 1996 17:08:47 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA29811 for ; Fri, 13 Sep 1996 17:08:43 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA09890; Fri, 13 Sep 1996 17:06:20 -0700 From: Terry Lambert Message-Id: <199609140006.RAA09890@phaeton.artisoft.com> Subject: Re: Build is complete To: pst@jnx.com (Paul Traina) Date: Fri, 13 Sep 1996 17:06:20 -0700 (MST) Cc: terry@lambert.org, hackers@freebsd.org In-Reply-To: <7ypw3qf0fq.fsf@base.jnx.com> from "Paul Traina" at Sep 13, 96 04:40:57 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Why do you think that GENERIC = BUILD? > > We could solve this by building a config file that has any/all excess crap > for folks who want to build releases, all 5 of us. When I get a kernel from a binary distribution, which kernel is it? In general, it's GENERIC. So if I build on a distribution kernel, I will have to bootstrap through generic -- no matter what I do. Seems to be a strong argument for equating them. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Fri Sep 13 18:18:40 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA03895 for hackers-outgoing; Fri, 13 Sep 1996 18:18:40 -0700 (PDT) Received: from intercore.com (num1sun.intercore.com [199.181.243.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA03889 for ; Fri, 13 Sep 1996 18:18:38 -0700 (PDT) Received: (robin@localhost) by intercore.com (8.7.1/8.6.4) id VAA28902; Fri, 13 Sep 1996 21:13:13 -0400 (EDT) From: Robin Cutshaw Message-Id: <199609140113.VAA28902@intercore.com> Subject: Re: 2.2-960801-SNAP--Problem with SMC 10/100 card and SMC 100mb `tiger hub' To: gilham@csl.sri.com (Fred Gilham) Date: Fri, 13 Sep 1996 21:13:08 -0400 (EDT) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199609121746.KAA02137@impulse.csl.sri.com> from "Fred Gilham" at Sep 12, 96 10:46:38 am X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > I've noticed that running the 2.2-960801 snap causes the de driver to > fail to link up to the 100mb SMC tiger hub that we're experimenting > with. It always reports > > de0: enabling 10baseT port > I had to add "link2" to the ifconfig of the device to get it to switch to 100Mb mode. Autosensing doesn't seem to work. robin -- ---- Robin Cutshaw internet: robin@interlabs.com robin@intercore.com Internet Labs, Inc. BellNet: 404-817-9787 "Time is just one damn thing after another" -- PBS/Nova ---- -- From owner-freebsd-hackers Fri Sep 13 18:56:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA06062 for hackers-outgoing; Fri, 13 Sep 1996 18:56:51 -0700 (PDT) Received: from nexgen.ampr.org (max2-193.HiWAAY.net [206.104.22.193]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA06057 for ; Fri, 13 Sep 1996 18:56:47 -0700 (PDT) Received: (from dkelly@localhost) by nexgen.ampr.org (8.7.5/8.6.12) id UAA00302; Fri, 13 Sep 1996 20:56:18 -0500 (CDT) Message-ID: X-Mailer: XFMail 0.5-alpha [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <7ysp8mfdg2.fsf@base.jnx.com> Date: Fri, 13 Sep 1996 20:38:14 -0500 (CDT) Organization: Amateur Radio N4HHE, Madison, AL. From: David Kelly To: Paul Traina Subject: Re: pty's and slattach Cc: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On 16:59:57 Paul Traina wrote: >>As a side note, you should really use the if_tun driver with *nos instead >of running slip between the two machines over the PTY port. It's *much* >more efficient. Yes, no doubt its more efficient. But we're talking about thruputs of up to 300 bytes per second. The CPU horsepower available in anything that runs FreeBSD should be enough to make any inefficiency almost unmeasurable. On the other hand, this code, TNOS, has its own SL/IP engine in its network stack that is supposed to work if pointed at a real serial port and SL/IP connection on the other end. Rather than run it out a precious sio port (hopefully) the thing to do is to use a cheap pty pair. Thats what they do with that "other" Un*x. Haven't actually tried it yet with real serial ports. Have run it out a real serial port to my radios with IP, but SL/IP isn't used there. Tried running a hacked slattach to bypass the earlier problem with TIOCSCTTY ./slattach -e "echo died" -l -L /dev/ptypf And got this in /var/log/messages: Sep 13 20:44:52 nexgen slattach[274]: ioctl(TIOCSDTR): Inappropriate ioctl for device Sep 13 20:44:52 nexgen slattach[274]: exiting after running echo died Hmm. Don't have TNOS running on the other end to catch it yet. Is it Friday the 13th yet? Meanwhile, where would one find docs on tun devices? I *would* really like to avoid this pty stuff and solve the real problem. Does the tun device require root privilege to connect? I'd guess so. And that brings us back to the slattach or ppp technique thru a pty as too many things are running in TNOS for the whole thing to run as root. Those who would like to know more about TNOS might start at http://www.lantz.com 73, -- David Kelly N4HHE, dkelly@tomcat1.tbe.com (wk), dkelly@hiwaay.net (hm) ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-hackers Fri Sep 13 20:05:23 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA10810 for hackers-outgoing; Fri, 13 Sep 1996 20:05:23 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA10799; Fri, 13 Sep 1996 20:05:13 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id XAA08479; Fri, 13 Sep 1996 23:04:59 -0400 (EDT) Date: Fri, 13 Sep 1996 23:04:59 -0400 (EDT) From: Brian Tao To: "Jonathan M. Bresler" cc: hackers@freefall.freebsd.org Subject: Re: hardare only scsi raid controller? In-Reply-To: <199609132050.NAA16337@freefall.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 13 Sep 1996, Jonathan M. Bresler wrote: > > i am looking for a scsi RAID controller that appears to be a plain-old > scsi controller. RAID 1 (disk mirroring) is sufficient for my application. Mylex, CMD and Streamlogic all make SCSI-to-SCSI RAID controllers. All you need is a plain old SCSI-2 controller on the host (narrow or wide, depending on the product). -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-hackers Fri Sep 13 20:42:43 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA13230 for hackers-outgoing; Fri, 13 Sep 1996 20:42:43 -0700 (PDT) Received: from mx.serv.net (mx.serv.net [199.201.191.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA13168; Fri, 13 Sep 1996 20:42:25 -0700 (PDT) Received: from MindBender.serv.net by mx.serv.net (8.7.5/SERV Revision: 2.30 † id UAA02153; Fri, 13 Sep 1996 20:42:00 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.serv.net (8.7.5/8.7.3) with SMTP id UAA04018; Fri, 13 Sep 1996 20:41:17 -0700 (PDT) Message-Id: <199609140341.UAA04018@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: Amanda Chou cc: questions@freebsd.org, hackers@freebsd.org, hardware@freebsd.org Subject: Re: Q: Tyan Tomcat I with > 64MB RAM In-reply-to: Your message of Fri, 13 Sep 96 10:00:28 -0700. Date: Fri, 13 Sep 1996 20:41:17 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Has anyone used Tyan Tomcat I with more than 64MB RAM? We ran into some >weird problems; it works fine when we just put 64MB EDO RAM, but it got >panicked at booting or some other random time when we put more than 64MB >EDO RAM. We followed the manual and changed its jumper setting, added one >more 32K X 8K SRAM; we changed the Award BIOS to make it able to recongnize >the memory up to 512MB; we added an option so it'll work with 128MB RAM. >Any idea? I'm not sure I followed everything you just tried to say. However, have you tested the memory by itself to make sure you don't have a bad chip? ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@MindBender.serv.net --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... ----------------------------------------------------------------------------- From owner-freebsd-hackers Fri Sep 13 20:54:32 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA14059 for hackers-outgoing; Fri, 13 Sep 1996 20:54:32 -0700 (PDT) Received: from iago.ienet.com (iago.ienet.com [207.78.32.53]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA14051 for ; Fri, 13 Sep 1996 20:54:28 -0700 (PDT) Received: from ienet.com (localhost.ienet.com [127.0.0.1]) by iago.ienet.com (8.7.5/8.7.3) with ESMTP id UAA01022; Fri, 13 Sep 1996 20:52:18 -0700 (PDT) Message-Id: <199609140352.UAA01022@iago.ienet.com> To: freebsd-hackers@FreeBSD.ORG Subject: How to safely remove a hard link to a directory? Date: Fri, 13 Sep 1996 20:52:18 -0700 From: Pius Fischer Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Oops, I know, I know, I shouldn't have done this, but maybe it's not too late. I think I need some help or advice on what to do now before I do anything that could really screw up the filesystem. On a pre-2.1.5 version of FreeBSD-stable, I wrote a little C program that just passes its first two command line arguments to link(2). That way, when I'm superuser, I can create a hard link to a directory (I won't get into why I wanted to do this). The program is called 'lndir' and here's basically what I did: /home/pius/web>mkdir testdir /home/pius/web>touch testdir/testfile Then I become superuser and do this: /home/pius/web>./lndir testdir testdir2 Now I want to remove both directories: /home/pius/web>rm testdir/testfile /home/pius/web>rm testdir2/testfile rm: testdir2/testfile: No such file or directory /home/pius/web>rmdir testdir2 rmdir: testdir2: Directory not empty /home/pius/web>rmdir testdir rmdir: testdir: Directory not empty /home/pius/web>ls -al testdir2 total 8 drwx------ 3 pius web 512 Sep 13 19:52 . drwx--x--- 6 pius web 512 Sep 13 19:57 .. /home/pius/web>ls -al testdir total 8 drwx------ 3 pius web 512 Sep 13 19:52 . drwx--x--- 6 pius web 512 Sep 13 19:57 .. /home/pius/web> Uh, so now I can't remove either directory and I'm a little afraid of doing an rm -rf or writing a C program that calls unlink(2) before I really know what is going to happen. Of course only after creating this hard link do I read the man page for link(2) on my FreeBSD 2.2-960612-SNAP system and the last couple lines are a little scary ("The link system call traditionally allows the super-user to link directories which corrupts the filesystem coherency."). The man page on the older system had no such warning. I was aware of what Richard Stevens says on p. 101 in his _Advanced Programming in the UNIX environment_ (again, the footnote is kind of scary and so I tried to be careful), but I figured he corrupted his filesystem because he created a hard link to the parent directory, creating a loop, and then tried to unlink the hard link. So, anyways, how can I safely remove these two directories? Maybe I'm a little too paranoid right now, but I'm going to go ahead and backup the important data from this filesystem onto another machine ... Thanks very much for any help, Pius From owner-freebsd-hackers Fri Sep 13 21:48:51 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA00982 for hackers-outgoing; Fri, 13 Sep 1996 21:48:51 -0700 (PDT) Received: from iago.ienet.com (iago.ienet.com [207.78.32.53]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA00976 for ; Fri, 13 Sep 1996 21:48:48 -0700 (PDT) Received: from ienet.com (localhost.ienet.com [127.0.0.1]) by iago.ienet.com (8.7.5/8.7.3) with ESMTP id VAA01177; Fri, 13 Sep 1996 21:46:38 -0700 (PDT) Message-Id: <199609140446.VAA01177@iago.ienet.com> To: freebsd-hackers@FreeBSD.ORG Subject: Re: How to safely remove a hard link to a directory? Date: Fri, 13 Sep 1996 21:46:38 -0700 From: Pius Fischer Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Sorry, a short follow-up ... I just ran across an old message from Joerg Wunsch on the mailing list archives ... Is it still safe to just call unlink(2) on the directory name to remove the hard link? Why does rmdir not work? Excuse my ignorance and thanks again, Pius From owner-freebsd-hackers Fri Sep 13 23:21:50 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA08364 for hackers-outgoing; Fri, 13 Sep 1996 23:21:50 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id XAA08358 for ; Fri, 13 Sep 1996 23:21:46 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id QAA05920; Sat, 14 Sep 1996 16:15:34 +1000 Date: Sat, 14 Sep 1996 16:15:34 +1000 From: Bruce Evans Message-Id: <199609140615.QAA05920@godzilla.zeta.org.au> To: freebsd-hackers@FreeBSD.ORG, pius@iago.ienet.com Subject: Re: How to safely remove a hard link to a directory? Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Sorry, a short follow-up ... I just ran across an old message >from Joerg Wunsch on the mailing list archives ... Is it still >safe to just call unlink(2) on the directory name to remove the >hard link? It depends where the link goes. It is fairly safe to remove bogus links that you just created. >Why does rmdir not work? ufs_rmdir() has a fairly bogus check that the link count is 2. If it checks it at all, then it should check that one of the links is for ".". Bruce From owner-freebsd-hackers Sat Sep 14 00:28:14 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA13565 for hackers-outgoing; Sat, 14 Sep 1996 00:28:14 -0700 (PDT) Received: from perki0.connect.com.au (perki0.connect.com.au [192.189.54.85]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA13553 for ; Sat, 14 Sep 1996 00:28:08 -0700 (PDT) Received: (from Unemeton@localhost) by perki0.connect.com.au id QAA14566 (8.7.5/IDA-1.6); Sat, 14 Sep 1996 16:55:41 +1000 (EST) X-Authentication-Warning: perki0.connect.com.au: Unemeton set sender to giles@nemeton.com.au using -f >Received: from localhost (localhost [127.0.0.1]) by nemeton.com.au (8.7.5/8.7.3) with SMTP id IAA15580; Sat, 14 Sep 1996 08:47:53 +1000 (EST) Message-Id: <199609132247.IAA15580@nemeton.com.au> To: Terletsky Slavik cc: hackers@freebsd.org Subject: Re: How to read /dev/console's messages Date: Sat, 14 Sep 1996 08:47:53 +1000 From: Giles Lean Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 13 Sep 1996 16:36:56 +0300 Terletsky Slavik wrote: > I use different log files for different events but want to feed > system monitoring program (swatch) by all of them. The GNU tail is supposed to be able to tail multiple files -- you might try using it with swatch. Alternatively I have a version of swatch that handles multiple log files. It is pretty much alpha code though, and is written in perl5. You are welcome to a copy if you'd like; I hope to clean it up some more over the next few days. (Really a question for -questions, I suggest too.) Regards, Giles From owner-freebsd-hackers Sat Sep 14 03:21:11 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA00179 for hackers-outgoing; Sat, 14 Sep 1996 03:21:11 -0700 (PDT) Received: from clipper.cs.kiev.ua (root@cs-demon.ua.net [193.124.48.251]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id DAA00159 for ; Sat, 14 Sep 1996 03:20:58 -0700 (PDT) Received: from dog by clipper.cs.kiev.ua with uucp id m0v1rc6-000szrC; Sat, 14 Sep 96 13:06 WET DST Received: (from dk@localhost) by dog.farm.org (8.7.5/dk#3) id BAA09747; Sat, 14 Sep 1996 01:10:48 -0700 (PDT) Date: Sat, 14 Sep 1996 01:10:48 -0700 (PDT) From: Dmitry Kohmanyuk Message-Id: <199609140810.BAA09747@dog.farm.org> To: pius@iago.ienet.com (Pius Fischer) Cc: freebsd-hackers@freebsd.org Subject: Re: How to safely remove a hard link to a directory? Newsgroups: cs-monolit.gated.lists.freebsd.hackers Organization: FARM Computing Association Reply-To: dk+@ua.net X-Newsreader: TIN [version 1.2 PL2] Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199609140352.UAA01022@iago.ienet.com> you wrote: > On a pre-2.1.5 version of FreeBSD-stable, I wrote a little > C program that just passes its first two command line > arguments to link(2). That way, when I'm superuser, I can > create a hard link to a directory (I won't get into why > I wanted to do this). The program is called 'lndir' and > here's basically what I did: > Now I want to remove both directories: > /home/pius/web>rm testdir/testfile > /home/pius/web>rm testdir2/testfile > rm: testdir2/testfile: No such file or directory > /home/pius/web>rmdir testdir2 > rmdir: testdir2: Directory not empty > /home/pius/web>rmdir testdir > rmdir: testdir: Directory not empty > /home/pius/web>ls -al testdir2 mv(1) or cp(1) all the files from testdir elsewhere to save them. (oh, you already emptied it. fine.) do ls -i and note the inode number. do df and note the special device name (/dev/xxxx). then, reboot single-user. (or just unmount the filesystem in question). # clri /dev/ # fsck /dev/ you should get a couple of errors (probably link count or wrong inode). Answer yes and fix them. mount your device again, or just reboot multi-user. > So, anyways, how can I safely remove these two directories? Maybe I'm > a little too paranoid right now, but I'm going to go ahead and backup > the important data from this filesystem onto another machine ... follow the steps above, and remember never do it again ;-) -- Real programmers don't just die, they produce core dumps. From owner-freebsd-hackers Sat Sep 14 03:53:57 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA01503 for hackers-outgoing; Sat, 14 Sep 1996 03:53:57 -0700 (PDT) Received: from pdx1.world.net (pdx1.world.net [192.243.32.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA01497 for ; Sat, 14 Sep 1996 03:53:54 -0700 (PDT) Received: from suburbia.net (suburbia.net [203.4.184.1]) by pdx1.world.net (8.7.5/8.7.3) with ESMTP id DAA13302 for ; Sat, 14 Sep 1996 03:53:01 -0700 (PDT) Received: (proff@localhost) by suburbia.net (8.7.4/Proff-950810) id UAA25565 for freebsd-hackers@freebsd.org; Sat, 14 Sep 1996 20:52:24 +1000 From: Julian Assange Message-Id: <199609141052.UAA25565@suburbia.net> Subject: attribute/inode caching To: freebsd-hackers@freebsd.org Date: Sat, 14 Sep 1996 20:52:24 +1000 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk What is the present status of attribute/inode/directory caching under freebsd? When performing a 'du' of even a relatively small hierarachy, the second 'du' appears no faster than the first and the drive can be heard to thrash around in exactly the same manner. -- "Of all tyrannies a tyranny sincerely exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies, The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for own good will torment us without end, for they do so with the approval of their own conscience." - C.S. Lewis, _God in the Dock_ +---------------------+--------------------+----------------------------------+ |Julian Assange RSO | PO Box 2031 BARKER | Secret Analytic Guy Union | |proff@suburbia.net | VIC 3122 AUSTRALIA | finger for PGP key hash ID = | |proff@gnu.ai.mit.edu | FAX +61-3-98199066 | 0619737CCC143F6DEA73E27378933690 | +---------------------+--------------------+----------------------------------+ From owner-freebsd-hackers Sat Sep 14 15:03:26 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA10533 for hackers-outgoing; Sat, 14 Sep 1996 15:03:26 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA10523 for ; Sat, 14 Sep 1996 15:03:21 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA12694; Sat, 14 Sep 1996 15:00:33 -0700 From: Terry Lambert Message-Id: <199609142200.PAA12694@phaeton.artisoft.com> Subject: Re: attribute/inode caching To: proff@suburbia.net (Julian Assange) Date: Sat, 14 Sep 1996 15:00:33 -0700 (MST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199609141052.UAA25565@suburbia.net> from "Julian Assange" at Sep 14, 96 08:52:24 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > What is the present status of attribute/inode/directory caching under > freebsd? When performing a 'du' of even a relatively small hierarachy, > the second 'du' appears no faster than the first and the drive can be > heard to thrash around in exactly the same manner. POSIX mandates that the access time will be marked for update when you read the directory; thus it's written out, and the thrashing is expected. One issue which is a big one in my book is that only data hung off a vnode is cached in the buffer cache. The caching is by inode/extent rather than by device/extent. The net result of this will be that the inode data itself will not be cached. There is a "second chance" ihash cache in FFS; other FS's are not so lucky; thus your performance will depend on number of elements before the hash overflows and whether or not you are testing FFS or some other FS. For instance, expect EXT2FS to have significantly worse performance under BSD. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat Sep 14 16:06:36 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA15491 for hackers-outgoing; Sat, 14 Sep 1996 16:06:36 -0700 (PDT) Received: from mail.jrihealth.com (mail.jrihealth.com [204.249.32.3]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA15486; Sat, 14 Sep 1996 16:06:32 -0700 (PDT) Received: from library.pride.net (danp@library.pride.net [204.249.32.4]) by mail.jrihealth.com (8.3/8.6.6.Beta9) with SMTP id TAA04547; Sat, 14 Sep 1996 19:07:11 -0400 Date: Sat, 14 Sep 1996 19:07:21 -0400 (EDT) From: Dan Polivy To: Gary Crutcher cc: freebsd-questions@FreeBSD.org, freebsd-hackers@FreeBSD.org Subject: Re: Excite Search engine In-Reply-To: <2.2.32.19960913163622.0068c274@nightflight.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Gary, On Fri, 13 Sep 1996, Gary Crutcher wrote: > Has anyone sucessfully installed the Excite > search engine for BSDI 2.0? Yes. Although, there was a slight problem getting the install script/perl to work right... > I get a core dump during installation when > it executes the following line: > > architextSearch -v > > Any suggestions how to overcome this. > I am using FreeBSD v2.1 and have 64MB ram > on a Pentium P133. FreeBSD 2.1 cannot run BSDI 2.0 binaries. Upgrade to 2.1.5 or -current (-stable should support them, too)... Dan +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | JRI HIS MIS Systems Administrator/Tech Support | |////////////////////////////////////////////////////////////////| | danp@busstop.org dpolivy@jri.org danp@library.pride.net | |\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\| | Check out JRI's Homepage at http://www.jri.org | |////////////////////////////////////////////////////////////////| | For More Info about JRI Health, call 617.457.8150, | | EMail health@jri.org or check out http://www.jri.org/jrihealth | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ From owner-freebsd-hackers Sat Sep 14 18:24:36 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA22490 for hackers-outgoing; Sat, 14 Sep 1996 18:24:36 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA22485 for ; Sat, 14 Sep 1996 18:24:30 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id LAA30846; Sun, 15 Sep 1996 11:19:02 +1000 Date: Sun, 15 Sep 1996 11:19:02 +1000 From: Bruce Evans Message-Id: <199609150119.LAA30846@godzilla.zeta.org.au> To: proff@suburbia.net, terry@lambert.org Subject: Re: attribute/inode caching Cc: freebsd-hackers@freebsd.org Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> What is the present status of attribute/inode/directory caching under >> freebsd? When performing a 'du' of even a relatively small hierarachy, Little improved since 1992. The vnode cache is a bit larger, at least on machines with plenty of memory (the default is up from about 200 on an 8MB system to about 2000 on a 32MB system), and you can tweak its size using sysctl(8) or the unnecessary EXTRAVNODES option, but the caching still breaks down when the vnode cache starts to thrash. The problem used to be that buffers for directories were attached to vnodes, so thrashing of the vnode cache also thrashed the buffer cache. Also, (?) inode buffers weren't kept in the buffer cache and the buffer cache was too small to hold many inodes. Under Linux, at least in 1992, the buffer cache isn't so tightly coupled to the vnode cache, so ordinary LRU caching results in the buffer cache filling up with inode data, so it can easily cache 6000 128-byte inodes (or 20000 32-byte inodes) and associated directory entries in only 1MB of buffer cache. This might not be the best use for the buffer cache, but it is good for traversing large hierarchies. I don't know exactly how the unified vm and buffer cache has affected this. Apparently, not much. >> the second 'du' appears no faster than the first and the drive can be >> heard to thrash around in exactly the same manner. I notice this mainly when I run `find' on relatively large heirachies. The problem is not so much that the second traversal reads everything again, but that the first traversal thrashes the buffer and/or vm cache. >POSIX mandates that the access time will be marked for update when you >read the directory; thus it's written out, and the thrashing is expected. Wrong. Neither marking for update nor updating the access times requires writing anything. In FreeBSD, writing is a side affect of thrashing the caches and updating is often a side effect of writing. First, when the vnode cache thrashes, the vnodes have to be updated and written to the buffer cache. Second, when the buffer cache thrashes, the dirty buffers containing the vnodes have to be written out. They are usually written with delayed writes, so the writes need not more than double the overhead for the thrashing (probably much worse in practice because of seeks). >One issue which is a big one in my book is that only data hung off a vnode >is cached in the buffer cache. The caching is by inode/extent rather than >by device/extent. Yes, this is the main problem. >The net result of this will be that the inode data itself will not be >cached. It could be hung off the vnode for the mounted device. I'm not sure if it isn't already. This problem is secondary. Repeated tree traversals aren't all that common, and you don't really want them to eat the buffer cache (you probably want to buffer precisely the inodes and directories that will be hit again a long time later in the same search, e.g., intermediate directories for a depth-first seach). >There is a "second chance" ihash cache in FFS; other FS's are not so >lucky; thus your performance will depend on number of elements before >the hash overflows and whether or not you are testing FFS or some other >FS. For instance, expect EXT2FS to have significantly worse performance >under BSD. Actually, ext2fs uses the ufs ihash. Hmm, EXTRAVNODES is necessary after all, since the ihash table isn't affected by the sysctl to change `desiredvnodes'. It's fishy that the ufs table size is the same as the vfs table size. Bruce From owner-freebsd-hackers Sat Sep 14 18:36:24 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA22833 for hackers-outgoing; Sat, 14 Sep 1996 18:36:24 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA22828 for ; Sat, 14 Sep 1996 18:36:23 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA00362; Sat, 14 Sep 1996 18:35:48 -0700 From: Terry Lambert Message-Id: <199609150135.SAA00362@phaeton.artisoft.com> Subject: Re: attribute/inode caching To: bde@zeta.org.au (Bruce Evans) Date: Sat, 14 Sep 1996 18:35:47 -0700 (MST) Cc: proff@suburbia.net, terry@lambert.org, freebsd-hackers@freebsd.org In-Reply-To: <199609150119.LAA30846@godzilla.zeta.org.au> from "Bruce Evans" at Sep 15, 96 11:19:02 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >POSIX mandates that the access time will be marked for update when you > >read the directory; thus it's written out, and the thrashing is expected. > > Wrong. Neither marking for update nor updating the access times requires > writing anything. In FreeBSD, writing is a side affect of thrashing the > caches and updating is often a side effect of writing. First, when the > vnode cache thrashes, the vnodes have to be updated and written to the > buffer cache. Second, when the buffer cache thrashes, the dirty buffers > containing the vnodes have to be written out. They are usually written > with delayed writes, so the writes need not more than double the overhead > for the thrashing (probably much worse in practice because of seeks). If it weren't marked, it wouldn't be written. I stand behind my statement. > >The net result of this will be that the inode data itself will not be > >cached. > > It could be hung off the vnode for the mounted device. I'm not sure if > it isn't already. This problem is secondary. Repeated tree traversals > aren't all that common, and you don't really want them to eat the buffer > cache (you probably want to buffer precisely the inodes and directories > that will be hit again a long time later in the same search, e.g., > intermediate directories for a depth-first seach). It is not hung off the vnode for the device. It probably should not be, in any case (there is no "device" for NFS, for instance). Really, it wants to be device relative, not vnode relative, and yet still have the vnode mapping that makes the extra bmap per data transfer unnecessary (ie: the heart of the unification). Two lists are as easily maintained as one, IMO. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-hackers Sat Sep 14 19:02:29 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA23640 for hackers-outgoing; Sat, 14 Sep 1996 19:02:29 -0700 (PDT) Received: from Lapkin.RoSprint.ru (root@Lapkin.RoSprint.ru [193.232.88.150]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA23635; Sat, 14 Sep 1996 19:02:23 -0700 (PDT) Received: (from sandy@localhost) by Lapkin.RoSprint.ru (8.7.5/8.6.9) id GAA00358; Sun, 15 Sep 1996 06:02:17 +0400 (MSD) From: Sandy Kovshov Message-Id: <199609150202.GAA00358@Lapkin.RoSprint.ru> Subject: sppp with cisco hdlc bug fix To: freebsd-current@freebsd.org Date: Sun, 15 Sep 1996 06:02:16 +0400 (MSD) Cc: freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4 PL24alpha5] Content-Type: text Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello guys, Here is little patch for bug in sppp pseudo driver with cisco hdlc protocol. I've found it when test Riscom/N2 card with Cisco. At unknown reason, Cisco send 20 byte packet (without ppp header) instead of 18 ;) With old version it cause line hangup on keepalive timeout. Index: net/if_spppsubr.c =================================================================== RCS file: /home/sandy/project/freebsd/cvs/src/sys/net/if_spppsubr.c,v retrieving revision 1.13 diff -c -r1.13 if_spppsubr.c *** if_spppsubr.c 1996/08/30 16:44:36 1.13 --- if_spppsubr.c 1996/09/15 01:46:31 *************** *** 848,854 **** struct ifaddr *ifa; struct ifnet *ifp = &sp->pp_if; ! if (m->m_pkthdr.len != CISCO_PACKET_LEN) { if (ifp->if_flags & IFF_DEBUG) printf ("%s%d: invalid cisco packet length: %d bytes\n", ifp->if_name, ifp->if_unit, m->m_pkthdr.len); --- 848,854 ---- struct ifaddr *ifa; struct ifnet *ifp = &sp->pp_if; ! if (m->m_pkthdr.len < CISCO_PACKET_LEN) { if (ifp->if_flags & IFF_DEBUG) printf ("%s%d: invalid cisco packet length: %d bytes\n", ifp->if_name, ifp->if_unit, m->m_pkthdr.len); With best regards. --- Sandy E-mail: Internet: sandy@dream.demos.su sandy@www.RoSprint.ru X.400: (C:USSR,A:SOVMAIL,O:SNUSSR,UN:A.KOVSHOV) X.400: (C:USA,A:TELEMAIL,O:SPRINTINTL,UN:A.KOVSHOV) From owner-freebsd-hackers Sat Sep 14 19:20:18 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA24269 for hackers-outgoing; Sat, 14 Sep 1996 19:20:18 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id TAA24263 for ; Sat, 14 Sep 1996 19:20:14 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id MAA32073; Sun, 15 Sep 1996 12:15:52 +1000 Date: Sun, 15 Sep 1996 12:15:52 +1000 From: Bruce Evans Message-Id: <199609150215.MAA32073@godzilla.zeta.org.au> To: bde@zeta.org.au, terry@lambert.org Subject: Re: attribute/inode caching Cc: freebsd-hackers@freebsd.org, proff@suburbia.net Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> >POSIX mandates that the access time will be marked for update when you >> >read the directory; thus it's written out, and the thrashing is expected. >> >> Wrong. Neither marking for update nor updating the access times requires >> writing anything. In FreeBSD, writing is a side affect of thrashing the >> caches and updating is often a side effect of writing. First, when the >> vnode cache thrashes, the vnodes have to be updated and written to the >> buffer cache. Second, when the buffer cache thrashes, the dirty buffers >> containing the vnodes have to be written out. They are usually written >> with delayed writes, so the writes need not more than double the overhead >> for the thrashing (probably much worse in practice because of seeks). > >If it weren't marked, it wouldn't be written. I stand behind my statement. If the buffer cache didn't thrash, then it would be written on the next sync, much later. If in addition writes were ordered in block order, then it would be written efficiently together with nearby dirty inodes. Normally, ffs_sync() writes things in the semi-random vnode list order. disksort() sorts the into block order, but this only helps if the disk can't keep up with the i/o requests. Another way to look at it: consider traversing my /usr/src, which has 21097 inodes and 2810 directories. if the cache thrashes (certain) and the inodes are contiguous on disk (unlikely :-), then there will be a 2637KB of reads and a whole 351KB of writes to update the atimes. The write time should be relatively negligible if the cache is working (more so, because you can schedule delayed writes but reads have to be synchronous). Bruce From owner-freebsd-hackers Sat Sep 14 20:34:52 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA26342 for hackers-outgoing; Sat, 14 Sep 1996 20:34:52 -0700 (PDT) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA26337 for ; Sat, 14 Sep 1996 20:34:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.5/8.6.5) with SMTP id UAA05077; Sat, 14 Sep 1996 20:33:26 -0700 (PDT) Message-Id: <199609150333.UAA05077@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: bde@zeta.org.au (Bruce Evans), proff@suburbia.net, freebsd-hackers@FreeBSD.org Subject: Re: attribute/inode caching In-reply-to: Your message of "Sat, 14 Sep 1996 18:35:47 PDT." <199609150135.SAA00362@phaeton.artisoft.com> From: David Greenman Reply-To: dg@root.com Date: Sat, 14 Sep 1996 20:33:25 -0700 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> It could be hung off the vnode for the mounted device. I'm not sure if >> it isn't already. This problem is secondary. Repeated tree traversals >> aren't all that common, and you don't really want them to eat the buffer >> cache (you probably want to buffer precisely the inodes and directories >> that will be hit again a long time later in the same search, e.g., >> intermediate directories for a depth-first seach). > >It is not hung off the vnode for the device. It probably should not be, >in any case (there is no "device" for NFS, for instance). Inode blocks are hung off the device vnode. Indirect blocks are hung off the file vnode (using negative block numbers). -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-hackers Sat Sep 14 20:44:50 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA26915 for hackers-outgoing; Sat, 14 Sep 1996 20:44:50 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA26902 for ; Sat, 14 Sep 1996 20:44:45 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id DAA12816; Sun, 15 Sep 1996 03:43:33 GMT Date: Sun, 15 Sep 1996 12:43:33 +0900 (JST) From: Michael Hancock To: Julian Assange cc: freebsd-hackers@freebsd.org Subject: Re: attribute/inode caching In-Reply-To: <199609141052.UAA25565@suburbia.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 14 Sep 1996, Julian Assange wrote: > > What is the present status of attribute/inode/directory caching under > freebsd? When performing a 'du' of even a relatively small hierarachy, > the second 'du' appears no faster than the first and the drive can be > heard to thrash around in exactly the same manner. There's a per-process directory cache that benefits things like 'ls' in large directories. It just stores the offset of the last successful search in the directory. If the next search is in the same directory then it starts at the cached offset. You can watch the namei cache and the per-process directory cache using systat -vmstat. The workings of the inode cache is a different story. Regards, Mike Hancock