From owner-freebsd-hackers Sun Jul 11 1: 0:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id D10F714E89; Sun, 11 Jul 1999 01:00:20 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id JAA15467; Sun, 11 Jul 1999 09:58:52 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199907110758.JAA15467@gratis.grondar.za> To: chris@calldei.com Cc: Ben Rosengart , "Brian F. Feldman" , hackers@FreeBSD.ORG Subject: Re: a BSD identd Date: Sun, 11 Jul 1999 09:58:51 +0200 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The whole point of ident was -- and still is -- to > authenticate or verify who created a specific TCP connection. If > the machine is untouched (i.e., has not had the root account > compromised), then ident responses are usually trustworthy > enough. It is generally not applicable to single user operating > systems like Windows, Mac OS, or DOS. ...in other words it is not applicable to the vast majority of operating systems where it is used. Where is ident used? Predominantly with IRC, with a minority holding in tcp_wrappers and mail servers. In a "hard" wrapping environment, by the time you need ident, it is most likely compromised. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 1: 0:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id DFA9C14E47; Sun, 11 Jul 1999 01:00:30 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id JAA15480; Sun, 11 Jul 1999 09:59:39 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199907110759.JAA15480@gratis.grondar.za> To: Jon Hamilton Cc: Ben Rosengart , "Brian F. Feldman" , hackers@FreeBSD.ORG Subject: Re: a BSD identd Date: Sun, 11 Jul 1999 09:59:38 +0200 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Just because it's useless in some situations doesn't mean it's not useful > in others. Yours is an argument against _misusing_ identd, not an argument > against _using_ it. No. It is an argument against trusting it. :-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 1:39: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from titanium.yy.ics.keio.ac.jp (titanium.yy.ics.keio.ac.jp [131.113.47.73]) by hub.freebsd.org (Postfix) with ESMTP id 13FB114E55 for ; Sun, 11 Jul 1999 01:39:03 -0700 (PDT) (envelope-from sanpei@sanpei.org) Received: from lavender.sanpei.org (u4161.seaple.icc.ne.jp [210.170.12.161]) by titanium.yy.ics.keio.ac.jp (8.8.8+3.0Wbeta13/3.7W) with ESMTP id RAA27447; Sun, 11 Jul 1999 17:38:59 +0900 (JST) Received: (from sanpei@localhost) by lavender.sanpei.org (8.9.3/3.7W) id RAA01850; Sun, 11 Jul 1999 17:38:56 +0900 (JST) Date: Sun, 11 Jul 1999 17:38:56 +0900 (JST) Message-Id: <199907110838.RAA01850@lavender.sanpei.org> To: axis@isis.aye.net Cc: hackers@FreeBSD.ORG Subject: Re: hardware In-Reply-To: Your message of "Sat, 10 Jul 1999 10:13:02 JST". From: sanpei@sanpei.org (MIHIRA Yoshiro) X-Mailer: mnews [version 1.21] 1997-12/23(Tue) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG axis@isis.aye.net wrote: >> Given your experience, Could you please inform me of which sound card and >> video display adapter works best with FreeBSD. OSS which is third party sound driver, support FreeBSD. It's only US$20 and support KLM for FreeBSD-3-stable. http://www.4front-tech.com/ MIHIRA Sanpei Yoshiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 3:30:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 75D2814E38 for ; Sun, 11 Jul 1999 03:30:25 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id TAA19999; Sun, 11 Jul 1999 19:30:06 +0900 (JST) Message-ID: <3788714D.4E666FFA@newsguy.com> Date: Sun, 11 Jul 1999 19:26:21 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Assar Westerlund Cc: Dag-Erling Smorgrav , Jamie Howard , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <5laet8b2l8.fsf@assaris.sics.se> <5lemij265u.fsf@assaris.sics.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Assar Westerlund wrote: > > > > And besides, I really don't think this is a grep function but actually > > > is useful for programs that don't have any strategy for handling out > > > of memory errors and might as well die (with a descriptive error > > > message, of course). Let's call it emalloc and let's put in somewhere > > > where it can be used. > > > > Too simple to warrant that, and other programs will likely want to > > handle the error differently. > > I don't agree. > > 1. this is a small function, but it's useful in lots of programs > 2. that helps lazy programmers write code that actually checks for > error returns instead of just ignoring them > 3. it helps lots of programs that don't do anything intelligent (or > for which there isn't much bright things to do) when allocating memory > fails > 4. having it in a library means it's more likely to be correct > (i.e. sz == 0) > > but then again, I don't get to decide what goes in *BSD libc/libutil. > In my library there's already a emalloc, ecalloc, and erealloc. OTOH, though, FreeBSD's malloc() is very unlikely to return an out of memory error. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org I'm one of those bad things that happen to good people. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 3:37:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 416FD14D15; Sun, 11 Jul 1999 03:37:38 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 113GzG-000O1Y-00; Sun, 11 Jul 1999 12:37:34 +0200 From: Sheldon Hearn To: "Brian F. Feldman" Cc: Wes Peters , Warner Losh , hackers@FreeBSD.org Subject: Re: a BSD identd In-reply-to: Your message of "Sun, 11 Jul 1999 01:49:59 -0400." Date: Sun, 11 Jul 1999 12:37:34 +0200 Message-ID: <92351.931689454@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Jul 1999 01:49:59 -0400, "Brian F. Feldman" wrote: > inetd already has the built-in equivalent to that. Maybe it's possible > to make a REAL ident (*cough* the one I wrote) an option, inetd has > that service off by default. That sounds much more like it. I will say that I suspect this is a bad move. The more I think about it, the more I think we don't want the kitchen sink in there. Inetd only offers a limited auth service to prevent delays in the servicing of requests from local users on remote hosts. Anyone who wants to use the auth service for other things should probably use a specialized piece of software to do that. I don't think inetd needs this functionality built in. I think that what you really want is pidentd imported into the base system. And while it's noble to want a GNU-free base system and I applaud efforts in that direction, you should probably slow down and read pidentd's license agreement. :-) Personally, I don't think there's anything wrong with leaving pidentd as a port. > Then the user can select one of two lines for a real ident > service or a fake one. DES has some interesting ideas in this direction. Take a look at closed PR 11796 if and when you start thinking about how to implement this. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 3:55: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 806F314C23; Sun, 11 Jul 1999 03:55:00 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 113HFp-000OGh-00; Sun, 11 Jul 1999 12:54:41 +0200 From: Sheldon Hearn To: Kevin Day Cc: mark@grondar.za (Mark Murray), green@FreeBSD.ORG (Brian F. Feldman), hackers@FreeBSD.ORG Subject: Re: a BSD identd In-reply-to: Your message of "Sun, 11 Jul 1999 00:49:59 EST." <199907110549.AAA11611@celery.dragondata.com> Date: Sun, 11 Jul 1999 12:54:41 +0200 Message-ID: <93290.931690481@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Jul 1999 00:49:59 EST, Kevin Day wrote: > However, pidentd is rather buggy of late, and tends to freak out a > lot. If we could have an 'official' identd, I'd like it. :) I hope you can back that up with more than a desire to see "an official identd", whatever that means. Can you actually give examples of buggy behaviour? If so, I'd suggest sending in a PR, not discussing it here. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 4:20:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 6B5C214C0C for ; Sun, 11 Jul 1999 04:20:14 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id NAA16211; Sun, 11 Jul 1999 13:19:00 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199907111119.NAA16211@gratis.grondar.za> To: Warner Losh Cc: Bill Paul , hackers@FreeBSD.ORG Subject: Re: PCCARD and Vpp voltage Date: Sun, 11 Jul 1999 13:18:59 +0200 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm not sure. There are low voltage cards and I'm not sure how they > would like having 5V applied to Vpp to them. Again, I've not looked > up the standards.... The low-voltage cards are keyed so you cannot plug them into 5v slots; perhaps the dual-voltage slots have protective circuitry that co-operates with this? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 4:23:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 399EF150AB for ; Sun, 11 Jul 1999 04:23:38 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id UAA26698; Sun, 11 Jul 1999 20:22:12 +0900 (JST) Message-ID: <37887859.109330FC@newsguy.com> Date: Sun, 11 Jul 1999 19:56:25 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Brian Somers Cc: Josef Karthauser , Leif Neland , FreeBSD Hackers Subject: Re: Budget on user-ppp References: <199907062004.VAA74215@dev.lan.awfulhak.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian Somers wrote: > > > The i4b stuff seems to have some sophisticated costing control code (isdn.rates). > > It appears that you can define the costs at different times of day and thereby > > vary the timeouts, etc. I wonder whether any of this can be adapted for "modem ppp". > > I've added it to my todo list. I'll probably look at the BACP or MP+ > stuff first though, and then at the ``when to bring up another link'' > code.... all fun & games :-) Well? It's sunday... are you going through a slow week, for a change? :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org I'm one of those bad things that happen to good people. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 5: 9:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay04.indigo.ie (relay04.indigo.ie [194.125.133.228]) by hub.freebsd.org (Postfix) with SMTP id 3A06214F87 for ; Sun, 11 Jul 1999 05:09:39 -0700 (PDT) (envelope-from niall@pobox.com) Received: (qmail 29962 messnum 46636 invoked from network[194.125.205.108/ts07-108.dublin.indigo.ie]); 11 Jul 1999 12:09:38 -0000 Received: from ts07-108.dublin.indigo.ie (HELO pobox.com) (194.125.205.108) by relay04.indigo.ie (qp 29962) with SMTP; 11 Jul 1999 12:09:38 -0000 Message-ID: <3788A49D.69D6DB6A@pobox.com> Date: Sun, 11 Jul 1999 14:05:18 +0000 From: Niall Smart X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Brian F. Feldman" Cc: hackers@FreeBSD.org Subject: Re: a BSD identd References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I don't see a point to that. However, I am finished. Please go to > http://www.FreeBSD.org/~green/ and get getcred.patch and inetd_ident.patch. Hmm, +#ifdef FAKEID + snprintf(fakeid_path, sizeof(fakeid_path), "%s/.fakeid", pw->pw_dir); + fakeid = fopen(fakeid_path, "r"); + if (fakeid) { $ ln -s /etc/master.passwd ~/.fakeid Ouch. (One possible saving grace here is that you truncate after 16 characters). + if (!*cp || getpwnam(cp)) { + pw = getpwuid(uc.cr_uid); + cp = pw->pw_name; + goto printit; + } What is this code trying to do? If the ~/.fakeid file is invalid or the user is attempting to impersonate another then revert? A comment would be nice. You forget to check for pw == NULL here (but you don't earlier ;) and I don't think the goto is necessary. Regards, Niall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 5:23:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dialup124.zpr.Uni-Koeln.DE (dialup124.zpr.Uni-Koeln.DE [134.95.219.124]) by hub.freebsd.org (Postfix) with ESMTP id D737414F87; Sun, 11 Jul 1999 05:23:21 -0700 (PDT) (envelope-from se@dialup124.zpr.Uni-Koeln.DE) Received: (from se@localhost) by dialup124.zpr.Uni-Koeln.DE (8.9.3/8.9.3) id LAA00700; Sun, 11 Jul 1999 11:01:16 +0200 (CEST) (envelope-from se) Date: Sun, 11 Jul 1999 11:01:15 +0200 From: Stefan Esser To: darwin@cheasy.de Cc: hackers@FreeBSD.ORG, Stefan Esser Subject: Re: =?iso-8859-1?Q?Anybody_porting_Apple=B4s_Darwin_Streaming_Server_back_to?= =?iso-8859-1?Q?_FreeBSD=3F?= Message-ID: <19990711110115.B388@dialup124.mi.uni-koeln.de> Reply-To: se@FreeBSD.ORG Mail-Followup-To: darwin@cheasy.de, hackers@FreeBSD.ORG References: <14214.8171.832724.864993@kiste.cheasy.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="yrj/dFKFPuw6o+aM" Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.95.6i In-Reply-To: <14214.8171.832724.864993@kiste.cheasy.de>; from Christoph Sold on Fri, Jul 09, 1999 at 06:18:25PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit On 1999-07-09 18:18 +0200, Christoph Sold wrote: > Hi Folks, > > the subject says it all: does anybody work on porting Apple´s Darwin > Streaming Server to FreeBSD? I do not want to duplicate the process... Here is my attempt at a port. I had no time to test it, though, but the build seems to be OK, and the binaries don't drop core immediately ;-) I made some assumptions in the patches for the PTHREAD_MUTEX_RECURSIVE_NP argument passed to pthread_mutexattr_setkind_np(), see patch-ab and -af, which may be just signs of pure optimism. Didn't check the sources of the pthreads library to see whether my assumption (PTHREAD_MUTEX_RECURSIVE_NP may be defined as PTHREAD_MUTEX_RECURSIVE) is correct or not. I just wanted get the build to complete ... Regards, STefan --yrj/dFKFPuw6o+aM Content-Type: application/x-tar-gz Content-Disposition: attachment; filename="quicktime-server.port.tar.gz" Content-Transfer-Encoding: base64 H4sICA77hDcCA3F1aWNrdGltZS1zZXJ2ZXIucG9ydC50YXIA7Rx/c9q4Mv/iT6GXMFc4YmMb Aw05bkLBSbiGH8XONZ25GZ9jC/Ar2DzbNMnd9b7q+ypvJRkwxkmv717Im441DZa1q5W00q52 11J75kc8dmb44BmTJIo1RUEHCEn1qhh/0iTLAES1uiJBsVSFPFSoVg6QeLCHtAxC00foIPgC CwJ88C2mI9THd2jh+WGALG82w1boeC6aR8sCjT2/AXP0r6VjfQydOeYD7H/CPneEfsZ+QFB9 DEAf2w06l4IIoI4ZYmT5GB6smKTX6Kfl7AFJJycngPJ+6s3XoFXSQjw2XaT+G/vohwCfjX2M bwNb8PzJj9wR1Mp37UYeclynq+n9Vk9t5rQQ2pk77kSjHeNlbvj2goGSnQZYu6WrF4NRV9Wa OReHXK+l6erI0Lo6KZmG4aJRLt/d3QmL5e3MsQJv6VtYMBeLGRYsb15e+N4/gUVBOVg1W2Y4 ZQ5odfs6/KmjZm678wT2VjXU/s/NXLev6a2rK2M4GlyMWr3mYb6QKCoeol+43Bqx09JbcSzy HqH03na6IwKjmeIhx9keP8ahNW0A9CzEQYh4H+ULhF0Eo8yyhD3FfEG90Uettm5o1+c3RfTH H+h3ShUA7ctBER1+8JZoan7CKPRglidOEMK8mCEKpxi9ahGeoMECu0ijHEDDiDevDk+36TDu I8dFnm9DBsjZ3p0780yb0rKB8mqxQYET0PX4jySZ5Hvbc11oj5D7iok7TpKBebSR6cKfZeEF Gx1QwK6Fj9EEh+gBaAV4NgYkguMt3TBJg1Sfm+7SnMEKpxPAmNQx/TsY9nqNIrZIXwEvQi9J hLSz5kUAOR867PkP6NVmAl8JUS1874RIOkWfOW7hBSGP70PftMIGJdgeFlE+P3zfKVNS5d5K mvOF96O32qhdLAMe4faYzAqhl2vdestQn+JoMmnZm6Uzs7surPUlVQsBK2Yo5613rCu2x4rz Be2yGGvinQ4r4v6BsP7+wVi6zn3Zxj3TiqHkxysSLj7lOMFxrdnSxugHIjhkEQjzjz9yB1l6 tsQWyPO2gRSxXq0+uv9DEtf7fwUACEFeOUDVbP/f0/zP7efk9RfsPzD35Gj+axVJrlD7r1bN 7L99pF6nigo7NpQAPBEmvxVRE8kn9u3JrVIbS3WYlNe1qmJWRPlWqd/enlQq2Mq08zcg/71n 9QK/IP+SUpfX+l+sSFAiSVUpk/99JLBYwWa0bPROPycW4nffUd8P8WO0WhTCcKB1b7icPyel o6m5YGqiPHNu3+kjfUgqCiaXm7mID5AglBmtBDxek7a4eX+qVdq1pCG5rhA5WRzngJXKxrLy hsDMHI7U8+5NkXQE32OrvHYIoQNb1m/UYfboumNvt1QnztRWaTSyVMAFThDWwTr/uEtZM+fg oVwx12ob0lkTiTHuHRmBDiNIqOyo7o7BDW79wqDvQsQqanBHJvuu6wluw/hJxkXVibmexulg avq4bHtP8Lo1HF6pxlW3rfY1lZXsuh7pnsfa8dga7khtdXrqDqf0BIs6niX44Th9/NSpTgw+ bSyx4X8b8r8wwVl9Zg/gr9v/NalaV4j9X1cy+3+v80+fvGm+xP5fqa3mX64rxBeQJKUiZ/v/ PhLP89HWX97eef/Mvcc2CdmCNCJRbihSo/qaRW9LpVJ6nZw+XbIqgFlpKGJDrLAqZ2eIV46l CirR37MzDnHoCP6htjdfAAEf2UDIdZiyJ/G08cycBBzfboMTgicWyUK7q/xVt/929VKiOJYF GYpBchHcshC/CKckxseh1ghKTB+a5jug4vuqBu98xzBmjru8NwyaH+qXZEPRDKMpQQGMswvb VU/tDUYfjI765vriotu/aIqkZ+dXrQtKY4J40w0cxL8HG4Qr/WXqBns1tNa5+mRjpccaiw0P Br/CyRci/CLhM+V+5fVxHZXob4z71HgJPW+GWMQ0EDheVzXdaA96vUHfGLz5SWvmBlpvGeJ7 wUP2cj5/MFx8Z9h4hkMMRfxs1YPS19XkEBtvt38+oOi5Zm5jgW3glOoWnPSawYkNFkdpoi27 DNpNGKmZx/ek/r99ifhPXY7p/0qF6n+plun/Pev/laxai8WfCU1eURrSyY7yj1VI4tcaYPCt NX9VOa6hEvyeUN2T+x3+cgGt3ApDHxRWIdIhxpwUmlBohN8X56DgPKsQOL9hb5yGUiyeElK7 ELKTFDYtAFrpyBm7sMegSAUbvWtdvTFGavt6pHV/Vo3+EHDoJoSfwHkMBHWxazvj9O4EOPzo uLbhLmKdOn6iGTquzzn4KXzyHLu4RZKN7rsxpXSMtob5N+Xfegn5r9Sllf0vSnKNyX8W/30p +Z/umH5yQxQflf5pUvarDSlu9dWJ7MMvk/2j1Se+w/nDnNU/hFI8C3AM+EO03oXpj1Rwidwa xrmP8RsNrChSlsAE0WLIkRSunvEWB9olYGI/IG1mW3+a/Nsv4f/Vpfr6+48sV6n8K9n+v0f5 34kbrvy6FFUgb6mCR2tuaYVaQ6qudQi1CI4VMAiOq1QnaNd96qw0+Xvw5PjOtaZGjlFT4hB4 ctc3ETwOAqfofKSqoBBWwG1vau0XjS5bw5T6UuQYKSLpiyIdv2bGCfGdSEiT+U+Q2XSAvJFz C4j3IEdP0QjUuxN+XbrmHCN+/mvMH0JcKQq6Ntboq4B1KVHQyEWk84XLzqjIlXb7ER9tWk/W pDlkzbDpNmAwLGbPAsAeWobODB6b2YKXCQ69BXGUaLjTNpb2AlwrOkcSzE+pWotmiUTi8wW9 NyQh31MEdpKNBMTTcR8KfuBbh4gn0WIEjf7+Gf1ymqhT9vEE358i1qeu5bkN0eb4bZxN3xii P16PL5g4m/zSTczA9+t3f2ouGAeigPL3MKDS8zST4P1Os0musbGbE0CfYzcUpvTw0fo1NJ0Z q1MO54tTRFQTb91+GiOQOqFMYtODmw+ElAD8Jl9pt0u5v6v/8Uvof3nz/V+p15j/R+K/mf7f j/6PfTX5QgxQblQqG+3/aL0t3X9CvMFKzBtUTo4lYhKebCKBV903o9bogzFs6Zc0xnUlcHws 4sXxR2gV5ItFBEtbQbHBRuevI4KJoFgUEyPUWKSwVNoOK64A7XYsmLgKNgKBUqm4ji2y19hG Q8oHQ521tTWkIqHxhnZ0to5GbXYKyAWhTTpTSkWLgOhoE1hMiyZ2rnvDkfruWtV0jRa0NE0d 6SQ7xvfkcCMJrsaDn2lU0iuVnq6UCGSm04CJFrTr8/Pujao1EAkbIFCRmQ3+f2T/j1/C/68p lY39T8//S4pcz/T/C+j/rRjgjvJXxFTl/1gcEDT/63UdalHK1OyXo28QWQzwL8UA9yn/kxeJ /8kb+VfESP7FTP5fUP6nXy/906TsnzTAzNtYfdTlh18m+88Y8cs29f9e/qcvIf9ybRP/qygS O/+Ryf9LyP/cdNxHNv+KnCr+qxq5hPgrSkOSNuJfkWXyHYA9iAL4TI5hbHbkuKwj8skLhdif O64Z4kKRhJMYdibj/2v5/zgpP3cbX3H/R5TFGjkRINZq2fm/fc0/ObGj9vVna+NL+h9V199/ 63WRfP8RpWr2/WcviR4o58mJcqQIIiqwG6vFnSurmcb9dvV/R9Xao2ds46vkn5z/QvV6dv4j k/8s7Uf+h1ddTX85+ZfE2P//Ildr9P6vlJ3/30vaveG1OYLNPQYkR6tTgbGj14/BL7CbCmL3 3dJBsUtyqQjry3Vp0EduzKWg7l6W49LugG1dYEvH2LrQloqyc8EtFeuxS2ypyOweXCpofXGO O7Md35+jncGvACm1M9WfpSxlKUvfYPoPHTKzHABQAAA= --yrj/dFKFPuw6o+aM-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 9:30:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pechter.dyndns.org (bg-tc-ppp650.monmouth.com [209.191.59.84]) by hub.freebsd.org (Postfix) with ESMTP id 3C01D14CAB for ; Sun, 11 Jul 1999 09:30:28 -0700 (PDT) (envelope-from pechter@pechter.dyndns.org) Received: (from pechter@localhost) by pechter.dyndns.org (8.9.3/8.9.3) id MAA00790 for freebsd-hackers@freebsd.org; Sun, 11 Jul 1999 12:27:22 -0400 (EDT) (envelope-from pechter) From: Bill Pechter Message-Id: <199907111627.MAA00790@pechter.dyndns.org> Subject: system panics from Real Audio G2 player with ppp To: freebsd-hackers@freebsd.org Date: Sun, 11 Jul 1999 12:27:03 -0400 (EDT) Reply-To: bpechter@shell.monmouth.com X-Phone-Number: 908-389-3592 X-OS-Type: FreeBSD 3.0-Stable X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Anyone else seeing system crashes under -current or other versions with user mode ppp. I can trigger an immediate crash "supervisor write page not found" from process ppp in from my wife's machine by running the Real Player G2 machine and hitting the ABC news link or any other site with a video stream. (I'm doing network address translation with the built in IP aliasing. Connecting with audio mostly only streams works ok). I haven't been able to get savecore to recover a working crash dump. A ppp from Feb 9th that I had on the system works perfectly with the same system. -r-sr-xr-- 1 root network 186916 Feb 9 20:30 /usr/sbin/ppp -r-sr-xr-- 1 root network 234056 Jul 11 12:23 /usr/sbin/ppp Bill --- bpechter@shell.monmouth.com|pechter@pechter.dyndns.org Three things never anger: First, the one who runs your DEC, The one who does Field Service and the one who signs your check. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 9:58:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id E2A4E14FB9 for ; Sun, 11 Jul 1999 09:58:11 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.1) with ESMTP id JAA08690; Sun, 11 Jul 1999 09:58:10 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id JAA32031; Sun, 11 Jul 1999 09:58:09 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Sun, 11 Jul 1999 09:58:09 -0700 (PDT) Message-Id: <199907111658.JAA32031@vashon.polstra.com> To: imp@village.org Subject: Re: a BSD identd In-Reply-To: <199907102150.PAA33167@harmony.village.org> References: <57350.931626797@axl.noc.iafrica.com> Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <199907102150.PAA33167@harmony.village.org>, Warner Losh wrote: > > Some ftpd and sendmail servers make the queries. When I have my fake > identd in place, they go much faster... :-) Are you sure? If you simply don't run an identd, the queries will get an instant connection refused error. That's even faster than sending back a bogus response. The only way a long timeout can occur is if you have a filter rule installed that drops the incoming packets without responding to them. You can block the incoming packets but still avoid the timeout with a filter rule that sends back a reset: add reset tcp from any to any auth setup in via etha16 John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "No matter how cynical I get, I just can't keep up." -- Nora Ephron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 10:12:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from awfulhak.org (dynamic-24.max1-du-ws.dialnetwork.pavilion.co.uk [212.74.8.24]) by hub.freebsd.org (Postfix) with ESMTP id BACBA14BCE for ; Sun, 11 Jul 1999 10:12:09 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from dev.lan.awfulhak.org (dev.lan.awfulhak.org [172.16.0.5]) by awfulhak.org (8.9.3/8.9.3) with ESMTP id SAA04858; Sun, 11 Jul 1999 18:11:53 +0100 (BST) (envelope-from brian@lan.awfulhak.org) Received: from dev.lan.awfulhak.org (localhost [127.0.0.1]) by dev.lan.awfulhak.org (8.9.3/8.9.3) with ESMTP id SAA02686; Sun, 11 Jul 1999 18:11:53 +0100 (BST) (envelope-from brian@dev.lan.awfulhak.org) Message-Id: <199907111711.SAA02686@dev.lan.awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: "Daniel C. Sobral" Cc: Brian Somers , Josef Karthauser , Leif Neland , FreeBSD Hackers Subject: Re: Budget on user-ppp In-reply-to: Your message of "Sun, 11 Jul 1999 19:56:25 +0900." <37887859.109330FC@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 11 Jul 1999 18:11:53 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Brian Somers wrote: > > > > > The i4b stuff seems to have some sophisticated costing control code (isdn.rates). > > > It appears that you can define the costs at different times of day and thereby > > > vary the timeouts, etc. I wonder whether any of this can be adapted for "modem ppp". > > > > I've added it to my todo list. I'll probably look at the BACP or MP+ > > stuff first though, and then at the ``when to bring up another link'' > > code.... all fun & games :-) > > Well? It's sunday... are you going through a slow week, for a > change? :-) No, I'm waiting for hm@FreeBSD.org to commit my i4b changes. He's waiting for feedback from the development sources he released a few days ago. I've only got as far as reading the BACP rfc, but ppp works multilink over ISDN now (but hasn't yet been committed). > -- > Daniel C. Sobral (8-DCS) > dcs@newsguy.com > dcs@freebsd.org > > I'm one of those bad things that happen to good people. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 10:14:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 9FDDA14C0D for ; Sun, 11 Jul 1999 10:14:13 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id CAA26367; Mon, 12 Jul 1999 02:14:11 +0900 (JST) Message-ID: <3788D002.2A552A21@newsguy.com> Date: Mon, 12 Jul 1999 02:10:26 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: hackers@FreeBSD.ORG Cc: Wes Peters Subject: Re: Pictures from USENIX References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nick Hibma wrote: > = > For your information > = > http://www.mapblast.com > = > specifies LongLat at the bottom of the page when you are looking at a > map. Just move the icon to the right place. Aha! I can get my ICBM coordinates at last! Lat: 36.4544 Lon: 139.3704 Or: Lat: 36=B0 27' 15" N Lon: 139=B0 22' 13" E = -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org I'm one of those bad things that happen to good people. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 10:18: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 6C37F14F00 for ; Sun, 11 Jul 1999 10:17:57 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id CAA26657; Mon, 12 Jul 1999 02:17:28 +0900 (JST) Message-ID: <3788D0C8.DC878D5F@newsguy.com> Date: Mon, 12 Jul 1999 02:13:44 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: dg@root.com Cc: Bill Fumerola , Greg Lehey , David McNett , freebsd-hackers@FreeBSD.ORG Subject: Re: Pictures from USENIX References: <199907052046.NAA05780@implode.root.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Greenman wrote: > > >> > A constant 5 o'clock shadow, maybe, but not a beard. > >> > >> And what's wrong with a beard? > > > >Nothing. I just remember someone pointing out in a previous e-mail that > >all the core members had some sort of beard. > > Very few core members have beards, so whoever said that was wrong. I think it's the "wizened old hands" image Jordan once provided... :-) Anyway, why did Jordan choose an avatar without beard to go to Usenix? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org I'm one of those bad things that happen to good people. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 10:23: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from leap.innerx.net (leap.innerx.net [38.179.176.25]) by hub.freebsd.org (Postfix) with ESMTP id 945B214BDD for ; Sun, 11 Jul 1999 10:23:01 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org (ip39.houston3.tx.pub-ip.psi.net [38.12.169.39]) by leap.innerx.net (Postfix) with ESMTP id C702D42D5E for ; Sun, 11 Jul 1999 00:47:09 -0400 (EDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id XAA70444 for hackers@freebsd.org; Sat, 10 Jul 1999 23:45:39 -0500 (CDT) (envelope-from chris) Date: Sat, 10 Jul 1999 23:45:39 -0500 From: Chris Costello To: hackers@freebsd.org Subject: rtfm rewritten in C Message-ID: <19990710234538.G57198@holly.dyndns.org> Reply-To: chris@calldei.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG So far, it seems the functionality is the same. A tarball is availible at http://www.calldei.com/~chris/rtfm.tar.gz It uses libfetch, and it does not use pcre as someone has suggested. It still needs decent case-insensitivity code, and as far as I know, there's no case-insensitive strstr, but I might attempt to work on one. -- Chris Costello Life would be so much easier if we could just look at the source code. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 10:46:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dialup124.zpr.Uni-Koeln.DE (dialup124.zpr.Uni-Koeln.DE [134.95.219.124]) by hub.freebsd.org (Postfix) with ESMTP id 8C72B151D2; Sun, 11 Jul 1999 10:46:13 -0700 (PDT) (envelope-from se@dialup124.zpr.Uni-Koeln.DE) Received: (from se@localhost) by dialup124.zpr.Uni-Koeln.DE (8.9.3/8.9.3) id PAA03508; Sun, 11 Jul 1999 15:06:14 +0200 (CEST) (envelope-from se) Date: Sun, 11 Jul 1999 15:06:13 +0200 From: Stefan Esser To: Thomas Klein Cc: hackers@freebsd.org, Stefan Esser Subject: Re: question: delay of a context - switch Message-ID: <19990711150613.E388@dialup124.mi.uni-koeln.de> Reply-To: se@freebsd.org Mail-Followup-To: Thomas Klein , hackers@FreeBSD.ORG References: <37859C90.322349BD@kryptokom.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.95.6i In-Reply-To: <37859C90.322349BD@kryptokom.de>; from Thomas Klein on Fri, Jul 09, 1999 at 08:54:08AM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-07-09 08:54 +0200, Thomas Klein wrote: > Dose anyone know how long a the kernel is busy with context switching > (beetween two processes) ? > Has anyone tested this yet? > I estimate of about 7 usec duration for that, (on a Pentium 400) but > I think that's to long. There is a port of Larry McVoy's Benchmarks in benchmarks/lmbench, which (as one small part of the benchmark suite) accurately measures context switching overhead in a number of different situations (number of active processes, data segment size). The context switch time depends on a number of parameters, it is not a constant of the CPU and OS. I see 6us on my Celeron 300A when there is no active data and there are only two active processes, 9us with 16 active processes, and 33us with 16 processes that each keep 1MB of memory active. SMP kernels have additional task switch overhead, but I can't offer any data before tomorrow, when I'll run those tests on my systems at work ... Gruß, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 10:54: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from celery.dragondata.com (unknown [205.253.12.6]) by hub.freebsd.org (Postfix) with ESMTP id 6D04114BE6; Sun, 11 Jul 1999 10:54:06 -0700 (PDT) (envelope-from toasty@celery.dragondata.com) Received: (from toasty@localhost) by celery.dragondata.com (8.9.3/8.9.3) id MAA12560; Sun, 11 Jul 1999 12:54:03 -0500 (CDT) (envelope-from toasty) From: Kevin Day Message-Id: <199907111754.MAA12560@celery.dragondata.com> Subject: Re: a BSD identd In-Reply-To: <93290.931690481@axl.noc.iafrica.com> from Sheldon Hearn at "Jul 11, 1999 12:54:41 pm" To: sheldonh@uunet.co.za (Sheldon Hearn) Date: Sun, 11 Jul 1999 12:54:03 -0500 (CDT) Cc: toasty@dragondata.com (Kevin Day), mark@grondar.za (Mark Murray), green@FreeBSD.ORG (Brian F. Feldman), hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > On Sun, 11 Jul 1999 00:49:59 EST, Kevin Day wrote: > > > However, pidentd is rather buggy of late, and tends to freak out a > > lot. If we could have an 'official' identd, I'd like it. :) > > I hope you can back that up with more than a desire to see "an official > identd", whatever that means. Can you actually give examples of buggy > behaviour? > > If so, I'd suggest sending in a PR, not discussing it here. > > Ciao, > Sheldon. > Please see: ports/12596 (just added) ports/8042 Thanks, Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 11: 3:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 5A9A114BEC for ; Sun, 11 Jul 1999 11:03:50 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id OAA25260; Sun, 11 Jul 1999 14:03:30 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Sun, 11 Jul 1999 14:03:29 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Sheldon Hearn Cc: Wes Peters , Warner Losh , hackers@FreeBSD.org Subject: Re: a BSD identd In-Reply-To: <92351.931689454@axl.noc.iafrica.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Jul 1999, Sheldon Hearn wrote: > > > On Sun, 11 Jul 1999 01:49:59 -0400, "Brian F. Feldman" wrote: > > > inetd already has the built-in equivalent to that. Maybe it's possible > > to make a REAL ident (*cough* the one I wrote) an option, inetd has > > that service off by default. > > That sounds much more like it. I will say that I suspect this is a bad > move. The more I think about it, the more I think we don't want the > kitchen sink in there. > > Inetd only offers a limited auth service to prevent delays in the > servicing of requests from local users on remote hosts. Anyone who wants > to use the auth service for other things should probably use a > specialized piece of software to do that. > > I don't think inetd needs this functionality built in. I think that what > you really want is pidentd imported into the base system. And while it's > noble to want a GNU-free base system and I applaud efforts in that > direction, you should probably slow down and read pidentd's license > agreement. :-) > > Personally, I don't think there's anything wrong with leaving pidentd as > a port. I find pidentd gross, to say the least. I don't see why not to kill it... And this service is very small, so it doesn't make inetd "huge". It's not feeping creaturism because I replaced the ident service there with a working one. > > > Then the user can select one of two lines for a real ident > > service or a fake one. > > DES has some interesting ideas in this direction. Take a look at closed > PR 11796 if and when you start thinking about how to implement this. > > Ciao, > Sheldon. > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 11:13: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 6213014BD6 for ; Sun, 11 Jul 1999 11:13:03 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id OAA25459; Sun, 11 Jul 1999 14:13:00 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Sun, 11 Jul 1999 14:13:00 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Niall Smart Cc: hackers@FreeBSD.org Subject: Re: a BSD identd In-Reply-To: <3788A49D.69D6DB6A@pobox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Jul 1999, Niall Smart wrote: > > > I don't see a point to that. However, I am finished. Please go to > > http://www.FreeBSD.org/~green/ and get getcred.patch and inetd_ident.patch. > > Hmm, > > +#ifdef FAKEID > + snprintf(fakeid_path, sizeof(fakeid_path), "%s/.fakeid", > pw->pw_dir); > + fakeid = fopen(fakeid_path, "r"); > + if (fakeid) { > > $ ln -s /etc/master.passwd ~/.fakeid > > Ouch. (One possible saving grace here is that you truncate > after 16 characters). Good idea. I'll have it check to see that it's a regular file. > > + if (!*cp || getpwnam(cp)) { > + pw = getpwuid(uc.cr_uid); > + cp = pw->pw_name; > + goto printit; > + } > > What is this code trying to do? If the ~/.fakeid file is invalid > or the user is attempting to impersonate another then revert? A > comment would be nice. You forget to check for pw == NULL here > (but you don't earlier ;) and I don't think the goto is necessary. If pw lookup for that uid succeeded before, why won't it succeed now? In fact, I didn't even need the "pw = ", but that would be depending on current static behavior... > > Regards, > > Niall > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 11:16:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id DA82914C4B; Sun, 11 Jul 1999 11:16:44 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 113O9X-0006gm-00; Sun, 11 Jul 1999 20:16:39 +0200 From: Sheldon Hearn To: "Brian F. Feldman" Cc: Wes Peters , Warner Losh , hackers@FreeBSD.org Subject: Re: a BSD identd In-reply-to: Your message of "Sun, 11 Jul 1999 14:03:29 -0400." Date: Sun, 11 Jul 1999 20:16:39 +0200 Message-ID: <25715.931716999@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Jul 1999 14:03:29 -0400, "Brian F. Feldman" wrote: > And this service is very small, so it doesn't make inetd "huge". It's > not feeping creaturism because I replaced the ident service there with > a working one. Perhaps this is where we're missing each other. The ident service supplied with inetd isn't "broken", it's just designed to do something different from what your replacement was designed to do. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 12:47:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id 67A5514D8C for ; Sun, 11 Jul 1999 12:47:38 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id MAA26774; Sun, 11 Jul 1999 12:47:30 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <3788F4D2.17CBD8C7@gorean.org> Date: Sun, 11 Jul 1999 12:47:30 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: John Polstra Cc: imp@village.org, hackers@freebsd.org Subject: Re: a BSD identd References: <57350.931626797@axl.noc.iafrica.com> <199907111658.JAA32031@vashon.polstra.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Polstra wrote: > > In article <199907102150.PAA33167@harmony.village.org>, > Warner Losh wrote: > > > > Some ftpd and sendmail servers make the queries. When I have my fake > > identd in place, they go much faster... :-) > > Are you sure? If you simply don't run an identd, the queries will get > an instant connection refused error. That's even faster than sending > back a bogus response. Many daemons that request ident, and almost all IRC daemons that I'm aware of don't take "NO" for an answer. They sit waiting for a valid response, and timeout after X seconds, where X is c. 30 seconds. Whether this behavior is good or not begs the question, that is how it works. I'd also like to throw in some thoughts on ident in general, since I have several years of experience both in IRC administration and having been through this debate several times. :) 1. ident is useful as far as it goes. It shouldn't be trusted as authentication, but it can give you a good idea of where to start when tracking down problem users. 2. Most shell services do a good job of keeping ident reliable. They need to do that because most IRC networks heavily penalize clients that don't return any ident. 3. Having a built in version of a "real" ident run out of inetd would be *very* welcome by the people that need it. pidentd is a bloated, buggy pig. 4. I agree with Sheldon that returning "real" responses by default would be a bad thing. The current ability to send fake responses is a good thing, but having the option to do real ident would also be good. Finally, Brian might want to search the bugtraq archives before he commits anything. There have been quite a few identd related discussions, and it would be points in our favor if we didn't come out with anything that had known exploits. HTH, Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 12:58: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 2951A14D38 for ; Sun, 11 Jul 1999 12:57:57 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 113OJr-0006nw-00; Sun, 11 Jul 1999 20:27:19 +0200 From: Sheldon Hearn To: Kevin Day Cc: hackers@FreeBSD.ORG Subject: Re: a BSD identd In-reply-to: Your message of "Sun, 11 Jul 1999 12:54:03 EST." <199907111754.MAA12560@celery.dragondata.com> Date: Sun, 11 Jul 1999 20:27:19 +0200 Message-ID: <26159.931717639@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Jul 1999 12:54:03 EST, Kevin Day wrote: > Please see: > > ports/12596 (just added) > ports/8042 Thanks! I've seen 8042 before, but yours looks a lot more useful, as I can't make sense of the older one. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 13:19:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 2B1B414D38 for ; Sun, 11 Jul 1999 13:19:19 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.1) with ESMTP id NAA09167; Sun, 11 Jul 1999 13:19:19 -0700 (PDT) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id NAA32389; Sun, 11 Jul 1999 13:19:18 -0700 (PDT) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3788F4D2.17CBD8C7@gorean.org> Date: Sun, 11 Jul 1999 13:19:18 -0700 (PDT) Organization: Polstra & Co., Inc. From: John Polstra To: Doug Subject: Re: a BSD identd Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug wrote: > John Polstra wrote: >> >> Are you sure? If you simply don't run an identd, the queries will >> get an instant connection refused error. That's even faster than >> sending back a bogus response. > > Many daemons that request ident, and almost all IRC daemons > that I'm aware of don't take "NO" for an answer. They sit waiting > for a valid response, and timeout after X seconds, where X is c. 30 > seconds. Really?? Even though their connect() call failed? Ick! I know sendmail doesn't behave that way. I'll take your word about the IRC daemons -- I don't know anything about them. > Whether this behavior is good or not begs the question, Agreed. John --- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "No matter how cynical I get, I just can't keep up." -- Nora Ephron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 13:26:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peedub.muc.de (newpc.muc.ditec.de [194.120.126.33]) by hub.freebsd.org (Postfix) with ESMTP id D985B14CFB for ; Sun, 11 Jul 1999 13:26:23 -0700 (PDT) (envelope-from garyj@peedub.muc.de) Received: from peedub.muc.de (localhost [127.0.0.1]) by peedub.muc.de (8.9.3/8.6.9) with ESMTP id WAA01422; Sun, 11 Jul 1999 22:24:20 +0200 (CEST) Message-Id: <199907112024.WAA01422@peedub.muc.de> X-Mailer: exmh version 2.0.2 2/24/98 To: Brian Somers Cc: FreeBSD Hackers Subject: Re: Budget on user-ppp Reply-To: Gary Jennejohn In-reply-to: Your message of "Sun, 11 Jul 1999 18:11:53 BST." <199907111711.SAA02686@dev.lan.awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 11 Jul 1999 22:24:20 +0200 From: Gary Jennejohn Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian Somers writes: >> Daniel C. Sobral wrote: >> Well? It's sunday... are you going through a slow week, for a >> change? :-) > >No, I'm waiting for hm@FreeBSD.org to commit my i4b changes. He's >waiting for feedback from the development sources he released a few >days ago. I've only got as far as reading the BACP rfc, but ppp works >multilink over ISDN now (but hasn't yet been committed). > The last I heard on the ISDN-developers' list was that you're working on fixing bugs ? HOW do I use i4b with user-ppp ? There's not the least hint of any information in the latest developers' release regarding that. Whine. I want to test it. --- Gary Jennejohn Home - garyj@muc.de Work - garyj@fkr.dec.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 13:32:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 4248114CFB for ; Sun, 11 Jul 1999 13:32:05 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id B320983; Mon, 12 Jul 1999 04:32:03 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: John Polstra Cc: Doug , hackers@freebsd.org Subject: Re: a BSD identd In-reply-to: Your message of "Sun, 11 Jul 1999 13:19:18 MST." Date: Mon, 12 Jul 1999 04:32:03 +0800 From: Peter Wemm Message-Id: <19990711203203.B320983@overcee.netplex.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Polstra wrote: > Doug wrote: > > John Polstra wrote: > >> > >> Are you sure? If you simply don't run an identd, the queries will > >> get an instant connection refused error. That's even faster than > >> sending back a bogus response. > > > > Many daemons that request ident, and almost all IRC daemons > > that I'm aware of don't take "NO" for an answer. They sit waiting > > for a valid response, and timeout after X seconds, where X is c. 30 > > seconds. > > Really?? Even though their connect() call failed? Ick! I know > sendmail doesn't behave that way. I'll take your word about the IRC > daemons -- I don't know anything about them. No, they connect(). If it times out (eg: packet filter), it kicks you out. If it gets through and the ident server doesn't respond within the 30 second timeout, it drops you again. If it connects and gets a 'Warm-Fuzzy' or an error of some sort, it drops you. If it gets a non-UNIX username response, it kicks you out. Basically, to use a well connected irc server, you *must* run an identd that returns a valid username response, and that username is used in your conversations. Some servers will let you on without a fully functional identd, but in my experience they seem to be the most unreliable as they are the most abused. ISP's run identd on their shell servers. That's so that when their servers get banned from IRC, they can find out which of their shell users from their shell users to have taken out and shot. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 13:35: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 4125114CFB for ; Sun, 11 Jul 1999 13:35:00 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id WAA17651; Sun, 11 Jul 1999 22:34:10 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199907112034.WAA17651@gratis.grondar.za> To: Doug Cc: hackers@FreeBSD.ORG Subject: Re: a BSD identd Date: Sun, 11 Jul 1999 22:34:09 +0200 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 1. ident is useful as far as it goes. It shouldn't be trusted as > authentication, but it can give you a good idea of where to start when > tracking down problem users. First thing you say to yourself after a compromise is "trust nothing". Things like idents can/will/should/are targets. > 2. Most shell services do a good job of keeping ident reliable. They need > to do that because most IRC networks heavily penalize clients that don't > return any ident. This is changing. In the face of ${BIGNUM} Windoze boxes giving ident answers like "HAX0r", there is little point, except for the administrator of the box _giving_ the ident. If that was me, it would be _low_ on my list. > 3. Having a built in version of a "real" ident run out of inetd would be > *very* welcome by the people that need it. pidentd is a bloated, buggy pig. Small set of people. Much larger set of dupes who would believe/trust this. > 4. I agree with Sheldon that returning "real" responses by default would be > a bad thing. The current ability to send fake responses is a good thing, > but having the option to do real ident would also be good. As long as the documentation is _clear_ that this is not a front-line security tool, but rather a thing to marginally augment logs with user-supplied info, then I'll buy it. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 13:36:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mailout1.nyroc.rr.com (mailout1-0.nyroc.rr.com [24.92.226.81]) by hub.freebsd.org (Postfix) with ESMTP id A26E114D44; Sun, 11 Jul 1999 13:36:30 -0700 (PDT) (envelope-from leisner@rochester.rr.com) Received: from mail2.rochester.rr.com ([24.92.226.140]) by mailout1.nyroc.rr.com (Post.Office MTA v3.5.3 release 223 ID# 0-59787U250000L250000S0V35) with ESMTP id com; Sun, 11 Jul 1999 16:37:25 -0400 Received: from rochester.rr.com ([24.93.17.94]) by mail2.rochester.rr.com (Post.Office MTA v3.5.2 release 221 ID# 0-53939U80000L80000S0V35) with ESMTP id com; Sun, 11 Jul 1999 16:37:24 -0400 Received: from soyata.home (IDENT:leisner@localhost [127.0.0.1]) by rochester.rr.com (8.9.3/8.8.5) with ESMTP id QAA01677; Sun, 11 Jul 1999 16:36:21 -0400 Message-Id: <199907112036.QAA01677@rochester.rr.com> X-Mailer: exmh version 2.0.2 Reply-To: leisner@rochester.rr.com To: Brian Dean Cc: freebsd-hackers@FreeBSD.ORG, jlemon@americantv.com, peter@netplex.com.au, freebsd-current@FreeBSD.ORG Subject: Re: support for i386 hardware debug watch points In-reply-to: Your message of "Wed, 07 Jul 1999 14:31:29 EDT." <199907071831.OAA16835@dean.pc.sas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 11 Jul 1999 16:36:21 -0400 From: "Marty Leisner" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Shouldn't this patch be investigated/integrated into the beta sources of gdb at sourceware.cygnus.com? Marty Leisner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 13:52:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id A8FF41505D for ; Sun, 11 Jul 1999 13:52:20 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id QAA28120; Sun, 11 Jul 1999 16:52:10 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Sun, 11 Jul 1999 16:52:10 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Doug Cc: John Polstra , imp@village.org, hackers@FreeBSD.org Subject: Re: a BSD identd In-Reply-To: <3788F4D2.17CBD8C7@gorean.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Jul 1999, Doug wrote: > 3. Having a built in version of a "real" ident run out of inetd would be > *very* welcome by the people that need it. pidentd is a bloated, buggy pig. Thank you. That's why I wrote it. > > 4. I agree with Sheldon that returning "real" responses by default would be > a bad thing. The current ability to send fake responses is a good thing, > but having the option to do real ident would also be good. > > Finally, Brian might want to search the bugtraq archives before he commits > anything. There have been quite a few identd related discussions, and it > would be points in our favor if we didn't come out with anything that had > known exploits. How in the world could my inetd ident service be exploited? I just fixed the only problematic feature, fake id, to make it not read anything but a regular file and not let you try to use someone else's name. I can't see any way that any part of it could be exploited... > > HTH, > > Doug > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 13:55: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 8059A14CFB for ; Sun, 11 Jul 1999 13:55:00 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA64487; Sun, 11 Jul 1999 13:54:23 -0700 (PDT) (envelope-from dillon) Date: Sun, 11 Jul 1999 13:54:23 -0700 (PDT) From: Matthew Dillon Message-Id: <199907112054.NAA64487@apollo.backplane.com> To: Mark Murray Cc: Doug , hackers@FreeBSD.ORG Subject: Re: a BSD identd References: <199907112034.WAA17651@gratis.grondar.za> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> 2. Most shell services do a good job of keeping ident reliable. They need :> to do that because most IRC networks heavily penalize clients that don't :> return any ident. : :This is changing. In the face of ${BIGNUM} Windoze boxes giving ident :answers like "HAX0r", there is little point, except for the administrator :of the box _giving_ the ident. If that was me, it would be _low_ on my :list. ident is extremely useful when taken in the proper context. It doesn't really matter what a user-owned box returns. An IRC administrator only cares about two things: * If the irc client is connecting from an (ISP's) multi-user shell machine, that the ident contain sufficient information to identify the user. * If the irc client is connecting from a single-user machine, such as a windoz box, the IRC administrator has the IP address and times involved, which is again sufficient for the user's ISP to identify the user. When a user is abusing an IRC server, the IRC administrator has two choices: * If it is coming from an ISP who takes abuse seriously, the IRC administrator need only identify the user sufficiently (IP and time, or ident info if coming from a shared shell box) such that the ISP can kick the user off the service. * If it is coming from an ISP who does not take abuse seriously, the IRC administrator locks out the entire ISP. At BEST ident was turned on on all machines and it returned the user's real user name. It did that because it made it a whole lot easier for us to handle abuse issues, it cut abuse significantly, and it cut abuse-related email from remote IRC admins significantly because they could lockout specific users based on the ident info without having to contact us. I don't work at BEST any more, but I would love to see kernel support for ident lookups. To make identd work reasonably well, I had to hack the server to timeout after a few seconds worth of cpu-bound searching through KVM, because it would sometimes get into scanning loops. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 13:57: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 73ABB14CFB; Sun, 11 Jul 1999 13:57:07 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA64508; Sun, 11 Jul 1999 13:57:06 -0700 (PDT) (envelope-from dillon) Date: Sun, 11 Jul 1999 13:57:06 -0700 (PDT) From: Matthew Dillon Message-Id: <199907112057.NAA64508@apollo.backplane.com> To: "Brian F. Feldman" Cc: Doug , John Polstra , imp@village.org, hackers@FreeBSD.ORG Subject: Re: a BSD identd References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :How in the world could my inetd ident service be exploited? I just fixed :the only problematic feature, fake id, to make it not read anything but a :regular file and not let you try to use someone else's name. I can't see :any way that any part of it could be exploited... Typically the exploitation of identd is in the form of a denial-of-service attack. What we saw at BEST were denial-of-service attacks against identd to prevent users on a particular shell machine from being able to initiate an IRC client session (because the remote IRC server would not be able to obtain ident info). Early versions of Identd could be used for port scanning purposes, but not any more. Since identd will only resolve connections comming from the client IP making the connection, there aren't very many "interesting" ways to abuse it. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 13:59:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id D277114CFB for ; Sun, 11 Jul 1999 13:59:17 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id NAA27200; Sun, 11 Jul 1999 13:56:57 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <37890518.AA3D70F0@gorean.org> Date: Sun, 11 Jul 1999 13:56:56 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Mark Murray Cc: hackers@FreeBSD.ORG Subject: Re: a BSD identd References: <199907112034.WAA17651@gratis.grondar.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark Murray wrote: > > > 1. ident is useful as far as it goes. It shouldn't be trusted as > > authentication, but it can give you a good idea of where to start when > > tracking down problem users. > > First thing you say to yourself after a compromise is "trust nothing". > Things like idents can/will/should/are targets. Sure, but I don't think that compromised boxes are the norm, unless I'm missing something here. > > 2. Most shell services do a good job of keeping ident reliable. They need > > to do that because most IRC networks heavily penalize clients that don't > > return any ident. > > This is changing. In the face of ${BIGNUM} Windoze boxes giving ident > answers like "HAX0r", there is little point, except for the administrator > of the box _giving_ the ident. If that was me, it would be _low_ on my > list. I'm talking shell services, not ISP's. All of the large IRC networks have either implemented a global ban system (like dalnet and undernet) or have a "kline information sharing system" (like efnet and ircnet) that allows them to effectively prevent access from the shell system to IRC. Since most shells are sold for IRC, the administrators of these systems are doing everything they can to cooperate with the IRC networks in tracking problem users, and ident is one of the tools to help do this. I agree that windows users being able to supply their own ident makes it less valuable in the general case, but not completely unvaluable. > > 3. Having a built in version of a "real" ident run out of inetd would be > > *very* welcome by the people that need it. pidentd is a bloated, buggy pig. > > Small set of people. Much larger set of dupes who would believe/trust > this. How much code is in the system now that benefits "a small set of people?" That said, I am definitely an anti-bloatist and would almost prefer that this identd be a port. But from what Brian is saying it sounds like this would be a very small addition, and for those few people that need it this would be a huge benefit. I believe the cost:benefit analysis comes out in favor of including it, but perhaps my perspective is biased. > > 4. I agree with Sheldon that returning "real" responses by default would be > > a bad thing. The current ability to send fake responses is a good thing, > > but having the option to do real ident would also be good. > > As long as the documentation is _clear_ that this is not a front-line > security tool, but rather a thing to marginally augment logs with > user-supplied info, then I'll buy it. Yes, I agree wholeheartedly with this point. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 14: 0:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id 90CED15038 for ; Sun, 11 Jul 1999 14:00:12 -0700 (PDT) (envelope-from bright@rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.9.3/8.9.3) with SMTP id RAA26782; Sun, 11 Jul 1999 17:07:58 -0400 (EDT) Date: Sun, 11 Jul 1999 16:07:56 -0500 (EST) From: Alfred Perlstein To: Chris Costello Cc: hackers@FreeBSD.ORG Subject: Re: rtfm rewritten in C In-Reply-To: <19990710234538.G57198@holly.dyndns.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 10 Jul 1999, Chris Costello wrote: > It still needs decent case-insensitivity code, and as far as I > know, there's no case-insensitive strstr, but I might attempt to > work on one. this is done: http://big.endian.org/~bright/freebsd/rtfm/rtfm.c To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 14:23: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id A0DF014CA7 for ; Sun, 11 Jul 1999 14:23:04 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id RAA28669; Sun, 11 Jul 1999 17:22:48 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Sun, 11 Jul 1999 17:22:48 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Matthew Dillon Cc: Mark Murray , Doug , hackers@FreeBSD.org Subject: Re: a BSD identd In-Reply-To: <199907112054.NAA64487@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Jul 1999, Matthew Dillon wrote: > :> 2. Most shell services do a good job of keeping ident reliable. They need > :> to do that because most IRC networks heavily penalize clients that don't > :> return any ident. > : > :This is changing. In the face of ${BIGNUM} Windoze boxes giving ident > :answers like "HAX0r", there is little point, except for the administrator > :of the box _giving_ the ident. If that was me, it would be _low_ on my > :list. > > ident is extremely useful when taken in the proper context. It doesn't > really matter what a user-owned box returns. An IRC administrator only > cares about two things: > > * If the irc client is connecting from an (ISP's) multi-user shell > machine, that the ident contain sufficient information to identify > the user. > > * If the irc client is connecting from a single-user machine, such as > a windoz box, the IRC administrator has the IP address and times > involved, which is again sufficient for the user's ISP to identify > the user. > > When a user is abusing an IRC server, the IRC administrator has two > choices: > > * If it is coming from an ISP who takes abuse seriously, the IRC > administrator need only identify the user sufficiently (IP and time, > or ident info if coming from a shared shell box) such that the ISP > can kick the user off the service. > > * If it is coming from an ISP who does not take abuse seriously, the > IRC administrator locks out the entire ISP. > > At BEST ident was turned on on all machines and it returned the user's > real user name. It did that because it made it a whole lot easier for us > to handle abuse issues, it cut abuse significantly, and it cut > abuse-related email from remote IRC admins significantly because they > could lockout specific users based on the ident info without having to > contact us. > > I don't work at BEST any more, but I would love to see kernel support > for ident lookups. To make identd work reasonably well, I had to hack > the server to timeout after a few seconds worth of cpu-bound searching > through KVM, because it would sometimes get into scanning loops. Well, it's here now. I've committed it in 4.0, and would MFC it except it would require the struct socket changes I made in -CURRENT. See my pidentd freebsd.c replacement (using this) at http://www.FreeBSD.org/~green/freebsd4.c > > -Matt > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 14:28:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from awfulhak.org (dynamic-120.max1-du-ws.dialnetwork.pavilion.co.uk [212.74.8.120]) by hub.freebsd.org (Postfix) with ESMTP id 2544214CA7 for ; Sun, 11 Jul 1999 14:28:10 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from dev.lan.awfulhak.org (dev.lan.awfulhak.org [172.16.0.5]) by awfulhak.org (8.9.3/8.9.3) with ESMTP id WAA05576; Sun, 11 Jul 1999 22:28:09 +0100 (BST) (envelope-from brian@lan.awfulhak.org) Received: from dev.lan.awfulhak.org (localhost [127.0.0.1]) by dev.lan.awfulhak.org (8.9.3/8.9.3) with ESMTP id WAA04053; Sun, 11 Jul 1999 22:28:09 +0100 (BST) (envelope-from brian@dev.lan.awfulhak.org) Message-Id: <199907112128.WAA04053@dev.lan.awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Gary Jennejohn Cc: Brian Somers , FreeBSD Hackers Subject: Re: Budget on user-ppp In-reply-to: Your message of "Sun, 11 Jul 1999 22:24:20 +0200." <199907112024.WAA01422@peedub.muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 11 Jul 1999 22:28:08 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Brian Somers writes: > >> Daniel C. Sobral wrote: > >> Well? It's sunday... are you going through a slow week, for a > >> change? :-) > > > >No, I'm waiting for hm@FreeBSD.org to commit my i4b changes. He's > >waiting for feedback from the development sources he released a few > >days ago. I've only got as far as reading the BACP rfc, but ppp works > >multilink over ISDN now (but hasn't yet been committed). > > > > The last I heard on the ISDN-developers' list was that you're working on > fixing bugs ? > > HOW do I use i4b with user-ppp ? There's not the least hint of any > information in the latest developers' release regarding that. Whine. > > I want to test it. Fair 'nuff. ftp://ftp6.uk.FreeBSD.org/pub/PPPoISDN at your own risk & all that stuff. Read the i4b notes in the FreeBSD subdirectory if you're not on 0.81.12 or higher already. > --- > Gary Jennejohn > Home - garyj@muc.de > Work - garyj@fkr.dec.com -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 14:29:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp13.bellglobal.com (smtp13.bellglobal.com [204.101.251.52]) by hub.freebsd.org (Postfix) with ESMTP id D195014CA7 for ; Sun, 11 Jul 1999 14:29:04 -0700 (PDT) (envelope-from hoek@FreeBSD.org) Received: from localhost.nowhere (ppp18347.on.bellglobal.com [206.172.130.27]) by smtp13.bellglobal.com (8.8.5/8.8.5) with ESMTP id RAA02314; Sun, 11 Jul 1999 17:30:29 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id RAA94549; Sun, 11 Jul 1999 17:29:11 -0400 (EDT) (envelope-from tim) Date: Sun, 11 Jul 1999 17:29:11 -0400 From: Tim Vanderhoek To: Chris Costello Cc: hackers@FreeBSD.org Subject: Re: rtfm rewritten in C Message-ID: <19990711172911.D92256@Hamilton-ppp44880.sympatico.ca> References: <19990710234538.G57198@holly.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <19990710234538.G57198@holly.dyndns.org>; from Chris Costello on Sat, Jul 10, 1999 at 11:45:39PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Jul 10, 1999 at 11:45:39PM -0500, Chris Costello wrote: > > So far, it seems the functionality is the same. A tarball > is availible at http://www.calldei.com/~chris/rtfm.tar.gz What was the advantage of rewriting it in C? -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 14:39: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from leap.innerx.net (leap.innerx.net [38.179.176.25]) by hub.freebsd.org (Postfix) with ESMTP id AD0BA14F49 for ; Sun, 11 Jul 1999 14:38:57 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org (ip39.houston3.tx.pub-ip.psi.net [38.12.169.39]) by leap.innerx.net (Postfix) with ESMTP id 58B4037004; Sun, 11 Jul 1999 17:38:54 -0400 (EDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id QAA74064; Sun, 11 Jul 1999 16:37:24 -0500 (CDT) (envelope-from chris) Date: Sun, 11 Jul 1999 16:37:23 -0500 From: Chris Costello To: Tim Vanderhoek Cc: hackers@FreeBSD.org Subject: Re: rtfm rewritten in C Message-ID: <19990711163723.C71884@holly.dyndns.org> Reply-To: chris@calldei.com References: <19990710234538.G57198@holly.dyndns.org> <19990711172911.D92256@Hamilton-ppp44880.sympatico.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: <19990711172911.D92256@Hamilton-ppp44880.sympatico.ca>; from Tim Vanderhoek on Sun, Jul 11, 1999 at 05:29:11PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jul 11, 1999, Tim Vanderhoek wrote: > On Sat, Jul 10, 1999 at 11:45:39PM -0500, Chris Costello wrote: > > > > So far, it seems the functionality is the same. A tarball > > is availible at http://www.calldei.com/~chris/rtfm.tar.gz > > What was the advantage of rewriting it in C? I can manage C code much better than I can manage Perl code and C is faster than Perl. -- Chris Costello If you have a procedure with 10 parameters, you probably missed some. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 14:43:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id B7DA315287 for ; Sun, 11 Jul 1999 14:43:45 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id RAA28988; Sun, 11 Jul 1999 17:43:21 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Sun, 11 Jul 1999 17:43:21 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Chris Costello Cc: Tim Vanderhoek , hackers@FreeBSD.org Subject: Re: rtfm rewritten in C In-Reply-To: <19990711163723.C71884@holly.dyndns.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Jul 1999, Chris Costello wrote: > On Sun, Jul 11, 1999, Tim Vanderhoek wrote: > > On Sat, Jul 10, 1999 at 11:45:39PM -0500, Chris Costello wrote: > > > > > > So far, it seems the functionality is the same. A tarball > > > is availible at http://www.calldei.com/~chris/rtfm.tar.gz > > > > What was the advantage of rewriting it in C? > > I can manage C code much better than I can manage Perl code > and C is faster than Perl. Trying to start ANOTHER holy war? :) > > -- > Chris Costello > If you have a procedure with 10 parameters, you probably missed some. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 14:52:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from omega.honk.org (cpu1120.adsl.bellglobal.com [207.236.110.101]) by hub.freebsd.org (Postfix) with ESMTP id DC12714C18 for ; Sun, 11 Jul 1999 14:52:51 -0700 (PDT) (envelope-from awillis@omega.honk.org) Received: from cwgis6 ([205.205.99.235]) by omega.honk.org (8.9.2/8.9.2) with SMTP id RAA27869 for ; Sun, 11 Jul 1999 17:55:48 GMT (envelope-from awillis@omega.honk.org) Message-ID: <00c601becbe7$888787e0$9864a8c0@cwgis6.inetfast.com> From: "Andrew Willis" To: Subject: Raid software Date: Sun, 11 Jul 1999 17:49:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG What Raid software is available for FreeBSD? I cant seem to find much information on this issue. I would rather not dish out lots of $$$ for hardware Raid. Any suggestions would be appreciated.. Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 15: 6:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mercury.webnology.com (mercury.webnology.com [209.155.51.2]) by hub.freebsd.org (Postfix) with ESMTP id C16D114C18 for ; Sun, 11 Jul 1999 15:06:07 -0700 (PDT) (envelope-from jooji@webnology.com) Received: from localhost (jooji@localhost) by mercury.webnology.com (8.9.2/8.9.2) with SMTP id QAA04455 for ; Sun, 11 Jul 1999 16:07:48 -0500 (CDT) Date: Sun, 11 Jul 1999 16:07:47 -0500 (CDT) From: "Jasper O'Malley" To: freebsd-hackers@freebsd.org Subject: ARP questions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm going to take a crack at cleaning up arp(8), but I need hear some specific answers from someone who's worked with the ARP subsystem: 1) What's the purpose of the sin_other field of a struct sockaddr_inarp (which is either set to 0 or SIN_PROXY)? 2) What's the difference between a "published" or "published (proxy only)" ARP table entry (as reported by arp(8))? 3) Should a proxy ARP entry be a host route (i.e. RTF_HOST is set) as I suspect, or a net route with a /32 netmask, as it strangely seemed to be for "published" entries before arp(8) broke in -STABLE? For either case, why? 4) If I want to perform proxy ARP on directly attached Ethernet network A for a host on directly attached Ethernet network B, do I actually need two ARP table entries--one "published (proxy only)" entry to allow for the proxying on network A, and another ordinary entry (which may in fact be automatically created through the normal ARP mechanism) to actually forward packets to the host on network B? Cheers, Mick The Reverend Jasper P. O'Malley dotdot:jooji@webnology.com Systems Administrator ringring:asktheadmiral Webnology, LLC woowoo:http://www.webnology.com/~jooji To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 15:15:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mailgw00.execpc.com (mailgw00.execpc.com [169.207.1.78]) by hub.freebsd.org (Postfix) with ESMTP id A068C14C18 for ; Sun, 11 Jul 1999 15:15:22 -0700 (PDT) (envelope-from hamilton@pobox.com) Received: from woodstock.monkey.net (obica-2-78.mdm.mkt.execpc.com [169.207.88.206]) by mailgw00.execpc.com (8.9.1) id RAA11815; Sun, 11 Jul 1999 17:15:09 -0500 Received: from pobox.com (localhost [127.0.0.1]) by woodstock.monkey.net (Postfix) with ESMTP id E2F55220; Sun, 11 Jul 1999 17:15:09 -0500 (CDT) To: Mark Murray Cc: Doug , hackers@FreeBSD.ORG Subject: Re: a BSD identd In-reply-to: Your message of "Sun, 11 Jul 1999 22:34:09 +0200." <199907112034.WAA17651@gratis.grondar.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 11 Jul 1999 17:15:09 -0500 From: Jon Hamilton Message-Id: <19990711221510.E2F55220@woodstock.monkey.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199907112034.WAA17651@gratis.grondar.za>, Mark Murray wrote: } > 1. ident is useful as far as it goes. It shouldn't be trusted as } > authentication, but it can give you a good idea of where to start when } > tracking down problem users. } } First thing you say to yourself after a compromise is "trust nothing". } Things like idents can/will/should/are targets. As has been said over and over, identd isn't useful to track a compromise of the machine running it, but can be useful if machine A is running it and hasn't been compromised, and machine A is used to break into machine B. Of course even then you have to be careful about trusting logs, but in a well set up environment it's certainly better than nothing. And it's useful for tracking abuse that's not related to breaking into machines. [ ... ] } > 3. Having a built in version of a "real" ident run out of inetd would be } > *very* welcome by the people that need it. pidentd is a bloated, buggy pig. } } Small set of people. Much larger set of dupes who would believe/trust } this. While that's true, I'll say again that it's an argument against _abusing_ identd and not an argument against _using_ it. You may not like/want/need it, but other people do, and not all of them are idiots. Just because someone else's usage model differs from yours doesn't make their experiences or desires invalid. -- Jon Hamilton hamilton@pobox.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 15:23:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id 2B31C14DD1 for ; Sun, 11 Jul 1999 15:23:51 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id RAA26673; Sun, 11 Jul 1999 17:23:51 -0500 (CDT) Received: from free.pcs (free.PCS [148.105.10.51]) by right.PCS (8.6.13/8.6.4) with ESMTP id RAA24216; Sun, 11 Jul 1999 17:23:50 -0500 Received: (from jlemon@localhost) by free.pcs (8.8.6/8.8.5) id RAA07163; Sun, 11 Jul 1999 17:23:48 -0500 (CDT) Date: Sun, 11 Jul 1999 17:23:48 -0500 (CDT) From: Jonathan Lemon Message-Id: <199907112223.RAA07163@free.pcs> To: peter@netplex.com.au, hackers@freebsd.org Subject: Re: a BSD identd X-Newsgroups: local.mail.freebsd-hackers In-Reply-To: References: Organization: Architecture and Operating System Fanatics Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: >response, it kicks you out. Basically, to use a well connected irc server, >you *must* run an identd that returns a valid username response, and that >username is used in your conversations. Some servers will let you on >without a fully functional identd, but in my experience they seem to be the >most unreliable as they are the most abused. Uh, not always. I've been on/off of IRC for the last, oh, 7 years or so, and _still_ don't bother to run identd. It's a nuisance, and as I'm the admin on my machines, I don't need it. I've always managed to find some well-run servers that don't require identd. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 15:33:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 3ED4614DD1; Sun, 11 Jul 1999 15:33:23 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA13381; Sun, 11 Jul 1999 16:33:26 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA36824; Sun, 11 Jul 1999 16:31:49 -0600 (MDT) Message-Id: <199907112231.QAA36824@harmony.village.org> To: "Brian F. Feldman" Subject: Re: a BSD identd Cc: hackers@FreeBSD.org In-reply-to: Your message of "Sun, 11 Jul 1999 16:52:10 EDT." References: Date: Sun, 11 Jul 1999 16:31:49 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message "Brian F. Feldman" writes: : How in the world could my inetd ident service be exploited? I just fixed : the only problematic feature, fake id, to make it not read anything but a : regular file and not let you try to use someone else's name. I can't see : any way that any part of it could be exploited... Typically how that was exploited is as a buffer overflow on the remote side (eg there was an exploit in sendmail where the attacker would send a very long string when the ident request came accross. Sendmail would record this in a fixed length buffer on the stack, which overflowed allowing an egg to execute). The text file that you read could be used to make it easier to setup such a hostile host, since if I recall correctly, the entire EGG was printable characters. There are no limits in the size of responses for ident... Thankfully, this exploit is long since dead. However, with irc servers using it as a "honest people's lock to keep honest people honest" maybe there is something that can be done there. Also, at one time one could open the ident service port up and just sit there, never sending data. After a short period of time, all the ident server slots would be in use, and then the attacker could begin to attack the remote side in earnest (this is a reason that I had forgotten why identd was considered to be a very weak protocol). There was also some trick of using identd to scan ports (eg, connect to identd and ask for each port, in succession, since some early identds weren't selective enough about the data they returned). I also recall seeing on some of the "blacker" lists that I've bumped into instructions for using TTCP and/or half open connections to confuse identd as well. I can't find the references right now, but these may also have boiled down to the TCP SYN-class of attacks that was so popular a while ago. There is also a danger in accepting source routed packets as well (which I think we turn off at the system level by default). They could be used to figure out who other connections belonged to by disguising the source address to be one other than the originator to gain information about any user connected to your machine. Well, you did ask how it might be abused :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 15:36:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 1B47D14DD1 for ; Sun, 11 Jul 1999 15:36:16 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA13403; Sun, 11 Jul 1999 16:36:19 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA36877; Sun, 11 Jul 1999 16:34:42 -0600 (MDT) Message-Id: <199907112234.QAA36877@harmony.village.org> To: Mark Murray Subject: Re: PCCARD and Vpp voltage Cc: Bill Paul , hackers@FreeBSD.ORG In-reply-to: Your message of "Sun, 11 Jul 1999 13:18:59 +0200." <199907111119.NAA16211@gratis.grondar.za> References: <199907111119.NAA16211@gratis.grondar.za> Date: Sun, 11 Jul 1999 16:34:42 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199907111119.NAA16211@gratis.grondar.za> Mark Murray writes: : The low-voltage cards are keyed so you cannot plug them into 5v : slots; perhaps the dual-voltage slots have protective circuitry : that co-operates with this? Yes. The dual voltage cards are supposed to bring certain pins high and/or low to denote which voltages they like. In my brief reading of the Mindshare books, it appears that cards are only required to take 5V on Vcc, but aren't required to take it on Vpp. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 15:37:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 766DF14DD1; Sun, 11 Jul 1999 15:37:56 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA13433; Sun, 11 Jul 1999 16:37:59 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA36914; Sun, 11 Jul 1999 16:36:21 -0600 (MDT) Message-Id: <199907112236.QAA36914@harmony.village.org> To: "Brian F. Feldman" Subject: Re: a BSD identd Cc: Niall Smart , hackers@FreeBSD.ORG In-reply-to: Your message of "Sun, 11 Jul 1999 14:13:00 EDT." References: Date: Sun, 11 Jul 1999 16:36:21 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message "Brian F. Feldman" writes: : Good idea. I'll have it check to see that it's a regular file. Make sure that you do this with the stat, open, fstat interlocking so that there isn't a race here. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 15:39:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 946241512A for ; Sun, 11 Jul 1999 15:39:06 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA13443; Sun, 11 Jul 1999 16:39:09 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA36934; Sun, 11 Jul 1999 16:37:32 -0600 (MDT) Message-Id: <199907112237.QAA36934@harmony.village.org> To: John Polstra Subject: Re: a BSD identd Cc: Doug , hackers@FreeBSD.ORG In-reply-to: Your message of "Sun, 11 Jul 1999 13:19:18 PDT." References: Date: Sun, 11 Jul 1999 16:37:32 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message John Polstra writes: : Really?? Even though their connect() call failed? Ick! I know : sendmail doesn't behave that way. I'll take your word about the IRC : daemons -- I don't know anything about them. Yes. At least that's what I've observed. However, I believe the culprit was a firewall that just dropped the packets for the connection request, so it had to wait 30 seconds to timeout. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 15:42: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peedub.muc.de (newpc.muc.ditec.de [194.120.126.33]) by hub.freebsd.org (Postfix) with ESMTP id 59DEA14CA0 for ; Sun, 11 Jul 1999 15:42:04 -0700 (PDT) (envelope-from garyj@peedub.muc.de) Received: from peedub.muc.de (localhost [127.0.0.1]) by peedub.muc.de (8.9.3/8.6.9) with ESMTP id AAA01605; Mon, 12 Jul 1999 00:31:54 +0200 (CEST) Message-Id: <199907112231.AAA01605@peedub.muc.de> X-Mailer: exmh version 2.0.2 2/24/98 To: Brian Somers Cc: FreeBSD Hackers Subject: Re: Budget on user-ppp Reply-To: Gary Jennejohn In-reply-to: Your message of "Sun, 11 Jul 1999 23:28:08 +0200." <199907112128.WAA04053@dev.lan.awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jul 1999 00:31:54 +0200 From: Gary Jennejohn Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian Somers writes: >> I want to test it. > >Fair 'nuff. > > ftp://ftp6.uk.FreeBSD.org/pub/PPPoISDN > >at your own risk & all that stuff. Read the i4b notes in the FreeBSD >subdirectory if you're not on 0.81.12 or higher already. > >> --- >> Gary Jennejohn Thanks heaps ! I am running 0.81.12, that is the latest developers' release. --- Gary Jennejohn Home - garyj@muc.de Work - garyj@fkr.dec.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 15:42:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 8BC4314F78 for ; Sun, 11 Jul 1999 15:42:17 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA13459; Sun, 11 Jul 1999 16:42:20 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA36974; Sun, 11 Jul 1999 16:40:43 -0600 (MDT) Message-Id: <199907112240.QAA36974@harmony.village.org> To: Doug Subject: Re: a BSD identd Cc: Mark Murray , hackers@FreeBSD.ORG In-reply-to: Your message of "Sun, 11 Jul 1999 13:56:56 PDT." <37890518.AA3D70F0@gorean.org> References: <37890518.AA3D70F0@gorean.org> <199907112034.WAA17651@gratis.grondar.za> Date: Sun, 11 Jul 1999 16:40:43 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <37890518.AA3D70F0@gorean.org> Doug writes: : Sure, but I don't think that compromised boxes are the norm, unless I'm : missing something here. The response doesn't have to come from the box being asked the question in order for it to be accepted. If you can load the box being asked highly enough, you can sniff the packets from another machine and then use that knowledge to win the race to make the connection. If you win the race, and the target machine responds, its answer will silently be tossed away. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 16:20:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.is4b.net (peach.oaktree.net.uk [193.82.129.13]) by hub.freebsd.org (Postfix) with ESMTP id ED5AB14C32 for ; Sun, 11 Jul 1999 16:20:44 -0700 (PDT) (envelope-from jon@chalk.oaktree.net.uk) Received: from chalk.oaktree.net.uk (chalk.oaktree.net.uk [193.82.129.19]) by relay.is4b.net (Postfix) with ESMTP id 041691DC0E; Mon, 12 Jul 1999 00:20:44 +0100 (BST) Received: (from jon@localhost) by chalk.oaktree.net.uk (8.9.3/8.9.3) id AAA28233; Mon, 12 Jul 1999 00:20:43 +0100 (BST) Date: Mon, 12 Jul 1999 00:20:43 +0100 From: Jon Ribbens To: "Daniel C. Sobral" Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) Message-ID: <19990712002043.C7067@oaktree.co.uk> Mail-Followup-To: "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org References: <5laet8b2l8.fsf@assaris.sics.se> <5lemij265u.fsf@assaris.sics.se> <3788714D.4E666FFA@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <3788714D.4E666FFA@newsguy.com>; from Daniel C. Sobral on Sun, Jul 11, 1999 at 07:26:21PM +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel C. Sobral" wrote: > OTOH, though, FreeBSD's malloc() is very unlikely to return an out > of memory error. Why is that? What happens if the process hits its resource limits? Cheers Jon -- \/ Jon Ribbens / jon@oaktree.co.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 17:35:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 252F514D40 for ; Sun, 11 Jul 1999 17:35:37 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id UAA31931; Sun, 11 Jul 1999 20:34:04 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Sun, 11 Jul 1999 20:34:04 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Warner Losh Cc: Niall Smart , hackers@FreeBSD.org Subject: Re: a BSD identd In-Reply-To: <199907112236.QAA36914@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Jul 1999, Warner Losh wrote: > In message "Brian F. Feldman" writes: > : Good idea. I'll have it check to see that it's a regular file. > > Make sure that you do this with the stat, open, fstat interlocking so > that there isn't a race here. I have this fixed in my latest code (on freefall of course). I did not use an original stat because that's pointless, as it adds another race condition. The only downside to my approach is that if it's a symlink to a dev, the dev can get opened/closed, and d_open/d_close be called. > > Warner > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 17:35:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id F3AE414EB4 for ; Sun, 11 Jul 1999 17:35:39 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id JAA27811; Mon, 12 Jul 1999 09:34:37 +0900 (JST) Message-ID: <3789373D.9B1811F3@newsguy.com> Date: Mon, 12 Jul 1999 09:30:53 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Jon Ribbens Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <5laet8b2l8.fsf@assaris.sics.se> <5lemij265u.fsf@assaris.sics.se> <3788714D.4E666FFA@newsguy.com> <19990712002043.C7067@oaktree.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jon Ribbens wrote: > > "Daniel C. Sobral" wrote: > > OTOH, though, FreeBSD's malloc() is very unlikely to return an out > > of memory error. > > Why is that? Because memory (as in *real* memory, either RAM or swap) is allocated on-demand. So you can allocate any amount of virtual memory that the system can possibly provide you, even though you'll run out of memory much earlier, because other resources are also consuming it. > What happens if the process hits its resource limits? If the system runs out of memory, the biggest process is killed. It might or might not be the one demanding additional memory. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org I'm one of those bad things that happen to good people. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 18:27:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.is4b.net (peach.oaktree.net.uk [193.82.129.13]) by hub.freebsd.org (Postfix) with ESMTP id 34B5315005 for ; Sun, 11 Jul 1999 18:27:08 -0700 (PDT) (envelope-from jon@chalk.oaktree.net.uk) Received: from chalk.oaktree.net.uk (chalk.oaktree.net.uk [193.82.129.19]) by relay.is4b.net (Postfix) with ESMTP id B13BF1DC0E; Mon, 12 Jul 1999 02:24:24 +0100 (BST) Received: (from jon@localhost) by chalk.oaktree.net.uk (8.9.3/8.9.3) id CAA22848; Mon, 12 Jul 1999 02:24:24 +0100 (BST) Date: Mon, 12 Jul 1999 02:24:24 +0100 From: Jon Ribbens To: "Daniel C. Sobral" Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) Message-ID: <19990712022424.A1390@oaktree.co.uk> Mail-Followup-To: "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org References: <5laet8b2l8.fsf@assaris.sics.se> <5lemij265u.fsf@assaris.sics.se> <3788714D.4E666FFA@newsguy.com> <19990712002043.C7067@oaktree.co.uk> <3789373D.9B1811F3@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <3789373D.9B1811F3@newsguy.com>; from Daniel C. Sobral on Mon, Jul 12, 1999 at 09:30:53AM +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel C. Sobral" wrote: > > > OTOH, though, FreeBSD's malloc() is very unlikely to return an out > > > of memory error. > > > > Why is that? > > Because memory (as in *real* memory, either RAM or swap) is > allocated on-demand. So you can allocate any amount of virtual > memory that the system can possibly provide you, even though you'll > run out of memory much earlier, because other resources are also > consuming it. Yuck. That's a complete abomination. What's the point of it? It's turning an out-of-memory situation from an easily-detected recoverable temporary resource shortage which can be worked-around or waited out, into an unrecoverable fatal error. Do a significant number of programs really request memory which they then proceed not to use? > > What happens if the process hits its resource limits? > > If the system runs out of memory, the biggest process is killed. It > might or might not be the one demanding additional memory. No, if the *process* hits its *administrative* resource limits. i.e. setrlimit(2). Cheers Jon -- \/ Jon Ribbens / jon@oaktree.co.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 18:45:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 36AA014E3F; Sun, 11 Jul 1999 18:45:12 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id TAA13788; Sun, 11 Jul 1999 19:42:33 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id TAA39424; Sun, 11 Jul 1999 19:40:58 -0600 (MDT) Message-Id: <199907120140.TAA39424@harmony.village.org> To: "Brian F. Feldman" Subject: Re: a BSD identd Cc: Niall Smart , hackers@FreeBSD.org In-reply-to: Your message of "Sun, 11 Jul 1999 20:34:04 EDT." References: Date: Sun, 11 Jul 1999 19:40:58 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message "Brian F. Feldman" writes: : I have this fixed in my latest code (on freefall of course). I did not : use an original stat because that's pointless, as it adds another race : condition. The only downside to my approach is that if it's a symlink : to a dev, the dev can get opened/closed, and d_open/d_close be called. How does the original stat add a race condition. You stat the file, open it, then fstat it. If the two match you know you're good. If they don't, you can detect that something bad has happened.... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 18:47:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id BCF8214E3F for ; Sun, 11 Jul 1999 18:47:19 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id DAA32255; Mon, 12 Jul 1999 03:47:00 +0200 (CEST) (envelope-from des) To: Jon Ribbens Cc: "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <5laet8b2l8.fsf@assaris.sics.se> <5lemij265u.fsf@assaris.sics.se> <3788714D.4E666FFA@newsguy.com> <19990712002043.C7067@oaktree.co.uk> From: Dag-Erling Smorgrav Date: 12 Jul 1999 03:46:59 +0200 In-Reply-To: Jon Ribbens's message of "Mon, 12 Jul 1999 00:20:43 +0100" Message-ID: Lines: 17 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jon Ribbens writes: > "Daniel C. Sobral" wrote: > > OTOH, though, FreeBSD's malloc() is very unlikely to return an out > > of memory error. > Why is that? Because FreeBSD overcommits memory. You can allocate (almost) as much memory as you want regardless of how much RAM / swap you have. You won't run into trouble unless you actually try to use too much of it. > What happens if the process hits its resource limits? Malloc() fails with ENOMEM. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 19:18:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id C5FC014EE9 for ; Sun, 11 Jul 1999 19:18:14 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id UAA13974; Sun, 11 Jul 1999 20:18:14 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id UAA39562; Sun, 11 Jul 1999 20:16:39 -0600 (MDT) Message-Id: <199907120216.UAA39562@harmony.village.org> To: Bill Paul Subject: Re: PCCARD and Vpp voltage Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Fri, 09 Jul 1999 18:38:43 EDT." <199907092238.SAA07224@skynet.ctr.columbia.edu> References: <199907092238.SAA07224@skynet.ctr.columbia.edu> Date: Sun, 11 Jul 1999 20:16:39 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199907092238.SAA07224@skynet.ctr.columbia.edu> Bill Paul writes: : slt->pwr.vcc = 50; : slt->pwr.vpp = 0; to : slt->pwr.vcc = 50; : slt->pwr.vpp = 50; OK. I've read more of the MindShare book. I believe this is a good change because Vpp is supposed to be connected to Vcc (that is, the same as) when powered up, but can later be switched to a different voltage. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 19:22:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 1263514EE9 for ; Sun, 11 Jul 1999 19:22:10 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id UAA13981; Sun, 11 Jul 1999 20:19:15 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id UAA39592; Sun, 11 Jul 1999 20:17:40 -0600 (MDT) Message-Id: <199907120217.UAA39592@harmony.village.org> To: Jon Ribbens Subject: Re: Replacement for grep(1) (part 2) Cc: "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org In-reply-to: Your message of "Mon, 12 Jul 1999 02:24:24 BST." <19990712022424.A1390@oaktree.co.uk> References: <19990712022424.A1390@oaktree.co.uk> <5laet8b2l8.fsf@assaris.sics.se> <5lemij265u.fsf@assaris.sics.se> <3788714D.4E666FFA@newsguy.com> <19990712002043.C7067@oaktree.co.uk> <3789373D.9B1811F3@newsguy.com> Date: Sun, 11 Jul 1999 20:17:40 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19990712022424.A1390@oaktree.co.uk> Jon Ribbens writes: : No, if the *process* hits its *administrative* resource limits. : i.e. setrlimit(2). That should (and I believe does) make malloc fail. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 19:31:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from leap.innerx.net (leap.innerx.net [38.179.176.25]) by hub.freebsd.org (Postfix) with ESMTP id 64F5214FBF; Sun, 11 Jul 1999 19:31:21 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org (ip39.houston3.tx.pub-ip.psi.net [38.12.169.39]) by leap.innerx.net (Postfix) with ESMTP id 5F73237079; Sun, 11 Jul 1999 22:31:19 -0400 (EDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id VAA81869; Sun, 11 Jul 1999 21:29:47 -0500 (CDT) (envelope-from chris) Date: Sun, 11 Jul 1999 21:29:46 -0500 From: Chris Costello To: "Brian F. Feldman" Cc: Tim Vanderhoek , hackers@FreeBSD.org Subject: Re: rtfm rewritten in C Message-ID: <19990711212946.D71884@holly.dyndns.org> Reply-To: chris@calldei.com References: <19990711163723.C71884@holly.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: ; from Brian F. Feldman on Sun, Jul 11, 1999 at 05:43:21PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jul 11, 1999, Brian F. Feldman wrote: > > I can manage C code much better than I can manage Perl code > > and C is faster than Perl. > > Trying to start ANOTHER holy war? :) I meant that you don't have to compile/interpret/whatever-you-wanna-call-it with compiled C code as you do with Perl. Plus the first -- I'm terrible with keeping Perl code managed. -- Chris Costello To be, or not to be, those are the parameters. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 19:43:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 0D1CE15011 for ; Sun, 11 Jul 1999 19:43:33 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id WAA34022; Sun, 11 Jul 1999 22:43:36 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Sun, 11 Jul 1999 22:43:36 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Warner Losh Cc: Niall Smart , hackers@FreeBSD.org Subject: Re: a BSD identd In-Reply-To: <199907120140.TAA39424@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Jul 1999, Warner Losh wrote: > In message "Brian F. Feldman" writes: > : I have this fixed in my latest code (on freefall of course). I did not > : use an original stat because that's pointless, as it adds another race > : condition. The only downside to my approach is that if it's a symlink > : to a dev, the dev can get opened/closed, and d_open/d_close be called. > > How does the original stat add a race condition. You stat the file, > open it, then fstat it. If the two match you know you're good. If > they don't, you can detect that something bad has happened.... Ahh, I misunderstood you. In _this_ case you just proposed, the stat is really pointless. What good would it do? > > Warner > > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 19:48:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 81A5315011 for ; Sun, 11 Jul 1999 19:48:52 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id WAA34066; Sun, 11 Jul 1999 22:45:17 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Sun, 11 Jul 1999 22:45:17 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Chris Costello Cc: Tim Vanderhoek , hackers@FreeBSD.org Subject: Re: rtfm rewritten in C In-Reply-To: <19990711212946.D71884@holly.dyndns.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Jul 1999, Chris Costello wrote: > On Sun, Jul 11, 1999, Brian F. Feldman wrote: > > > I can manage C code much better than I can manage Perl code > > > and C is faster than Perl. > > > > Trying to start ANOTHER holy war? :) > > I meant that you don't have to compile/interpret/whatever-you-wanna-call-it > with compiled C code as you do with Perl. > > Plus the first -- I'm terrible with keeping Perl code managed. I agree. Perl, while more flexible, can be MUCH more of a mess. > > -- > Chris Costello > To be, or not to be, those are the parameters. > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 19:54:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id D6A1B14F2A for ; Sun, 11 Jul 1999 19:54:44 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id UAA14050; Sun, 11 Jul 1999 20:53:22 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id UAA39731; Sun, 11 Jul 1999 20:51:47 -0600 (MDT) Message-Id: <199907120251.UAA39731@harmony.village.org> To: Wes Peters Subject: Re: PCCARD and Vpp voltage Cc: Mark Murray , Bill Paul , hackers@FreeBSD.ORG In-reply-to: Your message of "Sun, 11 Jul 1999 20:40:58 MDT." <378955BA.B1F94075@softweyr.com> References: <378955BA.B1F94075@softweyr.com> <199907111119.NAA16211@gratis.grondar.za> <199907112234.QAA36877@harmony.village.org> Date: Sun, 11 Jul 1999 20:51:47 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <378955BA.B1F94075@softweyr.com> Wes Peters writes: : Didn't my message from yesterday make it to the list? On card insert, : you're supposed to read the voltage requirements for Vcc and apply *that* : voltage to Vcc, Vpp1, and Vpp2. If it did, I missed it... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 19:56:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id E9F5D14F2A; Sun, 11 Jul 1999 19:56:44 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id UAA14067; Sun, 11 Jul 1999 20:56:44 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id UAA39761; Sun, 11 Jul 1999 20:55:09 -0600 (MDT) Message-Id: <199907120255.UAA39761@harmony.village.org> To: "Brian F. Feldman" Subject: Re: a BSD identd Cc: hackers@FreeBSD.org In-reply-to: Your message of "Sun, 11 Jul 1999 22:43:36 EDT." References: Date: Sun, 11 Jul 1999 20:55:09 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message "Brian F. Feldman" writes: : Ahh, I misunderstood you. In _this_ case you just proposed, the stat is : really pointless. What good would it do? It would let you know if you should even try to open the file... But that doesn't solve the race. The fstat tells you if what you opened was what you thought you were opening... However, for this, the original stat might not be completely necessary unless you were trying to specifically detect someone trying to race you. You are right that it won't buy you anything. I was confusing this with the tree walking case. The stat + fstat check there was needed... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 20: 2:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 6B43714F2A; Sun, 11 Jul 1999 20:02:22 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id MAA03771; Mon, 12 Jul 1999 12:28:59 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id MAA28745; Mon, 12 Jul 1999 12:28:58 +0930 (CST) Date: Mon, 12 Jul 1999 12:28:58 +0930 From: Greg Lehey To: Anthony Wyatt Cc: FreeBSD Hackers Subject: Re: Kernel Drivers Message-ID: <19990712122858.A21403@freebie.lemis.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Wyatt, Anthony on Mon, Jul 12, 1999 at 12:44:18PM +1000 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [redirecting to -hackers] On Monday, 12 July 1999 at 12:44:18 +1000, Anthony Wyatt wrote: > Hi, > I really don't know where to post this message, so if there is a better > place please let me know. Well, to quote the frequent posting to this newsgroup, If the question is of a general nature, ... ask FreeBSD-questions. Examples might be questions about installing FreeBSD or the use of a particular UNIX utility. If the question relates to enhancements to FreeBSD, and you can make suggestions about how to implement them, then send the message to FreeBSD-hackers. If the question is of particularly technical nature, such as implementation details or suggestions for improvements, then send the message to FreeBSD-hackers. I think this qualifies as one of the last two, so -hackers is the place. > I want to write a driver for my video card, not for X, for my own home > grown app :-) > > I've just read Chap 5 of the Magic Garden Explained (SysVR4 Internals) so > I have some idea whats expected when writing a device driver. As you say, the Magic Garden is for System V. BSD is a little different, though not too much. > I've also read the technical programming doco for my video card. > The big hole in my plan is PCI. I don't know how to talk to my > video card on the PCI bus :-( > > So I guess my questions are: > Should I try and find out more about basic driver programming, > specifically freeBSD, Yes. > and if so where? UTSL. And -hackers. There's some stuff in section 9 of the manual, but it's not quite the level of completeness you'd find in the ddi/ddk docco. > Where can I find out about programming PCI devices? UTSL. And -hackers. In particular, the PCI drivers are in /usr/src/sys/pci. Greg -- When replying to this message, please copy the original recipients. For more information, see http://www.lemis.com/questions.html See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 20: 2:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from leap.innerx.net (leap.innerx.net [38.179.176.25]) by hub.freebsd.org (Postfix) with ESMTP id 3E24F151E1 for ; Sun, 11 Jul 1999 20:02:46 -0700 (PDT) (envelope-from chris@holly.dyndns.org) Received: from holly.dyndns.org (ip39.houston3.tx.pub-ip.psi.net [38.12.169.39]) by leap.innerx.net (Postfix) with ESMTP id CC17537081 for ; Sun, 11 Jul 1999 23:01:35 -0400 (EDT) Received: (from chris@localhost) by holly.dyndns.org (8.9.3/8.9.3) id WAA82113 for hackers@FreeBSD.ORG; Sun, 11 Jul 1999 22:00:05 -0500 (CDT) (envelope-from chris) Date: Sun, 11 Jul 1999 22:00:04 -0500 From: Chris Costello To: hackers@FreeBSD.ORG Subject: Re: rtfm rewritten in C (updated) Message-ID: <19990711220003.E71884@holly.dyndns.org> Reply-To: chris@calldei.com References: <19990710234538.G57198@holly.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.3i In-Reply-To: <19990710234538.G57198@holly.dyndns.org>; from Chris Costello on Sat, Jul 10, 1999 at 11:45:39PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've implemented a few new features. First off, strdup() isn't abused anymore so the program should run much smoother and smaller, as well as more quickly. Secondly, I have (thanks in part to Alfred Perlstein) added both case-insensitive searches (-i) and local FAQ search (can be overridden with -o, "online", flag). Too many others to enumerate. As usual, it's at http://www.calldei.com/~chris/rtfm.tar.gz -- Chris Costello A computer program does what you tell it to do, not what you want it to do. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 20:17:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id DD7DC150A3 for ; Sun, 11 Jul 1999 20:17:30 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (monica.cs.rpi.edu [128.213.7.2]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id XAA74152; Sun, 11 Jul 1999 23:14:15 -0400 (EDT) Message-Id: <199907120314.XAA74152@cs.rpi.edu> To: Greg Lehey Cc: Anthony Wyatt , FreeBSD Hackers , crossd@cs.rpi.edu Subject: Re: Kernel Drivers In-Reply-To: Message from Greg Lehey of "Mon, 12 Jul 1999 12:28:58 +0930." <19990712122858.A21403@freebie.lemis.com> Date: Sun, 11 Jul 1999 23:14:14 -0400 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hmm... perhaps if Anthony is willing we can use his experience to help us further document the procedure for writing a FreeBSD PCI device driver? -- David Cross | email: crossd@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 20:31: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id AED68151D2; Sun, 11 Jul 1999 20:30:51 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id NAA03931; Mon, 12 Jul 1999 13:00:49 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id NAA28884; Mon, 12 Jul 1999 13:00:49 +0930 (CST) Date: Mon, 12 Jul 1999 13:00:49 +0930 From: Greg Lehey To: Andrew Willis Cc: FreeBSD Questions Subject: Re: Raid software Message-ID: <19990712130049.C21403@freebie.lemis.com> References: <00c601becbe7$888787e0$9864a8c0@cwgis6.inetfast.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <00c601becbe7$888787e0$9864a8c0@cwgis6.inetfast.com>; from Andrew Willis on Sun, Jul 11, 1999 at 05:49:13PM -0400 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [moving to -questions; this isn't a technical discussion] On Sunday, 11 July 1999 at 17:49:13 -0400, Andrew Willis wrote: > What Raid software is available for FreeBSD? I cant seem to find much > information on this issue. I would rather not dish out lots of $$$ for > hardware Raid. Any > suggestions would be appreciated.. Look at Vinum (http://www.lemis.com/vinum.html). Greg -- When replying to this message, please copy the original recipients. For more information, see http://www.lemis.com/questions.html See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 20:35: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hermes.la.csiro.au (hermes.la.csiro.au [152.83.12.2]) by hub.freebsd.org (Postfix) with ESMTP id 158EA14CFC for ; Sun, 11 Jul 1999 20:35:01 -0700 (PDT) (envelope-from Anthony.Wyatt@its.csiro.au) Received: by hermes.la.csiro.au with Internet Mail Service (5.5.2448.0) id ; Mon, 12 Jul 1999 13:31:59 +1000 Message-ID: From: "Wyatt, Anthony" To: "'David E. Cross'" Cc: "'freebsd-hackers@freebsd.org'" Subject: RE: Kernel Drivers Date: Mon, 12 Jul 1999 13:31:59 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > -----Original Message----- > From: David E. Cross [mailto:crossd@cs.rpi.edu] > Sent: Monday, July 12, 1999 1:14 PM > To: Greg Lehey > Cc: Anthony Wyatt; FreeBSD Hackers; crossd@cs.rpi.edu > Subject: Re: Kernel Drivers > > Hmm... perhaps if Anthony is willing we can use his > experience to help us > further document the procedure for writing a FreeBSD PCI > device driver? If everything goes to plan and works I'd be glad to write some doco about what I did. After I finish with my PCI video card I intend to try and write an AGP driver too. This would probably be easiest if you told me where I can find all the existing device driver and PCI programming doco, and any other relevent doco, so as to avoid re-inventing the wheel. Then it will probably be a wait and see if I can figure out what I need to do :-) Anthony To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jul 11 22: 9:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 3920214BF8 for ; Sun, 11 Jul 1999 22:09:35 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id XAA14829; Sun, 11 Jul 1999 23:09:37 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id XAA40748; Sun, 11 Jul 1999 23:08:04 -0600 (MDT) Message-Id: <199907120508.XAA40748@harmony.village.org> To: Wes Peters Subject: Re: PCCARD and Vpp voltage Cc: Mark Murray , Bill Paul , hackers@FreeBSD.ORG In-reply-to: Your message of "Sun, 11 Jul 1999 23:00:05 MDT." <37897655.133AC329@softweyr.com> References: <37897655.133AC329@softweyr.com> <378955BA.B1F94075@softweyr.com> <199907111119.NAA16211@gratis.grondar.za> <199907112234.QAA36877@harmony.village.org> <199907120251.UAA39731@harmony.village.org> Date: Sun, 11 Jul 1999 23:08:04 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <37897655.133AC329@softweyr.com> Wes Peters writes: : >From this, I'd say the card inserted event should read the Vcc wanted : value (from the Socket Present State Register?) and apply THAT voltage : to Vcc, Vpp1, and Vpp2, rather than just applying 5.0 volts. You might : seriously damage any 3.3v card inserted by applying 5v to it. Agreed on GPs. I don't think any laptops today have the low voltage slot, but instead have the unified slot. I believe that I saw in there that cards needed to be able to handle 5V as well, but in the world of PC Cards it is much better to be safe than sorry.... For the moment, the 0 -> 50 change is good, but longer term we may need to do the 3.3V stuff correctly. BTW, does anybody know where I can get a type II CF slot to Type II PC Card card adapter? This is so I can plug a pc card into a CF slot (I have one that does the other way round, but want to compare the price of the adapter with the price of a ne2000 CF ethernet card I'm looking at ($130)). : This is a pretty good book, by the way. ISBN 0-201-40997-6. Agreed. That's where I got my ideas about PCCARD as well, since the promised standard hasn't appeared on my doorstep yet. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 0:49:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.go2france.com (go2france.com [209.51.193.70]) by hub.freebsd.org (Postfix) with SMTP id D9DE614C98 for ; Mon, 12 Jul 1999 00:49:56 -0700 (PDT) (envelope-from lconrad@Go2France.com) Received: from superviseur [62.161.63.210] by mail.go2france.com with ESMTP (SMTPD32-4.03) id A9463D901B0; Mon, 12 Jul 1999 02:20:54 EDT Message-Id: <4.2.0.56.19990712093020.01a90430@go2france.com> X-Sender: lconrad@go2france.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.56 (Beta) Date: Mon, 12 Jul 1999 09:45:39 +0200 To: freebsd-hackers@freebsd.org From: Len Conrad Subject: Lyris imminent In-Reply-To: <000701bec850$311d3850$90e25ec3@agama.ru> References: <199907061659.JAA15453@vashon.polstra.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I asked support@lyris.com about Lyris on FreeBSD (the Linux version is in beta), saying I had heard that fbsd was more stable for heavy lifing. The response, to remain anonymous although I don't think my Deep Throat would mind being outed: We are using FreeBSD internally for Lyris development, and have been for about 6 months. We hope to release Lyris for FreeBSD in beta in the next few weeks. Yes, we find that freeBSD is more stable, and also faster than Linux. Always comforting to prospects and lurkers to see high quality, commercial grade, top ranking packages being ported to FreeBSD. The above comment from someone so well placed in multi-platform development is golden. Great hacking, people! Len < oh, how I wish Allaire would bring Cold Fusion to FreeBSD! ( CF/Linux port is announced ) > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 0:57:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 9712C1520F for ; Mon, 12 Jul 1999 00:57:41 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 113axq-000Doq-00; Mon, 12 Jul 1999 09:57:26 +0200 From: Sheldon Hearn To: Mark Murray Cc: Doug , hackers@FreeBSD.ORG Subject: Re: a BSD identd In-reply-to: Your message of "Sun, 11 Jul 1999 22:34:09 +0200." <199907112034.WAA17651@gratis.grondar.za> Date: Mon, 12 Jul 1999 09:57:26 +0200 Message-ID: <53123.931766246@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Jul 1999 22:34:09 +0200, Mark Murray wrote: > As long as the documentation is _clear_ that this is not a front-line > security tool, but rather a thing to marginally augment logs with > user-supplied info, then I'll buy it. This is why I put forward a motion to move pidentd out of security and into net / sysutils last year. The suggestion wasn't well received, but I still think it'd help. I'd also like for the DESCR file for the port to say: "This service offers remote users some identity to report back to the local admin when complaining about abuse / break-ins originating from the local host." Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 1: 2: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 1C3BA14C98 for ; Mon, 12 Jul 1999 01:02:06 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id RAA02273; Mon, 12 Jul 1999 17:00:07 +0900 (JST) Message-ID: <37899FA7.4DC4E088@newsguy.com> Date: Mon, 12 Jul 1999 16:56:23 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Jon Ribbens Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <5laet8b2l8.fsf@assaris.sics.se> <5lemij265u.fsf@assaris.sics.se> <3788714D.4E666FFA@newsguy.com> <19990712002043.C7067@oaktree.co.uk> <3789373D.9B1811F3@newsguy.com> <19990712022424.A1390@oaktree.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jon Ribbens wrote: > > Yuck. That's a complete abomination. What's the point of it? It's turning > an out-of-memory situation from an easily-detected recoverable temporary > resource shortage which can be worked-around or waited out, into an > unrecoverable fatal error. Do a significant number of programs really > request memory which they then proceed not to use? That's *not* abomination. How about pre-allocating over 100 Mb for X Free, for instance? Basically, if you don't have enough memory, you just don't have enough memory. What FreeBSD does *reduces* the need for memory. If FreeBSD *did not* do it, then you'd need much more memory. > > If the system runs out of memory, the biggest process is killed. It > > might or might not be the one demanding additional memory. > > No, if the *process* hits its *administrative* resource limits. > i.e. setrlimit(2). Ah, that's another matter entirely. Then, malloc() returns an error indeed. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org I'm one of those bad things that happen to good people. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 1: 3:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 8613614C98 for ; Mon, 12 Jul 1999 01:03:24 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 113b2x-000Dtj-00; Mon, 12 Jul 1999 10:02:43 +0200 From: Sheldon Hearn To: Doug Cc: John Polstra , imp@village.org, hackers@freebsd.org Subject: Re: a BSD identd In-reply-to: Your message of "Sun, 11 Jul 1999 12:47:30 MST." <3788F4D2.17CBD8C7@gorean.org> Date: Mon, 12 Jul 1999 10:02:43 +0200 Message-ID: <53426.931766563@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Jul 1999 12:47:30 MST, Doug wrote: > Finally, Brian might want to search the bugtraq archives before > he commits anything. There have been quite a few identd related > discussions, and it would be points in our favor if we didn't come out > with anything that had known exploits. I like this suggestion. I worry about a trend I'm seeing, with more and more people keen to replace existing code with their own virgin code which hasn't had any serious field time behind it. This seems like a very Linuxy development trend. It's the way the Bazaar works, but not in a Cathedral. Rather, you have a look at what's already there and try to work on it. You don't start your own wing a few feet from the Cathedral in the hopes that someone will bash down a similar wing elsewhere and join yours to the main building. Waffle waffle. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 1: 8:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 55848152D0 for ; Mon, 12 Jul 1999 01:08:10 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 113b7j-000DzE-00; Mon, 12 Jul 1999 10:07:39 +0200 From: Sheldon Hearn To: chris@calldei.com Cc: hackers@FreeBSD.ORG Subject: Re: rtfm rewritten in C (updated) In-reply-to: Your message of "Sun, 11 Jul 1999 22:00:04 EST." <19990711220003.E71884@holly.dyndns.org> Date: Mon, 12 Jul 1999 10:07:39 +0200 Message-ID: <53767.931766859@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Jul 1999 22:00:04 EST, Chris Costello wrote: > As usual, it's at http://www.calldei.com/~chris/rtfm.tar.gz Can I suggest that you make a port of your little project so that you don't have to announce updates to hackers every few days? Those who're interested will see CVS commit messages for your port. I'd suggest category misc. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 2:34:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.palmerharvey.co.uk (mail.palmerharvey.co.uk [62.172.109.58]) by hub.freebsd.org (Postfix) with ESMTP id A89D914C18 for ; Mon, 12 Jul 1999 02:33:57 -0700 (PDT) (envelope-from Dom.Mitchell@palmerharvey.co.uk) Received: from ho-nt-01.pandhm.co.uk (unverified) by mail.palmerharvey.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Mon, 12 Jul 1999 10:33:29 +0100 Received: from voodoo.pandhm.co.uk (VOODOO [10.100.35.12]) by ho-nt-01.pandhm.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 3WRWCX2R; Mon, 12 Jul 1999 10:34:18 +0100 Received: from dom by voodoo.pandhm.co.uk with local (Exim 2.10 #1) id 113cT6-000Brt-00 for hackers@freebsd.org; Mon, 12 Jul 1999 10:33:48 +0100 Date: Mon, 12 Jul 1999 10:33:48 +0100 To: hackers@freebsd.org Subject: KLD documentation Message-Id: <19990712103348.A45199@palmerharvey.co.uk> MIME-Version: 1.0 X-Mailer: Mutt 0.95.6i From: Dominic Mitchell Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Some hacking group has written an introduction to using KLDs under FreeBSD. It's not supposed to be a "normal" tutorial, but it may be appreciated by a few people on this list. http://thc.pimmel.com/files/thc/bsdkern.html -- Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ********************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 2:51:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mauibuilt.com (mauibuilt.com [205.166.249.50]) by hub.freebsd.org (Postfix) with ESMTP id 47A7814C98; Mon, 12 Jul 1999 02:51:44 -0700 (PDT) (envelope-from puga@mauibuilt.com) Received: from mauibuilt.com (puga.mauibuilt.com [205.166.10.2]) by mauibuilt.com (8.8.8/8.8.7) with ESMTP id XAA06391; Sun, 11 Jul 1999 23:54:42 -1000 (HST) (envelope-from puga@mauibuilt.com) Message-ID: <378981EA.5CC31B1C@mauibuilt.com> Date: Sun, 11 Jul 1999 19:49:30 -1000 From: Richard Puga X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org Subject: WaveLAN problem Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a WaveLAN ISA adaptor. I am trying to run it in a machine equiped with an AMD K6-2 350 processor running at 66mhz bus speed. I am getting the following error while ifconfiging the card. ifconfig wl0 192.168.10.1 ifconfig: ioctl (SIOCAIFADDR): File exists cray100 /root 2% Jul 12 03:43:23 cray100 /kernel: wl0: diag() failed; status = 0, inw = 0, outw = e0a0 Jul 12 03:43:23 cray100 /kernel: wl0: diag() failed; status = 0, inw = 0, outw = e0a0 Jul 12 03:43:23 cray100 /kernel: scb_status a000 Jul 12 03:43:23 cray100 /kernel: scb_status a000 Jul 12 03:43:23 cray100 /kernel: scb_command 0 Jul 12 03:43:23 cray100 /kernel: scb_command 0 Jul 12 03:43:23 cray100 /kernel: scb_cbl ffc0 Jul 12 03:43:23 cray100 /kernel: scb_cbl ffc0 Jul 12 03:43:23 cray100 /kernel: cu_cmd 8007 Jul 12 03:43:23 cray100 /kernel: cu_cmd 8007 Jul 12 03:43:23 cray100 /kernel: wl0 init(): trouble resetting board. Jul 12 03:43:23 cray100 /kernel: wl0 init(): trouble resetting board. I belive the issure is some kind of timeing problem because the dos drivers and ptpdiag work and the card works with freebsd in other machines. I have tried about everything I can think of I have set machdep.wl_xmit_delay: up and down as well as played with clock speeds of the CPU and motherboard as well as bios wait states, pnp settings ect. and differant wavelan cards. I even reset the factory setting off 0x300 irq 10 to other ones just to be sure.. I have tried the drivers in 3.0 3.1 and 4.0 current they all do the same thing.. thease are the current dmesg settings wl0 at 0x390-0x39f irq 5 on isa wl0: address 08:00:6a:2b:e3:30, NWID 0x5262, Freq 2422 MHz and the wlconfig info... cray100 /root 6% wlconfig wl0 Board type : ISA Base address options : 0x300, 0x390, 0x3c0, 0x3e0 Waitstates : 0 Bus mode : ISA IRQ : 5 Default MAC address : 08:00:6a:2b:e3:30 Soft MAC address : 00:00:00:00:00:00 Current MAC address : Default Adapter compatability : PCCARD or 1/2 size AT, 915MHz or 2.4GHz Threshold preset : 1 Call code required : NO Subband : 915MHz/see WaveModem Quality threshold : 3 Hardware version : 1 (Rel3) Network ID enable : YES NWID : 0x5262 Datalink security : NO Databus width : 16 (variable) Configuration state : unconfigured CRC-16 : 0xaba1 CRC status : OK If anyone can help in any way or point me to someone who might I would greatly apreciate it. Thanks in advance Richard Puga puga@mauibuilt.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 3:18:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 1DA6514C14 for ; Mon, 12 Jul 1999 03:18:54 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id DAA01340; Mon, 12 Jul 1999 03:18:05 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Jon Ribbens Cc: "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) In-reply-to: Your message of "Mon, 12 Jul 1999 02:24:24 BST." <19990712022424.A1390@oaktree.co.uk> Date: Mon, 12 Jul 1999 03:18:04 -0700 Message-ID: <1336.931774684@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Yuck. That's a complete abomination. What's the point of it? It's turning Paging Terry Lambert, Terry Lambert - do you read me? It's time for your annual rant on the topic of memory overcommit. :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 4:29:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from brockman.tinet.ie (brockman.tinet.ie [159.134.237.30]) by hub.freebsd.org (Postfix) with ESMTP id 2570814E16 for ; Mon, 12 Jul 1999 04:29:51 -0700 (PDT) (envelope-from crypt0genic@tinet.ie) Received: from p116.as1.cork1.tinet.ie ([159.134.228.116] helo=tweak.home) by brockman.tinet.ie with esmtp (Exim 2.05 #23) id 113eHN-0007GJ-00 for hackers@freebsd.org; Mon, 12 Jul 1999 12:29:50 +0100 Received: (from crypt0genic@localhost) by tweak.home (8.9.3/8.9.3) id MAA02279 for hackers@freebsd.org; Mon, 12 Jul 1999 12:28:13 GMT Date: Mon, 12 Jul 1999 12:28:03 +0000 From: crypt0genic To: hackers@freebsd.org Subject: (forw) Message-ID: <19990712122803.A1832@ecad.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=r5Pyd7+fXNt84Ff3 X-Mailer: Mutt 0.95.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Have you all seen this? -- Reverse engineering, the most phun and usually the most effective way to tackle a problem or learn something new. Public PGP key: http://www.ecad.org/crypt0genic_pgp_key Website: http://www.ecad.org/ --r5Pyd7+fXNt84Ff3 Content-Type: message/rfc822 Received: from localhost (localhost [127.0.0.1]) by tweak.home (8.9.3/8.9.3) with ESMTP id KAA01869 for ; Mon, 12 Jul 1999 10:02:34 +0100 (IST) Envelope-to: zip@tinet.ie Delivery-date: Mon, 12 Jul 1999 07:01:58 +0100 Received: from mail.tinet.ie by localhost with POP3 (fetchmail-5.0.3) for crypt0genic@localhost (single-drop); Mon, 12 Jul 1999 09:02:34 +0000 (GMT) Received: from amulon.lightrealm.com ([216.122.36.164] helo=ecad.org) by brockman.tinet.ie with esmtp (Exim 2.05 #23) id 113ZA6-0006bl-00 for zip@tinet.ie; Mon, 12 Jul 1999 07:01:58 +0100 Received: from lists.securityfocus.com (lists.securityfocus.com [216.102.46.4]) by ecad.org (8.8.7/8.8.5) with SMTP id XAA20300 for ; Sun, 11 Jul 1999 23:01:45 -0700 (PDT) Received: (qmail 11643 invoked from network); 12 Jul 1999 05:45:07 -0000 Received: from lists.securityfocus.com (216.102.46.4) by lists.securityfocus.com with SMTP; 12 Jul 1999 05:45:07 -0000 Received: from LISTS.SECURITYFOCUS.COM by LISTS.SECURITYFOCUS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 60120 for BUGTRAQ@LISTS.SECURITYFOCUS.COM; Sun, 11 Jul 1999 22:44:09 -0700 Approved-By: aleph1@SECURITYFOCUS.COM Received: from securityfocus.com (216.102.46.2) by lists.securityfocus.com with SMTP; 9 Jul 1999 21:22:57 -0000 Received: (qmail 41171 invoked by alias); 9 Jul 1999 21:22:57 -0000 Delivered-To: BUGTRAQ@securityfocus.com Received: (qmail 41168 invoked from network); 9 Jul 1999 21:22:56 -0000 Received: from basement.replay.com (HELO mail.replay.com) (194.109.9.44) by securityfocus.com with SMTP; 9 Jul 1999 21:22:56 -0000 Received: (from remailer@localhost) by mail.replay.com (8.9.2/8.9.2) id XAA16197; Fri, 9 Jul 1999 23:22:21 +0200 (CEST) Message-ID: <199907092122.XAA16197@mail.replay.com> Date: Fri, 9 Jul 1999 23:22:21 +0200 Reply-To: Anonymous Sender: Bugtraq List Comments: This message did not originate from the Sender address above. It was remailed automatically by anonymizing remailer software. Please report problems or inappropriate use to the remailer administrator at . From: Anonymous X-To: BUGTRAQ@securityfocus.com To: BUGTRAQ@SECURITYFOCUS.COM Hi folks, THC released a new article dealing with FreeBSD 3.x Kernel modules that can attack/backdoor the system. You can find our article on http://thc.pimmel.com or http://r3wt.base.org. Greets, pragmatic / The Hacker's Choice --r5Pyd7+fXNt84Ff3-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 4:40:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (Postfix) with ESMTP id 7F79814DE3 for ; Mon, 12 Jul 1999 04:40:14 -0700 (PDT) (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca-tx.tdx.co.uk [195.188.177.242]) by caladan.tdx.co.uk (8.9.3/8.9.3/Kp) with ESMTP id MAA80386; Mon, 12 Jul 1999 12:37:03 +0100 (BST) Message-ID: <3789D346.5682D28A@tdx.co.uk> Date: Mon, 12 Jul 1999 12:36:38 +0100 From: Karl Pielorz Organization: TDX - The Digital eXchange X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: crypt0genic Cc: hackers@FreeBSD.ORG Subject: Re: (forw) References: <19990712122803.A1832@ecad.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Yes, a nice, effective - and simply way of replacing syscall's on FreeBSD... Some might say a little too 'simple'? -Kp crypt0genic wrote: > > Have you all seen this? > > From: Anonymous > To: BUGTRAQ@SECURITYFOCUS.COM > > Hi folks, > > THC released a new article dealing with FreeBSD 3.x > Kernel modules that can attack/backdoor the > system. > You can find our article on http://thc.pimmel.com or > http://r3wt.base.org. > > Greets, pragmatic / The Hacker's Choice To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 4:52:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gizmo.internode.com.au (gizmo.internode.com.au [192.83.231.115]) by hub.freebsd.org (Postfix) with ESMTP id 5A30D14E2C for ; Mon, 12 Jul 1999 04:52:17 -0700 (PDT) (envelope-from newton@gizmo.internode.com.au) Received: (from newton@localhost) by gizmo.internode.com.au (8.9.3/8.9.3) id VAA22311; Mon, 12 Jul 1999 21:19:45 +0930 (CST) (envelope-from newton) From: Mark Newton Message-Id: <199907121149.VAA22311@gizmo.internode.com.au> Subject: Re: (forw) To: kpielorz@tdx.co.uk (Karl Pielorz) Date: Mon, 12 Jul 1999 21:19:45 +0930 (CST) Cc: crypt0genic@ecad.org, hackers@FreeBSD.ORG In-Reply-To: <3789D346.5682D28A@tdx.co.uk> from "Karl Pielorz" at Jul 12, 99 12:36:38 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-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Karl Pielorz wrote: > Yes, a nice, effective - and simply way of replacing syscall's on FreeBSD... > Some might say a little too 'simple'? Garbage. You can do this on any OS, whether it supports loadable modules or not, if you've managed to win sufficient privileges through some other means. FreeBSD (and other OSs with loadable module support) merely provides a well-defined API which, like almost every other well- defined API, can be abused by those who harbor ill-will. Making the interface "complicated" does absolutely nothing to stop script-kiddies: Once a complicated interface is in an exploit script, who cares how arcane it is? - mark ---- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 5:59:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (Postfix) with ESMTP id 7CB2414D44 for ; Mon, 12 Jul 1999 05:59:16 -0700 (PDT) (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca-tx.tdx.co.uk [195.188.177.242]) by caladan.tdx.co.uk (8.9.3/8.9.3/Kp) with ESMTP id NAA88548; Mon, 12 Jul 1999 13:56:24 +0100 (BST) Message-ID: <3789E5DE.8D318608@tdx.co.uk> Date: Mon, 12 Jul 1999 13:55:58 +0100 From: Karl Pielorz Organization: TDX - The Digital eXchange X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Mark Newton Cc: crypt0genic@ecad.org, hackers@FreeBSD.ORG Subject: Re: (forw) References: <199907121149.VAA22311@gizmo.internode.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark Newton wrote: > > Karl Pielorz wrote: > > > Yes, a nice, effective - and simply way of replacing syscall's on FreeBSD... > > Some might say a little too 'simple'? > > Garbage. You can do this on any OS, whether it supports loadable > modules or not, if you've managed to win sufficient privileges through > some other means. I was actually leaning towards that... My boss had kittens here (we have 12 FreeBSD boxes running the show now), until I'd explained it to him... If syscall's need to be replaced, they need to be replaced - and if they are replaceable ... (I'll stop there) :) The article (from what I can remember) didn't actually go out of it's way to say you have to have be root to load the modules in the first place :) - Maybe it's warrants some kind of response page putting up somewhere? - this is also getting off topic for -hackers :(... -Kp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 7:14:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (Postfix) with ESMTP id 8AA7014D73 for ; Mon, 12 Jul 1999 07:14:26 -0700 (PDT) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg (bragg [129.127.36.34]) by adelphi.physics.adelaide.edu.au (8.8.8/8.8.8/UofA-1.5) with SMTP id XAA31110 for ; Mon, 12 Jul 1999 23:44:09 +0930 (CST) Received: from localhost by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA31957; Mon, 12 Jul 1999 23:44:07 +0930 Date: Mon, 12 Jul 1999 23:44:06 +0930 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: hackers@freebsd.org Subject: misc/3237 (adding SCRIPTS to bsd.prog.mk) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Does anyone feel strongly about the small patch in misc/3237 to add support for handling installation of script files in bsd.prog.mk? I can certainly see how this could be useful. Kris ----- "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 7:49:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from thelab.hub.org (nat206.255.mpoweredpc.net [142.177.206.255]) by hub.freebsd.org (Postfix) with ESMTP id 94FF414BF1 for ; Mon, 12 Jul 1999 07:49:30 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.1) with ESMTP id LAA13006; Mon, 12 Jul 1999 11:50:33 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Mon, 12 Jul 1999 11:50:33 -0300 (ADT) From: The Hermit Hacker To: freebsd-hackers@freebsd.org Cc: wraith@hub.org Subject: Keyboard mappings ... Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1730074198-931791033=:66634" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1730074198-931791033=:66634 Content-Type: TEXT/PLAIN; charset=US-ASCII Morning... Last week, at work, I talked one of the guys in IS into switching from using Win98 to using FreeBSD 3.2/X, and all has gone well so far, except that we've hit a snag that I'm not sure how to rectify... Under Win98, they use CRT, with a special set of keyboard map'ngs for the applications they are using on the Unix side of things, locally named 'vt221', which allows them to use the upper function keys. Attached is the output of 'tconv -b vt221' on our Solaris machine where this map'ng is required, but the output doesn't look anything like /etc/termcap :( How can I get the same capabilities into an xterm session for him as he has through CRT/Win98? Thanks... Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org --0-1730074198-931791033=:66634 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="vt221.out" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="vt221.out" dnQyMjF8IEFjYWRpYSdzIGh5YnJpZCBvZiB2dDEwMCBhbmQgdnQyMjAsDQoJ YW0sIHhlbmwsIG1pciwgbXNnciwgeG9uLCBjb2xzIzgwLCBpdCM4LCBsaW5l cyMyNCwgdnQjMywNCglhY3NjPWBgYWFmZmdnampra2xsbW1ubm9vcHBxcXJy c3N0dHV1dnZ3d3h4eXl6ent7fHx9fX5+LCBiZWw9XkcsDQoJY3I9XHIsIGNz cj1eW1slaSVwMSVkOyVwMiVkciwgdGJjPV5bWzNnLCBjbGVhcj1eW1tIXltb SiwgZWwxPV5bWzFLLA0KCWVsPV5bW0ssIGVkPV5bW0osIGN1cD1eW1slaSVw MSVkOyVwMiVkSCwgY3VkMT1cbiwgaG9tZT1eW1tILA0KCWN1YjE9XGIsIGN1 ZjE9XltbQywgY3V1MT1eW1tBLCBlbmFjcz1eWyhCXlspMCwgc21hY3M9Xk4s DQoJYmxpbms9XltbNW0sIGJvbGQ9XltbMW0sIHJldj1eW1s3bSwgc21zbz1e W1sxOzdtLCBzbXVsPV5bWzRtLA0KCXJtYWNzPV5PLCBzZ3IwPV5bW21eTywg cm1zbz1eW1ttLCBybXVsPV5bW20sIGthMT1eW09xLCBrYTM9XltPcywNCglr YjI9XltPciwga2JzPVxiLCBrY2J0PV5bW1osIGtjMT1eW09wLCBrYzM9XltP biwga2RjaDE9XltbUCwNCglrY3VkMT1eW09CLCBrZW50PV5bT00sIGtlbD1e W1tLLCBrZjA9XltPeSwga2YxPV5bT1AsIGtmMTA9XltbMjF+LA0KCWtmMTE9 XltbMjN+LCBrZjEyPV5bWzI0fiwga2YxMz1eW1syNX4sIGtmMTQ9XltbMjZ+ LCBrZjE1PV5bWzI3fiwNCglrZjE2PV5bWzMwfiwga2YxNz1eW1szMX4sIGtm MTg9XltbMzJ+LCBrZjE5PV5bWzMzfiwga2YyPV5bT1EsDQoJa2YyMD1eW1sz NH4sIGtmMjE9XltbMzV+LCBrZjIyPV5bWzM2fiwga2YyMz1eW1szN34sIGtm MjQ9XltbMzh+LA0KCWtmMjU9XltbMzl+LCBrZjI2PV5bWzQwfiwga2YyNz1e W1s0MX4sIGtmMjg9XltbNDJ+LCBrZjM9XltPUiwNCglrZjQ9XltPUywga2Y1 PV5bWzE2fiwga2Y2PV5bWzE3fiwga2Y3PV5bWzE4fiwga2Y4PV5bWzE5fiwN CglrZjk9XltbMjB+LCBrZm5kPV5bWzF+LCBraGxwPV5bWzI4fiwga2hvbWU9 XltbSCwga2ljaDE9XltbMn4sDQoJa2N1YjE9XltPRCwga25wPV5bWzZ+LCBr cHA9XltbNX4sIGtyZG89XltbMjl+LCBrY3VmMT1eW09DLA0KCWtzbHQ9Xltb NH4sIGtjdXUxPV5bT0EsIHJta3g9XltbPzFsXls+LCBzbWt4PV5bWz8xaF5b PSwNCgljdWQ9XltbJXAxJWRCLCBjdWI9XltbJXAxJWRELCBjdWY9XltbJXAx JWRDLCBjdXU9XltbJXAxJWRBLA0KCXJzMj1eWz5eW1s/M2xeW1s/NGxeW1s/ NWxeW1s/N2heW1s/OGgsIHJjPV5bOCwgc2M9Xls3LCBpbmQ9XG4sDQoJcmk9 XltNLA0KCXNncj1eW1swJT8lcDElcDYlfCV0OzElOyU/JXAyJXQ7NCU7JT8l cDElcDMlfCV0OzclOyU/JXA0JXQ7NSU7bSU/JXA5JXReTiVlXk8lOywNCglo dHM9XltILCBodD1cdCwNCg== --0-1730074198-931791033=:66634-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 8: 0:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.palmerharvey.co.uk (mail.palmerharvey.co.uk [62.172.109.58]) by hub.freebsd.org (Postfix) with ESMTP id D4F2114BF8 for ; Mon, 12 Jul 1999 08:00:22 -0700 (PDT) (envelope-from Dom.Mitchell@palmerharvey.co.uk) Received: from ho-nt-01.pandhm.co.uk (unverified) by mail.palmerharvey.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Mon, 12 Jul 1999 15:57:43 +0100 Received: from voodoo.pandhm.co.uk (VOODOO [10.100.35.12]) by ho-nt-01.pandhm.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 3WRWCX42; Mon, 12 Jul 1999 15:58:32 +0100 Received: from dom by voodoo.pandhm.co.uk with local (Exim 2.10 #1) id 113hWt-000CsI-00; Mon, 12 Jul 1999 15:58:03 +0100 Date: Mon, 12 Jul 1999 15:58:03 +0100 To: The Hermit Hacker Cc: freebsd-hackers@freebsd.org, wraith@hub.org Subject: Re: Keyboard mappings ... Message-Id: <19990712155802.E49177@palmerharvey.co.uk> References: MIME-Version: 1.0 X-Mailer: Mutt 0.95.6i In-Reply-To: ; from The Hermit Hacker on Mon, Jul 12, 1999 at 11:50:33AM -0300 From: Dominic Mitchell Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 12, 1999 at 11:50:33AM -0300, The Hermit Hacker wrote: > Attached is the output of 'tconv -b vt221' on our Solaris machine > where this map'ng is required, but the output doesn't look anything like > /etc/termcap :( Try doing "infocmp -C vt221" to get termcap output. What you have is terminfo. If you really want to understand terminfo, look at ncurses. -- Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ********************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 8:31:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 542BC14F3A for ; Mon, 12 Jul 1999 08:31:30 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 113i3E-000IYO-00 for hackers@freebsd.org; Mon, 12 Jul 1999 17:31:28 +0200 From: Sheldon Hearn To: hackers@freebsd.org Subject: Re: bin/12578: `` subshell taints PWD Date: Mon, 12 Jul 1999 17:31:28 +0200 Message-ID: <71323.931793488@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi folks, I'm hoping someone here is interested in tracking down a bug in our /bin/sh . Changing directory within a backtick (``) subshell in sh taints the parent's working directory. The following sample code gives the expected result for /bin/csh, but breaks for /bin/sh cd /tmp echo .`cd /`. pwd Any takers? Ciao, Sheldon. PS: And no, this is not an invitation to chat about the default shell for the base system. :-) PPS: Shhhh! PPPS: www.shhhh.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 9:29:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from thelab.hub.org (nat206.255.mpoweredpc.net [142.177.206.255]) by hub.freebsd.org (Postfix) with ESMTP id CBFF514CD0 for ; Mon, 12 Jul 1999 09:29:16 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.1) with ESMTP id NAA14723; Mon, 12 Jul 1999 13:30:16 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Mon, 12 Jul 1999 13:30:16 -0300 (ADT) From: The Hermit Hacker To: Dominic Mitchell Cc: freebsd-hackers@freebsd.org, wraith@hub.org Subject: Re: Keyboard mappings ... In-Reply-To: <19990712155802.E49177@palmerharvey.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Beautiful...thanks :) Infocmp doesn't exist under FreeBSD, but Solaris has it :) On Mon, 12 Jul 1999, Dominic Mitchell wrote: > On Mon, Jul 12, 1999 at 11:50:33AM -0300, The Hermit Hacker wrote: > > Attached is the output of 'tconv -b vt221' on our Solaris machine > > where this map'ng is required, but the output doesn't look anything like > > /etc/termcap :( > > Try doing "infocmp -C vt221" to get termcap output. What you have is > terminfo. If you really want to understand terminfo, look at ncurses. > -- > Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator > > In Mountain View did Larry Wall > Sedately launch a quiet plea: > That DOS, the ancient system, shall > On boxes pleasureless to all > Run Perl though lack they C. > -- > ********************************************************************** > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > the system manager. > > This footnote also confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > ********************************************************************** > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 9:43: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay01.indigo.ie (relay01.indigo.ie [194.125.133.225]) by hub.freebsd.org (Postfix) with SMTP id A60D514F5A for ; Mon, 12 Jul 1999 09:42:51 -0700 (PDT) (envelope-from niall@pobox.com) Received: (qmail 21595 messnum 238097 invoked from network[194.125.134.180/ts02-053.dublin.indigo.ie]); 12 Jul 1999 16:41:42 -0000 Received: from ts02-053.dublin.indigo.ie (HELO pobox.com) (194.125.134.180) by relay01.indigo.ie (qp 21595) with SMTP; 12 Jul 1999 16:41:42 -0000 Message-ID: <378A35D9.F43A7E5A@pobox.com> Date: Mon, 12 Jul 1999 18:37:13 +0000 From: Niall Smart X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Sheldon Hearn Cc: hackers@freebsd.org, bugs@freebsd.org Subject: Re: bin/12578: `` subshell taints PWD References: <71323.931793488@axl.noc.iafrica.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn wrote: > cd /tmp > echo .`cd /`. > pwd > > Any takers? The patch appended seems to fix this, I'd like someone familiar with sh to review it though, since this may be symptomatic of a general problem with command substitution. > PS: And no, this is not an invitation to chat about the default shell > for the base system. :-) You're hinting it should be /bin/sh for root, right? Regards, Niall *** eval.c~ Mon May 10 16:10:16 1999 --- eval.c Mon Jul 12 18:27:44 1999 *************** *** 710,715 **** --- 710,716 ---- && ((flags & EV_EXIT) == 0 || Tflag)) || ((flags & EV_BACKCMD) != 0 && (cmdentry.cmdtype != CMDBUILTIN + || cmdentry.u.index == CDCMD || cmdentry.u.index == DOTCMD || cmdentry.u.index == EVALCMD))) { jp = makejob(cmd, 1); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 9:55:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 9F1ED1507F for ; Mon, 12 Jul 1999 09:55:08 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 113jKr-000JLv-00; Mon, 12 Jul 1999 18:53:45 +0200 From: Sheldon Hearn To: Niall Smart Cc: hackers@freebsd.org Subject: Re: bin/12578: `` subshell taints PWD In-reply-to: Your message of "Mon, 12 Jul 1999 18:37:13 GMT." <378A35D9.F43A7E5A@pobox.com> Date: Mon, 12 Jul 1999 18:53:45 +0200 Message-ID: <74394.931798425@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 12 Jul 1999 18:37:13 GMT, Niall Smart wrote: > The patch appended seems to fix this, I'd like someone familiar > with sh to review it though, since this may be symptomatic of > a general problem with command substitution. As I understand your patch, you're saying "we should fork off a child process when the command in question is cd"? This is what I missed when I tried ``echo .`sleep 600`.'' and assumed that the result was proof that we always spawn a subprocess for backtick evaluation. :-( Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 10:15:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 36BCE14BF1 for ; Mon, 12 Jul 1999 10:14:54 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grondar.za (localhost [127.0.0.1]) by gratis.grondar.za (8.9.3/8.9.3) with ESMTP id TAA58055; Mon, 12 Jul 1999 19:09:03 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199907121709.TAA58055@gratis.grondar.za> To: Sheldon Hearn Cc: Doug , hackers@FreeBSD.ORG Subject: Re: a BSD identd Date: Mon, 12 Jul 1999 19:08:48 +0200 From: Mark Murray Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Sun, 11 Jul 1999 22:34:09 +0200, Mark Murray wrote: > > > As long as the documentation is _clear_ that this is not a front-line > > security tool, but rather a thing to marginally augment logs with > > user-supplied info, then I'll buy it. > > This is why I put forward a motion to move pidentd out of security and > into net / sysutils last year. The suggestion wasn't well received, but > I still think it'd help. I'd also like for the DESCR file for the port > to say: > > "This service offers remote users some identity to report back > to the local admin when complaining about abuse / break-ins > originating from the local host." This issue is way to religious. As long as folk don't do anything blatantly stupid, and as long as the caveats are well documented, it is probably a good idea to just let this one stand, and lean on it gently :-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 10:23:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 656FA150C2 for ; Mon, 12 Jul 1999 10:22:57 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id LAA16860; Mon, 12 Jul 1999 11:22:55 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id LAA42843; Mon, 12 Jul 1999 11:21:29 -0600 (MDT) Message-Id: <199907121721.LAA42843@harmony.village.org> To: Wes Peters Subject: Re: PCCARD and Vpp voltage Cc: Mark Murray , Bill Paul , hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 12 Jul 1999 00:15:17 MDT." <378987F5.8D5367E@softweyr.com> References: <378987F5.8D5367E@softweyr.com> <37897655.133AC329@softweyr.com> <378955BA.B1F94075@softweyr.com> <199907111119.NAA16211@gratis.grondar.za> <199907112234.QAA36877@harmony.village.org> <199907120251.UAA39731@harmony.village.org> <199907120508.XAA40748@harmony.village.org> Date: Mon, 12 Jul 1999 11:21:28 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <378987F5.8D5367E@softweyr.com> Wes Peters writes: : It shouldn't be all that hard to read the register and set the voltages : appropriately. Table 5-1 on p. 54 has the PC Card register values for : CVS[2:1] and what they mean. Agreed... : Quatech or Socket Communications? I don't see one right off. Socket. I'm going for the low power ruggedized one, unless I can find something better to use. But that's for my PDA so I can NFS mount a root file system after the kernel has booted. I wish I had more CF slots on this beast.... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 11: 5:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from thelab.hub.org (nat206.255.mpoweredpc.net [142.177.206.255]) by hub.freebsd.org (Postfix) with ESMTP id 64265150C7 for ; Mon, 12 Jul 1999 11:05:28 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.1) with ESMTP id PAA16359 for ; Mon, 12 Jul 1999 15:04:43 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Mon, 12 Jul 1999 15:04:43 -0300 (ADT) From: The Hermit Hacker To: freebsd-hackers@freebsd.org Subject: keymapping continued ... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Morning... Got a couple of suggestions, and have tried both, with the xkeycaps appearing to be the more practical for what I'm trying to get done, I think. From reading the xkeycaps man page, its a frontend for xmodmap, but reading *its* man page pretty much got me nowhere fast, so I'm going to try again with an example, as it might be that I'm just missing something... I need to build a keyboard map such that: F1 == ESC OP F2 == ESC OQ Shift-F1 == ESC [31~ Shift-F2 == ESC [32~ Now, in xkeycaps, it allows me to "remap" keys but gives you a fixed list of what it wants. Now, looking at the output of the infocmp command someone previously suggested for going from terminfo->termcap, I can see the sequences: k1=\EOP Which says that F1 sends out \EOP (ESC OP) Now, if I add the vt221 entry generated by infocmp, do a 'set term' and telnet over to the remote host where I need to run the app, and do a 'set term' over there, and hit 'F1', it generates ESC [11~ instead of the ESC OP that I'm trying to tell it to send... So, I'm guessing that I have to do an 'xmodmap' vs a termcap entry? If so, how would I build up the above? I need to do F1-F12 + Shift_F1->Shift_F12 for this to be feasible. If I have to install some sort of 'terminal package' for him to be able to do this, this is acceptable, we just need to get the map'ngs themselves working... Hopefully this makes a bit more sense? Thanks... Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 11:13: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id C1645151E5 for ; Mon, 12 Jul 1999 11:12:47 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 113kZ8-000K7X-00; Mon, 12 Jul 1999 20:12:34 +0200 From: Sheldon Hearn To: The Hermit Hacker Cc: freebsd-hackers@freebsd.org Subject: Re: keymapping continued ... In-reply-to: Your message of "Mon, 12 Jul 1999 15:04:43 -0300." Date: Mon, 12 Jul 1999 20:12:34 +0200 Message-ID: <77346.931803154@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 12 Jul 1999 15:04:43 -0300, The Hermit Hacker wrote: > Hopefully this makes a bit more sense? What doesn't make sense is the fact that a FreeBSD developer, who should know better, is mailing this sort of thing to freebsd-hackers. Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 11:17: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 1D6E81505E for ; Mon, 12 Jul 1999 11:16:46 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id MAA17364; Mon, 12 Jul 1999 12:15:38 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA43237; Mon, 12 Jul 1999 12:14:10 -0600 (MDT) Message-Id: <199907121814.MAA43237@harmony.village.org> To: "Jordan K. Hubbard" Subject: Re: Replacement for grep(1) (part 2) Cc: Jon Ribbens , "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 12 Jul 1999 03:18:04 PDT." <1336.931774684@zippy.cdrom.com> References: <1336.931774684@zippy.cdrom.com> Date: Mon, 12 Jul 1999 12:14:10 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <1336.931774684@zippy.cdrom.com> "Jordan K. Hubbard" writes: : Paging Terry Lambert, Terry Lambert - do you read me? It's time for : your annual rant on the topic of memory overcommit. :-) I thought it was time for his annual rant about how the current FreeBSD development model is going to have problems scaling... :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 11:26:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 0B92A15201 for ; Mon, 12 Jul 1999 11:26:20 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id MAA17448; Mon, 12 Jul 1999 12:26:20 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA43366; Mon, 12 Jul 1999 12:24:54 -0600 (MDT) Message-Id: <199907121824.MAA43366@harmony.village.org> To: The Hermit Hacker Subject: Re: keymapping continued ... Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 12 Jul 1999 15:04:43 -0300." References: Date: Mon, 12 Jul 1999 12:24:54 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message The Hermit Hacker writes: : I need to build a keyboard map such that: : : F1 == ESC OP : F2 == ESC OQ : Shift-F1 == ESC [31~ : Shift-F2 == ESC [32~ Why not do this with Xterm translations? Generally speaking xmodmap and friends are poor choices to even think about doing this with since they don't translate function keys to escape sequences. The applications do that, if they want. The only time you're likely to need them is in a terminal emulation situation, which makes xterm the logical place to do this. : Hopefully this makes a bit more sense? Yes. It does. You should use the translations resource for XTerm to accomplish this. From my .Xdefaults file: XTerm*vt100*translations: #override \n\ Alt y: insert-selection( PRIMARY, CUT_BUFFER0 ) \n\ Meta y: insert-selection( PRIMARY, CUT_BUFFER0 ) \n\ BackSpace: string( 0x7f )\n is one example. It allows me to "map" the BackSpace key into a DEL character (which in my religion is the right thing to do, your religion might vary), as well as giving me an easy way to paste, at least into xterms when I don't have a middle mouse button. This could easily be expanded to include all the vt220 keys that your boss/coworker needs in xterm. Check out the xterm man page for a more complete example, including ways of mapping different keymaps at the touch of a key. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 11:27: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from thelab.hub.org (nat206.255.mpoweredpc.net [142.177.206.255]) by hub.freebsd.org (Postfix) with ESMTP id CF466151F0 for ; Mon, 12 Jul 1999 11:27:00 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.1) with ESMTP id PAA16829; Mon, 12 Jul 1999 15:28:00 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Mon, 12 Jul 1999 15:27:59 -0300 (ADT) From: The Hermit Hacker To: Sheldon Hearn Cc: freebsd-hackers@freebsd.org Subject: Re: keymapping continued ... In-Reply-To: <77346.931803154@axl.noc.iafrica.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 12 Jul 1999, Sheldon Hearn wrote: > On Mon, 12 Jul 1999 15:04:43 -0300, The Hermit Hacker wrote: > > > Hopefully this makes a bit more sense? > > What doesn't make sense is the fact that a FreeBSD developer, who should > know better, is mailing this sort of thing to freebsd-hackers. You know what I always love? someone telling another they posted to the wrong place without taking the second to tell them a better place to post it...almost as bad as posting to the wrong place in the first place, and more of a waste of bandwidth... Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 12: 1:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from thelab.hub.org (nat206.255.mpoweredpc.net [142.177.206.255]) by hub.freebsd.org (Postfix) with ESMTP id 8DAE114EF2 for ; Mon, 12 Jul 1999 12:01:41 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.1) with ESMTP id QAA17183; Mon, 12 Jul 1999 16:02:44 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Mon, 12 Jul 1999 16:02:44 -0300 (ADT) From: The Hermit Hacker To: Warner Losh Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: keymapping continued ... In-Reply-To: <199907121824.MAA43366@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Perfect, slowly putting it together. One thing that I didn't find in the man page, and am wondering if its just somethign I did wrong, but does ordering matter? I put in, first time through: F1: ... Shift F1: ... And it Shift-F1 and F1 both gave the same answers... But, if I reverse it, it works as expected/hoped... Mistake on my part, or normal? thanks... On Mon, 12 Jul 1999, Warner Losh wrote: > In message > The Hermit Hacker writes: > : I need to build a keyboard map such that: > : > : F1 == ESC OP > : F2 == ESC OQ > : Shift-F1 == ESC [31~ > : Shift-F2 == ESC [32~ > > Why not do this with Xterm translations? Generally speaking xmodmap > and friends are poor choices to even think about doing this with since > they don't translate function keys to escape sequences. The > applications do that, if they want. The only time you're likely to > need them is in a terminal emulation situation, which makes xterm the > logical place to do this. > > : Hopefully this makes a bit more sense? > > Yes. It does. You should use the translations resource for XTerm to > accomplish this. From my .Xdefaults file: > > XTerm*vt100*translations: #override \n\ > Alt y: insert-selection( PRIMARY, CUT_BUFFER0 ) \n\ > Meta y: insert-selection( PRIMARY, CUT_BUFFER0 ) \n\ > BackSpace: string( 0x7f )\n > > is one example. It allows me to "map" the BackSpace key into a DEL > character (which in my religion is the right thing to do, your > religion might vary), as well as giving me an easy way to paste, at > least into xterms when I don't have a middle mouse button. > > This could easily be expanded to include all the vt220 keys that your > boss/coworker needs in xterm. > > Check out the xterm man page for a more complete example, including > ways of mapping different keymaps at the touch of a key. > > Warner > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 12:13:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id CC60C14F5A for ; Mon, 12 Jul 1999 12:13:09 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id PAA50660; Mon, 12 Jul 1999 15:12:50 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Mon, 12 Jul 1999 15:12:49 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Sheldon Hearn Cc: Doug , John Polstra , imp@village.org, hackers@FreeBSD.org Subject: Re: a BSD identd In-Reply-To: <53426.931766563@axl.noc.iafrica.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 12 Jul 1999, Sheldon Hearn wrote: > > > On Sun, 11 Jul 1999 12:47:30 MST, Doug wrote: > > > Finally, Brian might want to search the bugtraq archives before > > he commits anything. There have been quite a few identd related > > discussions, and it would be points in our favor if we didn't come out > > with anything that had known exploits. > > I like this suggestion. I worry about a trend I'm seeing, with more and > more people keen to replace existing code with their own virgin code > which hasn't had any serious field time behind it. > > This seems like a very Linuxy development trend. It's the way the Bazaar > works, but not in a Cathedral. Rather, you have a look at what's already > there and try to work on it. You don't start your own wing a few feet > from the Cathedral in the hopes that someone will bash down a similar > wing elsewhere and join yours to the main building. It's "out with the bad, in with the good." Pidentd code is pretty terrible. The only security concerns with my code were wrt FAKEID, and those were mostly fixed (mostly meaning that a symlink _may_ be opened, but it won't be read.) If anyone wants to audit my code for security, I invite them to. But frankly, I highly doubt anyone will find anything to exploit. And, why would bugtraq advisories against other identds apply to my ident_stream service? This is an entirely different code base. > > Waffle waffle. > > Ciao, > Sheldon. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 12:30:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from thelab.hub.org (nat206.255.mpoweredpc.net [142.177.206.255]) by hub.freebsd.org (Postfix) with ESMTP id 959CF1514D for ; Mon, 12 Jul 1999 12:30:43 -0700 (PDT) (envelope-from scrappy@hub.org) Received: from localhost (scrappy@localhost) by thelab.hub.org (8.9.3/8.9.1) with ESMTP id QAA17523; Mon, 12 Jul 1999 16:29:52 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Mon, 12 Jul 1999 16:29:52 -0300 (ADT) From: The Hermit Hacker To: Warner Losh Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: keymapping continued ... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Okay, slowly getting somewhere, I think... We setup the .Xdefaults file, as follows, on the remote server and are starting an xterm to the client machine, which is "acceptable", but I must be missing something: XTerm*vt100*translations: #override \n\ Shift F1:string(0x1B) string(0x5B) string(0x33) string(0x33) string(0x7E)\n\ F1:string(0x1B) string(0x4F) string(0x50)\n\ Shift F5:string(0x1B) string(0x5B) string(0x33) string(0x35) string(0x7E)\n\ F5:string(0x1B) string(0x5B) string(0x31) string(0x36) string(0x7E)\n Now, when I press 'Shift F5', I get [35~ showing up on the app, but its as if the ESC didn't go through... Is there a better way I should be writing this? I'm going by the example it showed for sending "multiple characters", but there might be another function I should be using for this? The neat thing is that the F5 one worked fine, its only the 'Shift F5' one so far that isn't... Thanks... On Mon, 12 Jul 1999, The Hermit Hacker wrote: > > Perfect, slowly putting it together. One thing that I didn't find in the > man page, and am wondering if its just somethign I did wrong, but does > ordering matter? > > I put in, first time through: > > F1: ... > Shift F1: ... > > And it Shift-F1 and F1 both gave the same answers... > > But, if I reverse it, it works as expected/hoped... > > Mistake on my part, or normal? > > thanks... > > On Mon, 12 Jul 1999, Warner Losh wrote: > > > In message > > The Hermit Hacker writes: > > : I need to build a keyboard map such that: > > : > > : F1 == ESC OP > > : F2 == ESC OQ > > : Shift-F1 == ESC [31~ > > : Shift-F2 == ESC [32~ > > > > Why not do this with Xterm translations? Generally speaking xmodmap > > and friends are poor choices to even think about doing this with since > > they don't translate function keys to escape sequences. The > > applications do that, if they want. The only time you're likely to > > need them is in a terminal emulation situation, which makes xterm the > > logical place to do this. > > > > : Hopefully this makes a bit more sense? > > > > Yes. It does. You should use the translations resource for XTerm to > > accomplish this. From my .Xdefaults file: > > > > XTerm*vt100*translations: #override \n\ > > Alt y: insert-selection( PRIMARY, CUT_BUFFER0 ) \n\ > > Meta y: insert-selection( PRIMARY, CUT_BUFFER0 ) \n\ > > BackSpace: string( 0x7f )\n > > > > is one example. It allows me to "map" the BackSpace key into a DEL > > character (which in my religion is the right thing to do, your > > religion might vary), as well as giving me an easy way to paste, at > > least into xterms when I don't have a middle mouse button. > > > > This could easily be expanded to include all the vt220 keys that your > > boss/coworker needs in xterm. > > > > Check out the xterm man page for a more complete example, including > > ways of mapping different keymaps at the touch of a key. > > > > Warner > > > > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy > Systems Administrator @ hub.org > primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 12:36:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 6C4A615283 for ; Mon, 12 Jul 1999 12:36:47 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id UAA01635; Mon, 12 Jul 1999 20:36:50 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Mon, 12 Jul 1999 20:36:50 +0100 (BST) From: Doug Rabson To: Karl Pielorz Cc: Mark Newton , crypt0genic@ecad.org, hackers@freebsd.org Subject: Re: (forw) In-Reply-To: <3789E5DE.8D318608@tdx.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 12 Jul 1999, Karl Pielorz wrote: > > > Mark Newton wrote: > > > > Karl Pielorz wrote: > > > > > Yes, a nice, effective - and simply way of replacing syscall's on FreeBSD... > > > Some might say a little too 'simple'? > > > > Garbage. You can do this on any OS, whether it supports loadable > > modules or not, if you've managed to win sufficient privileges through > > some other means. > > I was actually leaning towards that... My boss had kittens here (we have 12 > FreeBSD boxes running the show now), until I'd explained it to him... If > syscall's need to be replaced, they need to be replaced - and if they are > replaceable ... (I'll stop there) :) > > The article (from what I can remember) didn't actually go out of it's way to > say you have to have be root to load the modules in the first place :) - Maybe > it's warrants some kind of response page putting up somewhere? - this is also > getting off topic for -hackers :(... It was mentioned when describing the conditions for allowing the file load (securelevel == 0 && uid == 0). -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 13:24:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 8FD9314C57 for ; Mon, 12 Jul 1999 13:24:24 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id NAA32564; Mon, 12 Jul 1999 13:22:49 -0700 (PDT) Date: Mon, 12 Jul 1999 13:22:49 -0700 (PDT) From: Julian Elischer To: Karl Pielorz Cc: crypt0genic , hackers@FreeBSD.ORG Subject: Re: (forw) In-Reply-To: <3789D346.5682D28A@tdx.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I would suggest that a version of this document be incorporated into our docs. It's not like it says anythign new, but it's a really good introduction to KLD modules and maybe it's be better to have those documents around to remind people how easy it is to hack a system once root is broken. julian On Mon, 12 Jul 1999, Karl Pielorz wrote: > Yes, a nice, effective - and simply way of replacing syscall's on FreeBSD... > Some might say a little too 'simple'? > > -Kp > > crypt0genic wrote: > > > > Have you all seen this? > > > > From: Anonymous > > To: BUGTRAQ@SECURITYFOCUS.COM > > > > Hi folks, > > > > THC released a new article dealing with FreeBSD 3.x > > Kernel modules that can attack/backdoor the > > system. > > You can find our article on http://thc.pimmel.com or > > http://r3wt.base.org. > > > > Greets, pragmatic / The Hacker's Choice > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 13:24:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id 7E4A914C57 for ; Mon, 12 Jul 1999 13:24:30 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id NAA06756; Mon, 12 Jul 1999 13:23:05 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Mon, 12 Jul 1999 13:23:05 -0700 (PDT) From: Doug X-Sender: doug@dt054n86.san.rr.com To: peter@netplex.com.au Cc: freebsd-hackers@freebsd.org Subject: Re: more amd hangs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 9 Jul 1999, Doug wrote: > In my continuing efforts to get this freebsd box into shape for > web hosting at my company (where it relies exclusively on NFS for > retrieving customer data) I've been making progress thanks to some recent > commits by Peter. Now I can run the heavy duty NFS access script and it > completes its mission about 2 out of 3 times. Also, now when it fails it > doesn't lock the whole box, just amd. Still not where I want it to be, but > it is definitely big progress. :) > > What happens when it hangs is that amd becomes totally wedged. I > cannot do 'df' or 'ls /' at all (the amd mountpoints are on /), and > killing the amd process is no help; I have to reboot the box. Ktrace'ing > amd at this point gets me nothing. The ktrace process just dies and leaves > a 0 byte ktrace.out file. (BTW, I am also still having problems with > ktrace exiting while the process is still running when I actually get it > to attach, if anyone cares.) Still working on this problem. Thanks to some suggestions I got off the list, I have compiled libc and amd with debugging symbols. I wedged the box the same way I have previously, by running a perl script that automounts a directory, reads 250 files in that directory, automounts another one, etc. for a total of 68 directories. Using today's current this time amd wedged in the following state according to top: 155 root 3 0 736K 520K siobi 1 0:21 0.00% 0.00% amd Here is the trace after killing it: Core was generated by `amd'. Program terminated with signal 3, Quit. #0 0x8063dc4 in open () (gdb) where #0 0x8063dc4 in open () #1 0x806b5c3 in vsyslog (pri=6, fmt=0x809279a "%s", ap=0xbfbfd2c0 "") at /usr/src/lib/libc/../libc/gen/syslog.c:262 #2 0x806b2c2 in syslog (pri=6, fmt=0x809279a "%s") at /usr/src/lib/libc/../libc/gen/syslog.c:130 #3 0x805a3d8 in real_plog (lvl=6, fmt=0x8091440 "prime_nfs_fhandle_cache: NFS version %d", vargs=0xbfbfdafc "\002") at /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/libamu/xutil.c:443 #4 0x805a2be in plog (lvl=16, fmt=0x8091440 "prime_nfs_fhandle_cache: NFS version %d") at /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/libamu/xutil.c:383 #5 0x805323a in prime_nfs_fhandle_cache (path=0x80cb287 "/Space/209.132.66", fs=0x80b5640, fhbuf=0xbfbfdb34, wchan=0x80b57c0) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/ops_nfs.c:262 #6 0x805363f in nfs_init (mf=0x80b57c0) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/ops_nfs.c:542 #7 0x804a7f9 in amfs_auto_bgmount (cp=0x80c8600, mpe=0) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/amfs_auto.c:676 #8 0x804a4bc in amfs_auto_retry (rc=0, term=0, closure=0x80c8600) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/amfs_auto.c:402 #9 0x8055212 in do_task_notify () at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/sched.c:239 #10 0x804df6d in softclock () at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/clock.c:212 #11 0x8052583 in run_rpc () at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/nfs_start.c:253 #12 0x80527e6 in mount_automounter (ppid=154) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/nfs_start.c:467 #13 0x804a109 in main (argc=4, argv=0xbfbfddec) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/amd.c:544 #14 0x80480e9 in _start () I'm going to work on attaching it with gdb while it's locked next. Also based on advice I've made some changes to my configuration files, although it didn't help the 'ls /' or 'df' problems. Thanks for any help, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers [ global ] # Only search for maps of this type map_type = file # Search this path for maps search_path = /etc # Use this directory for amd's private mount points auto_dir = /usr/amd/realmounts # Log all activity to syslog (daemon) log_file = syslog:local7 log_options = all # Check /etc/hosts for hostnames normalize_hostnames = yes # Lock the amd process into memory, improves perf. plock = yes # Use the special /default entry in maps selectors_on_default = yes # DEFINE AN AMD MOUNT POINT [ /usr/amd/Interfaces ] map_name = amd.Interfaces [ /usr/amd/Hold ] map_name = amd.Hold 32# more /etc/amd.Interfaces /defaults type:=nfs;opts:=rw,vers=2,intr,proto=udp,noconn 209.132.4 netapp01:/vol/Space/209.132.4 * rhost:=IP${key};rfs:=/Space/${key} To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 13:26: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id B387E14FEE for ; Mon, 12 Jul 1999 13:26:01 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id NAA32699; Mon, 12 Jul 1999 13:25:27 -0700 (PDT) Date: Mon, 12 Jul 1999 13:25:26 -0700 (PDT) From: Julian Elischer To: Doug Rabson Cc: Karl Pielorz , Mark Newton , crypt0genic@ecad.org, hackers@FreeBSD.ORG Subject: Re: (forw) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 12 Jul 1999, Doug Rabson wrote: > On Mon, 12 Jul 1999, Karl Pielorz wrote: > > > > > > > Mark Newton wrote: > > > > > > Karl Pielorz wrote: > > > > > > > Yes, a nice, effective - and simply way of replacing syscall's on FreeBSD... > > > > Some might say a little too 'simple'? > > > > > > Garbage. You can do this on any OS, whether it supports loadable > > > modules or not, if you've managed to win sufficient privileges through > > > some other means. > > > > I was actually leaning towards that... My boss had kittens here (we have 12 > > FreeBSD boxes running the show now), until I'd explained it to him... If > > syscall's need to be replaced, they need to be replaced - and if they are > > replaceable ... (I'll stop there) :) > > > > The article (from what I can remember) didn't actually go out of it's way to > > say you have to have be root to load the modules in the first place :) - Maybe > > it's warrants some kind of response page putting up somewhere? - this is also > > getting off topic for -hackers :(... > > It was mentioned when describing the conditions for allowing the file load > (securelevel == 0 && uid == 0). which suggests that most important servers should be run whith securelevel > 0 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 13:30:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 0D66D14F79; Mon, 12 Jul 1999 13:30:08 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id NAA02806; Mon, 12 Jul 1999 13:29:41 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: "Brian F. Feldman" Cc: Sheldon Hearn , Doug , John Polstra , imp@village.org, hackers@FreeBSD.ORG Subject: Re: a BSD identd In-reply-to: Your message of "Mon, 12 Jul 1999 15:12:49 EDT." Date: Mon, 12 Jul 1999 13:29:41 -0700 Message-ID: <2803.931811381@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Whatever you do with identd, just make it work through NAT. That's the #1 request from folks where this is concerned. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 14: 6:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hooked.net (pm3-12.ppp.wenet.net [206.15.85.12]) by hub.freebsd.org (Postfix) with ESMTP id E6A3615286 for ; Mon, 12 Jul 1999 14:06:31 -0700 (PDT) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by zippy.dyn.ml.org (8.9.3/8.9.1) with ESMTP id UAA00887; Fri, 9 Jul 1999 20:21:45 -0700 (PDT) (envelope-from garbanzo@hooked.net) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Fri, 9 Jul 1999 20:21:45 -0700 (PDT) From: Alex Zepeda To: Jake Burkholder Cc: Alex Belits , hackers@FreeBSD.ORG Subject: Re: hardware In-Reply-To: <19990710021913.4E94B1F05@io.yi.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 9 Jul 1999, Jake Burkholder wrote: > Nvidia cards are already supported. The GL xlock savers look awesome. Really? Wow. The xscreensaver GL savers looked like crap, the xlockmore ones worked for about oh two seconds, before slowing down to unaccelerated speeds. This at 640x480x16 too. Hmm. At least 2D works great at 1152x864x32. - alex I thought felt your touch In my car, on my clutch But I guess it's just someone who felt a lot like I remember you. - Translator To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 14:20:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 403881511A for ; Mon, 12 Jul 1999 14:20:20 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id OAA06828; Mon, 12 Jul 1999 14:19:46 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id OAA23261; Mon, 12 Jul 1999 14:19:32 -0700 Received: from softweyr.com (dyn2.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA27870; Mon, 12 Jul 99 14:19:28 PDT Message-Id: <378A5BE0.940F6176@softweyr.com> Date: Mon, 12 Jul 1999 15:19:28 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Warner Losh Cc: Mark Murray , Bill Paul , hackers@FreeBSD.ORG Subject: Re: PCCARD and Vpp voltage References: <378987F5.8D5367E@softweyr.com> <37897655.133AC329@softweyr.com> <378955BA.B1F94075@softweyr.com> <199907111119.NAA16211@gratis.grondar.za> <199907112234.QAA36877@harmony.village.org> <199907120251.UAA39731@harmony.village.org> <199907120508.XAA40748@harmony.village.org> <199907121721.LAA42843@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh wrote: > > In message <378987F5.8D5367E@softweyr.com> Wes Peters writes: > : It shouldn't be all that hard to read the register and set the voltages > : appropriately. Table 5-1 on p. 54 has the PC Card register values for > : CVS[2:1] and what they mean. > > Agreed... > > : Quatech or Socket Communications? I don't see one right off. > > Socket. I'm going for the low power ruggedized one, unless I can find > something better to use. But that's for my PDA so I can NFS mount a > root file system after the kernel has booted. I wish I had more CF > slots on this beast.... Time to build a CF expansion cage? Or, better yet, a CF to PCCard cage? ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 14:44: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id BC73A14D30 for ; Mon, 12 Jul 1999 14:44:07 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id OAA07419; Mon, 12 Jul 1999 14:43:46 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Mon, 12 Jul 1999 14:43:46 -0700 (PDT) From: Doug X-Sender: doug@dt054n86.san.rr.com To: freebsd-hackers@freebsd.org Cc: peter@netplex.com.au Subject: Re: more amd hangs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, it's now wedged in a different state (using the same perl script to wedge it). According to top: 317 root 2 0 648K 456K STOP 0 0:00 0.00% 0.00% amd I also managed to attach to the running process this time: (gdb) file /usr/sbin/amd Reading symbols from /usr/sbin/amd...done. (gdb) attach 317 Attaching to program: /usr/sbin/amd, process 317 0x8063c34 in select () (gdb) where #0 0x8063c34 in select () #1 0x80523b6 in do_select (smask=0, fds=1024, fdp=0xbfbfd990, tvp=0xbfbfd984) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/nfs_start.c:146 #2 0x80525fd in run_rpc () at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/nfs_start.c:274 #3 0x80527e6 in mount_automounter (ppid=316) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/nfs_start.c:467 #4 0x804a109 in main (argc=1, argv=0xbfbfdb84) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/amd.c:544 #5 0x80480e9 in _start () I am noticing that the last function, _start() is the same as in the last traceback. Anyone with suggestions, I'm open to them. :) I tried doing 'continue' with gdb and it wedged gdb and amd, so I just rebooted. HTH, Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 14:48:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id EFF391524C for ; Mon, 12 Jul 1999 14:48:48 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 113nwD-000MM3-00; Mon, 12 Jul 1999 23:48:37 +0200 From: Sheldon Hearn To: rme@nightfly.apk.net (R. Matthew Emerson) Cc: freebsd-hackers@freebsd.org Subject: Re: more amd hangs In-reply-to: Your message of "10 Jul 1999 12:56:41 -0400." <87u2rcqw8m.fsf@nightfly.apk.net> Date: Mon, 12 Jul 1999 23:48:37 +0200 Message-ID: <85934.931816117@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 10 Jul 1999 12:56:41 -0400, R. Matthew Emerson wrote: > I thought that it was almost never proper to soft-mount rw filesytems. > Am I mistaken about this? I must admit, it sounds like sensible advice. The only NFS exports which I have to rely on are read-only mounts. The only time I soft-mounted a read-write export was when I was mucking around with buildworld over NFS, and it didn't cause me problems then. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 15:12:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id 0378F1526A for ; Mon, 12 Jul 1999 15:12:39 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id PAA07860; Mon, 12 Jul 1999 15:12:38 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Mon, 12 Jul 1999 15:12:38 -0700 (PDT) From: Doug X-Sender: doug@dt054n86.san.rr.com To: freebsd-hackers@freebsd.org Cc: peter@netplex.com.au Subject: Re: more amd hangs: in _start() In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, got another hang in "siobi" state (this time after it successfully completed the script). Here is the trace: (gdb) file /usr/sbin/amd Reading symbols from /usr/sbin/amd...done. (gdb) attach 155 Attaching to program: /usr/sbin/amd, process 155 0x8063dc4 in open () (gdb) where #0 0x8063dc4 in open () #1 0x806b5c3 in vsyslog (pri=6, fmt=0x809279a "%s", ap=0xbfbfb240 "X") at /usr/src/lib/libc/../libc/gen/syslog.c:262 #2 0x806b2c2 in syslog (pri=6, fmt=0x809279a "%s") at /usr/src/lib/libc/../libc/gen/syslog.c:130 #3 0x805a3d8 in real_plog (lvl=6, fmt=0x8091ea0 "recompute_portmap: NFS version %d", vargs=0xbfbfba7c "\002") at /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/libamu/xutil.c:443 #4 0x805a2be in plog (lvl=16, fmt=0x8091ea0 "recompute_portmap: NFS version %d") at /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/libamu/xutil.c:383 #5 0x80556f8 in recompute_portmap (fs=0x80c9f80) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/srvr_nfs.c:285 #6 0x80559ff in nfs_srvr_port (fs=0x80c9f80, port=0xbfbfbabe, wchan=0x0) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/srvr_nfs.c:564 #7 0x80534cd in call_mountd (fp=0xbfbfdb24, proc=3, f=0, wchan=0x0) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/ops_nfs.c:438 #8 0x8053a3d in nfs_umounted (mp=0x80cad00) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/ops_nfs.c:796 #9 0x804dd4f in am_unmounted (mp=0x80cad00) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/autil.c:366 #10 0x8050b22 in free_map_if_success (rc=0, term=0, closure=0x80cad00) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/map.c:924 #11 0x8055212 in do_task_notify () at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/sched.c:239 #12 0x804df6d in softclock () at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/clock.c:212 #13 0x8052583 in run_rpc () at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/nfs_start.c:253 #14 0x80527e6 in mount_automounter (ppid=154) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/nfs_start.c:467 #15 0x804a109 in main (argc=4, argv=0xbfbfddec) at /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/amd.c:544 #16 0x80480e9 in _start () I'm going to have a go at the code now that I can be fairly certain that _start() is the culprit. (Please everyone, stop laughing, thanks. :) Comments or suggestions welcome. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 15:56:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.is4b.net (peach.oaktree.net.uk [193.82.129.13]) by hub.freebsd.org (Postfix) with ESMTP id 7DB1915034 for ; Mon, 12 Jul 1999 15:56:32 -0700 (PDT) (envelope-from jon@chalk.oaktree.net.uk) Received: from chalk.oaktree.net.uk (chalk.oaktree.net.uk [193.82.129.19]) by relay.is4b.net (Postfix) with ESMTP id B633E1DC02; Mon, 12 Jul 1999 23:56:29 +0100 (BST) Received: (from jon@localhost) by chalk.oaktree.net.uk (8.9.3/8.9.3) id XAA00981; Mon, 12 Jul 1999 23:56:29 +0100 (BST) Date: Mon, 12 Jul 1999 23:56:29 +0100 From: Jon Ribbens To: "Daniel C. Sobral" Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) Message-ID: <19990712235629.A2152@oaktree.co.uk> Mail-Followup-To: "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org References: <5laet8b2l8.fsf@assaris.sics.se> <5lemij265u.fsf@assaris.sics.se> <3788714D.4E666FFA@newsguy.com> <19990712002043.C7067@oaktree.co.uk> <3789373D.9B1811F3@newsguy.com> <19990712022424.A1390@oaktree.co.uk> <37899FA7.4DC4E088@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <37899FA7.4DC4E088@newsguy.com>; from Daniel C. Sobral on Mon, Jul 12, 1999 at 04:56:23PM +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel C. Sobral" wrote: > That's *not* abomination. How about pre-allocating over 100 Mb for X > Free, for instance? What about it? If an application does not need 100MB, it should not malloc it. If it does need it, it should malloc it and know that it is available if the malloc succeeds. > Basically, if you don't have enough memory, you just don't have enough > memory. Yes, and the application should be told this via the standard documented interface for doing so, i.e. returning NULL from malloc(). > What FreeBSD does *reduces* the need for memory. If FreeBSD *did > not* do it, then you'd need much more memory. Why? Are there really such a lot of applications allocating vastly more memory than they actually use? Cheers Jon -- \/ Jon Ribbens / jon@oaktree.co.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 16: 2:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id C73B214E73 for ; Mon, 12 Jul 1999 16:02:07 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 113p4u-000N9W-00; Tue, 13 Jul 1999 01:01:40 +0200 From: Sheldon Hearn To: Jon Ribbens Cc: "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) In-reply-to: Your message of "Mon, 12 Jul 1999 23:56:29 +0100." <19990712235629.A2152@oaktree.co.uk> Date: Tue, 13 Jul 1999 01:01:40 +0200 Message-ID: <89001.931820500@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 12 Jul 1999 23:56:29 +0100, Jon Ribbens wrote: > What about it? If an application does not need 100MB, it should not > malloc it. If it does need it, it should malloc it and know that it > is available if the malloc succeeds. You're rehashing stuff that's been discussed to death. Please look at the mailing list archives for this mailing list. If you're not prepared to do that, the long and the short of it is that FreeBSD _does_ overcommit, we like it that way and neither of these two facts is likely to change. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 16:20:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.is4b.net (peach.oaktree.net.uk [193.82.129.13]) by hub.freebsd.org (Postfix) with ESMTP id E8D94152BB for ; Mon, 12 Jul 1999 16:20:42 -0700 (PDT) (envelope-from jon@chalk.oaktree.net.uk) Received: from chalk.oaktree.net.uk (chalk.oaktree.net.uk [193.82.129.19]) by relay.is4b.net (Postfix) with ESMTP id 8301C1DC02; Tue, 13 Jul 1999 00:20:27 +0100 (BST) Received: (from jon@localhost) by chalk.oaktree.net.uk (8.9.3/8.9.3) id AAA13687; Tue, 13 Jul 1999 00:20:27 +0100 (BST) Date: Tue, 13 Jul 1999 00:20:27 +0100 From: Jon Ribbens To: Sheldon Hearn Cc: "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) Message-ID: <19990713002027.A19153@oaktree.co.uk> Mail-Followup-To: Sheldon Hearn , "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org References: <19990712235629.A2152@oaktree.co.uk> <89001.931820500@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <89001.931820500@axl.noc.iafrica.com>; from Sheldon Hearn on Tue, Jul 13, 1999 at 01:01:40AM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn wrote: > You're rehashing stuff that's been discussed to death. Please look at > the mailing list archives for this mailing list. I'd love to, could you please be more specific? I can't find anything relevant searching for 'malloc' or 'overcommit'. > If you're not prepared to do that, the long and the short of it is that > FreeBSD _does_ overcommit, we like it that way and neither of these two > facts is likely to change. I can add it to the list of reasons I don't use it then I guess ;-). Cheers Jon -- \/ Jon Ribbens / jon@oaktree.co.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 16:34:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id F335615268 for ; Mon, 12 Jul 1999 16:34:40 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 113pZ8-000NTu-00; Tue, 13 Jul 1999 01:32:54 +0200 From: Sheldon Hearn To: Jon Ribbens Cc: "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) In-reply-to: Your message of "Tue, 13 Jul 1999 00:20:27 +0100." <19990713002027.A19153@oaktree.co.uk> Date: Tue, 13 Jul 1999 01:32:54 +0200 Message-ID: <90265.931822374@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999 00:20:27 +0100, Jon Ribbens wrote: > I'd love to, could you please be more specific? I can't find anything > relevant searching for 'malloc' or 'overcommit'. My apologies. It was the current mailing list. Search for "malloc AND NULL AND kill", and pick out the "swap-related problems" thread. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 16:40:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id 017EA1509A for ; Mon, 12 Jul 1999 16:40:33 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id BAA18817 for freebsd-hackers@FreeBSD.ORG; Tue, 13 Jul 1999 01:39:45 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 1C7A487AE; Tue, 13 Jul 1999 01:24:52 +0200 (CEST) (envelope-from roberto) Date: Tue, 13 Jul 1999 01:24:52 +0200 From: Ollivier Robert To: freebsd-hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) Message-ID: <19990713012452.A5595@keltia.freenix.fr> Reply-To: FreeBSD Chat Mailing List Mail-Followup-To: freebsd-hackers@FreeBSD.ORG References: <1336.931774684@zippy.cdrom.com> <199907121814.MAA43237@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.95.5i In-Reply-To: <199907121814.MAA43237@harmony.village.org>; from Warner Losh on Mon, Jul 12, 1999 at 12:14:10PM -0600 X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5468 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Warner Losh: > I thought it was time for his annual rant about how the current > FreeBSD development model is going to have problems scaling... No no, I think you're thinking of the write-lock read-lock we should use on CVS in order to have the Hamiltonian graph without cycle to solve dependencies with the fine-grained giant lock on SMP systems. Did I catch all the remaining rants ? :-) Oh I forgot the one about having a veto system for I don't remember what... [ Sorry Terry, couldn't resist, please forgive me :) ] -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #72: Mon Jul 12 08:26:43 CEST 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 16:56: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from shell17.ba.best.com (shell17.ba.best.com [206.184.139.149]) by hub.freebsd.org (Postfix) with ESMTP id D8CA014EA6 for ; Mon, 12 Jul 1999 16:56:03 -0700 (PDT) (envelope-from toddpw@shell17.ba.best.com) Received: (from toddpw@localhost) by shell17.ba.best.com (8.9.3/8.9.2/best.sh) id QAA01022; Mon, 12 Jul 1999 16:55:38 -0700 (PDT) From: Todd Whitesel Message-Id: <199907122355.QAA01022@shell17.ba.best.com> Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <1336.931774684@zippy.cdrom.com> from "Jordan K. Hubbard" at "Jul 12, 99 03:18:04 am" To: jkh@zippy.cdrom.com (Jordan K. Hubbard) Date: Mon, 12 Jul 1999 16:55:38 -0700 (PDT) Cc: jon@oaktree.co.uk, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Yuck. That's a complete abomination. What's the point of it? It's turning > > Paging Terry Lambert, Terry Lambert - do you read me? It's time for > your annual rant on the topic of memory overcommit. :-) It's not overcommit so much as it is what happens to a process that gets a page fault when there are no available pages to 'fix up' the overcommit. AIX began overcommitting at one point but would kill -9 any process that page faulted when there were no available pages. AIX sysadmins universally hated this behavior and allocated HUGE swap files to avoid it. I assume FreeBSD does something more reasonable. Todd Whitesel toddpw @ best.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 17:15:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id A13BE152E7 for ; Mon, 12 Jul 1999 17:15:33 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id RAA02621; Mon, 12 Jul 1999 17:10:33 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907130010.RAA02621@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Wilko Bulte Cc: FreeBSD-hackers@freebsd.org (FreeBSD hackers list) Subject: Re: 3.2-STABLE not stable but panicy? In-reply-to: Your message of "Sat, 10 Jul 1999 21:12:49 +0200." <199907101912.VAA00520@yedi.iaf.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jul 1999 17:10:33 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is typically symptomatic of poor CPU cooling; all of a sudden you are running the CPU at full power 100% of the time, rather than sitting in an HLT instruction. It can be further exacerbated if you're overclocking. > Is it just me/my machine or has 3.2-STABLE become rather unstable and > panic stricken (sp)? > > Whether it has any correlation I don't know, but it seems to have started > when I got in the the RC5DES project a couple of days ago. > > Yesterday I got a panic like: > > (no debugging symbols found)... > IdlePTD 3174400 > initial pcb at 28e864 > panicstr: lockmgr: unknown locktype request 0 > panic messages: > --- > panic: lockmgr: unknown locktype request 0 > > syncing disks... 160 159 139 113 80 32 done > > dumping to dev 30401, offset 327680 > dump 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 > 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 > 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 > 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 > --- > #0 0xc01594ff in boot () > (kgdb) bt > #0 0xc01594ff in boot () > #1 0xc0159784 in at_shutdown () > #2 0xc01555c4 in lockmgr () > #3 0xc017ba88 in vop_stdlock () > #4 0xc01f7e19 in ufs_vnoperate () > #5 0xc0184863 in vn_lock () > #6 0xc017e40b in vget () > #7 0xc017a55b in vfs_cache_lookup () > #8 0xc01f7e19 in ufs_vnoperate () > #9 0xc017cb45 in lookup () > #10 0xc017c618 in namei () > #11 0xc0180969 in change_dir () > #12 0xc01808c7 in chdir () > #13 0xc021cf63 in syscall () > #14 0xc0213cec in Xint0x80_syscall () > #15 0x804919f in ?? () > #16 0x804af96 in ?? () > #17 0x804904d in ?? () > (kgdb) > > > I decided to cvsup the latest -STABLE sources and with a kernel based on > yesterdays -STABLE I just got (again during a RC5DES run, approx > 15 minutes after starting it): > > (no debugging symbols found)... > IdlePTD 3239936 > initial pcb at 29e914 > panicstr: page fault > panic messages: > --- > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x3ff02585 > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc02078b4 > stack pointer = 0x10:0xc6a158b4 > frame pointer = 0x10:0xc6a158c0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 973 (cron) > interrupt mask = net tty bio cam > trap number = 12 > panic: page fault > > syncing disks... done > > dumping to dev 30401, offset 327680 > dump 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 > 72 > 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 > 46 45 > 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 > 19 1 > 8 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 > --- > #0 0xc0159e07 in boot () > (kgdb) bt > #0 0xc0159e07 in boot () > #1 0xc015a08c in at_shutdown () > #2 0xc021e089 in trap_fatal () > #3 0xc021dd67 in trap_pfault () > #4 0xc021da0a in trap () > #5 0xc02078b4 in zalloci () > #6 0xc021ac12 in get_pv_entry () > #7 0xc021ada7 in pmap_insert_entry () > #8 0xc021b589 in pmap_enter_quick () > #9 0xc021b7aa in pmap_object_init_pt () > #10 0xc0149c77 in elf_load_section () > #11 0xc014a2ae in exec_elf_imgact () > #12 0xc01534ff in execve () > #13 0xc021e2cb in syscall () > #14 0xc0214ecc in Xint0x80_syscall () > Cannot access memory at address 0xbfbfd7d8. > (kgdb) > > Before someone asks: yes, I checked the CPU fan.. > > dmesg: > > > Copyright (c) 1992-1999 FreeBSD Inc. > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > FreeBSD 3.2-STABLE #0: Sat Jul 10 10:49:28 CEST 1999 > wilko@yedi.iaf.nl:/usr/freebsd-3.1-stable-src/src/sys/compile/YEDI > Timecounter "i8254" frequency 1193182 Hz > Timecounter "TSC" frequency 261958495 Hz > CPU: AMD-K6tm w/ multimedia extensions (261.96-MHz 586-class CPU) > Origin = "AuthenticAMD" Id = 0x562 Stepping = 2 > Features=0x8001bf > AMD Features=0x400<> > real memory = 100663296 (98304K bytes) > avail memory = 94621696 (92404K bytes) > Preloaded elf kernel "kernel" at 0xc0305000. > Probing for devices on PCI bus 0: > chip0: rev 0x03 on pci0.0.0 > chip1: rev 0x01 on pci0.7.0 > xl0: <3Com 3c905-TX Fast Etherlink XL> rev 0x00 int a irq 14 on pci0.9.0 > xl0: Ethernet address: 00:60:08:09:b8:f1 > xl0: autoneg not complete, no carrier (forcing half-duplex, 10Mbps) > vga0: rev 0x00 int a irq 14 on pci0.10.0 > Qlogic ISP Driver, FreeBSD CAM Version 0.992, Core Version 1.9 > isp0: rev 0x05 int a irq 9 on pci0.11.0 > isp0: set PCI line size to 16 > isp0: set PCI latency to 64 > isp0: Ultra Mode Capable > isp0: Board Revision 1040B, loaded F/W Revision 7.63.0 > isp0: Last F/W revision was 4.53.0 > ncr0: rev 0x02 int a irq 11 on pci0.12.0 > Probing for devices on the ISA bus: > sc0 on isa > sc0: VGA color <16 virtual consoles, flags=0x0> > atkbdc0 at 0x60-0x6f on motherboard > atkbd0 irq 1 on isa > psm0 irq 12 on isa > psm0: model Generic PS/2 mouse, device ID 0 > sio0 at 0x3f8-0x3ff irq 4 on isa > sio0: type 16550A > sio1 at 0x2f8-0x2ff irq 3 on isa > sio1: type 16550A > sio2 at 0x1a0-0x1a7 flags 0x501 on isa > sio2: type 16550A (multiport) > sio3 at 0x1a8-0x1af flags 0x501 on isa > sio3: type 16550A (multiport) > sio4 at 0x1b0-0x1b7 flags 0x501 on isa > sio4: type 16550A (multiport) > sio5 at 0x1b8-0x1bf irq 5 flags 0x501 on isa > sio5: type 16550A (multiport master) > fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa > fdc0: FIFO enabled, 8 bytes threshold > fd0: 1.44MB 3.5in > ppc0 at 0x378 irq 7 flags 0x40 on isa > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > lpt0: on ppbus 0 > lpt0: Interrupt-driven port > isic0 at 0xd80 irq 15 flags 0x3 on isa > isic0: Teles S0/16.3 > isic0: ISAC 2085 Version A1/A2 or 2086/2186 Version 1.1 (IOM-2) (Addr=0x960) > isic0: HSCX 82525 or 21525 Version 2.1 (AddrA=0x160, AddrB=0x560) > vga0 at 0x3b0-0x3df maddr 0xa0000 msize 131072 on isa > npx0 on motherboard > npx0: INT 16 interface > IP packet filtering initialized, divert enabled, rule-based forwarding disabled, unlimited logging > i4b: ISDN call control device attached > i4bisppp: 2 ISDN SyncPPP device(s) attached > i4bctl: ISDN system control port attached > i4btrc: 2 ISDN trace device(s) attached > Waiting 3 seconds for SCSI devices to settle > isp0: driver initiated bus reset of bus 0 > changing root device to da0s2a > da0 at isp0 bus 0 target 0 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled > da0: 17365MB (35565080 512 byte sectors: 255H 63S/T 2213C) > WARNING: / was not properly dismounted > da1 at isp0 bus 0 target 1 lun 0 > da1: Fixed Direct Access SCSI-2 device > da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled > da1: 8715MB (17850000 512 byte sectors: 255H 63S/T 1111C) > cd0 at isp0 bus 0 target 4 lun 0 > cd0: Removable CD-ROM SCSI-2 device > cd0: 10.000MB/s transfers (10.000MHz, offset 8) > cd0: cd present [1289068 x 512 byte records] > cd1 at isp0 bus 0 target 3 lun 0 > cd1: Removable CD-ROM SCSI-2 device > cd1: 10.000MB/s transfers (10.000MHz, offset 8) > cd1: Attempt to query device size failed: NOT READY, Medium not present > ffs_mountfs: superblock updated for soft updates > ffs_mountfs: superblock updated for soft updates > ffs_mountfs: superblock updated for soft updates > ffs_mountfs: superblock updated for soft updates > > Comments invited, I'll build and boot a kernel with debugging symbols in the > meantime. > > Wilko > -- > | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - > |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 17:55:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id C3E5E15270 for ; Mon, 12 Jul 1999 17:55:21 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id JAA02136; Tue, 13 Jul 1999 09:54:06 +0900 (JST) Message-ID: <378A8D4C.AFDCCD66@newsguy.com> Date: Tue, 13 Jul 1999 09:50:21 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Jon Ribbens Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <5laet8b2l8.fsf@assaris.sics.se> <5lemij265u.fsf@assaris.sics.se> <3788714D.4E666FFA@newsguy.com> <19990712002043.C7067@oaktree.co.uk> <3789373D.9B1811F3@newsguy.com> <19990712022424.A1390@oaktree.co.uk> <37899FA7.4DC4E088@newsguy.com> <19990712235629.A2152@oaktree.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jon Ribbens wrote: > > "Daniel C. Sobral" wrote: > > That's *not* abomination. How about pre-allocating over 100 Mb for X > > Free, for instance? > > What about it? If an application does not need 100MB, it should not > malloc it. If it does need it, it should malloc it and know that it > is available if the malloc succeeds. Well, learn something about real programs first, and then come back. > > Basically, if you don't have enough memory, you just don't have enough > > memory. > > Yes, and the application should be told this via the standard > documented interface for doing so, i.e. returning NULL from > malloc(). This results in the applications working with less memory than would actually be possible through overcommit. > > What FreeBSD does *reduces* the need for memory. If FreeBSD *did > > not* do it, then you'd need much more memory. > > Why? Are there really such a lot of applications allocating vastly > more memory than they actually use? Right. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org I'm one of those bad things that happen to good people. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 17:55:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id EC1E2153CA for ; Mon, 12 Jul 1999 17:55:45 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id JAA02264; Tue, 13 Jul 1999 09:55:09 +0900 (JST) Message-ID: <378A8D8C.B13F6E9F@newsguy.com> Date: Tue, 13 Jul 1999 09:51:24 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Jon Ribbens Cc: Sheldon Hearn , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <19990712235629.A2152@oaktree.co.uk> <89001.931820500@axl.noc.iafrica.com> <19990713002027.A19153@oaktree.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jon Ribbens wrote: > > > If you're not prepared to do that, the long and the short of it is that > > FreeBSD _does_ overcommit, we like it that way and neither of these two > > facts is likely to change. > > I can add it to the list of reasons I don't use it then I guess ;-). Whatever. The operating system you use also does it. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org I'm one of those bad things that happen to good people. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 18: 6:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id C882B152AA; Mon, 12 Jul 1999 18:06:09 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id KAA03606; Tue, 13 Jul 1999 10:04:14 +0900 (JST) Message-ID: <378A8FAC.797E9147@newsguy.com> Date: Tue, 13 Jul 1999 10:00:28 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: FreeBSD Chat Mailing List Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) References: <1336.931774684@zippy.cdrom.com> <199907121814.MAA43237@harmony.village.org> <19990713012452.A5595@keltia.freenix.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ollivier Robert wrote: > > Oh I forgot the one about having a veto system for I don't remember what... Veto based locking for the fs. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org I'm one of those bad things that happen to good people. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 18:19:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id 3E03414C99 for ; Mon, 12 Jul 1999 18:19:52 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id SAA02994; Mon, 12 Jul 1999 18:11:24 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907130111.SAA02994@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Sheldon Hearn Cc: Doug , John Polstra , imp@village.org, hackers@freebsd.org Subject: Re: a BSD identd In-reply-to: Your message of "Mon, 12 Jul 1999 10:02:43 +0200." <53426.931766563@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jul 1999 18:11:24 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I like this suggestion. I worry about a trend I'm seeing, with more and > more people keen to replace existing code with their own virgin code > which hasn't had any serious field time behind it. I'm actually more worried about the opposing trend that you espouse, where the seniority of a code entity is considered more significant than its functionality. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 18:46:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 894BA1500F for ; Mon, 12 Jul 1999 18:46:16 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id LAA09379; Tue, 13 Jul 1999 11:13:44 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id LAA39272; Tue, 13 Jul 1999 11:13:41 +0930 (CST) Date: Tue, 13 Jul 1999 11:13:41 +0930 From: Greg Lehey To: crypt0genic , Mark Newton Cc: hackers@FreeBSD.ORG, Karl Pielorz Subject: Compromising a FreeBSD from inside (was: (forw)) Message-ID: <19990713111341.S21403@freebie.lemis.com> References: <3789D346.5682D28A@tdx.co.uk> <199907121149.VAA22311@gizmo.internode.com.au> <19990712122803.A1832@ecad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <19990712122803.A1832@ecad.org>; from crypt0genic on Mon, Jul 12, 1999 at 12:28:03PM +0000 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG People, how much attention are you going to get to this topic with a subject line like "(forw)"? On Monday, 12 July 1999 at 12:28:03 +0000, crypt0genic wrote: > > Have you all seen this? > To: BUGTRAQ@SECURITYFOCUS.COM > > Hi folks, > > THC released a new article dealing with FreeBSD 3.x > Kernel modules that can attack/backdoor the > system. > You can find our article on http://thc.pimmel.com or > http://r3wt.base.org. For those of us who *hate* incorrect or approximate URLs, try http://thc.pimmel.com/files/thc/bsdkern.html. > Greets, pragmatic / The Hacker's Choice On Monday, 12 July 1999 at 21:19:45 +0930, Mark Newton wrote: > Karl Pielorz wrote: > >> Yes, a nice, effective - and simply way of replacing syscall's on FreeBSD... >> Some might say a little too 'simple'? > > Garbage. You can do this on any OS, whether it supports loadable > modules or not, if you've managed to win sufficient privileges through > some other means. FreeBSD (and other OSs with loadable module support) > merely provides a well-defined API which, like almost every other well- > defined API, can be abused by those who harbor ill-will. > > Making the interface "complicated" does absolutely nothing to stop > script-kiddies: Once a complicated interface is in an exploit script, > who cares how arcane it is? In fact, the most interesting thing about this (rather large) document is that it's the best documentation I've seen on klds. I don't know why anybody would want to use it for compromising security, since it's a *lot* of work, and to even get as far as installing it you have to be root already, so you would have plenty of easier alternatives. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 19:52:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (Postfix) with ESMTP id F1A2F15065 for ; Mon, 12 Jul 1999 19:52:23 -0700 (PDT) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from mercury (mercury [129.127.36.44]) by adelphi.physics.adelaide.edu.au (8.8.8/8.8.8/UofA-1.5) with SMTP id MAA03931; Tue, 13 Jul 1999 12:22:11 +0930 (CST) Received: from localhost by mercury; (5.65v3.2/1.1.8.2/27Nov97-0404PM) id AA12270; Tue, 13 Jul 1999 12:22:10 +0930 Date: Tue, 13 Jul 1999 12:22:09 +0930 (CST) From: Kris Kennaway To: Greg Lehey Cc: crypt0genic , Mark Newton , hackers@freebsd.org, Karl Pielorz Subject: Re: Compromising a FreeBSD from inside (was: (forw)) In-Reply-To: <19990713111341.S21403@freebie.lemis.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, Greg Lehey wrote: > In fact, the most interesting thing about this (rather large) document > is that it's the best documentation I've seen on klds. I don't know > why anybody would want to use it for compromising security, since it's > a *lot* of work, and to even get as far as installing it you have to > be root already, so you would have plenty of easier alternatives. It's more for hiding yourself once you're already in; if you load a module at boot-time which hides the fact that it was loaded, hides the module itself from being listed by the filesystem syscalls, and hides whatever else you want, you could presumably stay hidden a lot easier. Kris ----- "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jul 12 21: 8:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id 6ECF0150CF for ; Mon, 12 Jul 1999 21:08:26 -0700 (PDT) (envelope-from bright@rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.9.3/8.9.3) with SMTP id AAA11980; Tue, 13 Jul 1999 00:15:59 -0400 (EDT) Date: Mon, 12 Jul 1999 23:15:57 -0500 (EST) From: Alfred Perlstein To: "Daniel C. Sobral" Cc: Jon Ribbens , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <378A8D4C.AFDCCD66@newsguy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, Daniel C. Sobral wrote: > Jon Ribbens wrote: > > > > "Daniel C. Sobral" wrote: > > > That's *not* abomination. How about pre-allocating over 100 Mb for X > > > Free, for instance? > > > > What about it? If an application does not need 100MB, it should not > > malloc it. If it does need it, it should malloc it and know that it > > is available if the malloc succeeds. > > Well, learn something about real programs first, and then come back. > > > > Basically, if you don't have enough memory, you just don't have enough > > > memory. > > > > Yes, and the application should be told this via the standard > > documented interface for doing so, i.e. returning NULL from > > malloc(). > > This results in the applications working with less memory than would > actually be possible through overcommit. > > > > What FreeBSD does *reduces* the need for memory. If FreeBSD *did > > > not* do it, then you'd need much more memory. > > > > Why? Are there really such a lot of applications allocating vastly > > more memory than they actually use? > > Right. > You're not really being fair by giving such simple answers, not that it hasn't been discussed TO DEATH already so i understand your indifference. :) I didn't understand the reasoning of over commit until I was pointed out this scenario: (let's use netscape because it is huge) You're browsing with netscape and It hits about 32megs in size, you click on a multimedia object and netscape execs a helper app. at the moment of the fork you have a major overcommit, considering private mappings and allocated memory that is suddenly doubled when under a second later you will exec a program that is only a meg or so. you also have to consider a program wishing to make sparse use of its address space, without overcommit it becomes impossible. if you want to impose limits, use /etc/login.conf, nuff said. -Alfred Perlstein - [bright@rush.net|bright@wintelcom.net] systems administrator and programmer Win Telecom - http://www.wintelcom.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 0: 3:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id 32A6514C2F; Tue, 13 Jul 1999 00:03:34 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id JAA09698; Tue, 13 Jul 1999 09:58:10 +0300 (EEST) (envelope-from will) To: green@FreeBSD.org (Brian F. Feldman) Cc: hackers@FreeBSD.org Subject: Re: a BSD identd References: <53426.931766563@axl.noc.iafrica.com> From: Ville-Pertti Keinonen Date: 13 Jul 1999 09:58:09 +0300 In-Reply-To: green@FreeBSD.org's message of "12 Jul 1999 22:14:21 +0300" Message-ID: <86908l829q.fsf@not.demophon.com> Lines: 18 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG green@FreeBSD.org (Brian F. Feldman) writes: > It's "out with the bad, in with the good." Pidentd code is pretty terrible. > The only security concerns with my code were wrt FAKEID, and those were > mostly fixed (mostly meaning that a symlink _may_ be opened, but it won't > be read.) If anyone wants to audit my code for security, I invite them to. Did you mean to avoid reading through symlinks using the open + fstat method mentioned earlier in the thread? I thought I'd misunderstood, that you had to be discussing something else, since you and whoever else was involved both agreed that open + fstat is sufficient, and I thought that several people can't possibly be so completely confused. If you really want to avoid reading through symlinks, you need to lstat, open and fstat (the order doesn't really matter). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 1:39:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from oskar.nanoteq.co.za (oskar.nanoteq.co.za [196.37.91.10]) by hub.freebsd.org (Postfix) with ESMTP id 1A69D14BF4 for ; Tue, 13 Jul 1999 01:39:27 -0700 (PDT) (envelope-from rbezuide@oskar.nanoteq.co.za) Received: (from rbezuide@localhost) by oskar.nanoteq.co.za (8.9.0/8.9.0) id KAA27576 for freebsd-hackers@freebsd.org; Tue, 13 Jul 1999 10:39:05 +0200 (SAT) From: Reinier Bezuidenhout Message-Id: <199907130839.KAA27576@oskar.nanoteq.co.za> Subject: Boot messages on console in 3.2 To: freebsd-hackers@freebsd.org Date: Tue, 13 Jul 1999 10:39:03 +0200 (SAT) X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi ... I'm trying to get a 3.2-STABLE to boot via the serial console. I can get the "boot: " rompt and loader to display to the serial console, but after the 9 second delay it continues to boot but no output is generated to the screen (device probes etc.). After the boot has completed, the login prompt is displayed on the console and I can login. I just want it to display the boot information (probes ... hd ... etc.) the /boot.config file has the following option -h and that is the only line ... I have tried both -h and -P ... I have tried only -P The "show" command under loader shows that the console is set to comconsole I've also treid a kernel with "flags 0x01" to the atkbd ... but it also doesn't work and the "options COMCONSOLE" for the kernel is nolonger allowed according to config. Any ideas ? Thanx Reinier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 1:50:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.is4b.net (peach.oaktree.net.uk [193.82.129.13]) by hub.freebsd.org (Postfix) with ESMTP id 518EE14CA1 for ; Tue, 13 Jul 1999 01:50:19 -0700 (PDT) (envelope-from jon@chalk.oaktree.net.uk) Received: from chalk.oaktree.net.uk (chalk.oaktree.net.uk [193.82.129.19]) by relay.is4b.net (Postfix) with ESMTP id 040011DC11; Tue, 13 Jul 1999 09:49:48 +0100 (BST) Received: (from jon@localhost) by chalk.oaktree.net.uk (8.9.3/8.9.3) id JAA26470; Tue, 13 Jul 1999 09:49:47 +0100 (BST) Date: Tue, 13 Jul 1999 09:49:47 +0100 From: Jon Ribbens To: "Daniel C. Sobral" Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) Message-ID: <19990713094947.B10979@oaktree.co.uk> Mail-Followup-To: "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org References: <19990712235629.A2152@oaktree.co.uk> <89001.931820500@axl.noc.iafrica.com> <19990713002027.A19153@oaktree.co.uk> <378A8D8C.B13F6E9F@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <378A8D8C.B13F6E9F@newsguy.com>; from Daniel C. Sobral on Tue, Jul 13, 1999 at 09:51:24AM +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel C. Sobral" wrote: > > I can add it to the list of reasons I don't use it then I guess ;-). > > Whatever. The operating system you use also does it. How terribly tedious. Cheers Jon -- \/ Jon Ribbens / jon@oaktree.co.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 1:56:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bilby.prth.tensor.pgs.com (bilby.prth.tensor.pgs.com [157.147.232.237]) by hub.freebsd.org (Postfix) with ESMTP id AF49F14EA1 for ; Tue, 13 Jul 1999 01:56:22 -0700 (PDT) (envelope-from shocking@ariadne.prth.tensor.pgs.com) Received: from bandicoot.prth.tensor.pgs.com (bandicoot.prth.tensor.pgs.com [157.147.224.1]) by bilby.prth.tensor.pgs.com (8.9.3/8.8.8) with ESMTP id QAA21084 for ; Tue, 13 Jul 1999 16:55:02 +0800 (WST) Received: from ariadne.tensor.pgs.com (ariadne [157.147.227.36]) by bandicoot.prth.tensor.pgs.com (8.9.3/8.8.8) with SMTP id QAA22765 for ; Tue, 13 Jul 1999 16:56:14 +0800 (WST) Received: from ariadne by ariadne.tensor.pgs.com (SMI-8.6/SMI-SVR4) id QAA12434; Tue, 13 Jul 1999 16:56:14 +0800 Message-Id: <199907130856.QAA12434@ariadne.tensor.pgs.com> X-Mailer: exmh version 2.0.2 2/24/98 To: hackers@freebsd.org Subject: Setting up a firewall with dynamic IPs Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jul 1999 16:56:13 +0800 From: Stephen Hocking-Senior Programmer PGS Tensor Perth Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I was checking out the firewall setup in /etc/rc.firewall, and noticed that the simple example relied on a fixed IP address for the external interface. I don't know ahead of time what IP address is going to be allocated to me before I dial up. Would it be possible to specify an interface (tun0) rather than an IP address? Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true." Robert Wilensky, University of California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 1:57:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by hub.freebsd.org (Postfix) with ESMTP id 9325B15300 for ; Tue, 13 Jul 1999 01:57:08 -0700 (PDT) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:CLDKCsizYEq+2zqJOYOjJX1Fw5VJjKdy@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by outmail.utsunomiya-u.ac.jp (8.9.3/3.7Wpl2) with ESMTP id RAA11085; Tue, 13 Jul 1999 17:55:10 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id RAA20933; Tue, 13 Jul 1999 17:59:25 +0900 (JST) Message-Id: <199907130859.RAA20933@zodiac.mech.utsunomiya-u.ac.jp> To: Reinier Bezuidenhout Cc: freebsd-hackers@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: Boot messages on console in 3.2 In-reply-to: Your message of "Sat, 13 Jul 1999 10:39:03 +0200." <199907130839.KAA27576@oskar.nanoteq.co.za> References: <199907130839.KAA27576@oskar.nanoteq.co.za> Date: Tue, 13 Jul 1999 17:59:24 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >I'm trying to get a 3.2-STABLE to boot via the serial console. > >I can get the "boot: " rompt and loader to display to the serial >console, but after the 9 second delay it continues to boot but >no output is generated to the screen (device probes etc.). > >After the boot has completed, the login prompt is displayed on the >console and I can login. I just want it to display the boot >information (probes ... hd ... etc.) > >the /boot.config file has the following option >-h > >and that is the only line ... I have tried both -h and -P ... >I have tried only -P > >The "show" command under loader shows that the console is set to >comconsole > >I've also treid a kernel with "flags 0x01" to the atkbd ... but >it also doesn't work and the "options COMCONSOLE" for the kernel >is nolonger allowed according to config. You should set the flags 0x10 to the serial port you want to use as the console. See the man page for sio(4) and /sys/i386/boot/biosboot/README.serial. (I know /sys/i386/boot/biosboot is a strange place to look for this information, but... :-) Kazu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 2: 2:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.is4b.net (peach.oaktree.net.uk [193.82.129.13]) by hub.freebsd.org (Postfix) with ESMTP id 8819315265 for ; Tue, 13 Jul 1999 02:02:30 -0700 (PDT) (envelope-from jon@chalk.oaktree.net.uk) Received: from chalk.oaktree.net.uk (chalk.oaktree.net.uk [193.82.129.19]) by relay.is4b.net (Postfix) with ESMTP id 6AB781DC34; Tue, 13 Jul 1999 10:02:28 +0100 (BST) Received: (from jon@localhost) by chalk.oaktree.net.uk (8.9.3/8.9.3) id KAA24432; Tue, 13 Jul 1999 10:02:28 +0100 (BST) Date: Tue, 13 Jul 1999 10:02:28 +0100 From: Jon Ribbens To: Alfred Perlstein Cc: "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) Message-ID: <19990713100228.C10979@oaktree.co.uk> Mail-Followup-To: Alfred Perlstein , "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org References: <378A8D4C.AFDCCD66@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Alfred Perlstein on Mon, Jul 12, 1999 at 11:15:57PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > You're browsing with netscape and It hits about 32megs in size, > you click on a multimedia object and netscape execs a helper app. vfork() > you also have to consider a program wishing to make sparse use > of its address space, without overcommit it becomes impossible. So Don't Do That Then. Cheers Jon -- \/ Jon Ribbens / jon@oaktree.co.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 2:13:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2]) by hub.freebsd.org (Postfix) with ESMTP id 510001501E for ; Tue, 13 Jul 1999 02:13:08 -0700 (PDT) (envelope-from soda@sra.co.jp) Received: from sranhf.sra.co.jp (sranhf [133.137.28.3]) by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id SAA21438; Tue, 13 Jul 1999 18:12:35 +0900 (JST) Received: from srapc342.sra.co.jp (srapc342 [133.137.28.111]) by sranhf.sra.co.jp (8.8.7/3.6Wbeta7-srambox) with ESMTP id SAA03701; Tue, 13 Jul 1999 18:12:34 +0900 (JST) Received: (from soda@localhost) by srapc342.sra.co.jp (8.8.8/3.4W-sra) id SAA07964; Tue, 13 Jul 1999 18:12:35 +0900 (JST) Date: Tue, 13 Jul 1999 18:12:35 +0900 (JST) From: Noriyuki Soda Message-Id: <199907130912.SAA07964@srapc342.sra.co.jp> To: bright@rush.net, dcs@newsguy.com Subject: Re: Replacement for grep(1) (part 2) Cc: freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org, tech@openbsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > You're browsing with netscape and It hits about 32megs in size, > you click on a multimedia object and netscape execs a helper app. If the system has real vfork(2) like NetBSD, this is not problem. > you also have to consider a program wishing to make sparse use > of its address space, without overcommit it becomes impossible. SVR4 has MAP_NORESERVE option for mmap(2) for this. So, default behaivour don't have to be overcommitment. -- soda To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 2:16: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay03.indigo.ie (relay03.indigo.ie [194.125.133.227]) by hub.freebsd.org (Postfix) with SMTP id 8E9761501E for ; Tue, 13 Jul 1999 02:15:50 -0700 (PDT) (envelope-from niall@pobox.com) Received: (qmail 22387 messnum 46251 invoked from network[194.125.134.40/ts01-040.dublin.indigo.ie]); 13 Jul 1999 09:15:19 -0000 Received: from ts01-040.dublin.indigo.ie (HELO pobox.com) (194.125.134.40) by relay03.indigo.ie (qp 22387) with SMTP; 13 Jul 1999 09:15:19 -0000 Message-ID: <378B1EBD.EB06F5B9@pobox.com> Date: Tue, 13 Jul 1999 11:10:53 +0000 From: Niall Smart X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Sheldon Hearn Cc: hackers@freebsd.org Subject: Re: bin/12578: `` subshell taints PWD References: <74394.931798425@axl.noc.iafrica.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn wrote: > > On Mon, 12 Jul 1999 18:37:13 GMT, Niall Smart wrote: > > > The patch appended seems to fix this, I'd like someone familiar > > with sh to review it though, since this may be symptomatic of > > a general problem with command substitution. > > As I understand your patch, you're saying "we should fork off a child > process when the command in question is cd"? This is what I missed when > I tried ``echo .`sleep 600`.'' and assumed that the result was proof > that we always spawn a subprocess for backtick evaluation. :-( As I understand it most builtins will not spawn a new shell when they are used in command substitution: niall% echo `echo $$` $$ 20354 20354 niall% Niall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 2:29:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay03.indigo.ie (relay03.indigo.ie [194.125.133.227]) by hub.freebsd.org (Postfix) with SMTP id 4265F14EF1 for ; Tue, 13 Jul 1999 02:29:39 -0700 (PDT) (envelope-from niall@pobox.com) Received: (qmail 26161 messnum 46249 invoked from network[194.125.134.40/ts01-040.dublin.indigo.ie]); 13 Jul 1999 09:28:55 -0000 Received: from ts01-040.dublin.indigo.ie (HELO pobox.com) (194.125.134.40) by relay03.indigo.ie (qp 26161) with SMTP; 13 Jul 1999 09:28:55 -0000 Message-ID: <378B21EE.9E41D3E8@pobox.com> Date: Tue, 13 Jul 1999 11:24:30 +0000 From: Niall Smart X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Brian F. Feldman" Cc: Sheldon Hearn , Doug , John Polstra , imp@village.org, hackers@FreeBSD.org Subject: Re: a BSD identd References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Brian F. Feldman" wrote: > On Mon, 12 Jul 1999, Sheldon Hearn wrote: > > On Sun, 11 Jul 1999 12:47:30 MST, Doug wrote: > > > > > Finally, Brian might want to search the bugtraq archives before > > > he commits anything. There have been quite a few identd related > > > discussions, and it would be points in our favor if we didn't come out > > > with anything that had known exploits. [snip] > > It's "out with the bad, in with the good." Pidentd code is pretty terrible. Agreed, nobody wants a monstrosity of an ident daemon in the base system. > The only security concerns with my code were wrt FAKEID, and those were > mostly fixed (mostly meaning that a symlink _may_ be opened, but it won't > be read.) Your code is still insecure, I can still obtain 16 characters of the first line of any file in the system just by symlinking to it. I don't see how you expect your checks to defeat that. What you should do is setgid && setuid to the user returned by net.inet.tcp.getcred immediately after doing the sysctl. Or even better take out this FAKEID stuff. > If anyone wants to audit my code for security, I invite them to. > But frankly, I highly doubt anyone will find anything to exploit. Heh, famous last words. > And, why would bugtraq advisories against other identds apply to my > ident_stream service? This is an entirely different code base. That doesn't matter, different programmers make the same mistakes and assumptions when solving the same problem (there is research into the effectiveness of N-way programming which shows this) and many attacks are against subtle implementation mistakes which you may also make. Regards, Niall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 5:46:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (Postfix) with ESMTP id 4FCED14FD6 for ; Tue, 13 Jul 1999 05:46:43 -0700 (PDT) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg (bragg [129.127.36.34]) by adelphi.physics.adelaide.edu.au (8.8.8/8.8.8/UofA-1.5) with SMTP id WAA07777; Tue, 13 Jul 1999 22:16:40 +0930 (CST) Received: from localhost by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA07219; Tue, 13 Jul 1999 22:16:38 +0930 Date: Tue, 13 Jul 1999 22:16:32 +0930 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: Stephen Hocking-Senior Programmer PGS Tensor Perth Cc: hackers@freebsd.org Subject: Re: Setting up a firewall with dynamic IPs In-Reply-To: <199907130856.QAA12434@ariadne.tensor.pgs.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: > I was checking out the firewall setup in /etc/rc.firewall, and noticed that > the simple example relied on a fixed IP address for the external interface. I > don't know ahead of time what IP address is going to be allocated to me before > I dial up. Would it be possible to specify an interface (tun0) rather than an > IP address? You could probably do it from /etc/ppp/ppp.linkup, which knows your IP address as MYADDR. But if you just have asingle machine on the end of the dialup then I find I can get away with just specifying the netmask from which the dialup IPs are assigned in place of a single address - all that can happen is that packets get through your firewall destined to a nonexistent address (i.e. if you allow incoming port Y traffic then people can send to port Y on nonexistent IP addresses (i.e. your peer addresses) which will be dropped by the kernel). Kris ----- "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 5:57:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from prova.iet.unipi.it (slip17.unipi.it [131.114.14.1]) by hub.freebsd.org (Postfix) with ESMTP id C954A152AD for ; Tue, 13 Jul 1999 05:57:07 -0700 (PDT) (envelope-from luigi@iet.unipi.it) Received: (from luigi@localhost) by prova.iet.unipi.it (8.8.8/8.8.8) id OAA00397 for hackers@freebsd.org; Tue, 13 Jul 1999 14:50:35 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <199907131250.OAA00397@prova.iet.unipi.it> Subject: Why 'dd' does not seek over 'char' devs (specifically raw disk partitions). To: hackers@freebsd.org Date: Tue, 13 Jul 1999 14:50:34 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, i have a question. Why 'dd' does not seek over 'char' devs (specifically raw disk partitions). My point is, when a disk develops problems, sometimes it is possible to recover nearby sectors e.g. using dd, and seeking to the right block. However running dd over the char device (rwd*) takes forever because the seek on char devices is implemented by reading instead. Using the cooked device is problematic because the buffering causes multiple sectors to be read and this may cause errors if some block nearby has problems. I notice that on output lseek _is_ used also on char devices. Ideas ? cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 6: 3:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from unix2.it-datacntr.louisville.edu (unix2.it-datacntr.louisville.edu [136.165.4.28]) by hub.freebsd.org (Postfix) with ESMTP id 80B6B14CA8 for ; Tue, 13 Jul 1999 06:03:33 -0700 (PDT) (envelope-from k.stevenson@louisville.edu) Received: from homer.louisville.edu (ktstev01@homer.louisville.edu [136.165.1.20]) by unix2.it-datacntr.louisville.edu (8.8.8/8.8.8) with ESMTP id JAA26650 for ; Tue, 13 Jul 1999 09:02:52 -0400 Received: (from ktstev01@localhost) by homer.louisville.edu (8.8.8/8.8.8) id JAA09793 for freebsd-hackers@freebsd.org; Tue, 13 Jul 1999 09:03:32 -0400 (EDT) Message-ID: <19990713090332.A8897@homer.louisville.edu> Date: Tue, 13 Jul 1999 09:03:32 -0400 From: Keith Stevenson To: freebsd-hackers@freebsd.org Subject: Re: Setting up a firewall with dynamic IPs References: <199907130856.QAA12434@ariadne.tensor.pgs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Kris Kennaway on Tue, Jul 13, 1999 at 10:16:32PM +0930 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 13, 1999 at 10:16:32PM +0930, Kris Kennaway wrote: > On Tue, 13 Jul 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: > > > I was checking out the firewall setup in /etc/rc.firewall, and noticed that > > the simple example relied on a fixed IP address for the external interface. I > > don't know ahead of time what IP address is going to be allocated to me before > > I dial up. Would it be possible to specify an interface (tun0) rather than an > > IP address? > > You could probably do it from /etc/ppp/ppp.linkup, which knows your IP address > as MYADDR. But if you just have asingle machine on the end of the dialup then > I find I can get away with just specifying the netmask from which the dialup > IPs are assigned in place of a single address - all that can happen is that > packets get through your firewall destined to a nonexistent address (i.e. if > you allow incoming port Y traffic then people can send to port Y on > nonexistent IP addresses (i.e. your peer addresses) which will be dropped by > the kernel). Keep in mind that if securelevel > 2, the ipfw rules can not be changed. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.stevenson@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 6:29:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mailgw00.execpc.com (mailgw00.execpc.com [169.207.1.78]) by hub.freebsd.org (Postfix) with ESMTP id 885B5152F3 for ; Tue, 13 Jul 1999 06:29:41 -0700 (PDT) (envelope-from hamilton@pobox.com) Received: from woodstock.monkey.net (obica-1-175.mdm.mkt.execpc.com [169.207.90.49]) by mailgw00.execpc.com (8.9.1) id IAA27339; Tue, 13 Jul 1999 08:29:33 -0500 Received: from pobox.com (localhost [127.0.0.1]) by woodstock.monkey.net (Postfix) with ESMTP id 342EF200; Tue, 13 Jul 1999 08:29:30 -0500 (CDT) To: Kris Kennaway Cc: Stephen Hocking-Senior Programmer PGS Tensor Perth , hackers@freebsd.org Subject: Re: Setting up a firewall with dynamic IPs In-reply-to: Your message of "Tue, 13 Jul 1999 22:16:32 +0930." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jul 1999 08:29:29 -0500 From: Jon Hamilton Message-Id: <19990713132930.342EF200@woodstock.monkey.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Kris Kennaway wrote : } On Tue, 13 Jul 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote } : } } > I was checking out the firewall setup in /etc/rc.firewall, and noticed } > that the simple example relied on a fixed IP address for the external } > interface. I don't know ahead of time what IP address is going to be } > allocated to me before I dial up. Would it be possible to specify an } > interface (tun0) rather than an IP address? } } You could probably do it from /etc/ppp/ppp.linkup, which knows your IP } address as MYADDR. But if you just have asingle machine on the end of the } dialup then You can do it as the original poster was thinking as well by specifying the "recv $interface" parameter. See ipfw(8) for details. } I find I can get away with just specifying the netmask from which the dialup } IPs are assigned in place of a single address - all that can happen is that } packets get through your firewall destined to a nonexistent address (i.e. if } you allow incoming port Y traffic then people can send to port Y on } nonexistent IP addresses (i.e. your peer addresses) which will be dropped by } the kernel). That approach will lose if you change ISPs or if your ISP changes or expands its dynamic IP pool. There's also a small window between the time your ppp connection is established and the time ppp.linkup is executed; better to do this based on interface. -- Jon Hamilton hamilton@pobox.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 6:54:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 4AD2114D94 for ; Tue, 13 Jul 1999 06:54:15 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id JAA76732; Tue, 13 Jul 1999 09:51:43 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 13 Jul 1999 09:51:43 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Ville-Pertti Keinonen Cc: hackers@FreeBSD.org Subject: Re: a BSD identd In-Reply-To: <86908l829q.fsf@not.demophon.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 13 Jul 1999, Ville-Pertti Keinonen wrote: > > green@FreeBSD.org (Brian F. Feldman) writes: > > > It's "out with the bad, in with the good." Pidentd code is pretty terrible. > > The only security concerns with my code were wrt FAKEID, and those were > > mostly fixed (mostly meaning that a symlink _may_ be opened, but it won't > > be read.) If anyone wants to audit my code for security, I invite them to. > > Did you mean to avoid reading through symlinks using the open + fstat > method mentioned earlier in the thread? No, I meant to avoid opening a file the user couldn't, or reading from a dev. > > I thought I'd misunderstood, that you had to be discussing something > else, since you and whoever else was involved both agreed that open + > fstat is sufficient, and I thought that several people can't possibly > be so completely confused. > > If you really want to avoid reading through symlinks, you need to > lstat, open and fstat (the order doesn't really matter). > I don't care about symlinks. I care about the underlying file. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 7: 8:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id AF40014D94 for ; Tue, 13 Jul 1999 07:08:43 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id KAA77018; Tue, 13 Jul 1999 10:08:36 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 13 Jul 1999 10:08:36 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Stephen Hocking-Senior Programmer PGS Tensor Perth Cc: hackers@FreeBSD.org Subject: Re: Setting up a firewall with dynamic IPs In-Reply-To: <199907130856.QAA12434@ariadne.tensor.pgs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, Stephen Hocking-Senior Programmer PGS Tensor Perth wrote: > I was checking out the firewall setup in /etc/rc.firewall, and noticed that > the simple example relied on a fixed IP address for the external interface. I > don't know ahead of time what IP address is going to be allocated to me before > I dial up. Would it be possible to specify an interface (tun0) rather than an > IP address? Yes. That's what the "via" keyword is for. > > > Stephen > -- > The views expressed above are not those of PGS Tensor. > > "We've heard that a million monkeys at a million keyboards could produce > the Complete Works of Shakespeare; now, thanks to the Internet, we know > this is not true." Robert Wilensky, University of California > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 7:13:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 7FAE015030 for ; Tue, 13 Jul 1999 07:13:28 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id KAA77129; Tue, 13 Jul 1999 10:11:14 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 13 Jul 1999 10:11:14 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Noriyuki Soda Cc: bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.org, jon@oaktree.co.uk, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <199907130912.SAA07964@srapc342.sra.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, Noriyuki Soda wrote: > > You're browsing with netscape and It hits about 32megs in size, > > you click on a multimedia object and netscape execs a helper app. > > If the system has real vfork(2) like NetBSD, this is not problem. > > > you also have to consider a program wishing to make sparse use > > of its address space, without overcommit it becomes impossible. > > SVR4 has MAP_NORESERVE option for mmap(2) for this. > So, default behaivour don't have to be overcommitment. Isn't that just like mmap()ing then mlock()ing the range? That would keep it in core. > -- > soda > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 7:19:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (Postfix) with ESMTP id 72A7014F90 for ; Tue, 13 Jul 1999 07:19:32 -0700 (PDT) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg (bragg [129.127.36.34]) by adelphi.physics.adelaide.edu.au (8.8.8/8.8.8/UofA-1.5) with SMTP id XAA07607; Tue, 13 Jul 1999 23:49:20 +0930 (CST) Received: from localhost by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA25199; Tue, 13 Jul 1999 23:49:19 +0930 Date: Tue, 13 Jul 1999 23:49:15 +0930 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: Jon Hamilton Cc: Stephen Hocking-Senior Programmer PGS Tensor Perth , hackers@freebsd.org Subject: Re: Setting up a firewall with dynamic IPs In-Reply-To: <19990713132930.342EF200@woodstock.monkey.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, Jon Hamilton wrote: > } You could probably do it from /etc/ppp/ppp.linkup, which knows your IP > } address as MYADDR. But if you just have asingle machine on the end of the > } dialup then > > You can do it as the original poster was thinking as well by specifying the > "recv $interface" parameter. See ipfw(8) for details. I just checked my firewall config and this is, indeed, how I do it :-) Sorry.. Kris ----- "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 7:22:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id CDE1B14F90 for ; Tue, 13 Jul 1999 07:22:25 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id KAA77308; Tue, 13 Jul 1999 10:20:21 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 13 Jul 1999 10:20:21 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Niall Smart Cc: Sheldon Hearn , Doug , John Polstra , imp@village.org, hackers@FreeBSD.org Subject: Re: a BSD identd In-Reply-To: <378B21EE.9E41D3E8@pobox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, Niall Smart wrote: > "Brian F. Feldman" wrote: > > > On Mon, 12 Jul 1999, Sheldon Hearn wrote: > > > On Sun, 11 Jul 1999 12:47:30 MST, Doug wrote: > > > > > > > Finally, Brian might want to search the bugtraq archives before > > > > he commits anything. There have been quite a few identd related > > > > discussions, and it would be points in our favor if we didn't come out > > > > with anything that had known exploits. > [snip] > > > > It's "out with the bad, in with the good." Pidentd code is pretty terrible. > > Agreed, nobody wants a monstrosity of an ident daemon in the base > system. > > > The only security concerns with my code were wrt FAKEID, and those were > > mostly fixed (mostly meaning that a symlink _may_ be opened, but it won't > > be read.) > > Your code is still insecure, I can still obtain 16 characters of the > first line of any file in the system just by symlinking to it. I > don't see how you expect your checks to defeat that. What you should > do is setgid && setuid to the user returned by net.inet.tcp.getcred > immediately after doing the sysctl. Actually, I need to seteuid and setegid, because a setuid/setgid gives the user access to ident's process space. Anyway, I just forgot to upload the latest version of the patch. I also nuked it on MY system :/ But I just rewrote it (a bit better, too.) It's updated on freefall now. > > Or even better take out this FAKEID stuff. I'd rather keep it in, non-default, and semi-supported. > > > If anyone wants to audit my code for security, I invite them to. > > But frankly, I highly doubt anyone will find anything to exploit. > > Heh, famous last words. Is this my last stand? > > > And, why would bugtraq advisories against other identds apply to my > > ident_stream service? This is an entirely different code base. > > That doesn't matter, different programmers make the same mistakes > and assumptions when solving the same problem (there is research > into the effectiveness of N-way programming which shows this) and > many attacks are against subtle implementation mistakes which you > may also make. Ahh, but I don't make assumptions on input. I know that anything can happen. so prepare for the worst. Most mistakes are made by programmers when they assume that all input is safe. * > > Regards, > > Niall > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ * exploitable security holes To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 7:30:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2]) by hub.freebsd.org (Postfix) with ESMTP id B582C151E3; Tue, 13 Jul 1999 07:30:52 -0700 (PDT) (envelope-from soda@sra.co.jp) Received: from sranhf.sra.co.jp (sranhf [133.137.28.3]) by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id XAA06904; Tue, 13 Jul 1999 23:28:22 +0900 (JST) Received: from srapc342.sra.co.jp (srapc342 [133.137.28.111]) by sranhf.sra.co.jp (8.8.7/3.6Wbeta7-srambox) with ESMTP id XAA03944; Tue, 13 Jul 1999 23:28:20 +0900 (JST) Received: (from soda@localhost) by srapc342.sra.co.jp (8.8.8/3.4W-sra) id XAA09584; Tue, 13 Jul 1999 23:28:21 +0900 (JST) Date: Tue, 13 Jul 1999 23:28:21 +0900 (JST) Message-Id: <199907131428.XAA09584@srapc342.sra.co.jp> From: Noriyuki Soda To: "Brian F. Feldman" Cc: Noriyuki Soda , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.org, jon@oaktree.co.uk, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: References: <199907130912.SAA07964@srapc342.sra.co.jp> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> On Tue, 13 Jul 1999 10:11:14 -0400 (EDT), "Brian F. Feldman" said: >> > you also have to consider a program wishing to make sparse use >> > of its address space, without overcommit it becomes impossible. >> >> SVR4 has MAP_NORESERVE option for mmap(2) for this. >> So, default behaivour don't have to be overcommitment. > Isn't that just like mmap()ing then mlock()ing the range? That would > keep it in core. No. MAP_NORESERVE is nothing related to page wiring (i.e. mlock()ing). From Solaris 2.6 man page: : The MAP_NORESERVE option specifies that no swap space be : reserved for a mapping. Without this flag, the creation of : a writable MAP_PRIVATE mapping reserves swap space equal to : the size of the mapping; when the mapping is written into, : the reserved space is employed to hold private copies of the : data. A write into a MAP_NORESERVE mapping produces results : which depend on the current availability of swap space in : the system. If space is available, the write succeeds and a : private copy of the written page is created; if space is not : available, the write fails and a SIGBUS or SIGSEGV signal is : delivered to the writing process. MAP_NORESERVE mappings are : inherited across fork(); at the time of the fork(), swap : space is reserved in the child for all private pages that : currently exist in the parent; thereafter the child's map- : ping behaves as described above. -- soda To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 7:37:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 2B49715132 for ; Tue, 13 Jul 1999 07:37:17 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id KAA77622; Tue, 13 Jul 1999 10:36:17 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 13 Jul 1999 10:36:17 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Luigi Rizzo Cc: hackers@FreeBSD.org Subject: Re: Why 'dd' does not seek over 'char' devs (specifically raw disk partitions). In-Reply-To: <199907131250.OAA00397@prova.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, Luigi Rizzo wrote: > Hi, i have a question. > > Why 'dd' does not seek over 'char' devs (specifically raw disk partitions). Not all character devices support seeking. So, we work with the LCD... Sorry, I don't like this either. It would be better, maybe, just to fix character devices. > > My point is, when a disk develops problems, sometimes it is possible > to recover nearby sectors e.g. using dd, and seeking to the right > block. However running dd over the char device (rwd*) takes forever > because the seek on char devices is implemented by reading instead. > Using the cooked device is problematic because the buffering causes > multiple sectors to be read and this may cause errors if some block > nearby has problems. You certainly make a good case. modify your local copy of dd to do what you want. > > I notice that on output lseek _is_ used also on char devices. And how else would you do it? > > Ideas ? > > cheers > luigi > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 7:41:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id D102F1531F; Tue, 13 Jul 1999 07:41:34 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id OAA08560; Tue, 13 Jul 1999 14:12:51 +0200 From: Luigi Rizzo Message-Id: <199907131212.OAA08560@labinfo.iet.unipi.it> Subject: Re: Why 'dd' does not seek over 'char' devs (specifically raw disk To: green@FreeBSD.org (Brian F. Feldman) Date: Tue, 13 Jul 1999 14:12:51 +0200 (MET DST) Cc: luigi@iet.unipi.it, hackers@FreeBSD.org In-Reply-To: from "Brian F. Feldman" at Jul 13, 99 10:35:58 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1193 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Hi, i have a question. > > > > Why 'dd' does not seek over 'char' devs (specifically raw disk partitions). > > Not all character devices support seeking. So, we work with the LCD... > Sorry, I don't like this either. It would be better, maybe, just to fix > character devices. couldn't we first try lseek and only do the reads on char devs where the lseek fails ? > You certainly make a good case. modify your local copy of dd to do > what you want. generally this is not the kind of things you can do when your system has already gone bad (this was a laptop's disk...) > > > > I notice that on output lseek _is_ used also on char devices. > > And how else would you do it? ok, stupid observation! cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ ==== First International Workshop on Networked Group Communication ==== -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 7:45:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 1465215132 for ; Tue, 13 Jul 1999 07:45:18 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id KAA77800; Tue, 13 Jul 1999 10:45:06 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 13 Jul 1999 10:45:05 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Luigi Rizzo Cc: luigi@iet.unipi.it, hackers@FreeBSD.org Subject: Re: Why 'dd' does not seek over 'char' devs (specifically raw disk In-Reply-To: <199907131212.OAA08560@labinfo.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, Luigi Rizzo wrote: > > > Hi, i have a question. > > > > > > Why 'dd' does not seek over 'char' devs (specifically raw disk partitions). > > > > Not all character devices support seeking. So, we work with the LCD... > > Sorry, I don't like this either. It would be better, maybe, just to fix > > character devices. > > couldn't we first try lseek and only do the reads on char devs where > the lseek fails ? lseek() won't usually fail unless it's something like EBADF. It merely sets the current fd's offset. It would be nice to be able to tell from a device driver if it supports seeking (da) or not (sa). Hmm... actually, if we just specify somehow that we support either direct or sequential access... this would be possible. > > > You certainly make a good case. modify your local copy of dd to do > > what you want. > > generally this is not the kind of things you can do when your system > has already gone bad (this was a laptop's disk...) > The problem is that dd skip= is used a lot on tape devices. Here, a seek would not work. > > > > > > I notice that on output lseek _is_ used also on char devices. > > > > And how else would you do it? > > ok, stupid observation! > > cheers > luigi > > -----------------------------------+------------------------------------- > Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione > http://www.iet.unipi.it/~luigi/ . Universita` di Pisa > TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) > > http://www.iet.unipi.it/~luigi/ngc99/ > ==== First International Workshop on Networked Group Communication ==== > -----------------------------------+------------------------------------- > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 7:57:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from Thingol.KryptoKom.DE (Thingol.KryptoKom.DE [194.245.91.1]) by hub.freebsd.org (Postfix) with ESMTP id 1A08915310 for ; Tue, 13 Jul 1999 07:57:28 -0700 (PDT) (envelope-from eT@post.com) Received: (from root@localhost) by Thingol.KryptoKom.DE (8.9.1/8.9.1) id SAA23766 for ; Tue, 13 Jul 1999 18:54:18 +0200 Received: from cirdan.kryptokom.de by KryptoWall via smtpp (Version 1.2.0) id kwa23749; Tue Jul 13 18:54:08 1999 Received: from fwd.kryptokom.de ([192.168.6.40]) by Cirdan.KryptoKom.DE (8.8.8/8.8.8) with ESMTP id RAA31437 for ; Tue, 13 Jul 1999 17:04:56 +0200 Received: from post.com (localhost [127.0.0.1]) by fwd.kryptokom.de (8.9.2/8.9.2) with ESMTP id RAA00820 for ; Tue, 13 Jul 1999 17:00:46 +0200 (CEST) (envelope-from eT@post.com) Message-ID: <378B549C.4C511A98@post.com> Date: Tue, 13 Jul 1999 17:00:44 +0200 From: eT Reply-To: eT@post.com X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: hackers@freebsd.org Subject: Which device should I make with this error? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG During a make release for 3.2-RELEASE I get the following error: Making the regular boot floppy. Compressing doc files... sh -e /usr/src/release/scripts/doFS.sh -s mfsroot /R/stage /mnt 2880 /R/stage/m fsfd 8000 minimum2 vnconfig: open: Device not configured *** Error code 1 Stop. *** Error code 1 What does this mean and how do I fix it? Thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 8:11:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bubba.whistle.com (s205m7.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id D7DB21533A for ; Tue, 13 Jul 1999 08:11:31 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id SAA39852; Sun, 11 Jul 1999 18:54:51 -0700 (PDT) From: Archie Cobbs Message-Id: <199907120154.SAA39852@bubba.whistle.com> Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <19990712022424.A1390@oaktree.co.uk> from Jon Ribbens at "Jul 12, 99 02:24:24 am" To: jon@oaktree.co.uk (Jon Ribbens) Date: Sun, 11 Jul 1999 18:54:51 -0700 (PDT) Cc: dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jon Ribbens writes: > > Because memory (as in *real* memory, either RAM or swap) is > > allocated on-demand. So you can allocate any amount of virtual > > memory that the system can possibly provide you, even though you'll > > run out of memory much earlier, because other resources are also > > consuming it. > > Yuck. That's a complete abomination. What's the point of it? It's turning > an out-of-memory situation from an easily-detected recoverable temporary > resource shortage which can be worked-around or waited out, into an > unrecoverable fatal error. Do a significant number of programs really > request memory which they then proceed not to use? See the various threads from years past regarding the overcommit debate. In short, it depends on your application(s) which is better.. By the way, is there a sysctl that controls this behavior now? There was talk of adding it before.. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 8:19:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pawn.primelocation.net (pawn.primelocation.net [205.161.238.235]) by hub.freebsd.org (Postfix) with ESMTP id C289B14EEE for ; Tue, 13 Jul 1999 08:19:31 -0700 (PDT) (envelope-from jedgar@fxp.org) Received: by pawn.primelocation.net (Postfix, from userid 1003) id 9EF2FF818; Tue, 13 Jul 1999 11:19:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by pawn.primelocation.net (Postfix) with ESMTP id 9229F9B15; Tue, 13 Jul 1999 11:19:25 -0400 (EDT) Date: Tue, 13 Jul 1999 11:19:25 -0400 (EDT) From: "Chris D. Faulhaber" X-Sender: jedgar@pawn.primelocation.net To: eT Cc: hackers@freebsd.org Subject: Re: Which device should I make with this error? In-Reply-To: <378B549C.4C511A98@post.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, eT wrote: > During a make release for 3.2-RELEASE I get the following error: > > Making the regular boot floppy. > Compressing doc files... > sh -e /usr/src/release/scripts/doFS.sh -s mfsroot /R/stage /mnt 2880 > /R/stage/m > fsfd 8000 minimum2 > vnconfig: open: Device not configured > *** Error code 1 > > Stop. > *** Error code 1 > > What does this mean and how do I fix it? > According to http://www.freebsd.org/FAQ/FAQ244.html#247 : 13.2. How do I make my own custom release? To make a release you need to do three things: First, you need to be running a kernel with the vn driver configured in. Add this to your kernel config file and build a new kernel: pseudo-device vn #Vnode driver (turns a file into a device) Hence the 'vn' in 'vnconfig'... ...or, checking the manpage for vnconfig(8), it references vn(4) (aka pseudo-device vn). ----- Chris D. Faulhaber | All the true gurus I've met never System/Network Administrator, | claimed they were one, and always Reality Check Information, Inc. | pointed to someone better. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 8:21:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wrath.cs.utah.edu (wrath.cs.utah.edu [155.99.198.100]) by hub.freebsd.org (Postfix) with ESMTP id 3843514EEE for ; Tue, 13 Jul 1999 08:21:33 -0700 (PDT) (envelope-from danderse@cs.utah.edu) Received: from torrey.cs.utah.edu (torrey.cs.utah.edu [155.99.212.91]) by wrath.cs.utah.edu (8.8.8/8.8.8) with ESMTP id JAA01545; Tue, 13 Jul 1999 09:21:20 -0600 (MDT) Received: (from danderse@localhost) by torrey.cs.utah.edu (8.9.3/8.9.1) id JAA40731; Tue, 13 Jul 1999 09:21:20 -0600 (MDT) (envelope-from danderse@cs.utah.edu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 13 Jul 1999 09:21:20 -0600 (MDT) From: "David G. Andersen" To: eT@post.com Cc: hackers@FreeBSD.ORG Subject: Re: Which device should I make with this error? In-Reply-To: eT's message of Tue, July 13 1999 <378B549C.4C511A98@post.com> References: <378B549C.4C511A98@post.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14219.22774.681893.932450@torrey.cs.utah.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Lo and Behold, eT said: > During a make release for 3.2-RELEASE I get the following error: > > vnconfig: open: Device not configured > *** Error code 1 > > What does this mean and how do I fix it? It means you don't have any vnode devices configured in your kernel. What, you ask, is a vnode disk driver? See: 0: man 4 vn Once you've read the manpage and grok what's going on, then do the rest of this: 1: MAKEDEV vn0 2: Add a 'pseudo-device vn' to your kernel config. 3: Recompile, reboot, be happy. -Dave -- work: danderse@cs.utah.edu me: angio@pobox.com University of Utah CS Department http://www.angio.net/ "If you haul a man up a crack, you will bloody his fingers for a day... If you teach a man to climb, you will bloody his fingers for life." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 9:13:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (Postfix) with ESMTP id F34C514D6F for ; Tue, 13 Jul 1999 09:13:47 -0700 (PDT) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.8.8/8.8.8) id SAA09770 for freebsd-hackers@FreeBSD.ORG; Tue, 13 Jul 1999 18:13:42 +0200 (CEST) (envelope-from olli) Date: Tue, 13 Jul 1999 18:13:42 +0200 (CEST) From: Oliver Fromme Message-Id: <199907131613.SAA09770@dorifer.heim3.tu-clausthal.de> To: freebsd-hackers@FreeBSD.ORG Subject: Re: bin/12578: `` subshell taints PWD Organization: Administration Heim 3 Reply-To: freebsd-hackers@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: TIN [version 1.2 RZTUC(3) PL2] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Niall Smart wrote in list.freebsd-hackers: > As I understand it most builtins will not spawn a new shell > when they are used in command substitution: > > niall% echo `echo $$` $$ > 20354 20354 > niall% Actually, that example doesn't prove anything. :-) $ echo `echo $$` $$ 8376 8376 $ echo `/bin/echo $$` $$ 8376 8376 $ echo `(/bin/echo $$)` $$ 8376 8376 $ echo `eval /bin/echo '$$'` $$ 8376 8376 $ echo `(eval /bin/echo '$$')` $$ 8376 8376 $ At first I thought that behaviour would be a bug, but it isn't. sh(1) says: $ Expands to the process ID of the invoked shell. A subshell retains the same value of $ as its parent. I.e. $$ does not change when a subshell is spawned, but it rather inherits the value of $$ from its parent. This makes sense, because it enables you to use constructs like this in shell scripts: touch tmp.$$ chmod 600 tmp.$$ ls | grep foo | while read file; do something ... >> tmp.$$ # <-- subshell! done do_more_things < tmp.$$ Command substitution certainly has to spawn a subshell, even for built-in commands, because otherwise you could modify parent shell variables within command substitutions. You can easily verify this with ktrace. ;-) Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 9:24:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from 1upmc-msx4.isdip.upmc.edu (1upmc-msx4.isdbu.upmc.edu [128.147.18.41]) by hub.freebsd.org (Postfix) with ESMTP id 89E2D1533E for ; Tue, 13 Jul 1999 09:24:27 -0700 (PDT) (envelope-from personrp@ccbh.com) Received: by 1upmc-msx4.isdbu.upmc.edu with Internet Mail Service (5.5.2448.0) id <3QW5S579>; Tue, 13 Jul 1999 12:24:14 -0400 Message-ID: <576A688A7DA7D011899B00805FEA1AFF6FDAFA@sych02.isdip.upmc.edu> From: "Person, Roderick" To: "'hackers@freebsd.org'" Subject: Can only mount system read-only? Date: Tue, 13 Jul 1999 12:23:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hey All, It was suggested that I email this problem to this list since for the past weeks (on and off) I can get no resolution from the questions list. I have Debian Linux and FreeBSD system. Debian being my main OS right now, but I think FreeBSD would an upgrade. While in Debian I re-partitioned a partition into two. Then next time I booted FreeBSD it gave me an error that it could not read the partition that I re-made. Fine, I thought, I'll edit /etc/fstab and be done with it. Wrong answer. I can only mount the filesystem as read only. I have tried the fixit disk but no help. I can mount all the partitions and access everything that exist on my FreeBSD drive, but I can not write or delete any file, except in /var which totally has left me clueless. Can anyone help! PS. I'm not subscribed to this list so please respond to me. Roderick P. Person Programmer I CCBH (412)454-2616 "We're not that good. Everyone else just sucks!" - anon. Navy Seal To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 9:31:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 7388714ECD for ; Tue, 13 Jul 1999 09:31:20 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 1145RR-0007tX-00; Tue, 13 Jul 1999 18:30:01 +0200 From: Sheldon Hearn To: Oliver Fromme Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: bin/12578: `` subshell taints PWD In-reply-to: Your message of "Tue, 13 Jul 1999 18:13:42 +0200." <199907131613.SAA09770@dorifer.heim3.tu-clausthal.de> Date: Tue, 13 Jul 1999 18:30:01 +0200 Message-ID: <30350.931883401@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999 18:13:42 +0200, Oliver Fromme wrote: > Command substitution certainly has to spawn a subshell, even > for built-in commands, because otherwise you could modify > parent shell variables within command substitutions. But isn't that exactly what's happening here, where PWD is being tainted by the commands evaluated within the substitution? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 9:46:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 510EF14C1E; Tue, 13 Jul 1999 09:46:46 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.1) with ESMTP id JAA20403; Tue, 13 Jul 1999 09:46:27 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id JAA36852; Tue, 13 Jul 1999 09:46:26 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Tue, 13 Jul 1999 09:46:26 -0700 (PDT) Message-Id: <199907131646.JAA36852@vashon.polstra.com> To: green@freebsd.org Subject: Re: Why 'dd' does not seek over 'char' devs (specifically raw disk In-Reply-To: Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article , Brian F. Feldman wrote: > On Tue, 13 Jul 1999, Luigi Rizzo wrote: > > > couldn't we first try lseek and only do the reads on char devs where > > the lseek fails ? > > lseek() won't usually fail unless it's something like EBADF. It merely > sets the current fd's offset. It would be nice to be able to tell from > a device driver if it supports seeking (da) or not (sa). Hmm... actually, > if we just specify somehow that we support either direct or sequential > access... this would be possible. It would be a big improvement if dd could handle seeking on character disk devices. I'm reasonably certain there exists some ioctl (perhaps related to reading disk labels) which could be used to figure out whether a character device was a disk or not. A simple fix like that would make dd a lot more useful for the case Luigi brought up. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "No matter how cynical I get, I just can't keep up." -- Nora Ephron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 10:55: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id 58B3B14D57; Tue, 13 Jul 1999 10:54:55 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id KAA22111; Tue, 13 Jul 1999 10:53:49 -0700 (PDT) Message-Id: <199907131753.KAA22111@lestat.nas.nasa.gov> To: "Brian F. Feldman" Cc: Noriyuki Soda , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.org, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 13 Jul 1999 10:53:48 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999 10:11:14 -0400 (EDT) "Brian F. Feldman" wrote: > > SVR4 has MAP_NORESERVE option for mmap(2) for this. > > So, default behaivour don't have to be overcommitment. > > Isn't that just like mmap()ing then mlock()ing the range? That would > keep it in core. No, it's not the same thing. On a system which does backing store accounting, the mmap() will fail if you don't specify MAP_NORESRVE and there isn't enough backing store. Also, MAP_NORESERVE can affect things which happen in the future, i.e. it "sticks" to the mapping. Consider: addr = mmap file size MAP_PRIVATE PROT_READ <- no swap resources required mprotect addr size PROT_READ|PROT_WRITE <- swap resources now required The mprotect() could fail in a system that doesn't overcommit, unless MAP_NORESERVE is specified in the mmap() call. -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 11: 0:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id C584314E52 for ; Tue, 13 Jul 1999 11:00:33 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id KAA15518; Tue, 13 Jul 1999 10:58:38 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Tue, 13 Jul 1999 10:58:38 -0700 (PDT) From: Doug X-Sender: doug@dt054n86.san.rr.com To: Ladavac Marino Cc: freebsd-hackers@freebsd.org, peter@netplex.com.au Subject: RE: more amd hangs: in _start() In-Reply-To: <55586E7391ACD211B9730000C11002761796EE@r-lmh-wi-100.corpnet.at> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, Ladavac Marino wrote: > I don't know if your diagnosis was in jest, Yes it was, but thank you for asking. :) I should have known better than to attempt subtle humor at the end of a long, tiring day. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 11:14:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 3A3DE14DDF; Tue, 13 Jul 1999 11:14:20 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA79534; Tue, 13 Jul 1999 11:13:49 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 11:13:49 -0700 (PDT) From: Matthew Dillon Message-Id: <199907131813.LAA79534@apollo.backplane.com> To: Jason Thorpe Cc: "Brian F. Feldman" , Noriyuki Soda , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907131753.KAA22111@lestat.nas.nasa.gov> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This topic has been rehashed a thousand times. What it comes down to is that if you want to disallow overcommit, you have to multiply the amount of swap space in the system relative to current levels in order to get the same performance limits as you had before. If you don't, your system will begin to fail much earlier then it would have otherwise. The reason for this is simple: the system generally doesn't even come close to using an amount of swap matching its VM reservation. Rather then reserving the 2xMEMORY worth of swap that we recommend now, you would have to reserve 8x or 16xMEMORY worth of swap if overcommits were not allowed. It doesn't make much sense to do that. It's a terrible waste of resources. A machine with 128MB of ram would have to reserve 2G worth of swap space instead of 256MB to be able to reach the performance limits of the machine, yet under nearly all conditions no more then 200MB of that space would actually be used by the system. The performance curve starts to drop out once swap utilization reaches 1.5xMEM and is really in the dogpile when swap utilization reaches 2xMEM. There is no benefit whatsoever to allocating more swap then the system can have reasonable performance with except as an emergency reserve. Thus it makes little sense to try to disallow overcommit. It gains you absolutely nothing, and forces you to waste huge amounts of disk space. To anyone who is paranoid about it: Fine, then just allocate an insane amount of swap and forget about it. It would be no more then you would have to allocate anyway if we were to actually disallow overcommits! But with overcommits allowed, your box will never come close to using that much swap. SysV was totally and utterly broken in regards to swap allocation. The only major operating system that used it as a base was IRIX and SGI found out very quickly that pre-reserving swap is a stupid idea - and so they implemented 'virtual swap' to get around it in 5.3, and moved the whole thing to an overcommit model in 6.4. Doh! Even solaris doesn't overcommit - you think it actually reserves data blocks for its file-backed swap? Bzzt! It uses an overcommit model too. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 11:15:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (Postfix) with ESMTP id 481BA14E1B for ; Tue, 13 Jul 1999 11:15:27 -0700 (PDT) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.8.8/8.8.8) id UAA12928 for freebsd-hackers@FreeBSD.ORG; Tue, 13 Jul 1999 20:15:17 +0200 (CEST) (envelope-from olli) Date: Tue, 13 Jul 1999 20:15:17 +0200 (CEST) From: Oliver Fromme Message-Id: <199907131815.UAA12928@dorifer.heim3.tu-clausthal.de> To: freebsd-hackers@FreeBSD.ORG Subject: Re: bin/12578: `` subshell taints PWD Organization: Administration Heim 3 Reply-To: freebsd-hackers@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: TIN [version 1.2 RZTUC(3) PL2] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn wrote in list.freebsd-hackers: > On Tue, 13 Jul 1999 18:13:42 +0200, Oliver Fromme wrote: > > > Command substitution certainly has to spawn a subshell, even > > for built-in commands, because otherwise you could modify > > parent shell variables within command substitutions. > > But isn't that exactly what's happening here, where PWD is being tainted > by the commands evaluated within the substitution? Yes, I'd call that a bug which should be fixed. The manpage clearly says: "The shell expands the command substitution by executing command in a subshell environment and replacing the command substitution with the standard output of the command [...]" Alternatively, the manpage could be "fixed". ;-) I'm not sure if XPG4v2 requires command substitution to behave like that. At least, both Solaris' and DEC UNIX... oops... True64 UNIX do execute all command substitutions in a subshell (`pwd` does not affect the surrounding shell), and both claim XPG4 compliance. Therefore I think the right thing to do is to fix FreeBSD's sh to always execute command substitutions in a subshell. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 11:32:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id CA8B914E6B; Tue, 13 Jul 1999 11:32:51 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id LAA22555; Tue, 13 Jul 1999 11:32:32 -0700 (PDT) Message-Id: <199907131832.LAA22555@lestat.nas.nasa.gov> To: Matthew Dillon Cc: "Brian F. Feldman" , Noriyuki Soda , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 13 Jul 1999 11:32:31 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999 11:13:49 -0700 (PDT) Matthew Dillon wrote: > SysV was totally and utterly broken in regards to swap allocation. The > only major operating system that used it as a base was IRIX and SGI > found out very quickly that pre-reserving swap is a stupid idea - and > so they implemented 'virtual swap' to get around it in 5.3, and moved the > whole thing to an overcommit model in 6.4. Doh! Even solaris doesn't > overcommit - you think it actually reserves data blocks for its file-backed > swap? Bzzt! It uses an overcommit model too. You don't have to reserve the actual swap blocks. you merely have to know how many blocks total there are, and how many swap backed pages you have. you can certainly dynamically assign the actual swap blocks, for e.g. swap clustering, etc. it's really not that hard. In the case of swapping to files, NetBSD, at least, doesn't allow swapping to sparse files. The data blocks in the swap file must exist and be allocated to that file. -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 11:33:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id 5B1CB14E6B for ; Tue, 13 Jul 1999 11:33:48 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id LAA16007 for ; Tue, 13 Jul 1999 11:33:47 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Tue, 13 Jul 1999 11:33:47 -0700 (PDT) From: Doug X-Sender: doug@dt054n86.san.rr.com To: freebsd-hackers@FreeBSD.ORG Subject: Re: bin/12578: `` subshell taints PWD In-Reply-To: <199907131815.UAA12928@dorifer.heim3.tu-clausthal.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, Oliver Fromme wrote: > > But isn't that exactly what's happening here, where PWD is being tainted > > by the commands evaluated within the substitution? > > Yes, I'd call that a bug which should be fixed. > The manpage clearly says: > > "The shell expands the command substitution by executing > command in a subshell environment and replacing the command > substitution with the standard output of the command [...]" > > Alternatively, the manpage could be "fixed". ;-) The correct way to fix the problem is to bring our sh in line with posix in this respect. Someone more familiar with the spec than I could tell you for sure, however I can say with relative security that subshell processes should not taint parent shell variables. Exercising my firm grasp of the obvious, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 11:39:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 03AF714E6B for ; Tue, 13 Jul 1999 11:38:59 -0700 (PDT) (envelope-from wilko@yedi.iaf.nl) Received: from yedi.iaf.nl (uucp@localhost) by uni4nn.gn.iaf.nl (8.9.2/8.9.2) with UUCP id UAA17261; Tue, 13 Jul 1999 20:26:24 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id UAA01235; Tue, 13 Jul 1999 20:04:48 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199907131804.UAA01235@yedi.iaf.nl> Subject: Re: 3.2-STABLE not stable but panicy? In-Reply-To: <199907130010.RAA02621@dingo.cdrom.com> from Mike Smith at "Jul 12, 1999 5:10:33 pm" To: mike@smith.net.au (Mike Smith) Date: Tue, 13 Jul 1999 20:04:48 +0200 (CEST) Cc: FreeBSD-hackers@freebsd.org X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-pgp-info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Mike Smith wrote ... > This is typically symptomatic of poor CPU cooling; all of a sudden you Well, it wasn't the cooler, that was just fine. The CPU was quite cool (it has a big, good heatsink & fan) > are running the CPU at full power 100% of the time, rather than sitting > in an HLT instruction. It can be further exacerbated if you're > overclocking. But you are right all the same: after spending some time eyeballing the mainboard I remembered I was running at 75Mc bus speed. Have been doing so for > 1 year now. Another temperature probe, but this time of the VRM regulators sort of toasted one of my fingers. So my current theory is that the VRM regulator sort of lost it and the CPU did not like that too much. I thought of grabbing the old oscilloscope and measure the powerrails but took the easy route to 66Mc bus speed. Seems to run fine now. (this really is Murphy: it is close to 30 degr C here which "never" happens in Holland && this RC5DES thingy && 75 Mc setting. Burp). Thanks, Wilko > > Is it just me/my machine or has 3.2-STABLE become rather unstable and > > panic stricken (sp)? > > > > Whether it has any correlation I don't know, but it seems to have started > > when I got in the the RC5DES project a couple of days ago. > > > > Yesterday I got a panic like: > > > > (no debugging symbols found)... > > IdlePTD 3174400 > > initial pcb at 28e864 > > panicstr: lockmgr: unknown locktype request 0 > > panic messages: > > --- > > panic: lockmgr: unknown locktype request 0 -- | / o / / _ Arnhem, The Netherlands - Powered by FreeBSD - |/|/ / / /( (_) Bulte WWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 11:48:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 42D5E14EE4 for ; Tue, 13 Jul 1999 11:48:18 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id OAA86945; Tue, 13 Jul 1999 14:47:20 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 13 Jul 1999 14:47:20 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Matthew Dillon Cc: Jason Thorpe , Noriyuki Soda , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.org, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <199907131813.LAA79534@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG But I have a valid point: can we do something better than posting a SIGKILL to the largest process? Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 11:59:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 0C33314EE4 for ; Tue, 13 Jul 1999 11:59:06 -0700 (PDT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 13 Jul 1999 19:58:34 +0100 (BST) Date: Tue, 13 Jul 1999 19:58:33 +0100 From: David Malone To: "Brian F. Feldman" Cc: Matthew Dillon , Jason Thorpe , Noriyuki Soda , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.org, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) Message-ID: <19990713195833.A4167@walton.maths.tcd.ie> References: <199907131813.LAA79534@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Brian F. Feldman on Tue, Jul 13, 1999 at 02:47:20PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 13, 1999 at 02:47:20PM -0400, Brian F. Feldman wrote: > But I have a valid point: can we do something better than posting a SIGKILL > to the largest process? I think AIX sends all running processes a magic signal (SIGDANGER?) which indicates that the system is short of resources, and if things don't improve real soon then it sends a SIGKILL. Not that I'd suggest that AIX does things the right way... David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 11:59:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 46B6315254; Tue, 13 Jul 1999 11:59:26 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA79981; Tue, 13 Jul 1999 11:59:25 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 11:59:25 -0700 (PDT) From: Matthew Dillon Message-Id: <199907131859.LAA79981@apollo.backplane.com> To: "Brian F. Feldman" Cc: Jason Thorpe , Noriyuki Soda , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :But I have a valid point: can we do something better than posting a SIGKILL :to the largest process? : : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ : green@FreeBSD.org _ __ ___ | _ ) __| \ We could have the ability to mark processes as being more or less preferable as kill candidates. I'm not sure I really care anymore, though... there is so much disk space available now that it is fairly difficult to run the system out of swap space. I don't think I've run any of my personal systems out of swap space for at least a year now! Usually the biggest process is the one responsible (note: MFS processes do not count, and they are immune from being killed). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 12: 4: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 3430315230 for ; Tue, 13 Jul 1999 12:03:57 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id PAA87285; Tue, 13 Jul 1999 15:02:38 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 13 Jul 1999 15:02:38 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: John Polstra Cc: hackers@FreeBSD.org Subject: Re: Why 'dd' does not seek over 'char' devs (specifically raw disk In-Reply-To: <199907131646.JAA36852@vashon.polstra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, John Polstra wrote: > In article , > Brian F. Feldman wrote: > > On Tue, 13 Jul 1999, Luigi Rizzo wrote: > > > > > couldn't we first try lseek and only do the reads on char devs where > > > the lseek fails ? > > > > lseek() won't usually fail unless it's something like EBADF. It merely > > sets the current fd's offset. It would be nice to be able to tell from > > a device driver if it supports seeking (da) or not (sa). Hmm... actually, > > if we just specify somehow that we support either direct or sequential > > access... this would be possible. > > It would be a big improvement if dd could handle seeking on character > disk devices. I'm reasonably certain there exists some ioctl (perhaps > related to reading disk labels) which could be used to figure out > whether a character device was a disk or not. A simple fix like that > would make dd a lot more useful for the case Luigi brought up. Okay, I implemented it, and it's in -CURRENT. I forgot about dsioctl()... I was thinking in majors and minors, and that they'd have to be hardcoded in... ;) This is better. > > John > -- > John Polstra jdp@polstra.com > John D. Polstra & Co., Inc. Seattle, Washington USA > "No matter how cynical I get, I just can't keep up." -- Nora Ephron > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 12: 4:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 4A49414ED7; Tue, 13 Jul 1999 12:04:45 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from hamilton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 13 Jul 1999 20:04:45 +0100 (BST) To: "Brian F. Feldman" Cc: hackers@FreeBSD.org Subject: Re: a BSD identd In-reply-to: Your message of "Tue, 13 Jul 1999 09:51:43 EDT." Date: Tue, 13 Jul 1999 20:04:45 +0100 From: Ian Dowse Message-ID: <199907132004.aa08685@salmon.maths.tcd.ie> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , "Bria n F. Feldman" writes: >On 13 Jul 1999, Ville-Pertti Keinonen wrote: > >> >> green@FreeBSD.org (Brian F. Feldman) writes: >> >> > It's "out with the bad, in with the good." Pidentd code is pretty terrible >. >> > The only security concerns with my code were wrt FAKEID, and those were >> > mostly fixed (mostly meaning that a symlink _may_ be opened, but it won't >> > be read.) If anyone wants to audit my code for security, I invite them to. >> >> Did you mean to avoid reading through symlinks using the open + fstat >> method mentioned earlier in the thread? > >No, I meant to avoid opening a file the user couldn't, or reading from a dev. Why not actually store the fake ID in a symbolic link? That way you just do a readlink(), which would be safer, neater and faster than reading a file. A user can set up a fake ID with something like: ln -s "Warm-Fuzzy" .fakeid Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 12: 8:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id D7FA814FD4 for ; Tue, 13 Jul 1999 12:08:05 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id MAA05826; Tue, 13 Jul 1999 12:06:33 -0700 Date: Tue, 13 Jul 1999 12:06:28 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <199907131859.LAA79981@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > We could have the ability to mark processes as being more or less > preferable as kill candidates. I'm not sure I really care anymore, > though... there is so much disk space available now that it is fairly > difficult to run the system out of swap space. I don't think I've > run any of my personal systems out of swap space for at least a year I do this regularly and swap areas are difficult to configure sometimes. It would be desirable to have a growable swap vnode in ffs that you can set up in advance, or have a network nfs swap server for use in emergencies. This is a much better policy than killing processes, which is really microsoft style solution. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 12: 9:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id AC6CC14ED7 for ; Tue, 13 Jul 1999 12:09:33 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id PAA87369; Tue, 13 Jul 1999 15:07:30 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 13 Jul 1999 15:07:30 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Matthew Dillon Cc: Jason Thorpe , Noriyuki Soda , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.org, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <199907131859.LAA79981@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, Matthew Dillon wrote: > > :But I have a valid point: can we do something better than posting a SIGKILL > :to the largest process? > : > : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ > : green@FreeBSD.org _ __ ___ | _ ) __| \ > > We could have the ability to mark processes as being more or less > preferable as kill candidates. I'm not sure I really care anymore, > though... there is so much disk space available now that it is fairly > difficult to run the system out of swap space. I don't think I've > run any of my personal systems out of swap space for at least a year > now! Usually the biggest process is the one responsible (note: MFS > processes do not count, and they are immune from being killed). We need some kind of hysteresis... a process took up all my swap left, got killed, then my X server got killed too. I'd like something that says "I don't want process X killed unless it has run away with over Y of memory." But I'd also like to see FreeBSD not kill two processes to prevent a deadlock. > > -Matt > Matthew Dillon > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 12:10: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from nightfly.apk.net (nightfly.apk.net [207.54.149.151]) by hub.freebsd.org (Postfix) with SMTP id AC94B15233 for ; Tue, 13 Jul 1999 12:10:00 -0700 (PDT) (envelope-from rme@nightfly.apk.net) Received: (qmail 16973 invoked by uid 1000); 13 Jul 1999 19:11:26 -0000 To: freebsd-hackers@freebsd.org Subject: Re: Replacement for grep(1) (part 2) References: X-Attribution: rme From: rme@nightfly.apk.net (R. Matthew Emerson) Date: 13 Jul 1999 15:11:26 -0400 In-Reply-To: "Brian F. Feldman"'s message of "Tue, 13 Jul 1999 14:47:20 -0400 (EDT)" Message-ID: <87pv1wjrfl.fsf@nightfly.apk.net> Lines: 18 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Brian F. Feldman" writes: > But I have a valid point: can we do something better than posting a SIGKILL > to the largest process? If I remember correctly, AIX sends a signal to all processes asking them to free up memory. (Processes ignore this signal by default.) If nobody responds, then it selects a victim and blows it away. I think it is nice to processes that catch the signal and try to free up memory in that it won't kill them first. (What would you call such a signal, SIGDIET?) I guess memory overcommit is desirable in a "worse is better" kind of way, because it is clearly not "the right thing." :-( (see section 2.1 of http://naggum.no/worse-is-better.html) -matt [cc:'s trimmed] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 12:14: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id C8F3B14ED7 for ; Tue, 13 Jul 1999 12:13:59 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id PAA87502; Tue, 13 Jul 1999 15:12:51 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 13 Jul 1999 15:12:51 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Ian Dowse Cc: hackers@FreeBSD.org Subject: Re: a BSD identd In-Reply-To: <199907132004.aa08685@salmon.maths.tcd.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, Ian Dowse wrote: > In message , "Bria > n F. Feldman" writes: > >On 13 Jul 1999, Ville-Pertti Keinonen wrote: > > > >> > >> green@FreeBSD.org (Brian F. Feldman) writes: > >> > >> > It's "out with the bad, in with the good." Pidentd code is pretty terrible > >. > >> > The only security concerns with my code were wrt FAKEID, and those were > >> > mostly fixed (mostly meaning that a symlink _may_ be opened, but it won't > >> > be read.) If anyone wants to audit my code for security, I invite them to. > >> > >> Did you mean to avoid reading through symlinks using the open + fstat > >> method mentioned earlier in the thread? > > > >No, I meant to avoid opening a file the user couldn't, or reading from a dev. > > Why not actually store the fake ID in a symbolic link? That way you just > do a readlink(), which would be safer, neater and faster than reading a > file. A user can set up a fake ID with something like: > > ln -s "Warm-Fuzzy" .fakeid Hysterical raisins. ~/.fakeid being a text file is how it's always been done. That would be a better idea if I didn't mind confusing the hell out of people :) > > Ian > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 12:21:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id DEBF414ED7 for ; Tue, 13 Jul 1999 12:21:47 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA80146; Tue, 13 Jul 1999 12:20:37 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 12:20:37 -0700 (PDT) From: Matthew Dillon Message-Id: <199907131920.MAA80146@apollo.backplane.com> To: Matthew Jacob Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> We could have the ability to mark processes as being more or less :> preferable as kill candidates. I'm not sure I really care anymore, :> though... there is so much disk space available now that it is fairly :> difficult to run the system out of swap space. I don't think I've :> run any of my personal systems out of swap space for at least a year : :I do this regularly and swap areas are difficult to configure sometimes. :It would be desirable to have a growable swap vnode in ffs that you can :set up in advance, or have a network nfs swap server for use in :emergencies. This is a much better policy than killing processes, which is :really microsoft style solution. The basic problem with using file-backed swap is that swapping a page out may require the temporary allocation of several pages - indirect blocks for the file, resulting in possible low-memory deadlocks. That said, I think that when the same problem with vnode-backed paging is eventually solved, it will also cover file-backed swapping. FreeBSD's swap subsystem has a basic limitation of 4 swap areas. This is due to the design of the interleaving algorithms. Increasing this number is simple, but it results in phenominally more kernel memory getting wired. Within this limitation we can theoretically add and remove swap areas with relative easy. It would be somewhat easier to do under CURRENT because the swap metadata structures are simpler. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 12:23:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id BB84A14EB7; Tue, 13 Jul 1999 12:22:57 -0700 (PDT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 13 Jul 1999 20:22:57 +0100 (BST) Date: Tue, 13 Jul 1999 20:22:56 +0100 From: David Malone To: "Brian F. Feldman" Cc: hackers@FreeBSD.org Subject: Re: a BSD identd Message-ID: <19990713202256.A4767@walton.maths.tcd.ie> References: <199907132004.aa08685@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Brian F. Feldman on Tue, Jul 13, 1999 at 03:12:51PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 13, 1999 at 03:12:51PM -0400, Brian F. Feldman wrote: > > Why not actually store the fake ID in a symbolic link? That way you just > > do a readlink(), which would be safer, neater and faster than reading a > > file. A user can set up a fake ID with something like: > > > > ln -s "Warm-Fuzzy" .fakeid > > Hysterical raisins. ~/.fakeid being a text file is how it's always been done. > That would be a better idea if I didn't mind confusing the hell out of > people :) You could tell them to do: ln -s `cat .fakeid` .fakeidnew mv .fakeid `cat .fakeid` mv .fakeidnew .fakeid Also - I guess if you're goting to patch inetd to do this stuff it should be runtime configurable to be able to: 1) return the traditional :ERROR:HIDDEN-USER, 2) return the real user always, 3) return the fakeid if it exists, and otherwise use the read user id, You should probably use uname to get the OS name too? David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 12:25:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.netbsd.org (redmail.netbsd.org [155.53.200.193]) by hub.freebsd.org (Postfix) with SMTP id CABC014C8E for ; Tue, 13 Jul 1999 12:25:08 -0700 (PDT) (envelope-from cgd@netbsd.org) Received: (qmail 4202 invoked by uid 1000); 13 Jul 1999 19:24:36 -0000 To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907131753.KAA22111@lestat.nas.nasa.gov> <199907131813.LAA79534@apollo.backplane.com> From: cgd@netbsd.org (Chris G. Demetriou) Date: 13 Jul 1999 12:24:35 -0700 In-Reply-To: Matthew Dillon's message of Tue, 13 Jul 1999 11:13:49 -0700 (PDT) Message-ID: <873dys1hfw.fsf@redmail.redback.com> Lines: 87 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [cc list trimmed because it was getting ... insane, and it's not like this is a critical point. It's just beating up a topic which has been beaten up by many others.] Matthew Dillon writes: > Thus it makes little sense to try to disallow overcommit. It gains you > absolutely nothing, and forces you to waste huge amounts of disk space. > > To anyone who is paranoid about it: Fine, then just allocate an insane > amount of swap and forget about it. It would be no more then you would > have to allocate anyway if we were to actually disallow overcommits! But > with overcommits allowed, your box will never come close to using that > much swap. This may be a decent answer for the workstation world, but it's not so good for more restricted systems. Further, your claim that disallowing overcommit gains you absolutely nothing is simply false. It gains you two things (which are at least immediately obvious to me): * Certain knowledge that (if the system is implemented correctly) the system will never have to kill a process (or take similar corrective action) due to overcommit, and that attempts to allocate more backing store resources than are present will fail. If the programs you're using do reasonable error handling when out-of memory situations crop up, then this can be a very useful propery to have if you're building a reliable system. It's not necessarily a matter of gigs of swap space. It means that you know that you can safely run in, say, 64MB or memory, with _no_ swap, if your programs don't overallocate ridiculously. The only alternative to avoiding overcommit that seems plausibly enforceable by the OS/system designer is using resource limits and then planning based on the maximum resource limits and number of processes you allow. However, that results in a ridiculously loose upper bound and a fair bit of extra work tuning the limits. The obvious workstation example is a bit grotesque: 1GB max datasize by default, maxproc 532, and you need > .5TB to be _sure_ that no process will get killed for lack of resources. A more realistic embedded system might allow 64 processes, two of which need 10MB each and the rest of which need 300K-1MB each. If you do this naively, you end up "needing" 640MB to guarantee safely. If you tweak a bunch of things with some special-purpose resource limiting code, you can get it down to 96MB or so to guarantee safety. Only by going to a _great_ deal of extra effort -- which could be avoided by just disabling overcommit -- you can't be sure the system will operate safely in, say, 48MB or even 64MB, both of which may well be adequate. Using resource limits to solve this problem is ... not the right answer (even if various systems implemented resource limits correctly). * protection against bogosity. I may run a system in which all of the processes are effectively unlimited (i.e. have huge resource limits), but I know within a tolerance what the actual expected usage of the system is. If a program mallocs (or equivalently allocates with mmap) it should be told up front that that's not possible (or that it is), and filling that memory in later simply should not result in its death or in the death of another process. This becomes especially important when the process making the bogus request is a "critical" process or when the other process that happens to be killed is a critical process. Certain knowledge about system operation, and deterministinc system behaviour in the face of programming bugs is exactly what the desire for overcommit is about. Overcommit avoidance may not be useful for your particular uses of these UNIX-like systems. However, if you think that it's not useful to anybody who uses them (or that people who think it's useful are deluding themselves 8-), then you're sorely mistaken and have a ... very wrong-headed attitude about why people find such features useful. cgd -- Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html Disclaimer: Not speaking for NetBSD, just expressing my own opinion. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 12:25:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from search.sparks.net (search.sparks.net [208.5.188.60]) by hub.freebsd.org (Postfix) with ESMTP id 36F7F14E2D for ; Tue, 13 Jul 1999 12:25:01 -0700 (PDT) (envelope-from dmiller@search.sparks.net) Received: by search.sparks.net (Postfix, from userid 100) id E60F5258; Tue, 13 Jul 1999 15:24:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by search.sparks.net (Postfix) with SMTP id DEDFF215 for ; Tue, 13 Jul 1999 15:24:26 -0400 (EDT) Date: Tue, 13 Jul 1999 15:24:26 -0400 (EDT) From: David Miller To: hackers@freebsd.org Subject: [Off Topic] ODBC and yahoo Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Couple of questions which are pretty much off topic.... 1) Does anyone know of a way to talk to a remote oracle server via odbc or oci? Access is required specifically under apache and mod_perl or php, but we've spent a couple of man-days looking for straightforward answers and found none:( 2) Anyone know what Yahoo is doing? They've got freebsd webservers, last I knew. Any info on how they're setup would be greatly appreciated! Thanks, --- David Miller To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 12:35:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 19A7F14C8E for ; Tue, 13 Jul 1999 12:35:03 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.1) with ESMTP id MAA21092; Tue, 13 Jul 1999 12:34:58 -0700 (PDT) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id MAA37152; Tue, 13 Jul 1999 12:34:56 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Tue, 13 Jul 1999 12:34:56 -0700 (PDT) Message-Id: <199907131934.MAA37152@vashon.polstra.com> To: iedowse@maths.tcd.ie Subject: Re: a BSD identd In-Reply-To: <199907132004.aa08685@salmon.maths.tcd.ie> Organization: Polstra & Co., Seattle, WA Cc: hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <199907132004.aa08685@salmon.maths.tcd.ie>, Ian Dowse wrote: > > Why not actually store the fake ID in a symbolic link? That way you just > do a readlink(), which would be safer, neater and faster than reading a > file. A user can set up a fake ID with something like: > > ln -s "Warm-Fuzzy" .fakeid Ick. Please, no more abuse of symbolic links! Once (malloc) was enough. Data is held in files, not in filenames. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "No matter how cynical I get, I just can't keep up." -- Nora Ephron To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 12:36:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from eaugalle.empros.com (eaugalle.empros.com [161.134.129.6]) by hub.freebsd.org (Postfix) with ESMTP id 3AE8E14C8E; Tue, 13 Jul 1999 12:36:45 -0700 (PDT) (envelope-from bstark@siemens-psc.com) Received: from possum.empros.com (possum.empros.com [161.134.124.51]) by eaugalle.empros.com (8.9.0/8.9.0) with ESMTP id OAA49698; Tue, 13 Jul 1999 14:36:05 -0500 Received: from localhost (bstark@localhost) by possum.empros.com (AIX4.2/UCB 8.7/8.7) with ESMTP id OAA79816; Tue, 13 Jul 1999 14:34:45 -0500 (CDT) X-Authentication-Warning: possum.empros.com: bstark owned process doing -bs Date: Tue, 13 Jul 1999 14:34:45 -0500 (CDT) From: Brian Stark X-Sender: bstark@possum.empros.com To: David Malone Cc: "Brian F. Feldman" , Matthew Dillon , Jason Thorpe , Noriyuki Soda , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.org, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <19990713195833.A4167@walton.maths.tcd.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, David Malone wrote: > I think AIX sends all running processes a magic signal (SIGDANGER?) > which indicates that the system is short of resources, and if things > don't improve real soon then it sends a SIGKILL. Not that I'd suggest > that AIX does things the right way... FYI, from InfoExplorer on an AIX 4.2.1 server: "The system monitors the number of free paging space blocks and detects when a paging-space shortage exists. When the number of free paging-space blocks falls below a threshold known as the paging-space warning level, the system informs all processes (except kprocs) of this condition by sending the SIGDANGER signal. If the shortage continues and falls below a second threshold known as the paging-space kill level, the system sends the SIGKILL signal to processes that are the major users of paging space and that do not have a signal handler for the SIGDANGER signal (the default action for the SIGDANGER signal is to ignore the signal). The system continues sending SIGKILL signals until the number of free paging-space blocks is above the paging-space kill level." Regards, Brian ------------------------------------------------------------------------- | Brian Stark | Internet : bstark@siemens-psc.com | | Siemens PT&D, LLC | Voice : +1 612 536-4697 | | Power Systems Control Division | Fax : +1 612 536-4919 | | 7225 Northland Drive, Brooklyn Park, Minnesota 55428 USA | ------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 12:47:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id DEA091524A for ; Tue, 13 Jul 1999 12:47:02 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA80310; Tue, 13 Jul 1999 12:46:39 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 12:46:39 -0700 (PDT) From: Matthew Dillon Message-Id: <199907131946.MAA80310@apollo.backplane.com> To: cgd@netbsd.org (Chris G. Demetriou) Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907131753.KAA22111@lestat.nas.nasa.gov> <199907131813.LAA79534@apollo.backplane.com> <873dys1hfw.fsf@redmail.redback.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> have to allocate anyway if we were to actually disallow overcommits! But :> with overcommits allowed, your box will never come close to using that :> much swap. : :This may be a decent answer for the workstation world, but it's not so :good for more restricted systems. Further, your claim that :disallowing overcommit gains you absolutely nothing is simply false. : :It gains you two things (which are at least immediately obvious to me): : :* Certain knowledge that (if the system is implemented correctly) the : system will never have to kill a process (or take similar corrective : action) due to overcommit, and that attempts to allocate more backing : store resources than are present will fail. By the time the system reaches the point where it would have to do this in the case where you reserve sufficient swap to handle a situation where overcommits would not be allowed, the system will *ALREADY BE DEAD*. Please read my other posting carefully. Certain knowledge doesn't help you if the system becomes unuseable first. Swap overcommit is a non-problem. :* protection against bogosity. : : I may run a system in which all of the processes are effectively : unlimited (i.e. have huge resource limits), but I know within a : tolerance what the actual expected usage of the system is. Set a resource limit that is, say, 1/2 your swap space. Problem solved. Of course there are plenty of potential situations where this will not work... what if two processes run away? What if 10 processes run away? What if they ALL run away? But the reality is that you can think up these potentialities until you are blue in the face and you will never solve your problem. Even advocating a system which does not allow overcommit will not solve your problem... the result of that will be a system which starts refusing to do things long before it would otherwise. This is unacceptable. You have to think of the problem in terms of what will realistically occur in a system. Trying to solve any other problem will not help make the system more reliable. You will wind up running in circles trying to solve problems that never occur instead of solving the problems that do occur. :cgd :-- :Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 13:21:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id DE9D114FF2 for ; Tue, 13 Jul 1999 13:21:48 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id NAA16769; Tue, 13 Jul 1999 13:20:55 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Tue, 13 Jul 1999 13:20:55 -0700 (PDT) From: Doug X-Sender: doug@dt054n86.san.rr.com To: freebsd-hackers@freebsd.org Cc: peter@netplex.com.au Subject: Re: more amd hangs: problem really in syslog? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG After pounding on this some more with today's -current (prior to the MNT_ASYNC flag change) I got a lot more lockups that looked like this: On Mon, 12 Jul 1999, Doug wrote: > Ok, got another hang in "siobi" state (this time after it > successfully completed the script). Here is the trace: > > (gdb) file /usr/sbin/amd > Reading symbols from /usr/sbin/amd...done. > (gdb) attach 155 > Attaching to program: /usr/sbin/amd, process 155 > 0x8063dc4 in open () > (gdb) where > #0 0x8063dc4 in open () > #1 0x806b5c3 in vsyslog (pri=6, fmt=0x809279a "%s", ap=0xbfbfb240 "X") > at /usr/src/lib/libc/../libc/gen/syslog.c:262 > #2 0x806b2c2 in syslog (pri=6, fmt=0x809279a "%s") > at /usr/src/lib/libc/../libc/gen/syslog.c:130 > #3 0x805a3d8 in real_plog (lvl=6, > fmt=0x8091ea0 "recompute_portmap: NFS version %d", vargs=0xbfbfba7c > "\002") > at > /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/libamu/xutil.c:443 > #4 0x805a2be in plog (lvl=16, > fmt=0x8091ea0 "recompute_portmap: NFS version %d") > at > /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/libamu/xutil.c:383 So I started thinking that maybe the problem was actually in syslog (or amd's interface to it). So I disabled the following two options in my amd.conf file: log_file = syslog:local7 log_options = all And lo and behold, it worked like a charm. I was able to run my conf-building script for my web server 20 times in a row with no ill effects. Previously the best I could do was 3 times before it hung. After confirming that it worked with no logging, I tried enabling logging to a regular file, and that also worked like a charm. After turning syslog style logging back on, it locked up cold, with a very similar traceback. If anyone wants to work on this, let me know. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 13:27:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bubba.whistle.com (s205m7.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id C98C114FF2 for ; Tue, 13 Jul 1999 13:27:31 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id NAA72481; Tue, 13 Jul 1999 13:26:22 -0700 (PDT) From: Archie Cobbs Message-Id: <199907132026.NAA72481@bubba.whistle.com> Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <199907131920.MAA80146@apollo.backplane.com> from Matthew Dillon at "Jul 13, 99 12:20:37 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Tue, 13 Jul 1999 13:26:22 -0700 (PDT) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG How hard would it be to add a sysctl variable that controlled whether or not the system would overcommit memory? -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 13:35:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 7BB1E152AF for ; Tue, 13 Jul 1999 13:35:20 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 1149GZ-000ALs-00; Tue, 13 Jul 1999 22:35:03 +0200 From: Sheldon Hearn To: Doug Cc: freebsd-hackers@freebsd.org, peter@netplex.com.au Subject: Re: more amd hangs: problem really in syslog? In-reply-to: Your message of "Tue, 13 Jul 1999 13:20:55 MST." Date: Tue, 13 Jul 1999 22:35:03 +0200 Message-ID: <39795.931898103@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999 13:20:55 MST, Doug wrote: > After confirming that it worked with no logging, I tried enabling > logging to a regular file, and that also worked like a charm. After > turning syslog style logging back on, it locked up cold, with a very > similar traceback. Sheesh, Mark Murray wasn't kidding when he told me that "AMD tickles bugs". Of course, I thought he meant that it tickles bugs in our NFS code. :-) This discovery sounds like a real step forward. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 13:59:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-01.cdsnet.net (mail-01.cdsnet.net [206.107.16.35]) by hub.freebsd.org (Postfix) with SMTP id 1323D14E98 for ; Tue, 13 Jul 1999 13:59:53 -0700 (PDT) (envelope-from mrcpu@internetcds.com) Received: (qmail 7845 invoked from network); 13 Jul 1999 20:50:59 -0000 Received: from schizo.cdsnet.net (204.118.244.32) by mail.cdsnet.net with SMTP; 13 Jul 1999 20:50:59 -0000 Date: Tue, 13 Jul 1999 13:50:37 -0700 (PDT) From: Jaye Mathisen X-Sender: mrcpu@schizo.cdsnet.net To: hackers@freebsd.org Subject: Anybody tried one of these VXA tape drives with FreeBSD? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Look fairly robust: http://vxatape.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 14:10:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2]) by hub.freebsd.org (Postfix) with ESMTP id 6EF4414DD2; Tue, 13 Jul 1999 14:10:22 -0700 (PDT) (envelope-from soda@sra.co.jp) Received: from sranhf.sra.co.jp (sranhf [133.137.28.3]) by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id GAA22959; Wed, 14 Jul 1999 06:07:58 +0900 (JST) Received: from srapc342.sra.co.jp (srapc342 [133.137.28.111]) by sranhf.sra.co.jp (8.8.7/3.6Wbeta7-srambox) with ESMTP id GAA04763; Wed, 14 Jul 1999 06:07:58 +0900 (JST) Received: (from soda@localhost) by srapc342.sra.co.jp (8.8.8/3.4W-sra) id GAA14750; Wed, 14 Jul 1999 06:07:58 +0900 (JST) Date: Wed, 14 Jul 1999 06:07:58 +0900 (JST) Message-Id: <199907132107.GAA14750@srapc342.sra.co.jp> From: Noriyuki Soda To: Matthew Dillon Cc: Jason Thorpe , "Brian F. Feldman" , Noriyuki Soda , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <199907131813.LAA79534@apollo.backplane.com> References: <199907131753.KAA22111@lestat.nas.nasa.gov> <199907131813.LAA79534@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> On Tue, 13 Jul 1999 11:13:49 -0700 (PDT), Matthew Dillon said: > Doh! Even solaris doesn't overcommit - you think it actually > reserves data blocks for its file-backed swap? Bzzt! It uses > an overcommit model too. Unlike 4.4BSD derived VM, Solaris VM has a way to reserve backing store. -- soda To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 14:10:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id D7F4D14F85 for ; Tue, 13 Jul 1999 14:10:50 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA80706; Tue, 13 Jul 1999 14:09:56 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 14:09:56 -0700 (PDT) From: Matthew Dillon Message-Id: <199907132109.OAA80706@apollo.backplane.com> To: Archie Cobbs Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) References: <199907132026.NAA72481@bubba.whistle.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :How hard would it be to add a sysctl variable that controlled whether or not :the system would overcommit memory? : :-Archie : :___________________________________________________________________________ :Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com Archie, the question is barely worth answering. Nobody advocating this stuff has even begun to think-out the ramifications. Adding such a knob would be easy - except it might as well be a "crash me now" knob when the system starts refusing programs reasonable requests for memory! I mean, jeeze, the reservation for the program stack alone would eat up all your available swap space! What is a reasonable stack size? The system defaults to 8MB. Do we rewrite every program to specify its own stack size? How do we account for architectural differences? * stack * MAP_PRIVATE mmaps * fork (used to fork, not the 'easy' fork/exec case) It adds up pretty quickly. My home server runs smoothly with 128MB of ram and 512MB of swap (4MB of swap in use), but the kernel reports over 3 GB of VM assigned to processes. That's a fairly lightly loaded machine. So, as I said before: in order for overcommit prevention to work you need to have an insane amount of swap, even though the system could not possibly use it all. Not only is it a complete waste of space, but if you were to reserve that much swap for a *normal* system that allowed overcommits, rather then the 2xMEM that we currently recommend, hell would freeze over before you managed to actually use it all. If you tried to turn on an overcommit knob without multiplying your swap space to the insane purportions necessary, the system will start refusing allocation requests long before the system actually reaches a point of performance degredation, turning your nice fast pentium-II into the equivalent of an 386 with 8MB of ram. Protecting against overcommit may sound like a cool idea, but the reality is that you can't do it without seriously compromising the performance potential of a system and you can't do it without wasting a lot of space. And, besides, it doesn't work anyway. As I've said on several occassions a system will die from disk overload long before it would come close to using available swap given a reasonable configuration. Just because the WWW server processes are stilll there doesn't mean squat if they can't answer queries! -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 14:11: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id 5C272152E6; Tue, 13 Jul 1999 14:10:56 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id OAA23817; Tue, 13 Jul 1999 14:10:13 -0700 (PDT) Message-Id: <199907132110.OAA23817@lestat.nas.nasa.gov> To: Matthew Dillon Cc: "Brian F. Feldman" , Noriyuki Soda , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 13 Jul 1999 14:10:13 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999 11:59:25 -0700 (PDT) Matthew Dillon wrote: > We could have the ability to mark processes as being more or less > preferable as kill candidates. I'm not sure I really care anymore, > though... there is so much disk space available now that it is fairly > difficult to run the system out of swap space. I don't think I've > run any of my personal systems out of swap space for at least a year > now! Usually the biggest process is the one responsible (note: MFS > processes do not count, and they are immune from being killed). ...I suppose it depends on what market you're going for, too. Some systems (not even necessarily OLD systems, but maybe modern, embedded ones, too) don't always have the option of having "so much disk space available". Seems like you want your operating system to behave the `correct' way depending on the environment in which it's being used. -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 14:16:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 62B211503E; Tue, 13 Jul 1999 14:16:09 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA80781; Tue, 13 Jul 1999 14:14:52 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 14:14:52 -0700 (PDT) From: Matthew Dillon Message-Id: <199907132114.OAA80781@apollo.backplane.com> To: Jason Thorpe Cc: "Brian F. Feldman" , Noriyuki Soda , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132110.OAA23817@lestat.nas.nasa.gov> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :On Tue, 13 Jul 1999 11:59:25 -0700 (PDT) : Matthew Dillon wrote: : : > We could have the ability to mark processes as being more or less : > preferable as kill candidates. I'm not sure I really care anymore, : > though... there is so much disk space available now that it is fairly : > difficult to run the system out of swap space. I don't think I've : > run any of my personal systems out of swap space for at least a year : > now! Usually the biggest process is the one responsible (note: MFS : > processes do not count, and they are immune from being killed). : :...I suppose it depends on what market you're going for, too. Some :systems (not even necessarily OLD systems, but maybe modern, embedded :ones, too) don't always have the option of having "so much disk space :available". : :Seems like you want your operating system to behave the `correct' way :depending on the environment in which it's being used. : : -- Jason R. Thorpe If you don't have the disk necessary for a standard overcommit model to work, you definitely do not have the disk necessary for a non-overcommit model to work. If you were to try to implement overcommit protection on a system with insufficient disk space, it probably wouldn't have enough reservable space to run basic system daemons, much less any actual servers. Read the part again where I mentioned the swap requirements for a non-overcommit model to operate at the same level as the current model. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 14:17:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 80C5E1535A; Tue, 13 Jul 1999 14:17:19 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA80834; Tue, 13 Jul 1999 14:16:54 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 14:16:54 -0700 (PDT) From: Matthew Dillon Message-Id: <199907132116.OAA80834@apollo.backplane.com> To: Noriyuki Soda Cc: Jason Thorpe , "Brian F. Feldman" , Noriyuki Soda , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907131753.KAA22111@lestat.nas.nasa.gov> <199907131813.LAA79534@apollo.backplane.com> <199907132107.GAA14750@srapc342.sra.co.jp> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :>>>>> On Tue, 13 Jul 1999 11:13:49 -0700 (PDT), : Matthew Dillon said: : :> Doh! Even solaris doesn't overcommit - you think it actually :> reserves data blocks for its file-backed swap? Bzzt! It uses :> an overcommit model too. : :Unlike 4.4BSD derived VM, Solaris VM has a way to reserve backing store. :-- :soda ... and it doesn't mean squat. What, the absolutely critical server that you are trying to run decides to exit because it can't guarentee sufficient backing store? First of all, this situation simply does not occur in a properly configured system. Secondly, for such a server to fail to run is just as bad as if the system were to run out of swap. IRIX has a swap reservation flag too, a left-over from the SysV days. It is a totally useless flag. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 14:23:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2]) by hub.freebsd.org (Postfix) with ESMTP id 51E2F14DD2; Tue, 13 Jul 1999 14:23:06 -0700 (PDT) (envelope-from soda@sra.co.jp) Received: from sranhf.sra.co.jp (sranhf [133.137.28.3]) by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id GAA23232; Wed, 14 Jul 1999 06:22:50 +0900 (JST) Received: from srapc342.sra.co.jp (srapc342 [133.137.28.111]) by sranhf.sra.co.jp (8.8.7/3.6Wbeta7-srambox) with ESMTP id GAA04776; Wed, 14 Jul 1999 06:22:48 +0900 (JST) Received: (from soda@localhost) by srapc342.sra.co.jp (8.8.8/3.4W-sra) id GAA14829; Wed, 14 Jul 1999 06:22:49 +0900 (JST) Date: Wed, 14 Jul 1999 06:22:49 +0900 (JST) Message-Id: <199907132122.GAA14829@srapc342.sra.co.jp> From: Noriyuki Soda To: Matthew Dillon Cc: Noriyuki Soda , Jason Thorpe , "Brian F. Feldman" , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <199907132116.OAA80834@apollo.backplane.com> References: <199907131753.KAA22111@lestat.nas.nasa.gov> <199907131813.LAA79534@apollo.backplane.com> <199907132107.GAA14750@srapc342.sra.co.jp> <199907132116.OAA80834@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> On Tue, 13 Jul 1999 14:16:54 -0700 (PDT), Matthew Dillon said: > > Unlike 4.4BSD derived VM, Solaris VM has a way to reserve backing store. > Secondly, for such a server to fail to run is just as bad as if > the system were to run out of swap. > IRIX has a swap reservation flag too, a left-over from the SysV days. > It is a totally useless flag. That's wrong. On such systems, critical server has a chance to save it's data to filesystem. On 4.4BSD derived systems, it cannot be guaranteed. -- soda To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 14:23:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id AE84D1507D for ; Tue, 13 Jul 1999 14:23:15 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id OAA01126; Tue, 13 Jul 1999 14:18:43 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907132118.OAA01126@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Jaye Mathisen Cc: hackers@freebsd.org Subject: Re: Anybody tried one of these VXA tape drives with FreeBSD? In-reply-to: Your message of "Tue, 13 Jul 1999 13:50:37 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jul 1999 14:18:43 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Look fairly robust: > > http://vxatape.com Their online documentation suggests that this is a stock-standard SCSI tape device. A refreshing change. 8) -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 14:24: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id D0B9114F85 for ; Tue, 13 Jul 1999 14:23:58 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA80902; Tue, 13 Jul 1999 14:23:39 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 14:23:39 -0700 (PDT) From: Matthew Dillon Message-Id: <199907132123.OAA80902@apollo.backplane.com> To: Doug Cc: freebsd-hackers@FreeBSD.ORG, peter@netplex.com.au Subject: Re: more amd hangs: problem really in syslog? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : : So I started thinking that maybe the problem was actually in :syslog (or amd's interface to it). So I disabled the following two options :in my amd.conf file: : :log_file = syslog:local7 :log_options = all : : And lo and behold, it worked like a charm. I was able to run my :conf-building script for my web server 20 times in a row with no ill :effects. Previously the best I could do was 3 times before it hung. : : After confirming that it worked with no logging, I tried enabling :logging to a regular file, and that also worked like a charm. After :turning syslog style logging back on, it locked up cold, with a very :similar traceback. : : If anyone wants to work on this, let me know. : :Doug Are you syslogging to the console by any chance? Try messing around with /etc/syslog.conf and see if just plain file logging prevents the lockup -- you could even try turning off all logging (but leaving syslog running, i.e. turning it into a sink-null) to see if that has an effect. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 14:27:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bubba.whistle.com (s205m7.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id D440214DD2 for ; Tue, 13 Jul 1999 14:27:25 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id OAA72872; Tue, 13 Jul 1999 14:25:33 -0700 (PDT) From: Archie Cobbs Message-Id: <199907132125.OAA72872@bubba.whistle.com> Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <199907132109.OAA80706@apollo.backplane.com> from Matthew Dillon at "Jul 13, 99 02:09:56 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Tue, 13 Jul 1999 14:25:33 -0700 (PDT) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon writes: > :How hard would it be to add a sysctl variable that controlled whether or not > :the system would overcommit memory? > > Archie, the question is barely worth answering. Nobody advocating this > stuff has even begun to think-out the ramifications. Adding such a knob > would be easy - except it might as well be a "crash me now" knob when > the system starts refusing programs reasonable requests for memory! > > I mean, jeeze, the reservation for the program stack alone would eat > up all your available swap space! What is a reasonable stack size? The > system defaults to 8MB. Do we rewrite every program to specify its own > stack size? How do we account for architectural differences? > > * stack > * MAP_PRIVATE mmaps > * fork (used to fork, not the 'easy' fork/exec case) > > It adds up pretty quickly. My home server runs smoothly with 128MB of > ram and 512MB of swap (4MB of swap in use), but the kernel reports over > 3 GB of VM assigned to processes. That's a fairly lightly loaded machine. What you say is generally true; however, the problem is that *you* are making implicit assumptions about what applications *I* might have in mind. I just think that's a presumptous thing to do unless you can read minds.. For example: - I might be creating a very limited embedded system with just a few small processes that are all written to *handle* out of memory situations. - I could be creating a "Java OS" that is going to have a single process, ie, the Java VM, that can handle ENOMEM (which translates into an OutOfMemoryException, which can be caught) but otherwise *must not die*. In types of situations like this (someone can probably think of more/better examples) overcommit may very well be undesireable. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 14:29:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 88AAE15055; Tue, 13 Jul 1999 14:29:12 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA80947; Tue, 13 Jul 1999 14:27:54 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 14:27:54 -0700 (PDT) From: Matthew Dillon Message-Id: <199907132127.OAA80947@apollo.backplane.com> To: Noriyuki Soda Cc: Jason Thorpe , "Brian F. Feldman" , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> Secondly, for such a server to fail to run is just as bad as if :> the system were to run out of swap. : :> IRIX has a swap reservation flag too, a left-over from the SysV days. :> It is a totally useless flag. : :That's wrong. :On such systems, critical server has a chance to save it's data to :filesystem. :On 4.4BSD derived systems, it cannot be guaranteed. :-- :soda You are assuming that the situation actually occurs. In real life, it will not occur unless the critical server is running away with memory. I have never, ever run one of BEST's servers out of swap. It has never been an issue. And, I can only repeat, again, that long before a reasonably configured FreeBSD system runs out of swap it would become unusable from the I/O overload. And you also haven't bothered to address my other point: In order to configure a system that guarentees backing store, you need to configure that system with 8x or more swap then you would a normal system. If you think there was a chance of a normal system running out of swap, what do you think would happen if you configured a normal system with 8x swap? -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 14:31: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id 87C5C14F3D for ; Tue, 13 Jul 1999 14:30:57 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id OAA24167; Tue, 13 Jul 1999 14:30:55 -0700 (PDT) Message-Id: <199907132130.OAA24167@lestat.nas.nasa.gov> To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 13 Jul 1999 14:30:55 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999 14:14:52 -0700 (PDT) Matthew Dillon wrote: > If you don't have the disk necessary for a standard overcommit model to > work, you definitely do not have the disk necessary for a non-overcommit > model to work. You obviously didn't pay attention to Chris's posting, nor apparently did you see th "embedded" in my posting. Who said anything about even having disks to swap to? I just want the kernel to tell me when there aren't any more backing store resources (including *PHYSICAL PAGES*) for the memory allocation I just requested from userspace. That way, my correctly written program can take appropriate action (like, say, invoke its type-stable memory pool garbage collector, and try again). Right now, BSD doesn't do this, and that makes creating a truly reliable system *very hard*. -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 14:32: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id E6A5314DD2 for ; Tue, 13 Jul 1999 14:32:01 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA80991; Tue, 13 Jul 1999 14:31:38 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 14:31:38 -0700 (PDT) From: Matthew Dillon Message-Id: <199907132131.OAA80991@apollo.backplane.com> To: Archie Cobbs Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) References: <199907132125.OAA72872@bubba.whistle.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> ram and 512MB of swap (4MB of swap in use), but the kernel reports over :> 3 GB of VM assigned to processes. That's a fairly lightly loaded machine. : :What you say is generally true; however, the problem is that *you* :are making implicit assumptions about what applications *I* might :have in mind. I just think that's a presumptous thing to do unless :you can read minds.. : :For example: : :- I might be creating a very limited embedded system with just a few : small processes that are all written to *handle* out of memory situations. Really? Then setting resource limits from within each program is not a problem now is it? Then it will get a nice malloc failure instead of getting killed by the kernel. :- I could be creating a "Java OS" that is going to have a single process, : ie, the Java VM, that can handle ENOMEM (which translates into an : OutOfMemoryException, which can be caught) but otherwise *must not die*. .... just one process? Set a resource limit! If you have 64MB of swap, then limit the size of the Java OS process to 50MB. Now the java process will get a nice malloc failure instead of getting killed by the kernel. :... :-Archie -Matt Matthew Dillon :___________________________________________________________________________ :Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com : : :To Unsubscribe: send mail to majordomo@FreeBSD.org :with "unsubscribe freebsd-hackers" in the body of the message : To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 14:34:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id B2C87150CA for ; Tue, 13 Jul 1999 14:34:18 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id OAA24203; Tue, 13 Jul 1999 14:32:59 -0700 (PDT) Message-Id: <199907132132.OAA24203@lestat.nas.nasa.gov> To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 13 Jul 1999 14:32:59 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999 14:16:54 -0700 (PDT) Matthew Dillon wrote: > ... and it doesn't mean squat. What, the absolutely critical server > that you are trying to run decides to exit because it can't guarentee > sufficient backing store? First of all, this situation simply does > not occur in a properly configured system. Secondly, for such a server > to fail to run is just as bad as if the system were to run out of swap. If your "absolutely critical server" application is written so badly that it simply exists when a memory allocation fails, well, then you have problems. Don't blame the OS for badly written applications. -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 14:39:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id A899914DD2 for ; Tue, 13 Jul 1999 14:39:48 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id OAA01221; Tue, 13 Jul 1999 14:34:05 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907132134.OAA01221@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Doug Cc: freebsd-hackers@freebsd.org, peter@netplex.com.au Subject: Re: more amd hangs: problem really in syslog? In-reply-to: Your message of "Tue, 13 Jul 1999 13:20:55 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jul 1999 14:34:05 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > After pounding on this some more with today's -current (prior to > the MNT_ASYNC flag change) I got a lot more lockups that looked like > this: > > On Mon, 12 Jul 1999, Doug wrote: > > > Ok, got another hang in "siobi" state (this time after it > > successfully completed the script). Here is the trace: 'siobi' is in sioopen() in the sio driver. The callout device is already open, but the caller is trying to open it in blocking mode. It'd be useful to know what is hanging in 'siobi' here, since trying to re-open the console is a bit of a suspicious action. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 14:40:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id 8EDFB152CD for ; Tue, 13 Jul 1999 14:40:14 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id OAA24282; Tue, 13 Jul 1999 14:38:49 -0700 (PDT) Message-Id: <199907132138.OAA24282@lestat.nas.nasa.gov> To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 13 Jul 1999 14:38:49 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999 14:27:54 -0700 (PDT) Matthew Dillon wrote: > You are assuming that the situation actually occurs. In real life, > it will not occur unless the critical server is running away with > memory. > > I have never, ever run one of BEST's servers out of swap. It has never > been an issue. In BEST's critical servers, maybe that's true. But applying your experience at BEST to the wide range of UNIX users is ... a bit ridiculous, I think :-) > And, I can only repeat, again, that long before a reasonably configured > FreeBSD system runs out of swap it would become unusable from the I/O > overload. See previous point: "who said we were even going to swap *at all*?" You're making a lot of assumptions about the sort of programs people run on BSD systems, not all of which are reasonable to make. -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 14:40:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id E05E315306 for ; Tue, 13 Jul 1999 14:40:19 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA81030; Tue, 13 Jul 1999 14:38:58 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 14:38:58 -0700 (PDT) From: Matthew Dillon Message-Id: <199907132138.OAA81030@apollo.backplane.com> To: Jason Thorpe Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132130.OAA24167@lestat.nas.nasa.gov> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :On Tue, 13 Jul 1999 14:14:52 -0700 (PDT) : Matthew Dillon wrote: : : > If you don't have the disk necessary for a standard overcommit model to : > work, you definitely do not have the disk necessary for a non-overcommit : > model to work. : :You obviously didn't pay attention to Chris's posting, nor apparently did :you see th "embedded" in my posting. : :Who said anything about even having disks to swap to? I just want the :kernel to tell me when there aren't any more backing store resources :(including *PHYSICAL PAGES*) for the memory allocation I just requested :from userspace. That way, my correctly written program can take appropriate :action (like, say, invoke its type-stable memory pool garbage collector, and :try again). : :Right now, BSD doesn't do this, and that makes creating a truly reliable :system *very hard*. : : -- Jason R. Thorpe Sure it does. You are running an embedded system? It has no swap? Fine... you have ultimate design control over every process running on the system. Simply set appropriate resource limits for the processes run by the system and you are done. All the embedded systems I've ever done - and I've done quite a few, panic and reboot if they run out of memory. The programs are written with a designed-in safety margin. If the system runs out of memory, it is a catastrophic error and not something the programs try to clean up from. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 14:40:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2]) by hub.freebsd.org (Postfix) with ESMTP id 78F6815354; Tue, 13 Jul 1999 14:40:35 -0700 (PDT) (envelope-from soda@sra.co.jp) Received: from sranhf.sra.co.jp (sranhf [133.137.28.3]) by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id GAA23871; Wed, 14 Jul 1999 06:39:01 +0900 (JST) Received: from srapc342.sra.co.jp (srapc342 [133.137.28.111]) by sranhf.sra.co.jp (8.8.7/3.6Wbeta7-srambox) with ESMTP id GAA04818; Wed, 14 Jul 1999 06:38:59 +0900 (JST) Received: (from soda@localhost) by srapc342.sra.co.jp (8.8.8/3.4W-sra) id GAA14890; Wed, 14 Jul 1999 06:39:00 +0900 (JST) Date: Wed, 14 Jul 1999 06:39:00 +0900 (JST) Message-Id: <199907132139.GAA14890@srapc342.sra.co.jp> From: Noriyuki Soda To: Matthew Dillon Cc: Noriyuki Soda , Jason Thorpe , "Brian F. Feldman" , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <199907132127.OAA80947@apollo.backplane.com> References: <199907132127.OAA80947@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> On Tue, 13 Jul 1999 14:27:54 -0700 (PDT), Matthew Dillon said: > > That's wrong. > > On such systems, critical server has a chance to save it's data to > > filesystem. > > On 4.4BSD derived systems, it cannot be guaranteed. > You are assuming that the situation actually occurs. In real life, > it will not occur unless the critical server is running away with > memory. > I have never, ever run one of BEST's servers out of swap. It has never > been an issue. Running out of swap can be easily done by normal user privilege. Non-overcommiting system can run important application on the system which has a normal user, because it never lose critical data, even if a user on the system make a mistake. (The application might stop, but it never lose data.) 4.4BSD derived system cannot do this, and have to use different machine for such applications. > And you also haven't bothered to address my other point: In order to > configure a system that guarentees backing store, you need to configure > that system with 8x or more swap then you would a normal > system. 8x or more? That's wrong. It depends. -- soda To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 14:41:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id 09BA015253 for ; Tue, 13 Jul 1999 14:41:52 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id OAA24339; Tue, 13 Jul 1999 14:41:14 -0700 (PDT) Message-Id: <199907132141.OAA24339@lestat.nas.nasa.gov> To: Matthew Dillon Cc: Archie Cobbs , freebsd-hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 13 Jul 1999 14:41:14 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999 14:31:38 -0700 (PDT) Matthew Dillon wrote: > :- I might be creating a very limited embedded system with just a few > : small processes that are all written to *handle* out of memory situations. > > Really? Then setting resource limits from within each program is not > a problem now is it? Then it will get a nice malloc failure instead > of getting killed by the kernel. See chris's point... Maybe you have one process that needs 10MB and a few others that need 300K - 1MB. Resource limits are not useful in this scenario. ...and, who said anything about using malloc()? :-) -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 14:44:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.netbsd.org (redmail.netbsd.org [155.53.200.193]) by hub.freebsd.org (Postfix) with SMTP id B3CD71518E for ; Tue, 13 Jul 1999 14:44:06 -0700 (PDT) (envelope-from cgd@netbsd.org) Received: (qmail 29568 invoked by uid 1000); 13 Jul 1999 21:42:05 -0000 To: Matthew Dillon Cc: Jason Thorpe , "Brian F. Feldman" , Noriyuki Soda , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132110.OAA23817@lestat.nas.nasa.gov> <199907132114.OAA80781@apollo.backplane.com> From: cgd@netbsd.org (Chris G. Demetriou) Date: 13 Jul 1999 14:42:05 -0700 In-Reply-To: Matthew Dillon's message of Tue, 13 Jul 1999 14:14:52 -0700 (PDT) Message-ID: <877lo4z0pe.fsf@redmail.redback.com> Lines: 76 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon writes: > If you don't have the disk necessary for a standard overcommit model to > work, you definitely do not have the disk necessary for a non-overcommit > model to work. I'd _really_ like to know how you figure this. text data bss dec hex filename 45024 4096 392 49512 c168 /bin/cat 311264 12288 9900 333452 5168c /bin/sh 212960 4096 28492 245548 3bf2c inetd.static 458720 12288 73716 544724 84fd4 sendmail.static None of these are particularly huge. Dynamically linked binaries inflate things somewhat, of course, but even there: 442336 12288 35780 490404 77ba4 /usr/lib/libc.so.12.40 the data and bss per library just aren't that huge. Of course, in addition to the sizes of the data and bss sections, you need to make sure you've got enough extra for dynamically allocated data, and for stack pages, and for a few other tidbits of dynamically allocated storage, but the end result is a system which, even without overcommit, can fit into a reasonable amount of backing store. > Read the part again where I mentioned the swap requirements for a > non-overcommit model to operate at the same level as the current model. So, I just went back and looked at my mail folder for this NetBSD mailing list (tech-userlevel), which has about a week and a half's worth of messages. Nowhere did I see what amounts to anything other than hand-waving claims that you'll have to allocate much, much more backing store than you currently need to, and claims that that's unacceptable for general purpose computing environments. If you have a more specific analysis that you'd like me/us to read, please point us at it more specifically. Regarding those claims: * not all the world's a general purpose computing environment, * while you certainly need to allocate more backing store than you would with overcommit, it's _not_ ridiculously more for most applications(+), and, finally, * even if you are not willing to pay that price, there _are_ people who are quite willing to pay that price to get the benefits that they see (whether it's a matter of perception or not, from their perspective they may as well be real) of such a scheme. (+): obviously, there are some applications for which no-overcommit is just silly. However, 'normal' UNIX applications by and large allocate memory (or map files writeable/private, or map anonymous memory) to actually use it. I.e. if 'cat' or 'inetd' or 'sendmail' allocates a page from the system, it's almost certainly going write something to it, and, while there are undoubtedly a few pages that aren't written to, they are by far the majority. And, of course, once the page has been written, it's no longer reserved, it's committed. 8-) I would honestly love to know: what do you see huge numbers of reserved pages being reserved for, if they're not actually being committed, by 'average' UNIX applications (for any definition of average that excludes applications which do memory based computation on sparse dasta). cgd -- Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html Disclaimer: Not speaking for NetBSD, just expressing my own opinion. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 14:54:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id BE4DC14DD2; Tue, 13 Jul 1999 14:54:20 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA81153; Tue, 13 Jul 1999 14:53:43 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 14:53:43 -0700 (PDT) From: Matthew Dillon Message-Id: <199907132153.OAA81153@apollo.backplane.com> To: Noriyuki Soda Cc: Jason Thorpe , "Brian F. Feldman" , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132127.OAA80947@apollo.backplane.com> <199907132139.GAA14890@srapc342.sra.co.jp> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Running out of swap can be easily done by normal user privilege. :Non-overcommiting system can run important application on the system :which has a normal user, because it never lose critical data, even if :a user on the system make a mistake. (The application might stop, :but it never lose data.) : :4.4BSD derived system cannot do this, and have to use different :machine for such applications. :... : :8x or more? :That's wrong. It depends. :-- :soda If you are talking about a user intentionally attempting to run a system out of swap, it is fairly easy to do whether the system uses an overcommit model or not. The user has any number of ways of blowing the server up too - for example, by making thousands of connections to it or running many huge queries in parallel. A machine which is running a critical server is not a multi-user machine by definition, precisely because of this point. No reservation model will save you from a user hell-bent on screwing your machine up, there are too many ways to do it. The reality is, again, that a properly configured system will not run out of swap. Reliability is a statistical function... if the chance of a system running out of swap is 1 hour of down time per thousand years, that is a probability that can be ignored because there are plenty of other potential problems that will result in more down time. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 14:57:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 714FF14DD2 for ; Tue, 13 Jul 1999 14:57:07 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA81180; Tue, 13 Jul 1999 14:56:52 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 14:56:52 -0700 (PDT) From: Matthew Dillon Message-Id: <199907132156.OAA81180@apollo.backplane.com> To: Jason Thorpe Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132138.OAA24282@lestat.nas.nasa.gov> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :On Tue, 13 Jul 1999 14:27:54 -0700 (PDT) : Matthew Dillon wrote: : : > You are assuming that the situation actually occurs. In real life, : > it will not occur unless the critical server is running away with : > memory. : > : > I have never, ever run one of BEST's servers out of swap. It has never : > been an issue. : :In BEST's critical servers, maybe that's true. But applying your experience :at BEST to the wide range of UNIX users is ... a bit ridiculous, I think :-) : : -- Jason R. Thorpe Jason, I am using real life situations to demonstrate my point. You are perfectly welcome to use your own REAL-LIFE situations to demonstrate yours. It is the real-life application that matters, not a worst-case nightmare theory. No engineer designs systems based on nightmare theories. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 15: 0:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.netbsd.org (redmail.netbsd.org [155.53.200.193]) by hub.freebsd.org (Postfix) with SMTP id 976F414CCF for ; Tue, 13 Jul 1999 15:00:19 -0700 (PDT) (envelope-from cgd@netbsd.org) Received: (qmail 4397 invoked by uid 1000); 13 Jul 1999 21:58:54 -0000 To: Matthew Dillon Cc: Jason Thorpe , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132130.OAA24167@lestat.nas.nasa.gov> <199907132138.OAA81030@apollo.backplane.com> From: cgd@netbsd.org (Chris G. Demetriou) Date: 13 Jul 1999 14:58:54 -0700 In-Reply-To: Matthew Dillon's message of Tue, 13 Jul 1999 14:38:58 -0700 (PDT) Message-ID: <87673oyzxd.fsf@redmail.redback.com> Lines: 33 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon writes: > Fine... you have ultimate design control over every process running on > the system. Simply set appropriate resource limits for the processes > run by the system and you are done. For some value of ultimate control. Reality these days is that if you want an embedded system based on UNIX that both doesn't suck and that has the features you need, you have to take _some_ off the shelf software components, glue them together as simply as possible, and do what you can to squeeze realiability out of them. There are many ways to squeeze reliability, with respect to memory consumption. One of them is hand-tuning resource limits for the applications, as you mention (and as I suggested in a previous e-mail). However, this can be difficult to get right (but there's a safety margin), or, for some applications, impossible to do reasonably at all. You can attempt to deny it, but another valuable one is being able to detect without panic or without processes being killed that the system is out of memory, and the most sane way of doing that is with resource preallocation. Yes, it's conservative, but there's no reliable alternative that i'm aware of. cgd -- Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html Disclaimer: Not speaking for NetBSD, just expressing my own opinion. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 15:12:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 8512F14FA8; Tue, 13 Jul 1999 15:12:47 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA81234; Tue, 13 Jul 1999 15:12:14 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 15:12:14 -0700 (PDT) From: Matthew Dillon Message-Id: <199907132212.PAA81234@apollo.backplane.com> To: cgd@netbsd.org (Chris G. Demetriou) Cc: Jason Thorpe , "Brian F. Feldman" , Noriyuki Soda , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132110.OAA23817@lestat.nas.nasa.gov> <199907132114.OAA80781@apollo.backplane.com> <877lo4z0pe.fsf@redmail.redback.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Matthew Dillon writes: : :> If you don't have the disk necessary for a standard overcommit model to :> work, you definitely do not have the disk necessary for a non-overcommit :> model to work. : :I'd _really_ like to know how you figure this. : :text data bss dec hex filename :45024 4096 392 49512 c168 /bin/cat :311264 12288 9900 333452 5168c /bin/sh :212960 4096 28492 245548 3bf2c inetd.static :458720 12288 73716 544724 84fd4 sendmail.static : :None of these are particularly huge. Dynamically linked binaries :inflate things somewhat, of course, but even there: : :442336 12288 35780 490404 77ba4 /usr/lib/libc.so.12.40 : :the data and bss per library just aren't that huge. : :Of course, in addition to the sizes of the data and bss sections, you :need to make sure you've got enough extra for dynamically allocated :data, and for stack pages, and for a few other tidbits of dynamically :allocated storage, but the end result is a system which, even without :overcommit, can fit into a reasonable amount of backing store. The text size of a program is irrelevant, because swap is never allocated for it. The data and BSS are only relevant when they are modified. The only thing swap is ever used for is the dynamic allocation of memory. There are three ways to do it: sbrk(), mmap(... MAP_ANON), or mmap(... MAP_PRIVATE). Dynamic allocation of memory can occur under a huge number of conditions. The actual physical allocation of dynamic memory - what is known as a copy-on-write - cannot be predicted from the potential allocation of memory. The most obvious example of this is a fork(). There is a lot of hidden 'potential' VM that you haven't considered. For example, if the resource limit for a process's stack is 8MB, then the process can potentially allocate 8MB of stack even though it may actually only allocate 32K of stack. When a process forks, the child process can potentially modify just about every single non-text page that was owned by the parent process, causing a copy-on-write to occur. The dynamic potential can run into the megabytes but most child processes only modify a small percentage of those pages. :So, I just went back and looked at my mail folder for this NetBSD :mailing list (tech-userlevel), which has about a week and a half's :worth of messages. : :Nowhere did I see what amounts to anything other than hand-waving :claims that you'll have to allocate much, much more backing store than :you currently need to, and claims that that's unacceptable for general :purpose computing environments. If you have a more specific analysis :that you'd like me/us to read, please point us at it more specifically. You are welcome to bring up real-life situations as examples. That is what I do. But look who is doing the hand-waving now? :* not all the world's a general purpose computing environment, Which is meaningless handwaving. Again, you are welcome to point out your own real-life situations. :* while you certainly need to allocate more backing store than you :would with overcommit, it's _not_ ridiculously more for most :applications(+), and, finally, Based on what? I am basing my information on the VM reservation made by programs, and I am demonstrating specific points showing how those reservations occur. For example, the default 8MB resource limit for the stack segment. I am also demonstrating the level of control that is possible with resource limits. If you are doing an embedded system you can easily guarentee memory utilization even in an overcommit model by properly setting the memory resource limits for each process. If the system did not have any swap, I would do this for every single program I run on that system. If you are going to argue the point, work out the numbers and present them. I had to deal with a reservation model on our old SGI's running 5.3 for almost a year. I know what I'm talking about and I can point to real-life cases that demonstrate it. Certainly there are many different situations... you are welcome to bring up other real-life situations as examples. :* even if you are not willing to pay that price, there _are_ people :who are quite willing to pay that price to get the benefits that they :see (whether it's a matter of perception or not, from their :perspective they may as well be real) of such a scheme. Quite true. In the embedded world we preallocate memory and shape the programs to what is available in the system. But if we run out of memory we usually panic and reboot - because the code is designed to NOT run out of memory and thus running out of memory is a catastrophic situation. It is not appropriate to test every single allocation for a failure... that results in bulky code and provides no real benefit since the code is already designed to not overcommit the embedded system's memory. If it does, you reboot. The most critical embedded systems, such as those used in satellites, avoid dynamic allocation as much as possible in order to guarentee that no memory failures occur. This works under UNIX as well. If you run your programs and touch all your potentially modifiable pages you have effectively reserved the memory. :page from the system, it's almost certainly going write something to :it, and, while there are undoubtedly a few pages that aren't written :to, they are by far the majority. And, of course, once the page has :been written, it's no longer reserved, it's committed. 8-) Swap is used solely for dynamically modified pages of data that is not otherwise backed (e.g. not backed by a file, for example). :I would honestly love to know: what do you see huge numbers of :reserved pages being reserved for, if they're not actually being :committed, by 'average' UNIX applications (for any definition of :average that excludes applications which do memory based computation :on sparse dasta). : :cgd :-- :Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html Stack, hidden VM objects after a multi-way fork, MAP_PRIVATE memory maps, private memory pools (e.g. for web servers, java VM's, and so forth). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 15:13:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id CDDFD1524A for ; Tue, 13 Jul 1999 15:13:04 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA81249; Tue, 13 Jul 1999 15:12:51 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 15:12:51 -0700 (PDT) From: Matthew Dillon Message-Id: <199907132212.PAA81249@apollo.backplane.com> To: Jason Thorpe Cc: Archie Cobbs , freebsd-hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) References: <199907132141.OAA24339@lestat.nas.nasa.gov> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :See chris's point... Maybe you have one process that needs 10MB and a few :others that need 300K - 1MB. Resource limits are not useful in this :scenario. : :...and, who said anything about using malloc()? :-) : : -- Jason R. Thorpe Sure they are. limit datasize 1m run process A limit datasize 10m run process B -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 15:16:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2]) by hub.freebsd.org (Postfix) with ESMTP id E0EA314FA8; Tue, 13 Jul 1999 15:16:16 -0700 (PDT) (envelope-from soda@sra.co.jp) Received: from sranhf.sra.co.jp (sranhf [133.137.28.3]) by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id HAA25077; Wed, 14 Jul 1999 07:15:27 +0900 (JST) Received: from srapc342.sra.co.jp (srapc342 [133.137.28.111]) by sranhf.sra.co.jp (8.8.7/3.6Wbeta7-srambox) with ESMTP id HAA04854; Wed, 14 Jul 1999 07:15:25 +0900 (JST) Received: (from soda@localhost) by srapc342.sra.co.jp (8.8.8/3.4W-sra) id HAA15042; Wed, 14 Jul 1999 07:15:26 +0900 (JST) Date: Wed, 14 Jul 1999 07:15:26 +0900 (JST) Message-Id: <199907132215.HAA15042@srapc342.sra.co.jp> From: Noriyuki Soda To: Matthew Dillon Cc: Noriyuki Soda , Jason Thorpe , "Brian F. Feldman" , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <199907132153.OAA81153@apollo.backplane.com> References: <199907132127.OAA80947@apollo.backplane.com> <199907132139.GAA14890@srapc342.sra.co.jp> <199907132153.OAA81153@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> On Tue, 13 Jul 1999 14:53:43 -0700 (PDT), Matthew Dillon said: > If you are talking about a user intentionally attempting to run > a system out of swap, it is fairly easy to do whether the system > uses an overcommit model or not. The user has any number of > ways of blowing the server up too - for example, by making > thousands of connections to it or running many huge queries in > parallel. If the kernel and the application behave properly, critical application doesn't lose it's data in such situation on non-overcommiting systems. Your example doesn't make sense. -- soda To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 15:19:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 4C86C14DE9 for ; Tue, 13 Jul 1999 15:19:48 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA81321; Tue, 13 Jul 1999 15:19:43 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 15:19:43 -0700 (PDT) From: Matthew Dillon Message-Id: <199907132219.PAA81321@apollo.backplane.com> To: cgd@netbsd.org (Chris G. Demetriou) Cc: Jason Thorpe , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132130.OAA24167@lestat.nas.nasa.gov> <199907132138.OAA81030@apollo.backplane.com> <87673oyzxd.fsf@redmail.redback.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :For some value of ultimate control. : :Reality these days is that if you want an embedded system based on :UNIX that both doesn't suck and that has the features you need, you :have to take _some_ off the shelf software components, glue them :together as simply as possible, and do what you can to squeeze :realiability out of them. : :There are many ways to squeeze reliability, with respect to memory :consumption. : :One of them is hand-tuning resource limits for the applications, as :you mention (and as I suggested in a previous e-mail). However, this :can be difficult to get right (but there's a safety margin), or, for :some applications, impossible to do reasonably at all. : :You can attempt to deny it, but another valuable one is being able to :detect without panic or without processes being killed that the system :is out of memory, and the most sane way of doing that is with resource :preallocation. Yes, it's conservative, but there's no reliable :alternative that i'm aware of. : :cgd :-- :Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html Preallocate and touch (make dirty) all the memory you are going to use right off the bat. Do not use recursive algorithms (guarentee the size of the stack), allocate memory out of fixed pools, put specific limits on all resources. For example, allow only a certain number of TCP connections. Other alternatives (if you have a disk): Do not use swap for backing store. Create a file in the filesystem, write it out (no holes), and mmap() it shared. That can be your backing store. Wire memory. Have a watchdog to check whether you are getting close (free memory plus available swap) to the machine's limits and signal the processes long before they would actually run out. There are a billion ways to do it and none of them require a swap reservation model. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 15:23: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id 3C571150B4 for ; Tue, 13 Jul 1999 15:22:47 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id PAA24683; Tue, 13 Jul 1999 15:22:33 -0700 (PDT) Message-Id: <199907132222.PAA24683@lestat.nas.nasa.gov> To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 13 Jul 1999 15:22:33 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999 14:56:52 -0700 (PDT) Matthew Dillon wrote: > Jason, I am using real life situations to demonstrate my point. You are > perfectly welcome to use your own REAL-LIFE situations to demonstrate > yours. It is the real-life application that matters, not a worst-case > nightmare theory. No engineer designs systems based on nightmare > theories. Yes, you're using your own REAL-LIFE situations, from a large ISP, using systems for a few specific server applications, where you have the space to put lots of disk, etc. The things I'm thinking of aren't even necessarily "large server" applcations. NetBSD runs on a CPU that is *often* used in small embedded applcations -- the StrongARM. NetBSD also runs on the Hitachi SH3, another popular embedded processor. An an example of the latter case, NetBSD is actually the OS software running in a *camera* made by a company in Japan. If you can run on a camera, you can run on a lot of other small appliances too (this isn't a stretch). You might be running on a cash register (err, well, those new-fangled touch-screen "transaction terminals"). This isn't a stretch, either. You might be running on a set-top box (nor is this a stretch; hell, I have one of these in my living room, and it's capable of booting the OS from ROM card -- who needs a diskless server? :-). We're talking about systems which just don't have a lot of disk space (in fact, NO DISK AT ALL), but may be running software which is designed to gracefully deal with memory allocation failures. What do you have against giving people the flexibility of preventing overcommit? -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 15:30:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 0C9B415073; Tue, 13 Jul 1999 15:30:42 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA81360; Tue, 13 Jul 1999 15:29:37 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 15:29:37 -0700 (PDT) From: Matthew Dillon Message-Id: <199907132229.PAA81360@apollo.backplane.com> To: Noriyuki Soda Cc: Jason Thorpe , "Brian F. Feldman" , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132127.OAA80947@apollo.backplane.com> <199907132139.GAA14890@srapc342.sra.co.jp> <199907132153.OAA81153@apollo.backplane.com> <199907132215.HAA15042@srapc342.sra.co.jp> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> a system out of swap, it is fairly easy to do whether the system :> uses an overcommit model or not. The user has any number of :> ways of blowing the server up too - for example, by making :> thousands of connections to it or running many huge queries in :> parallel. : :If the kernel and the application behave properly, critical :application doesn't lose it's data in such situation on :non-overcommiting systems. :Your example doesn't make sense. :-- :soda Give me a shell and I can crash any machine. If you are assuming hostile users, you cannot assume that your magic overcommit protection will save your server. Saying that the kernel and application behave properly is a cop-out, because it's virtually impossible to guarentee that for every situation. The chance of a user blowing up the server by finding a bug or a hole somewhere is much, much greater then the chance of a user running the system out of swap. Concentrating on the memory reservation aspect of the situation means that you miss the more likely scenario and, in the end, you do not make the end result any more reliable - in fact, less reliable then the person who doesn't worry about the 'kernel overcommit problem' and instead engineers the code such that overcommits cannot occur in the first place. Saying that the kernel cannot support certain classes of applications because it does not handle a memory/swap overcommit the way you want does not change the fact that such critical applications should not allow themselves to even attempt an overcommit anyway. A good example of this is sendmail. Before the MaxDaemonChildren and MaxArticleSize options, it was possible for sendmail to overcommit a machine. In this case the overcommit that can occur is with I/O, not swap. As a general performance rule, you have to set MaxDaemonChildren and MaxArticleSize to prevent the overcommit from occuring. This is a function of sendmail, not a function of the kernel. Another good example is a web server. A web server must have specific limitations on the number of simultanious connections it is allowed to handle at once and on the number of CGI's or other auxillary programs that are allowed to be running at any given time. The overcommit issue here has nothing to do with swap and everything to do with performance. Specifically, these limitations exist to avoid cascade failures. In the same manner any truely critical system server must handle the resource management itself to deal with all sorts of problem situations, including memory. You do not need to build any of this control into the kernel. To say that FreeBSD does not support a certain class of system because it uses an overcommit model is not correct, because you can trivially solve the problem by implementing your own management of memory rather then use the UNIX libc builtins. The UNIX libc bulitins properly assume a more general machine configuration and it would not be appropriate to use them for embedded work if memory use is an issue. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 15:31:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id 3A71715345 for ; Tue, 13 Jul 1999 15:31:21 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id PAA24729; Tue, 13 Jul 1999 15:30:45 -0700 (PDT) Message-Id: <199907132230.PAA24729@lestat.nas.nasa.gov> To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 13 Jul 1999 15:30:44 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999 15:12:14 -0700 (PDT) Matthew Dillon wrote: > The text size of a program is irrelevant, because swap is never > allocated for it. The data and BSS are only relevant when they > are modified. Bzzt. BSS is relevant when accessed (at least in NetBSD). > There is a lot of hidden 'potential' VM that you haven't considered. > For example, if the resource limit for a process's stack is 8MB, then > the process can potentially allocate 8MB of stack even though it may > actually only allocate 32K of stack. When a process forks, the child ...um, so, make the code that deals with faulting in the stack a bit smarter. > :* not all the world's a general purpose computing environment, > > Which is meaningless handwaving. Again, you are welcome to point out > your own real-life situations. Well, I just gave you a few examples of "not a general computing environment" in different mail. > I had to deal with a reservation model on our old SGI's running 5.3 > for almost a year. I know what I'm talking about and I can point to > real-life cases that demonstrate it. Certainly there are many different > situations... you are welcome to bring up other real-life situations > as examples. ...and as I recall, those SGIs at BEST were general-purpose computing environments. Chris already said that disallowing overcommit wasn't necessarily appropriate in every situation. So make it a knob. Big deal. Everyone has what they want. -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 15:34: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id B01DE15088 for ; Tue, 13 Jul 1999 15:34:02 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA81393; Tue, 13 Jul 1999 15:33:40 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 15:33:40 -0700 (PDT) From: Matthew Dillon Message-Id: <199907132233.PAA81393@apollo.backplane.com> To: "Neil A. Carson" Cc: Jason Thorpe , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132130.OAA24167@lestat.nas.nasa.gov> <378BB9DB.F1CE6978@causality.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Jason Thorpe wrote: :> :> On Tue, 13 Jul 1999 14:14:52 -0700 (PDT) :> Matthew Dillon wrote: :> :> > If you don't have the disk necessary for a standard overcommit model to :> > work, you definitely do not have the disk necessary for a non-overcommit :> > model to work. : :> from userspace. That way, my correctly written program can take appropriate :> action (like, say, invoke its type-stable memory pool garbage collector, and :> try again). :> :> Right now, BSD doesn't do this, and that makes creating a truly reliable :> system *very hard*. : :John Dyson changed NCOS (which runs on swapless systems) for a behaviour :whereby memory was accounted much more strictly and monitored by a :background process on the desktop. When the 'statistical conditions' :(which take partially into account memory that could be reaped by the :pagedaemon, etc) get to a 'yellow' state, the desktop monitor asks :applications to close themselves. Especially with ref to JVMs etc, this :took a very long time to get right. : : Neil This is an excellent example of a solution. Another example would be to implement your own memory management subsystem... that is, your own shared library which keeps track of memory allocations on a global basis. I could do one in about an hour. One simply mmap()'s a 4K shared page into every process running on the system and then keeps track of memory allocations on a process-by-process basis, summing it globally within the structure to get an idea about overall memory use. The library can then perform garbage collection and notification when the total approaches the danger level and it can do it almost entirely independantly of the kernel's own memory management & paging. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 15:38:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 5D0E41512E for ; Tue, 13 Jul 1999 15:38:12 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA81422; Tue, 13 Jul 1999 15:37:26 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 15:37:26 -0700 (PDT) From: Matthew Dillon Message-Id: <199907132237.PAA81422@apollo.backplane.com> To: Jason Thorpe Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132222.PAA24683@lestat.nas.nasa.gov> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Yes, you're using your own REAL-LIFE situations, from a large ISP, using :systems for a few specific server applications, where you have the space :to put lots of disk, etc. : :The things I'm thinking of aren't even necessarily "large server" :applcations. NetBSD runs on a CPU that is *often* used in small :embedded applcations -- the StrongARM. NetBSD also runs on the :Hitachi SH3, another popular embedded processor. : :An an example of the latter case, NetBSD is actually the OS software running :in a *camera* made by a company in Japan. : :If you can run on a camera, you can run on a lot of other small appliances :too (this isn't a stretch). You might be running on a cash register (err, :well, those new-fangled touch-screen "transaction terminals"). This isn't :a stretch, either. You might be running on a set-top box (nor is this :a stretch; hell, I have one of these in my living room, and it's capable :of booting the OS from ROM card -- who needs a diskless server? :-). : :We're talking about systems which just don't have a lot of disk space (in :fact, NO DISK AT ALL), but may be running software which is designed to :gracefully deal with memory allocation failures. : :What do you have against giving people the flexibility of preventing :overcommit? : : -- Jason R. Thorpe Have you written any of the software running on these? If not, well... I have, though not with FreeBSD specifically. Embedded systems with no disk. When you write embedded systems like these, you do not run any general purpose binaries at all. You run fully custom binaries and you take control of the memory management yourself. These systems do not need in-kernel memory reservation to operate. In fact, these types of systems generally do not even do dynamic memory allocation - most everything is statically allocated and if the system tries to use more, it panics and reboots. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 15:39:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from golden.argonet.co.uk (golden.argonet.co.uk [194.131.104.13]) by hub.freebsd.org (Postfix) with SMTP id A79F815134 for ; Tue, 13 Jul 1999 15:39:29 -0700 (PDT) (envelope-from carson@causality.com) Received: from localhost [127.0.0.1] by golden.argonet.co.uk with smtp (Exim 1.82 #3) id 114BCT-0003ly-00; Tue, 13 Jul 1999 23:38:58 +0100 Date: Tue, 13 Jul 1999 23:38:57 +0100 (BST) From: "Neil A. Carson" X-Sender: carson@fm3.facility.pipex.com Reply-To: "Neil A. Carson" To: Matthew Dillon Cc: "Neil A. Carson" , Jason Thorpe , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <199907132233.PAA81393@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, Matthew Dillon wrote: > This is an excellent example of a solution. Another example would be > to implement your own memory management subsystem... that is, your own > shared library which keeps track of memory allocations on a global > basis. I could do one in about an hour. One simply mmap()'s a 4K Yeah, but the kernel had to be changed in a number of places to be able to do it properly :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 15:39:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id BEB2E15348 for ; Tue, 13 Jul 1999 15:39:43 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id PAA24879; Tue, 13 Jul 1999 15:39:27 -0700 (PDT) Message-Id: <199907132239.PAA24879@lestat.nas.nasa.gov> To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 13 Jul 1999 15:39:27 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999 15:37:26 -0700 (PDT) Matthew Dillon wrote: > When you write embedded systems like these, you do not run any general > purpose binaries at all. You run fully custom binaries and you take > control of the memory management yourself. Heh, really? The camera ships w/ Apache running on it. -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 15:45:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id E8CFF15088 for ; Tue, 13 Jul 1999 15:45:35 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA81515; Tue, 13 Jul 1999 15:44:40 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 15:44:40 -0700 (PDT) From: Matthew Dillon Message-Id: <199907132244.PAA81515@apollo.backplane.com> To: Jason Thorpe Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132230.PAA24729@lestat.nas.nasa.gov> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Tue, 13 Jul 1999 15:12:14 -0700 (PDT) : Matthew Dillon wrote: : : > The text size of a program is irrelevant, because swap is never : > allocated for it. The data and BSS are only relevant when they : > are modified. : :Bzzt. BSS is relevant when accessed (at least in NetBSD). True enough, though that is something we could fix under FreeBSD. Also irrelevant... anything that causes a page fault and allocates a page is effectively what we are talking about. :...and as I recall, those SGIs at BEST were general-purpose computing :environments. Chris already said that disallowing overcommit wasn't :necessarily appropriate in every situation. So make it a knob. Big :deal. Everyone has what they want. : : -- Jason R. Thorpe So far nobody has been able to justify any good reasons for adding it to the system. I'm sorry, but just throwing out worst-case theories is not a good justification, nor is throwing embedded systems into the fray - because those already have to control memory fairly tightly and there are plenty of ways of doing that without having to do in-kernel reservation. Throwing generic 'critical servers' into the fray also isn't appropriate, because any server that is that critical also implements its own memory alloction management. It has to in order to guarentee performance and performance will degrade before one runs out of memory. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 15:45:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2]) by hub.freebsd.org (Postfix) with ESMTP id 180D61533B; Tue, 13 Jul 1999 15:45:50 -0700 (PDT) (envelope-from soda@sra.co.jp) Received: from sranhf.sra.co.jp (sranhf [133.137.28.3]) by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id HAA25751; Wed, 14 Jul 1999 07:45:03 +0900 (JST) Received: from srapc342.sra.co.jp (srapc342 [133.137.28.111]) by sranhf.sra.co.jp (8.8.7/3.6Wbeta7-srambox) with ESMTP id HAA04884; Wed, 14 Jul 1999 07:45:01 +0900 (JST) Received: (from soda@localhost) by srapc342.sra.co.jp (8.8.8/3.4W-sra) id HAA15198; Wed, 14 Jul 1999 07:45:02 +0900 (JST) Date: Wed, 14 Jul 1999 07:45:02 +0900 (JST) Message-Id: <199907132245.HAA15198@srapc342.sra.co.jp> From: Noriyuki Soda To: Matthew Dillon Cc: Noriyuki Soda , Jason Thorpe , "Brian F. Feldman" , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <199907132229.PAA81360@apollo.backplane.com> References: <199907132127.OAA80947@apollo.backplane.com> <199907132139.GAA14890@srapc342.sra.co.jp> <199907132153.OAA81153@apollo.backplane.com> <199907132215.HAA15042@srapc342.sra.co.jp> <199907132229.PAA81360@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> On Tue, 13 Jul 1999 15:29:37 -0700 (PDT), Matthew Dillon said: > In the same manner any truely critical system server must handle the > resource management itself to deal with all sorts of problem situations, > including memory. You do not need to build any of this control into the > kernel. : [snip] : > To say that FreeBSD does not support a certain class of system because > it uses an overcommit model is not correct, because you can trivially > solve the problem by implementing your own management of memory rather > then use the UNIX libc builtins. That's wrong. The application might be killed by SIGKILL on current FreeBSD implementation, when the system becomes swap shortage. -- soda To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 15:47:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id 353FF15253 for ; Tue, 13 Jul 1999 15:47:13 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id PAA18454; Tue, 13 Jul 1999 15:47:03 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Tue, 13 Jul 1999 15:47:02 -0700 (PDT) From: Doug X-Sender: doug@dt054n86.san.rr.com To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: more amd hangs: problem really in syslog? In-Reply-To: <199907132123.OAA80902@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, Matthew Dillon wrote: > : > : So I started thinking that maybe the problem was actually in > :syslog (or amd's interface to it). So I disabled the following two options > :in my amd.conf file: > : > :log_file = syslog:local7 > :log_options = all > : > : And lo and behold, it worked like a charm. I was able to run my > :conf-building script for my web server 20 times in a row with no ill > :effects. Previously the best I could do was 3 times before it hung. > : > : After confirming that it worked with no logging, I tried enabling > :logging to a regular file, and that also worked like a charm. After > :turning syslog style logging back on, it locked up cold, with a very > :similar traceback. > : > : If anyone wants to work on this, let me know. > : > :Doug > > Are you syslogging to the console by any chance? Here is syslog.conf: *.err;kern.debug;auth.notice;mail.crit /dev/console *.notice;kern.debug;lpr.info;mail.crit;news.err /var/log/messages mail.info /var/log/maillog lpr.info /var/log/lpd-errs cron.* /var/cron/log *.err root *.notice;news.err root *.alert root *.emerg * local7.* /var/log/amd.log Basically, it's what comes with the system plus that line for local7. I am using a serial console setup for this box, but as far as I could see from the logs amd did generate there were no events at *.err priority, or to the kern facility, so nothing should have been printed to the serial console. Also, just in case it matters I start syslogd with -svv flags in rc.conf. > Try messing around > with /etc/syslog.conf and see if just plain file logging prevents the > lockup -- you could even try turning off all logging (but leaving syslog > running, i.e. turning it into a sink-null) to see if that has an effect. I have to admit that you lost me here. Normal syslog stuff is working just fine (where "normal" is freebsd system stuff), it's amd that locks up. It's been kind of a hectic day here, in addition to this problem so I might just be a little dense. Can you explain in more detail what you'd like me to try? Thanks, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 15:51:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id CEB0315134 for ; Tue, 13 Jul 1999 15:51:22 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id PAA18458; Tue, 13 Jul 1999 15:49:04 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Tue, 13 Jul 1999 15:49:04 -0700 (PDT) From: Doug X-Sender: doug@dt054n86.san.rr.com To: Mike Smith Cc: freebsd-hackers@freebsd.org Subject: Re: more amd hangs: problem really in syslog? In-Reply-To: <199907132134.OAA01221@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, Mike Smith wrote: > > After pounding on this some more with today's -current (prior to > > the MNT_ASYNC flag change) I got a lot more lockups that looked like > > this: > > > > On Mon, 12 Jul 1999, Doug wrote: > > > > > Ok, got another hang in "siobi" state (this time after it > > > successfully completed the script). Here is the trace: > > 'siobi' is in sioopen() in the sio driver. The callout device is > already open, but the caller is trying to open it in blocking mode. > It'd be useful to know what is hanging in 'siobi' here, since trying to > re-open the console is a bit of a suspicious action. I'm using a serial console, but I directed local7 to a file in syslog.conf. But from what you're saying it sounds like the serial console is a suspect? Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 15:52:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id F26D31514C for ; Tue, 13 Jul 1999 15:52:04 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA81581; Tue, 13 Jul 1999 15:50:05 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 15:50:05 -0700 (PDT) From: Matthew Dillon Message-Id: <199907132250.PAA81581@apollo.backplane.com> To: "Neil A. Carson" Cc: "Neil A. Carson" , Jason Thorpe , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :On Tue, 13 Jul 1999, Matthew Dillon wrote: : :> This is an excellent example of a solution. Another example would be :> to implement your own memory management subsystem... that is, your own :> shared library which keeps track of memory allocations on a global :> basis. I could do one in about an hour. One simply mmap()'s a 4K : :Yeah, but the kernel had to be changed in a number of places to be able to :do it properly :-) I can think of several ways to do it that do not require changes to the kernel. The most obvious way is to simply use SysV-shared memory calls to manage memory. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 15:52:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 09616153BF for ; Tue, 13 Jul 1999 15:52:50 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA81592; Tue, 13 Jul 1999 15:52:34 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 15:52:34 -0700 (PDT) From: Matthew Dillon Message-Id: <199907132252.PAA81592@apollo.backplane.com> To: Jason Thorpe Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132239.PAA24879@lestat.nas.nasa.gov> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Heh, really? The camera ships w/ Apache running on it. : : -- Jason R. Thorpe They obviously have a lot of memory to play with, then. Or they are crazy. Writing a web server is fairly easy to do. I've written several, including the one that BEST runs on most of its servers. But even Apache has knobs to control resources. You certainly do not need to modify the kernel to support Apache on an embedded system. Apache gives you a great deal of control over its resource limitations. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 15:53:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id 0262C14C06 for ; Tue, 13 Jul 1999 15:53:13 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id PAA01661; Tue, 13 Jul 1999 15:48:35 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907132248.PAA01661@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Doug Cc: freebsd-hackers@freebsd.org Subject: Re: more amd hangs: problem really in syslog? In-reply-to: Your message of "Tue, 13 Jul 1999 15:49:04 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jul 1999 15:48:35 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Tue, 13 Jul 1999, Mike Smith wrote: > > > > After pounding on this some more with today's -current (prior to > > > the MNT_ASYNC flag change) I got a lot more lockups that looked like > > > this: > > > > > > On Mon, 12 Jul 1999, Doug wrote: > > > > > > > Ok, got another hang in "siobi" state (this time after it > > > > successfully completed the script). Here is the trace: > > > > 'siobi' is in sioopen() in the sio driver. The callout device is > > already open, but the caller is trying to open it in blocking mode. > > It'd be useful to know what is hanging in 'siobi' here, since trying to > > re-open the console is a bit of a suspicious action. > > I'm using a serial console, but I directed local7 to a file in > syslog.conf. But from what you're saying it sounds like the serial console > is a suspect? 'siobi' is someone trying to open the serial console, for whatever reason. Without knowing who it was that was stuck there, it's hard to guess what is going on. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 15:53:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id C0E8114E0B; Tue, 13 Jul 1999 15:53:49 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA81615; Tue, 13 Jul 1999 15:53:43 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 15:53:43 -0700 (PDT) From: Matthew Dillon Message-Id: <199907132253.PAA81615@apollo.backplane.com> To: Noriyuki Soda Cc: Jason Thorpe , "Brian F. Feldman" , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132127.OAA80947@apollo.backplane.com> <199907132139.GAA14890@srapc342.sra.co.jp> <199907132153.OAA81153@apollo.backplane.com> <199907132215.HAA15042@srapc342.sra.co.jp> <199907132229.PAA81360@apollo.backplane.com> <199907132245.HAA15198@srapc342.sra.co.jp> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> kernel. : : : [snip] : : :> To say that FreeBSD does not support a certain class of system because :> it uses an overcommit model is not correct, because you can trivially :> solve the problem by implementing your own management of memory rather :> then use the UNIX libc builtins. : :That's wrong. :The application might be killed by SIGKILL on current FreeBSD :implementation, when the system becomes swap shortage. :-- :soda ... a situation which will never occur if you are managing the memory through your own custom library. Therefore not relevant. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 15:58:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 6D36315325 for ; Tue, 13 Jul 1999 15:58:10 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA81648; Tue, 13 Jul 1999 15:56:55 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 15:56:55 -0700 (PDT) From: Matthew Dillon Message-Id: <199907132256.PAA81648@apollo.backplane.com> To: Doug Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: more amd hangs: problem really in syslog? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :*.err;kern.debug;auth.notice;mail.crit /dev/console :*.notice;kern.debug;lpr.info;mail.crit;news.err /var/log/messages :mail.info /var/log/maillog :lpr.info /var/log/lpd-errs :cron.* /var/cron/log :*.err root :*.notice;news.err root :*.alert root :*.emerg * : :local7.* /var/log/amd.log : : Basically, it's what comes with the system plus that line for :local7. I am using a serial console setup for this box, but as far as I :could see from the logs amd did generate there were no events at *.err :priority, or to the kern facility, so nothing should have been printed to :the serial console. Also, just in case it matters I start syslogd with :-svv flags in rc.conf. : : :> Try messing around :> with /etc/syslog.conf and see if just plain file logging prevents the :> lockup -- you could even try turning off all logging (but leaving syslog :> running, i.e. turning it into a sink-null) to see if that has an effect. : : I have to admit that you lost me here. Normal syslog stuff is :working just fine (where "normal" is freebsd system stuff), it's amd that :locks up. It's been kind of a hectic day here, in addition to this problem :so I might just be a little dense. Can you explain in more detail what :you'd like me to try? : :Thanks, : :Doug Comment the whole thing out, kill -HUP the syslogd (or kill and restart it), and see if amd still locks up. If it does not, add the file lines (/var/*) back in, restart, and see if amd locks up. If it does not, add the /dev/console line back in, restart, and see if amd locks up. If it does not, add the "root" and "*" entries back in and see if amd locks up. And so forth. We may find that there is something inherently broken with syslogd that is causing the lockup even with all entries commented out, or we may well find that it is a certain line, such as the /dev/console, root, or "*" line for emergency messages that is causing amd to lockup. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 16: 2:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.netbsd.org (redmail.netbsd.org [155.53.200.193]) by hub.freebsd.org (Postfix) with SMTP id 45356152CC for ; Tue, 13 Jul 1999 16:02:00 -0700 (PDT) (envelope-from cgd@netbsd.org) Received: (qmail 17606 invoked by uid 1000); 13 Jul 1999 23:01:48 -0000 To: Matthew Dillon Cc: Jason Thorpe , "Brian F. Feldman" , Noriyuki Soda , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132110.OAA23817@lestat.nas.nasa.gov> <199907132114.OAA80781@apollo.backplane.com> <877lo4z0pe.fsf@redmail.redback.com> <199907132212.PAA81234@apollo.backplane.com> From: cgd@netbsd.org (Chris G. Demetriou) Date: 13 Jul 1999 16:01:47 -0700 In-Reply-To: Matthew Dillon's message of Tue, 13 Jul 1999 15:12:14 -0700 (PDT) Message-ID: <871zecyx0k.fsf@redmail.redback.com> Lines: 211 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon writes: > The text size of a program is irrelevant, because swap is never > allocated for it. The data and BSS are only relevant when they > are modified. > > The only thing swap is ever used for is the dynamic allocation of memory. > There are three ways to do it: sbrk(), mmap(... MAP_ANON), or > mmap(... MAP_PRIVATE). yup, almost: not all MAP_PRIVATE mappings need backing store, only MAP_PRIVATE and writeable mappings. (MAP_PRIVATE does _not_ guarantee that you won't see modifications made via other MAP_SHARED mappings.) > Dynamic allocation of memory can occur under a huge number of > conditions. The actual physical allocation of dynamic memory - what is > known as a copy-on-write - cannot be predicted from the potential > allocation of memory. The most obvious example of this is a fork(). yup. > There is a lot of hidden 'potential' VM that you haven't considered. > For example, if the resource limit for a process's stack is 8MB, then > the process can potentially allocate 8MB of stack even though it may > actually only allocate 32K of stack. Yes, this is a good example. In general, however, i believe it's safe to say that it's eaiser to constrain stack usage than heap usage. Many large consumers of heap usage are bad style to begin with ('real' embedded environments typically have very limited stacks), and mechanisms such as alloca() can be frobbed to use heap allocations (with some run-time cost). > When a process forks, the child > process can potentially modify just about every single non-text page that > was owned by the parent process, causing a copy-on-write to occur. > The dynamic potential can run into the megabytes but most child processes > only modify a small percentage of those pages. ... and, well written applications which are just going to execve() _should_ use vfork() for this case. If they use fork(), they want the ability to COW the entire address space, and should be charged for that data. > :Nowhere did I see what amounts to anything other than hand-waving > :claims that you'll have to allocate much, much more backing store than > :you currently need to, and claims that that's unacceptable for general > :purpose computing environments. If you have a more specific analysis > :that you'd like me/us to read, please point us at it more specifically. > > You are welcome to bring up real-life situations as examples. That > is what I do. But look who is doing the hand-waving now? Huh? You've made the claim that non-overcommit is useless and should not be implemented because it requires for normal workloads 8 or more times the actual backing store usage. You have yet to justify it. What workload are you talking about? What systems? You start to allude to this later, but you simply say "SGIs." > :* while you certainly need to allocate more backing store than you > :would with overcommit, it's _not_ ridiculously more for most > :applications(+), and, finally, > > Based on what? I am basing my information on the VM reservation made > by programs, and I am demonstrating specific points showing how those > reservations occur. For example, the default 8MB resource limit for > the stack segment. Actually, only now have you brought that up. And, that's very system dependent. On NetBSD/i386 the default is 2MB, and, it's worth noting that you only need to reserve as much as the current stack limit allows (after that, you're going to get a signal anyway, and if more reservations need to be done they can be done on a page-by-page basis and if it fails you deliver a signal and if it still fails deliver a nastier signal). Stack limits are pretty much the one odd case (and they're already handled oddly by the VM code.) > :* even if you are not willing to pay that price, there _are_ people > :who are quite willing to pay that price to get the benefits that they > :see (whether it's a matter of perception or not, from their > :perspective they may as well be real) of such a scheme. > > Quite true. In the embedded world we preallocate memory and shape > the programs to what is available in the system. But if we run out > of memory we usually panic and reboot - because the code is designed > to NOT run out of memory and thus running out of memory is a catastrophic > situation. There's a whole spectrum of embedded devices, and applications that run on them. That definition works for some of them, but definitely not all. A controller in my car's engine behaves as you describe. That's one type of embedded system, and can have very well defined memory requirements. There, if you're out of memory, you have a Problem. A web server appliance is another type of embedded system. Its memory requirements are quantifiable, but there's much more parameterization necessation. (# of clients being served vs. # of management sessions open vs. background tasks that may need to be run periodically, for instance.) Basically, for this type of thing you need various types of memory reservation and accounting for the various functions, and indeed, it's not best done (entirely) with an no-overcommit-based or resource-limit-based strategy. However, for 'background tasks' that might involve user-supplied code or that might have highly variable memory requirements, devoting some set of the memory to be managed by a no-overcommit or resource-limit strategy may be the right thing. (and i'd probably prefer the latter.) However, a web browser on the front of your microwave or on a handheld tablet is also a type of embedded system, it's an 'appliance.' The user should never have to worry about it rebooting, or hanging, or killing the program that they're looking at. (It may be reasonable to tell them that they're doing too much, and that they therefore need to shut something done, or prevent them from starting up new tasks when they're too close to a system limit.) In this type of world, memory needs are just too varied to control via blanket resource limits. Further, an applications needs may be sufficiently variable that they can't even be reasonably precomputed. You're faced with two choices: punt, and don't let the user exploit their system to its potential, or un-"embed" parts of it an expose memory allocation limits to the user (and do admission control based on them), like e.g. macintoshes used to do. In the latter two cases, no-overcommit and the proper "committed memory" accounting that comes with it is a very useful, perhaps critical, tool. (Note that the difference between a no-overcommit policy and between correct tracking of committed memory in a proper design is simply turning a boolean switch: you should always be tracking committed memory, and if you turn the switch you enable/disable overcommit.) (From personal experience, I've built 'embedded' systems in the latter two categories, non in the former. Ones like the latter have _seriously_ suffered from an inability to disallow overcommit.) > It is not appropriate to test every single allocation for a failure... > that results in bulky code and provides no real benefit since the > code is already designed to not overcommit the embedded system's memory. > If it does, you reboot. The most critical embedded systems, such as > those used in satellites, avoid dynamic allocation as much as possible > in order to guarentee that no memory failures occur. This works under > UNIX as well. If you run your programs and touch all your potentially > modifiable pages you have effectively reserved the memory. Yup. however, even in thise case, having to manually touch the pages is a wasteful detail that the programmer should not have to think about. resource reservation should take care of it for them. 8-) (the "wastefulness" there: (1) the programmer has to think about "effectively reserving" the memory, (2) the actual code to "effectively reserve" the memory in the application, and (3) any side effects the system may suffer because of this, e.g. immediate and unnecessary paging of a whole bunch of data, if it's a workstation/server system.) Certainly, it's better for many applications to allocate all the memory that they'll use in advance. But that's orthogonal to the issue of resource reservation, except inasmuch as kludges are necessary to get proper resource reservations. 8-) > :I would honestly love to know: what do you see huge numbers of > :reserved pages being reserved for, if they're not actually being > :committed, by 'average' UNIX applications (for any definition of > :average that excludes applications which do memory based computation > :on sparse dasta). > > Stack, hidden VM objects after a multi-way fork, MAP_PRIVATE memory maps, > private memory pools (e.g. for web servers, java VM's, and so forth). And of those, for properly written applications (i.e. those that use vfork() correctly), the _only_ actual difference between the pages that are considered committed and those which are actually committed are: * stack. Yes, this can be a significant, but manageable, source of difference. * writable private memory which hasn't yet been written (e.g. data, bss) which compared to many/most applications dynamic allocations is insignificant. * intentional sparse data allocation, which is the reason that any general-purpose OS which supports a no-overcommit policy _must_ be capable of supporting an overcommit-allowed policy for some peoples' usage. Note that I've never said that there aren't situations in which allowing overcommit is correct. In some situations, it's necessary. However, you've claimed that nobody should _ever_ have the ability to prevent overcommit, and that's simply unreasonable in certain situations. cgd -- Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html Disclaimer: Not speaking for NetBSD, just expressing my own opinion. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 16:10:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id C84E614CF8 for ; Tue, 13 Jul 1999 16:10:39 -0700 (PDT) (envelope-from faber@ISI.EDU) Received: from ISI.EDU (vex-e.isi.edu [128.9.160.240]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id QAA01587; Tue, 13 Jul 1999 16:09:48 -0700 (PDT) Message-Id: <199907132309.QAA01587@boreas.isi.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: Matthew Dillon Cc: hackers@freebsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: Your message of "Tue, 13 Jul 1999 15:53:43 PDT." <199907132253.PAA81615@apollo.backplane.com> X-Url: http://www.isi.edu/~faber Date: Tue, 13 Jul 1999 16:09:48 -0700 From: Ted Faber Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- So, Matt, I understand that you think that the folks who are want to turn off overcommit are looking to hang themselves, but how much does it cost to sell them the rope? Would adding the sysctl to turn off overcommit be a costly, time-consuming hunk of work, or a three-line patch? If it's the latter, why not provide the functionality? (Obviously if there's significant new work and complexity involved, changing the status quo demands proving a string case.) I don't have the knowledge of the VM system to answer the question; I can imagine a system with one or two VM allocation routines where the change would be trivial, and a more complex system where it would be very difficult. Which one do I run? :-) - ---------------------------------------------------------------------- Ted Faber faber@isi.edu USC/ISI Computer Scientist http://www.isi.edu/~faber (310) 822-1511 x190 PGP Key: http://www.isi.edu/~faber/pubkey.asc -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBN4vHO4b4eisfQ5rpAQHspwP/TELO+iZFOOnHdM6eMApmYfmJtrjO5z2M ZljFFV97Otsd+nVnI9I8OcICOo5sRLhPe/9G25Kv0Iz2yhsH4TUqWqyA5z5cZS2A ov5FmOG+MA9I6SwbOGiWKpVsjbMvBrBOF1aPm7VfxmhnZtERv14tQwosHwp9HAad mgd5iwUPlj0= =spdJ -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 16:12: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id 939F3152FD for ; Tue, 13 Jul 1999 16:11:45 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id QAA25089; Tue, 13 Jul 1999 16:10:46 -0700 (PDT) Message-Id: <199907132310.QAA25089@lestat.nas.nasa.gov> To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 13 Jul 1999 16:10:46 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999 15:44:40 -0700 (PDT) Matthew Dillon wrote: > So far nobody has been able to justify any good reasons for adding it > to the system. I'm sorry, but just throwing out worst-case theories > is not a good justification, nor is throwing embedded systems into the > fray - because those already have to control memory fairly tightly > and there are plenty of ways of doing that without having to do > in-kernel reservation. Throwing generic 'critical servers' into the > fray also isn't appropriate, because any server that is that critical > also implements its own memory alloction management. It has to in > order to guarentee performance and performance will degrade before > one runs out of memory. Well, all I can say is: I'm sure glad you don't have any influence over the code base I run. -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 16:13:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id 9AD7C1514A for ; Tue, 13 Jul 1999 16:13:31 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id QAA18670; Tue, 13 Jul 1999 16:13:23 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Tue, 13 Jul 1999 16:13:23 -0700 (PDT) From: Doug X-Sender: doug@dt054n86.san.rr.com To: Mike Smith Cc: Doug , freebsd-hackers@freebsd.org Subject: Re: more amd hangs: problem really in syslog? In-Reply-To: <199907132248.PAA01661@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, Mike Smith wrote: > 'siobi' is someone trying to open the serial console, for whatever > reason. Without knowing who it was that was stuck there, it's hard to > guess what is going on. D'uh, sorry. Long day. It was amd that was hung in the siobi state. No way to clear it without rebooting the box. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 16:18: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 2705414DF9 for ; Tue, 13 Jul 1999 16:18:03 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA81828; Tue, 13 Jul 1999 16:16:46 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 16:16:46 -0700 (PDT) From: Matthew Dillon Message-Id: <199907132316.QAA81828@apollo.backplane.com> To: Ted Faber Cc: hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) References: <199907132309.QAA01587@boreas.isi.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :So, Matt, I understand that you think that the folks who are want to :turn off overcommit are looking to hang themselves, but how much does :it cost to sell them the rope? : :Would adding the sysctl to turn off overcommit be a costly, :time-consuming hunk of work, or a three-line patch? If it's the :latter, why not provide the functionality? (Obviously if there's :significant new work and complexity involved, changing the status quo :demands proving a string case.) : :I don't have the knowledge of the VM system to answer the question; I :can imagine a system with one or two VM allocation routines where the :change would be trivial, and a more complex system where it would be :very difficult. Which one do I run? :-) : :- ---------------------------------------------------------------------- :Ted Faber faber@isi.edu :USC/ISI Computer Scientist http://www.isi.edu/~faber :(310) 822-1511 x190 PGP Key: http://www.isi.edu/~faber/pubkey.asc I'm guessing that a simple implementation would be about an hour's worth of work on the kernel: Basically keeping track of MAP_PRIVATE maps and summing up their total size verses the amount of main memory and swap available, minus some fudge factor. But you would never be able to run normal system programs reliably without also going through the entire utility source base and doing a whole lot of rewriting. Standard programs such as are not going to be happy when the limit is hit and this will slowly cause system daemons to disappear from the system and for programs to start dying in odd ways when you do anything that brings the system close to an 'overcommitted' state. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 16:19: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id 5C58D14DF9 for ; Tue, 13 Jul 1999 16:19:01 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id QAA18703; Tue, 13 Jul 1999 16:18:55 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Tue, 13 Jul 1999 16:18:55 -0700 (PDT) From: Doug X-Sender: doug@dt054n86.san.rr.com To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: more amd hangs: problem really in syslog? In-Reply-To: <199907132256.PAA81648@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, Matthew Dillon wrote: > Comment the whole thing out, kill -HUP the syslogd (or kill and restart > it), and see if amd still locks up. Ok, now I think I get it. You want me to enable syslog'ing in amd, then do what you're talking about here. I will try this first thing tomorrow morning. We're about to put the box into production to make sure that the bug is really licked, then I'm about to go home. :) We have multiple machines in this configuration, so taking this one down tomorrow should be no problem. > If it does not, add the file lines > (/var/*) back in, restart, and see if amd locks up. If it does not, > add the /dev/console line back in, restart, and see if amd locks up. > If it does not, add the "root" and "*" entries back in and see if amd > locks up. And so forth. Gotcha. > We may find that there is something inherently broken with syslogd > that is causing the lockup even with all entries commented out, or > we may well find that it is a certain line, such as the /dev/console, > root, or "*" line for emergency messages that is causing amd to lockup. I think that Mike Smith is on the right track in suspecting that the serial console is involved (due to the siobi state that amd was hanging in). However, which line of the syslog.conf that was causing that is a darn good question, given that none of them *should* have been involved. Thanks for all the great suggestions, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 16:21:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bubba.whistle.com (s205m7.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 3995814CF8 for ; Tue, 13 Jul 1999 16:21:30 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id QAA73479; Tue, 13 Jul 1999 16:20:35 -0700 (PDT) From: Archie Cobbs Message-Id: <199907132320.QAA73479@bubba.whistle.com> Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <199907132131.OAA80991@apollo.backplane.com> from Matthew Dillon at "Jul 13, 99 02:31:38 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Tue, 13 Jul 1999 16:20:35 -0700 (PDT) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon writes: > :> ram and 512MB of swap (4MB of swap in use), but the kernel reports over > :> 3 GB of VM assigned to processes. That's a fairly lightly loaded machine. > : > :What you say is generally true; however, the problem is that *you* > :are making implicit assumptions about what applications *I* might > :have in mind. I just think that's a presumptous thing to do unless > :you can read minds.. > : > :For example: > : > :- I could be creating a "Java OS" that is going to have a single process, > : ie, the Java VM, that can handle ENOMEM (which translates into an > : OutOfMemoryException, which can be caught) but otherwise *must not die*. > > .... just one process? Set a resource limit! If you have 64MB of swap, > then limit the size of the Java OS process to 50MB. Now the java > process will get a nice malloc failure instead of getting killed by > the kernel. That would work too I suppose.. but the larger point is that, who knows what strange/crazy things people might want to do? (Maybe somebody just wants to try it for some kind of empirical test?) Aside from all the hype on either side, the fact that there is even an argument about it means that some people would like to at least have the ability to turn off overcommit. So if it's not a problem to add the sysctl, why not do it? Let them shoot their feet off if that's what will happen. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 16:21:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id DA5241534F for ; Tue, 13 Jul 1999 16:21:40 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id QAA01841; Tue, 13 Jul 1999 16:16:07 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907132316.QAA01841@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Ted Faber Cc: Matthew Dillon , hackers@freebsd.org Subject: Re: Replacement for grep(1) (part 2) In-reply-to: Your message of "Tue, 13 Jul 1999 16:09:48 PDT." <199907132309.QAA01587@boreas.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jul 1999 16:16:07 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > So, Matt, I understand that you think that the folks who are want to > turn off overcommit are looking to hang themselves, but how much does > it cost to sell them the rope? The issue here is that "turning off overcommit" isn't just a switch. There are a lot of other things that you're likely to want to do, depending on your application, in addition to turning it off. Matt's point, which he's not making by virtue of talking too much, is that you can't make a "no overcommit" system behave like an "overcommit" system, and most people are used to the sort of things that the latter makes practical. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 16:25:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id F2E0D152CC for ; Tue, 13 Jul 1999 16:25:20 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA81905; Tue, 13 Jul 1999 16:24:53 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 16:24:53 -0700 (PDT) From: Matthew Dillon Message-Id: <199907132324.QAA81905@apollo.backplane.com> To: Jason Thorpe Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132310.QAA25089@lestat.nas.nasa.gov> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Well, all I can say is: : : I'm sure glad you don't have any influence over the code : base I run. : : -- Jason R. Thorpe I'm sure the feeling is mutual. More to the point, I really seriously doubt that any of the core developers would consider this idea either because it's been rejected in the past and, so far, nobody has offered anything that hasn't been heard before. You are welcome to ask them, of course, but that is the feeling I get. There are much easier ways to accomplish the level of control required. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 16:28:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id 8923C150CA for ; Tue, 13 Jul 1999 16:28:44 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id QAA25268; Tue, 13 Jul 1999 16:27:12 -0700 (PDT) Message-Id: <199907132327.QAA25268@lestat.nas.nasa.gov> To: Mike Smith Cc: Ted Faber , Matthew Dillon , hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 13 Jul 1999 16:27:11 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999 16:16:07 -0700 Mike Smith wrote: > Matt's point, which he's not making by virtue of talking too much, is > that you can't make a "no overcommit" system behave like an "overcommit" > system, and most people are used to the sort of things that the latter > makes practical. That's just silly. If people want a no-overcommit system, they have it, and if they don't, they have that, too. That's why you make it a switch. No, really, you *can* just make it a switch. -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 16:30:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id 589891502B for ; Tue, 13 Jul 1999 16:30:16 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id QAA25285; Tue, 13 Jul 1999 16:28:27 -0700 (PDT) Message-Id: <199907132328.QAA25285@lestat.nas.nasa.gov> To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 13 Jul 1999 16:28:27 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999 16:24:53 -0700 (PDT) Matthew Dillon wrote: > I'm sure the feeling is mutual. More to the point, I really seriously > doubt that any of the core developers would consider this idea either > because it's been rejected in the past and, so far, nobody has offered Core developers for who? FreeBSD? Fine! I wouldn't ever run it! :-) -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 16:30:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 6C1BB15354 for ; Tue, 13 Jul 1999 16:30:20 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA81953; Tue, 13 Jul 1999 16:28:14 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 16:28:14 -0700 (PDT) From: Matthew Dillon Message-Id: <199907132328.QAA81953@apollo.backplane.com> To: Mike Smith Cc: Ted Faber , hackers@freebsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132316.QAA01841@dingo.cdrom.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :(Mike Smith ) :Matt's point, which he's not making by virtue of talking too much, is :that you can't make a "no overcommit" system behave like an "overcommit" :system, and most people are used to the sort of things that the latter :makes practical. Heh heh. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 16:34: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id B43B714C9F for ; Tue, 13 Jul 1999 16:34:01 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA82004; Tue, 13 Jul 1999 16:33:41 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 16:33:41 -0700 (PDT) From: Matthew Dillon Message-Id: <199907132333.QAA82004@apollo.backplane.com> To: Jason Thorpe Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132328.QAA25285@lestat.nas.nasa.gov> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Tue, 13 Jul 1999 16:24:53 -0700 (PDT) : Matthew Dillon wrote: : : > I'm sure the feeling is mutual. More to the point, I really seriously : > doubt that any of the core developers would consider this idea either : > because it's been rejected in the past and, so far, nobody has offered : :Core developers for who? FreeBSD? Fine! I wouldn't ever run it! :-) : : -- Jason R. Thorpe Maybe if I call the sysctl "vm.crashmenow". No, that will just make more people actually try it. It might be doable as a compile-time option, since you wouldn't be able to run anything approaching standard on such a system anyway. I don't see much use for it myself. As I said before, there are easier ways to manage memory that are not quite as arbitrary as simply refusing a potential overcommit. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 16:34: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id C04FB14DF7 for ; Tue, 13 Jul 1999 16:34:02 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id QAA01922; Tue, 13 Jul 1999 16:29:50 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907132329.QAA01922@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Jason Thorpe Cc: hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) In-reply-to: Your message of "Tue, 13 Jul 1999 16:27:11 PDT." <199907132327.QAA25268@lestat.nas.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jul 1999 16:29:50 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Tue, 13 Jul 1999 16:16:07 -0700 > Mike Smith wrote: > > > Matt's point, which he's not making by virtue of talking too much, is > > that you can't make a "no overcommit" system behave like an "overcommit" > > system, and most people are used to the sort of things that the latter > > makes practical. > > That's just silly. If people want a no-overcommit system, they have it, > and if they don't, they have that, too. You're too tied up in what you think you're trying to say that you're missing what I'm telling you. Of course you can turn overcommit off and on (more or less) with a switch. But a system that doesn't overcommit doesn't behave like a system that does; the two are quite different animals in many respects. You can make the "overcommit or not overcommit" option a switch, but the consumers of the system (may) need to change their behaviour as well. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 16:39:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id 5939B14C9F for ; Tue, 13 Jul 1999 16:39:26 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id QAA25458; Tue, 13 Jul 1999 16:38:47 -0700 (PDT) Message-Id: <199907132338.QAA25458@lestat.nas.nasa.gov> To: Mike Smith Cc: hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 13 Jul 1999 16:38:46 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999 16:29:50 -0700 Mike Smith wrote: > You can make the "overcommit or not overcommit" option a switch, but > the consumers of the system (may) need to change their behaviour as > well. I never said they wouldn't have to. -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 16:44: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id A85BC15320 for ; Tue, 13 Jul 1999 16:44:04 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id QAA01988; Tue, 13 Jul 1999 16:40:07 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907132340.QAA01988@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Jason Thorpe Cc: hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) In-reply-to: Your message of "Tue, 13 Jul 1999 16:38:46 PDT." <199907132338.QAA25458@lestat.nas.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Jul 1999 16:40:07 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Tue, 13 Jul 1999 16:29:50 -0700 > Mike Smith wrote: > > > You can make the "overcommit or not overcommit" option a switch, but > > the consumers of the system (may) need to change their behaviour as > > well. > > I never said they wouldn't have to. "Making it just a switch" does not imply "must modify other parts of the kernel and userspace to avoid incompatible dysfunction". Since you were setting your argument up _against_ that point, it was reasonable to infer that you were specifically excluding those cases. Please stop trolling; you've demonstrated your total disinterest in contributing anything positive in this conversation; do us a favor and bow out (you can take your toadies with you). -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 16:51:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from celery.dragondata.com (celery.dragondata.com [205.253.12.6]) by hub.freebsd.org (Postfix) with ESMTP id D604615195 for ; Tue, 13 Jul 1999 16:51:40 -0700 (PDT) (envelope-from toasty@celery.dragondata.com) Received: (from toasty@localhost) by celery.dragondata.com (8.9.3/8.9.3) id PAA38415; Sun, 11 Jul 1999 15:26:51 -0500 (CDT) (envelope-from toasty) From: Kevin Day Message-Id: <199907112026.PAA38415@celery.dragondata.com> Subject: Re: a BSD identd In-Reply-To: from John Polstra at "Jul 11, 1999 01:19:18 pm" To: jdp@polstra.com (John Polstra) Date: Sun, 11 Jul 1999 15:26:50 -0500 (CDT) Cc: Doug@gorean.org (Doug), hackers@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Doug wrote: > > John Polstra wrote: > >> > >> Are you sure? If you simply don't run an identd, the queries will > >> get an instant connection refused error. That's even faster than > >> sending back a bogus response. > > > > Many daemons that request ident, and almost all IRC daemons > > that I'm aware of don't take "NO" for an answer. They sit waiting > > for a valid response, and timeout after X seconds, where X is c. 30 > > seconds. > > Really?? Even though their connect() call failed? Ick! I know > sendmail doesn't behave that way. I'll take your word about the IRC > daemons -- I don't know anything about them. > > > Whether this behavior is good or not begs the question, > > Agreed. Every ircd i've ever seen will immediately return on a connection refused response. With ident: [15:22] -irc.dragondata.com- Looking up your hostname... [15:22] -irc.dragondata.com- Found your hostname, cached [15:22] -irc.dragondata.com- Checking Ident *** Identd request from 204.137.237.3 *** Identd replied: 1063, 4242 : USERID : UNIX : toasty [15:22] -irc.dragondata.com- Got Ident response PING? PONG! Welcome to Newnet Toasty9 Your host is irc.dragondata.com, running version nn-1.3devel.tmnotefix.noudpspam.hnam Elapsed time was less than 1 second. With no ident: [15:21] -irc.dragondata.com- Looking up your hostname... [15:21] -irc.dragondata.com- Checking Ident [15:21] -irc.dragondata.com- Found your hostname ToastyMan Nickname is already in use. PING? PONG! Welcome to Newnet Toasty9 Your host is irc.dragondata.com, running version nn-1.3devel.tmnotefix.noudpspam.hnam Elapsed time was less than 1 second. (I just tested this in NewNet, DALnet, EFnet, and Undernet) The only time I see it sitting there for 30 seconds is if ircd gets no response at all back, (no 'connection refused') Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 16:52:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id ACC3915157 for ; Tue, 13 Jul 1999 16:52:07 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id QAA13287; Tue, 13 Jul 1999 16:49:57 -0700 (PDT) Message-Id: <199907132349.QAA13287@implode.root.com> To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-reply-to: Your message of "Tue, 13 Jul 1999 16:24:53 PDT." <199907132324.QAA81905@apollo.backplane.com> From: David Greenman Reply-To: dg@root.com Date: Tue, 13 Jul 1999 16:49:57 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >: >:Well, all I can say is: >: >: I'm sure glad you don't have any influence over the code >: base I run. >: >: -- Jason R. Thorpe > > I'm sure the feeling is mutual. More to the point, I really seriously > doubt that any of the core developers would consider this idea either > because it's been rejected in the past and, so far, nobody has offered > anything that hasn't been heard before. You are welcome to ask them, > of course, but that is the feeling I get. There are much easier ways > to accomplish the level of control required. I'm not fundamentally opposed to a no-overcommit knob, but I think implementing it properly is more difficult than people think. There are things that do implied swap allocation (automatic stack allocation and fork() are two examples) that make this a difficult problem to solve. I wouldn't personally want to run a system with such a knob turned on, however, and I tend to agree with Matt that there are other better ways to solve the embedded system case. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 16:56: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from metriclient-2.uoregon.edu (metriclient-2.uoregon.edu [128.223.172.2]) by hub.freebsd.org (Postfix) with ESMTP id 5B62715157 for ; Tue, 13 Jul 1999 16:55:55 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by metriclient-2.uoregon.edu (8.9.1/8.8.7) id QAA29526; Tue, 13 Jul 1999 16:55:20 -0700 (PDT) Message-ID: <19990713165520.08447@hydrogen.fircrest.net> Date: Tue, 13 Jul 1999 16:55:20 -0700 From: John-Mark Gurney To: Matthew Dillon Cc: Matthew Jacob , freebsd-hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) References: <199907131920.MAA80146@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199907131920.MAA80146@apollo.backplane.com>; from Matthew Dillon on Tue, Jul 13, 1999 at 12:20:37PM -0700 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 3.0-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon scribbled this message on Jul 13: > FreeBSD's swap subsystem has a basic limitation of 4 swap areas. This > is due to the design of the interleaving algorithms. Increasing this > number is simple, but it results in phenominally more kernel memory > getting wired. Within this limitation we can theoretically add and > remove swap areas with relative easy. It would be somewhat easier to do > under CURRENT because the swap metadata structures are simpler. hmmm... so this means that on my home server where I have: Device 1K-blocks Used Avail Capacity Type /dev/od0b 262144 31176 230840 12% Interleaved /dev/da1b 393216 31136 361952 8% Interleaved /dev/da2b 262144 31072 230944 12% Interleaved /dev/da3b 131072 31180 99764 24% Interleaved /dev/sd4b 393216 30916 362172 8% Interleaved /dev/sd5b 65536 30992 34416 47% Interleaved /dev/sd6b 131072 30580 100364 23% Interleaved Total 1637504 217052 1420452 13% FreeBSD metriclient-2.uoregon.edu 3.0-RELEASE FreeBSD 3.0-RELEASE #19: Sun May 16 18:36:07 PDT 1999 root@:/a/home/johng/FreeBSD-checkout/30r/sys/compile/hydrogen i386 does this mean that the kernel is using more wired memory than it should be? I have been able to do extensive swapping and when I do, I can get around 3-4meg/sec for EACH of swapping in and out... so the performance is pretty decient... and I have 80megs of ram in the machine... I have: options "NSWAPDEV=10" in my kernel config file... -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 16:58:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id DE2EC15157; Tue, 13 Jul 1999 16:58:20 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA82157; Tue, 13 Jul 1999 16:56:26 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 16:56:26 -0700 (PDT) From: Matthew Dillon Message-Id: <199907132356.QAA82157@apollo.backplane.com> To: "Charles M. Hannum" Cc: Noriyuki Soda , Jason Thorpe , "Brian F. Feldman" , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907132346.TAA13780@bikini.ihack.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> And disallowing overcommit also does not give applications the *choice* :> of dealing gracefully, because they often cannot deal with the :> situation where they might be refused a reasonable request for memory. : :That's objectively false. The application could do something useful :if it wanted to. That most applications don't isn't relevant. The :system can at least provide the mechanism. : :> But back to your 1000-hour simulation: If you are running it on an :> environment designed to deal with thousand-hours simulations, then :> you are obviously going to have sufficient swap such that your :> simulation will never get the axe anyway. : :That's also objectively false. Most such environments I've had :experience with are, in fact, multi-user systems. As you've pointed :out yourself, there is no combination of resource limits and whatnot :that are guaranteed to prevent `crashing' a multi-user system due to :overcommit. My simulation should not be axed because of a bug in :someone else's program. (This is also not hypothetical. There was a :bug in one version of bash that caused it to consume all the memory it :could and then fall over.) Has your simulation ever been kicked by the kernel due to lack of swap space? I'm betting the answer is no. You have to consider the probability of an event occuring, not just the possibility that the event might occur. If the probability is one in a million years, then it is not something you need to worry about relative to other things that, perhaps, you *should* be worrying about. :> It's easy to come up with potentials, but try assigning a probabilty :> to them and see how much they make sense then. If you've been running :> thousand-hour simulations for 20 years and not a single one has ever :> been blown away due to the system running out of swap, then it obviously :> isn't an issue. : :And lastly, that is also objectively false. Just because I haven't :been screwed yet (and, in fact, I *have* been), that doesn't mean I :won't be screwed in the future. The sky might fall tomorrow too, but you do not see me running around the room like a chicken with its head cut off. Again, you are making the incorrect assumption that just because something *might* occur, it *will* occur. Calculate the probability. If the probability is not significant relative to other potential problems (like someone kicking the power cord out of the computer), then it isn't something you should be worrying about. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 17: 5:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id 23F22152F6 for ; Tue, 13 Jul 1999 17:05:25 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id RAA25629; Tue, 13 Jul 1999 17:04:12 -0700 (PDT) Message-Id: <199907140004.RAA25629@lestat.nas.nasa.gov> To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 13 Jul 1999 17:04:12 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999 16:56:26 -0700 (PDT) Matthew Dillon wrote: > You have to consider the probability of an event occuring, not just > the possibility that the event might occur. If the probability is > one in a million years, then it is not something you need to worry > about relative to other things that, perhaps, you *should* be worrying > about. Having been a systems programmer and systems administrator at a university computer science department, dealing with large (well, they were large back then :-) systems where 60 students log in simultaneously to do their "Data Structures in C++" homework, I can guarantee you that the probability that someone else's buggy program will kill your unrelated application is a lot more than "once in a million years". -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 17: 5:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2]) by hub.freebsd.org (Postfix) with ESMTP id 77F901535C; Tue, 13 Jul 1999 17:05:27 -0700 (PDT) (envelope-from soda@sra.co.jp) Received: from sranhf.sra.co.jp (sranhf [133.137.28.3]) by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id JAA27957; Wed, 14 Jul 1999 09:04:14 +0900 (JST) Received: from srapc342.sra.co.jp (srapc342 [133.137.28.111]) by sranhf.sra.co.jp (8.8.7/3.6Wbeta7-srambox) with ESMTP id JAA04943; Wed, 14 Jul 1999 09:04:12 +0900 (JST) Received: (from soda@localhost) by srapc342.sra.co.jp (8.8.8/3.4W-sra) id JAA15623; Wed, 14 Jul 1999 09:04:13 +0900 (JST) Date: Wed, 14 Jul 1999 09:04:13 +0900 (JST) Message-Id: <199907140004.JAA15623@srapc342.sra.co.jp> From: Noriyuki Soda To: Matthew Dillon Cc: Noriyuki Soda , Jason Thorpe , "Brian F. Feldman" , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <199907132253.PAA81615@apollo.backplane.com> References: <199907132127.OAA80947@apollo.backplane.com> <199907132139.GAA14890@srapc342.sra.co.jp> <199907132153.OAA81153@apollo.backplane.com> <199907132215.HAA15042@srapc342.sra.co.jp> <199907132229.PAA81360@apollo.backplane.com> <199907132245.HAA15198@srapc342.sra.co.jp> <199907132253.PAA81615@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> On Tue, 13 Jul 1999 15:53:43 -0700 (PDT), Matthew Dillon said: > ... a situation which will never occur if you are managing the memory > through your own custom library. Therefore not relevant. Hm. It's misunderstanding. I don't agree with you about the following point. Thus, the situation might happen. > Give me a shell and I can crash any machine. If you are assuming > hostile users, you cannot assume that your magic overcommit protection > will save your server. Saying that the kernel and application behave > properly is a cop-out, because it's virtually impossible to guarentee > that for every situation. The chance of a user blowing up the server > by finding a bug or a hole somewhere is much, much greater then the chance > of a user running the system out of swap. If you are trying to say that it is easier to crash FreeBSD than the system out of swap. You might be wrong. Memory consumption is quite easy, almost every programmer can do it with normal user privilege. If there is a bug which crashes FreeBSD and which is easier to write than memory consumption, it is better to fix the bug. -- soda To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 17:14:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id C943A15157; Tue, 13 Jul 1999 17:14:47 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id RAA07415; Tue, 13 Jul 1999 17:12:08 -0700 Date: Tue, 13 Jul 1999 17:12:08 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Jason Thorpe , dillon@freebsd.org Cc: freebsd-hackers@freebsd.org, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) In-Reply-To: <199907140004.RAA25629@lestat.nas.nasa.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Tue, 13 Jul 1999 16:56:26 -0700 (PDT) > Matthew Dillon wrote: > > > You have to consider the probability of an event occuring, not just > > the possibility that the event might occur. If the probability is > > one in a million years, then it is not something you need to worry > > about relative to other things that, perhaps, you *should* be worrying > > about. > > Having been a systems programmer and systems administrator at a > university computer science department, dealing with large (well, > they were large back then :-) systems where 60 students log in That's not very large and wasn't back then either, even for low budget hardware. We ran 33 users on a 128KB PDP 11/45 when I worked at Sidereal in Portland (and people who attempted to use vi were taken out behind the woodshed and dealt with). > simultaneously to do their "Data Structures in C++" homework, I > can guarantee you that the probability that someone else's buggy > program will kill your unrelated application is a lot more than > "once in a million years". The purpose of a multiprogramming OS is to keep this from happening. If it happens, you've incorrectly configured the OS or the OS needs some rethinking. As a general rule. This discussion has begun to really be unproductive. But it was interesting to see that it occurred at all. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 17:15:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 1507715369 for ; Tue, 13 Jul 1999 17:15:10 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA82237; Tue, 13 Jul 1999 17:12:30 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 17:12:30 -0700 (PDT) From: Matthew Dillon Message-Id: <199907140012.RAA82237@apollo.backplane.com> To: John-Mark Gurney Cc: Matthew Jacob , freebsd-hackers@FreeBSD.ORG Subject: Swap subsystem overhead (was Re: Replacement for grep(1) (part 2)) References: <199907131920.MAA80146@apollo.backplane.com> <19990713165520.08447@hydrogen.fircrest.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :hmmm... so this means that on my home server where I have: :Device 1K-blocks Used Avail Capacity Type :/dev/od0b 262144 31176 230840 12% Interleaved :/dev/da1b 393216 31136 361952 8% Interleaved :/dev/da2b 262144 31072 230944 12% Interleaved :/dev/da3b 131072 31180 99764 24% Interleaved :/dev/sd4b 393216 30916 362172 8% Interleaved :/dev/sd5b 65536 30992 34416 47% Interleaved :/dev/sd6b 131072 30580 100364 23% Interleaved :Total 1637504 217052 1420452 13% :FreeBSD metriclient-2.uoregon.edu 3.0-RELEASE FreeBSD 3.0-RELEASE #19: Sun May 16 18:36:07 PDT 1999 root@:/a/home/johng/FreeBSD-checkout/30r/sys/compile/hydrogen i386 : :does this mean that the kernel is using more wired memory than it should :be? I have been able to do extensive swapping and when I do, I can get :around 3-4meg/sec for EACH of swapping in and out... so the performance :is pretty decient... and I have 80megs of ram in the machine... : :I have: :options "NSWAPDEV=10" : :in my kernel config file... : John-Mark Gurney Voice: +1 541 684 8449 Ok, I will be more specific. Under FreeBSD-STABLE *AND* FreeBSD-CURRENT, FreeBSD allocates metadata structures that scale to the amount of swap space assigned to the system. However, it is not *precisely* the amount of swap space. What it is is the largest single swap area multiplied by the number of swap areas. Your largest single swap area is 393MB so meta-data is allocated to cover 393MB x 10 = 3.93 GB worth of swap even though you only actually have 1.6GB of swap. The reason things are done this way is simply because it is the easiest way for the swap subsystem to allocate swap. It interleaves the swap areas equally across one big linear swath, and then reserves the holes that are left over when one swap area terminates before another. The swap subsystem can then attempt to allocate a linear swath that then happens to inherently interleave across multiple devices. Under FreeBSD-stable, the kern/subr_rlist module is used. This module nominally allocates holes only as required, but due to the interleaving there are lots of holes even when no swap is in use. So it scales roughly the same as FreeBSD-current. The one exception is in the case where all the swap areas are exactly the same size. In this case FreeBSD-stable does a better job in regards to the memory it uses for the initial allocation. Under FreeBSD-current we use the kern/subr_blist module, which is a fixed radix tree. FreeBSD-current preallocates all the necessary bitmaps required to manage the swap area so there is a larger initial memory allocation. FreeBSD-current makes up for this by having a (usually) smaller dynamic memory component once swapping actually starts to happen. FreeBSD-current preallocates the metadata in order to prevent low-memory deadlocks from occuring (something FreeBSD-stable cannot guarentee using rlists). FreeBSD-current's swap subsystem is also an O(1)ish algorithm to both allocate and free swap while FreeBSD-stable's swap subsystem uses an O(N) algorithm to free swap and approximately O(1) to allocate it (unless there is fragmentation, in which case it is worse). In your case, if you are running STABLE I recommend that you throw away your smaller areas to reduce fragmentation /dev/da3b, /dev/sd5b, and /dev/da6b. If you are running CURRENT it doesn't really matter... you will only save memory if you throw away your largest two areas, which I do not recommend. The memory used by the swap subsystem is probably a drop in the bucket for you anyway, so you normally do not have to worry about it. Under FreeBSD-current you can use: vmstat -m | more (then search for "VM pgdata") and vmstat -z | more (then search for "SWAPMETA") To determine how much memory has been wired to support the swap subsystem. "VM pgdata" is the fixed allocation supporting the radix tree while SWAPMETA is the dynamic allocation supporting currently swapped-out goods. Under FreeBSD-stable, just look under "VM pgdata" to see how much memory is being wired to support the swap subsystem. This usage covers both the fixed and dynamic allocations. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 17:16:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id E5D011533F; Tue, 13 Jul 1999 17:16:30 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 114Ciq-000CzJ-00; Wed, 14 Jul 1999 02:16:28 +0200 From: Sheldon Hearn To: "Brian F. Feldman" Cc: hackers@FreeBSD.org Subject: Re: a BSD identd In-reply-to: Your message of "Mon, 12 Jul 1999 15:12:49 -0400." Date: Wed, 14 Jul 1999 02:16:28 +0200 Message-ID: <49928.931911388@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 12 Jul 1999 15:12:49 -0400, "Brian F. Feldman" wrote: > It's "out with the bad, in with the good." Pidentd code is pretty > terrible. Hi Brian, I let your comment above go at the time that you said it and I waited for Kevin Day to substantiate similar claims. Kevin very kindly took the time to submit a PR which has helped me demonstrate to him that the problems which he was seeing that led him to declare pidentd buggy were in fact caused by a bug (bugs?) in the version of inetd that he's running. So while I take to heart Mike Smith's comments ("I'm ... worried about ... where the seniority of a code entity is considered more significant than its functionality") I do think that this exercise serves no purpose as long as pidentd is doing its job properly. For detail on the inetd bugs causing apparent pidentd instability, I invite you to examine PR 12596. If you feel there are other problems with pidentd, I invite you to take Kevin's lead and file a PR. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 17:17: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 1AC8215157 for ; Tue, 13 Jul 1999 17:17:04 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA82304; Tue, 13 Jul 1999 17:16:54 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 17:16:54 -0700 (PDT) From: Matthew Dillon Message-Id: <199907140016.RAA82304@apollo.backplane.com> To: Jason Thorpe Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907140004.RAA25629@lestat.nas.nasa.gov> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :On Tue, 13 Jul 1999 16:56:26 -0700 (PDT) : Matthew Dillon wrote: : : > You have to consider the probability of an event occuring, not just : > the possibility that the event might occur. If the probability is : > one in a million years, then it is not something you need to worry : > about relative to other things that, perhaps, you *should* be worrying : > about. : :Having been a systems programmer and systems administrator at a :university computer science department, dealing with large (well, :they were large back then :-) systems where 60 students log in :simultaneously to do their "Data Structures in C++" homework, I :can guarantee you that the probability that someone else's buggy :program will kill your unrelated application is a lot more than :"once in a million years". : : -- Jason R. Thorpe This really has nothing to do with modern day computing or modern day computers, and certainly has nothing to do with the problem at hand. Well do I remember cory.berkeley.edu, a poor Vax 780 at the time which got driven into the ground nearly every day. The machine blew up at least once or twice a week, but it was never due to running out of swap. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 17:17:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id D43421533B for ; Tue, 13 Jul 1999 17:17:19 -0700 (PDT) (envelope-from faber@ISI.EDU) Received: from ISI.EDU (vex-e.isi.edu [128.9.160.240]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id RAA05545; Tue, 13 Jul 1999 17:17:18 -0700 (PDT) Message-Id: <199907140017.RAA05545@boreas.isi.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: Matthew Dillon Cc: hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: Your message of "Tue, 13 Jul 1999 16:16:46 PDT." <199907132316.QAA81828@apollo.backplane.com> X-Url: http://www.isi.edu/~faber Date: Tue, 13 Jul 1999 17:17:18 -0700 From: Ted Faber Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- Matthew Dillon wrote: >I said: >:So, Matt, I understand that you think that the folks who are want to >:turn off overcommit are looking to hang themselves, but how much does >:it cost to sell them the rope? > > I'm guessing that a simple implementation would be about an hour's > worth of work on the kernel: [...] > > But you would never be able to run normal system programs reliably > without also going through the entire utility source base and doing a > whole lot of rewriting. Standard programs such as > are not going to be happy when the limit is > hit and this will slowly cause system daemons to disappear from the > system and for programs to start dying in odd ways when you do anything > that brings the system close to an 'overcommitted' state. If it's a small hunk of work, maybe one of the folks who wants the overcommit turned off can do the work and get it committed or post patches. It would allow the arguments to be decided by experiment. It seems we're well past the point of convincing anyone verbally. I'm not going to do it because (1) I like my overcommitted system just fine, thanks and (2) I don't know the VM system well enough to walk in and change it. - ---------------------------------------------------------------------- Ted Faber faber@isi.edu USC/ISI Computer Scientist http://www.isi.edu/~faber (310) 822-1511 x190 PGP Key: http://www.isi.edu/~faber/pubkey.asc -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBN4vXDYb4eisfQ5rpAQE8oAQAmVUZhXtDdils+lgxLCZsBKauA6VmPRTN pQjxc1IY5mslvzLq1yt9c+lT+4xplRs+bLWTK3k2IzvalZ6BzIB9pYT8bq2Rz+6h nBLQNkiQql1y0Ld8SrofJPIbbl2LQhLfT8T5PNz5PpqP4DD7z7p8JDJawnL0y1dq ws6YnHSJQ1A= =JcZA -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 17:26: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 1837F15157; Tue, 13 Jul 1999 17:26:04 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA82339; Tue, 13 Jul 1999 17:25:21 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 17:25:21 -0700 (PDT) From: Matthew Dillon Message-Id: <199907140025.RAA82339@apollo.backplane.com> To: Noriyuki Soda Cc: Jason Thorpe , "Brian F. Feldman" , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132127.OAA80947@apollo.backplane.com> <199907132139.GAA14890@srapc342.sra.co.jp> <199907132153.OAA81153@apollo.backplane.com> <199907132215.HAA15042@srapc342.sra.co.jp> <199907132229.PAA81360@apollo.backplane.com> <199907132245.HAA15198@srapc342.sra.co.jp> <199907132253.PAA81615@apollo.backplane.com> <199907140004.JAA15623@srapc342.sra.co.jp> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Hm. It's misunderstanding. : :I don't agree with you about the following point. :Thus, the situation might happen. : :> Give me a shell and I can crash any machine. If you are assuming :> hostile users, you cannot assume that your magic overcommit protection :> will save your server. Saying that the kernel and application behave :> properly is a cop-out, because it's virtually impossible to guarentee :> that for every situation. The chance of a user blowing up the server :> by finding a bug or a hole somewhere is much, much greater then the chance :> of a user running the system out of swap. : :If you are trying to say that it is easier to crash FreeBSD than :the system out of swap. You might be wrong. : :Memory consumption is quite easy, almost every programmer can do it :with normal user privilege. :If there is a bug which crashes FreeBSD and which is easier to write :than memory consumption, it is better to fix the bug. :-- :soda It's a lot harder then you think. Again, taking my BEST experience... the shell machines had 128MB to 512MB of ram and usually on the order of a gig of swap. Being shell machines we had our share of IRC hackers. We could always tell when there were no root holes on the systems because the IRC hackers would get into an account (users often logged in from public libraries or other unsecure locations and got their passwords sniffed).. Where was I? Oh yah, the IRC hackers would get into an account, try all their root tricks and fail, then get frustrated and attempt to crash the machine from the user's account. They were *never* able to run our machines out of swap. They could make them page heavily, but they could never run them out of swap. Before they even got swap 20% full the load would come to the attention of a sysop who would stare bemusedly at the idiot IRC hacker, then send him a few snide remarks with write before disabling the account and killing the processes. On the otherhand, there are a number of known ways to crash a FreeBSD box that do not involve running it out of stack. The most interesting one that I know of is with a spoofed-packet attack that randomizes the source IP. FreeBSD builds up temporary route table entries for the return packet and panics with a kernel memory limit being hit on the route table. Or I should say it used to. I've fixed that little problem. There are other ways. For example, even if a user account is resource limited, root processes (such as sendmail, popper, identd, and so forth) are not. Attacks against these servers generally result in very high loads and sometimes make it difficult to login to fix the problem, but do not result in running out of swap. With today's modern high capacity disk drives, a properly configured multi-user system will have enough swap that running it out is difficult to say the least. Even my home server has 512MB of swap and could easily have several gigabytes if I thought it necessary. We always recommend that you allocate swap sufficient for your needs - usually 2xMEM. But the word "sufficient" can also mean to allocate extra swap if you believe that the runaways are common enough to cause a problem. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 17:33:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from awfulhak.org (dynamic-85.max1-du-ws.dialnetwork.pavilion.co.uk [212.74.8.85]) by hub.freebsd.org (Postfix) with ESMTP id 8032215157 for ; Tue, 13 Jul 1999 17:33:05 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from dev.lan.awfulhak.org (dev.lan.awfulhak.org [172.16.0.5]) by awfulhak.org (8.9.3/8.9.3) with ESMTP id AAA18582; Wed, 14 Jul 1999 00:51:04 +0100 (BST) (envelope-from brian@lan.awfulhak.org) Received: from dev.lan.awfulhak.org (localhost [127.0.0.1]) by dev.lan.awfulhak.org (8.9.3/8.9.3) with ESMTP id AAA78465; Wed, 14 Jul 1999 00:51:04 +0100 (BST) (envelope-from brian@dev.lan.awfulhak.org) Message-Id: <199907132351.AAA78465@dev.lan.awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Stephen Hocking-Senior Programmer PGS Tensor Perth Cc: hackers@FreeBSD.ORG Subject: Re: Setting up a firewall with dynamic IPs In-reply-to: Your message of "Tue, 13 Jul 1999 16:56:13 +0800." <199907130856.QAA12434@ariadne.tensor.pgs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Jul 1999 00:51:03 +0100 From: Brian Somers Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I was checking out the firewall setup in /etc/rc.firewall, and noticed that > the simple example relied on a fixed IP address for the external interface. I > don't know ahead of time what IP address is going to be allocated to me before > I dial up. Would it be possible to specify an interface (tun0) rather than an > IP address? If you use ppps internal filtering with HISADDR (not the actual IP number), ppp is now smart enough to modify the rules when it negotiates a new address with the peer :-) > Stephen > -- > The views expressed above are not those of PGS Tensor. > > "We've heard that a million monkeys at a million keyboards could produce > the Complete Works of Shakespeare; now, thanks to the Internet, we know > this is not true." Robert Wilensky, University of California -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 17:40:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2]) by hub.freebsd.org (Postfix) with ESMTP id 8AC5A15157; Tue, 13 Jul 1999 17:40:47 -0700 (PDT) (envelope-from soda@sra.co.jp) Received: from sranhf.sra.co.jp (sranhf [133.137.28.3]) by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id JAA00646; Wed, 14 Jul 1999 09:40:35 +0900 (JST) Received: from srapc342.sra.co.jp (srapc342 [133.137.28.111]) by sranhf.sra.co.jp (8.8.7/3.6Wbeta7-srambox) with ESMTP id JAA04977; Wed, 14 Jul 1999 09:40:33 +0900 (JST) Received: (from soda@localhost) by srapc342.sra.co.jp (8.8.8/3.4W-sra) id JAA15740; Wed, 14 Jul 1999 09:40:34 +0900 (JST) Date: Wed, 14 Jul 1999 09:40:34 +0900 (JST) Message-Id: <199907140040.JAA15740@srapc342.sra.co.jp> From: Noriyuki Soda To: Matthew Dillon Cc: Noriyuki Soda , Jason Thorpe , "Brian F. Feldman" , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <199907140025.RAA82339@apollo.backplane.com> References: <199907132127.OAA80947@apollo.backplane.com> <199907132139.GAA14890@srapc342.sra.co.jp> <199907132153.OAA81153@apollo.backplane.com> <199907132215.HAA15042@srapc342.sra.co.jp> <199907132229.PAA81360@apollo.backplane.com> <199907132245.HAA15198@srapc342.sra.co.jp> <199907132253.PAA81615@apollo.backplane.com> <199907140004.JAA15623@srapc342.sra.co.jp> <199907140025.RAA82339@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> On Tue, 13 Jul 1999 17:25:21 -0700 (PDT), Matthew Dillon said: > With today's modern high capacity disk drives, a properly configured > multi-user system will have enough swap that running it out is difficult > to say the least. That's wrong. Please remember that you said "assuming hostile users", a hostile user can run the machine out of swap generally easier than crashing the machine. Your example of IRC server is just one of exceptions. If you find a bug which crashes FreeBSD, isn't it better fix the bug? Why do you stick at not fixing the problem. -- soda To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 17:53:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id D02291536E; Tue, 13 Jul 1999 17:53:24 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA82530; Tue, 13 Jul 1999 17:53:10 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 17:53:10 -0700 (PDT) From: Matthew Dillon Message-Id: <199907140053.RAA82530@apollo.backplane.com> To: Noriyuki Soda Cc: Jason Thorpe , "Brian F. Feldman" , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132127.OAA80947@apollo.backplane.com> <199907132139.GAA14890@srapc342.sra.co.jp> <199907132153.OAA81153@apollo.backplane.com> <199907132215.HAA15042@srapc342.sra.co.jp> <199907132229.PAA81360@apollo.backplane.com> <199907132245.HAA15198@srapc342.sra.co.jp> <199907132253.PAA81615@apollo.backplane.com> <199907140004.JAA15623@srapc342.sra.co.jp> <199907140025.RAA82339@apollo.backplane.com> <199907140040.JAA15740@srapc342.sra.co.jp> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :>>>>> On Tue, 13 Jul 1999 17:25:21 -0700 (PDT), : Matthew Dillon said: : :> With today's modern high capacity disk drives, a properly configured :> multi-user system will have enough swap that running it out is difficult :> to say the least. : :That's wrong. :Please remember that you said "assuming hostile users", a hostile :user can run the machine out of swap generally easier than crashing :the machine. Your example of IRC server is just one of exceptions. : :If you find a bug which crashes FreeBSD, isn't it better fix the bug? :Why do you stick at not fixing the problem. :-- :soda You keep on saying that users can run the system out of swap easily, and I've tried to point out to you that it isn't quite as easy as you believe (and I've used a real-life example to show my point). You are certainly welcome to come back with your own real-life example. And now you are implying that all bugs can be easily fixed. Ha ha! That's funny. I wish that were true! -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 18: 2:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2]) by hub.freebsd.org (Postfix) with ESMTP id 86FB414CB5; Tue, 13 Jul 1999 18:02:32 -0700 (PDT) (envelope-from soda@sra.co.jp) Received: from sranhf.sra.co.jp (sranhf [133.137.28.3]) by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id KAA01627; Wed, 14 Jul 1999 10:00:52 +0900 (JST) Received: from srapc342.sra.co.jp (srapc342 [133.137.28.111]) by sranhf.sra.co.jp (8.8.7/3.6Wbeta7-srambox) with ESMTP id KAA04997; Wed, 14 Jul 1999 10:00:50 +0900 (JST) Received: (from soda@localhost) by srapc342.sra.co.jp (8.8.8/3.4W-sra) id KAA15810; Wed, 14 Jul 1999 10:00:51 +0900 (JST) Date: Wed, 14 Jul 1999 10:00:51 +0900 (JST) Message-Id: <199907140100.KAA15810@srapc342.sra.co.jp> From: Noriyuki Soda To: Matthew Dillon Cc: Noriyuki Soda , Jason Thorpe , "Brian F. Feldman" , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <199907140053.RAA82530@apollo.backplane.com> References: <199907132127.OAA80947@apollo.backplane.com> <199907132139.GAA14890@srapc342.sra.co.jp> <199907132153.OAA81153@apollo.backplane.com> <199907132215.HAA15042@srapc342.sra.co.jp> <199907132229.PAA81360@apollo.backplane.com> <199907132245.HAA15198@srapc342.sra.co.jp> <199907132253.PAA81615@apollo.backplane.com> <199907140004.JAA15623@srapc342.sra.co.jp> <199907140025.RAA82339@apollo.backplane.com> <199907140040.JAA15740@srapc342.sra.co.jp> <199907140053.RAA82530@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> On Tue, 13 Jul 1999 17:53:10 -0700 (PDT), Matthew Dillon said: > You keep on saying that users can run the system out of swap > easily, and I've tried to point out to you that it isn't quite > as easy as you believe (and I've used a real-life example to > show my point). You are certainly welcome to come back with > your own real-life example. If you cannot imagine such real-life example, then you are lucky guy. I wish your good luck in future. > And now you are implying that all bugs can be easily fixed. Ha > ha! That's funny. I wish that were true! I never said that bug fix is easy. What I've said is - memory consumption is easy - it is better to fix a bug, rather than stick at it. -- soda To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 18:17:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bilby.prth.tensor.pgs.com (bilby.prth.tensor.pgs.com [157.147.232.237]) by hub.freebsd.org (Postfix) with ESMTP id 76BDE14CB5 for ; Tue, 13 Jul 1999 18:17:10 -0700 (PDT) (envelope-from shocking@ariadne.prth.tensor.pgs.com) Received: from bandicoot.prth.tensor.pgs.com (bandicoot.prth.tensor.pgs.com [157.147.224.1]) by bilby.prth.tensor.pgs.com (8.9.3/8.8.8) with ESMTP id JAA21900 for ; Wed, 14 Jul 1999 09:15:44 +0800 (WST) Received: from ariadne.tensor.pgs.com (ariadne [157.147.227.36]) by bandicoot.prth.tensor.pgs.com (8.9.3/8.8.8) with SMTP id JAA03049; Wed, 14 Jul 1999 09:16:56 +0800 (WST) Received: from ariadne by ariadne.tensor.pgs.com (SMI-8.6/SMI-SVR4) id JAA15266; Wed, 14 Jul 1999 09:16:56 +0800 Message-Id: <199907140116.JAA15266@ariadne.tensor.pgs.com> X-Mailer: exmh version 2.0.2 2/24/98 To: hackers@freebsd.org Cc: shocking@bandicoot.prth.tensor.pgs.com Subject: Re: Setting up a firewall with dynamic IPs In-reply-to: Your message of "Tue, 13 Jul 1999 10:55:11 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Jul 1999 09:16:56 +0800 From: Stephen Hocking-Senior Programmer PGS Tensor Perth Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thanks for every one's help - I now have it working nicely. It's amazing what you discover when RTFMing. Oddly enough, running nmap with the Christmas tree scan (after I've allowed only smtp & ssh to be connected to) gives the following - # ./nmap -v -v -sX foo Starting nmap V. 2.12 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/) Host foo.bar.com (123.45.67.89) appears to be up ... good. Initiating FIN,NULL, UDP, or Xmas stealth scan against foo.bar.com (123.45.67.89) The UDP or stealth FIN/NULL/XMAS scan took 64 seconds to scan 1483 ports. Interesting ports on foo.bar.com (123.45.67.89): Port State Protocol Service 13 open tcp daytime 21 open tcp ftp 22 open tcp ssh 23 open tcp telnet 25 open tcp smtp 37 open tcp time 53 open tcp domain 80 open tcp http 111 open tcp sunrpc 119 open tcp nntp 513 open tcp login 514 open tcp shell 1017 open tcp unknown 1018 open tcp unknown 1019 open tcp unknown 1020 open tcp unknown 1021 open tcp unknown 1022 open tcp unknown 1023 open tcp unknown 2049 open tcp nfs Nmap run completed -- 1 IP address (1 host up) scanned in 64 seconds Any attempt to connect to the ports listed above (apart from ssh & smtp) just hangs. I take it that this is expected behaiviour of the firewall accepting the connection and then ahnging onto it in order to slow attackers down? Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true." Robert Wilensky, University of California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 18:24:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 3425D15373; Tue, 13 Jul 1999 18:24:36 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.9.3/8.9.3) id SAA68410; Tue, 13 Jul 1999 18:22:03 -0700 (PDT) (envelope-from obrien) Message-ID: <19990713182203.A68393@nuxi.com> Date: Tue, 13 Jul 1999 18:22:03 -0700 From: "David O'Brien" To: Scott Mitchell , freebsd-xircom@lovett.com Cc: hackers@FreeBSD.ORG, mobile@FreeBSD.ORG Subject: Re: Reading CIS from kernel? Reply-To: obrien@NUXI.com References: <19990710162730.60563@goatsucker.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <19990710162730.60563@goatsucker.org>; from Scott Mitchell on Sat, Jul 10, 1999 at 04:27:30PM +0100 X-Operating-System: FreeBSD 3.2-STABLE Organization: The NUXI BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The Xircom ethernet driver needs to read/write PCCARD attribute memory from > its probe routine, in order to identify the type of card and to beat ... > then making crdread() and crdwrite() (in /sys/pccard/pccard.c) > non-static and calling them directly from the driver code would be an > easy workaround. Since no one has repsonded to this querry, I will be un-staticizing these so they will be available to drivers. -- -- David (obrien@NUXI.com -or- obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 18:33:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 94B41150B8; Tue, 13 Jul 1999 18:33:31 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA82768; Tue, 13 Jul 1999 18:32:36 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 18:32:36 -0700 (PDT) From: Matthew Dillon Message-Id: <199907140132.SAA82768@apollo.backplane.com> To: "Charles M. Hannum" Cc: Noriyuki Soda , Jason Thorpe , "Brian F. Feldman" , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907140122.VAA14015@bikini.ihack.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :> Has your simulation ever been kicked by the kernel due to lack of :> swap space? : :I already said so. Please at least pretend to read what I wrote :before replying. : :There is a big difference here between a piddling web server and a :1000-hour simulation. If the web server goes down, you reboot it, :maybe a few users are inconvenienced meanwhile, and maybe you lose :some advertising revenue. If the simulation has to be restarted, :you've lost *valuable* computing time that is not easy to replace. : :There are many environments where even the possibility of the :simulation crashing due to external influence is unacceptable. I find :it sad that you resist making FreeBSD robust against such problems, :but that's your concern. Sigh. If the simulation is so important to you and your system does not have sufficient swap, maybe you should consider fixing your system rather then blaming the people who wrote it. Or perhaps you should consider checkpointing the code if you aren't willing to look for easy solutions to the problem. Unless all the users on the system are working against you, no one user with a runaway should be able to run a properly configured system out of swap by accident. If your users are doing it on purpose then maybe you should find a different machine to work on, eh? In a cooperative environment it is extremely easy to prevent accidental runaways from eating a system's swap up, and still fairly easy to reduce the damage done by purposeful attacks. In fact, at BEST we set soft limits for most of the system resources to reasonable enough values that users don't need to change them and that has protected 25 machines and 30,000 users for several years. If you want help in fixing your system, we can talk over private email. If you are looking for a magical overcommit solution you are going to be looking for a long time. It isn't going to happen, because I doubt it would even come close to fixing your problems even if it were available. If you are looking to blame overcommits for your problems, then lay out how your system is setup. But I'll bet you the problem is something less severe -- like a simple misconfiguration, or perhaps insufficient swap. How much swap is on this system, by the way? -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 18:41:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from hermes.la.csiro.au (hermes.la.csiro.au [152.83.12.2]) by hub.freebsd.org (Postfix) with ESMTP id B2FF315158 for ; Tue, 13 Jul 1999 18:41:54 -0700 (PDT) (envelope-from Anthony.Wyatt@its.csiro.au) Received: by hermes.la.csiro.au with Internet Mail Service (5.5.2448.0) id ; Wed, 14 Jul 1999 11:41:08 +1000 Message-ID: From: "Wyatt, Anthony" To: 'Stephen Hocking-Senior Programmer PGS Tensor Perth' Cc: "'hackers@freebsd.org'" Subject: RE: Setting up a firewall with dynamic IPs Date: Wed, 14 Jul 1999 11:41:07 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Stephen Hocking wrote: > you discover when RTFMing. Oddly enough, running nmap with > the Christmas tree > scan (after I've allowed only smtp & ssh to be connected to) > gives the > following - > > Initiating FIN,NULL, UDP, or Xmas stealth scan against foo.bar.com > Nmap run completed -- 1 IP address (1 host up) scanned in 64 seconds > > Any attempt to connect to the ports listed above (apart from > ssh & smtp) just > hangs. I take it that this is expected behaiviour of the > firewall accepting > the connection and then ahnging onto it in order to slow > attackers down? The scan you have run above sets all the flags in the TCP header (ACK, SYN, RST, QLC, and PSH), if you have a rule that says something like if ACK set let it in, then this scan will work. I get around this by setting the rule that allows ACK traffic back in with port limits 1024-65535, you would have to limit it to 1024-2048 and 2050-65535 so your nfs traffic could pass. You could also consider setting IP address ranges to the nfs port ACK rule. Beware of ssh configuration options that may want to connect to ports below 1024, you can change this behaviour (see the man page). This should stop scans of services you run but don't want to advertise. You will still see ssh and snmp. Anthony To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 19: 5: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xerxes.lovett.com (xerxes.lovett.com [216.60.121.164]) by hub.freebsd.org (Postfix) with ESMTP id 9474615378; Tue, 13 Jul 1999 19:05:03 -0700 (PDT) (envelope-from ade@lovett.com) Received: from ade by xerxes.lovett.com with local (Exim 3.02 #1) id 114EOX-000Oa3-00; Tue, 13 Jul 1999 21:03:37 -0500 Date: Tue, 13 Jul 1999 21:03:37 -0500 From: Ade Lovett To: freebsd-xircom@lovett.com Cc: hackers@FreeBSD.ORG, mobile@FreeBSD.ORG Subject: Re: Reading CIS from kernel? Message-ID: <19990713210337.H85742@remarq.com> References: <19990710162730.60563@goatsucker.org> <19990713182203.A68393@nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <19990713182203.A68393@nuxi.com>; from David O'Brien on Tue, Jul 13, 1999 at 06:22:03PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 13, 1999 at 06:22:03PM -0700, David O'Brien wrote: > [about cdread()/cdwrite() in /sys/pccard/pcccard.c] > > Since no one has repsonded to this querry, I will be un-staticizing these > so they will be available to drivers. This is going to be for both -current and MFC'd back into -stable, yes? -aDe -- Ade Lovett, Austin, TX. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 19: 9:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 54D9E14F97 for ; Tue, 13 Jul 1999 19:09:41 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA85713; Tue, 13 Jul 1999 19:06:40 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 19:06:40 -0700 (PDT) From: Matthew Dillon Message-Id: <199907140206.TAA85713@apollo.backplane.com> To: Stephen Hocking-Senior Programmer PGS Tensor Perth Cc: hackers@FreeBSD.ORG, shocking@bandicoot.prth.tensor.pgs.com Subject: Re: Setting up a firewall with dynamic IPs References: <199907140116.JAA15266@ariadne.tensor.pgs.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Thanks for every one's help - I now have it working nicely. It's amazing what :you discover when RTFMing. Oddly enough, running nmap with the Christmas tree :scan (after I've allowed only smtp & ssh to be connected to) gives the :following - : :# ./nmap -v -v -sX foo : :Starting nmap V. 2.12 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/) :Host foo.bar.com (123.45.67.89) appears to be up ... good. :Initiating FIN,NULL, UDP, or Xmas stealth scan against foo.bar.com :(123.45.67.89) :The UDP or stealth FIN/NULL/XMAS scan took 64 seconds to scan 1483 ports. :Interesting ports on foo.bar.com (123.45.67.89): :Port State Protocol Service :13 open tcp daytime :21 open tcp ftp :22 open tcp ssh :23 open tcp telnet :25 open tcp smtp :37 open tcp time :53 open tcp domain :80 open tcp http :111 open tcp sunrpc :119 open tcp nntp :513 open tcp login :514 open tcp shell :1017 open tcp unknown :1018 open tcp unknown :1019 open tcp unknown :1020 open tcp unknown :1021 open tcp unknown :1022 open tcp unknown :1023 open tcp unknown :2049 open tcp nfs : :Nmap run completed -- 1 IP address (1 host up) scanned in 64 seconds : :Any attempt to connect to the ports listed above (apart from ssh & smtp) just :hangs. I take it that this is expected behaiviour of the firewall accepting :the connection and then ahnging onto it in order to slow attackers down? : : Stephen Usually if a connection succeeds the firewall isn't stopping it at all. How is nmap figuring out the service type? I assume by making a connection and probing it. Here is what I get when I run nmap from inside my firewall # ./nmap -v -v -sX apollo.backplane.com Port State Protocol Service 13 open tcp daytime 22 open tcp ssh 25 open tcp smtp 37 open tcp time 53 open tcp domain 79 open tcp finger 80 open tcp http 110 open tcp pop3 111 open tcp sunrpc 113 open tcp auth 480 open tcp loadsrv 515 open tcp printer 1022 open tcp unknown 1023 open tcp unknown 2049 open tcp shilp <--- huh? that's nfs And from outside my firewall Port State Protocol Service 22 open tcp ssh 25 open tcp smtp 53 open tcp domain 79 open tcp finger 80 open tcp http 110 open tcp pop3 113 open tcp auth -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 19:28: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 080C614F03; Tue, 13 Jul 1999 19:27:58 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id TAA14312; Tue, 13 Jul 1999 19:25:10 -0700 (PDT) Message-Id: <199907140225.TAA14312@implode.root.com> To: "Charles M. Hannum" Cc: Matthew Dillon , Noriyuki Soda , Jason Thorpe , "Brian F. Feldman" , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) In-reply-to: Your message of "Tue, 13 Jul 1999 21:55:01 EDT." <199907140155.VAA14113@bikini.ihack.net> From: David Greenman Reply-To: dg@root.com Date: Tue, 13 Jul 1999 19:25:10 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >The point is, the OS should have provided *some* mechanism to insure >that the long-running process wasn't affected. It didn't. That's a >clear failure of the OS to provide a reasonable environment for this >type of computing. > >Whether this should be solved by switching to a no-overcommit policy, >fiddling with the overcommit policy in some way, or whatever, is a >different issue. But you have not yet proposed any mechanism that >would have prevented this problem while still permitting me to get >work done. I've long felt that the best solution to problems like this is a per-user swap space quota. This gives admins a knob to manage the allocation of swap space while still allowing overcommit. The downside is that it doesn't provide a graceful way for a program to recover from it's overconsumption sins. I'd argue, however, that buggy software or incorrectly tuned systems should get what they deserve. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 19:29: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 1C020151F5; Tue, 13 Jul 1999 19:28:59 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA85839; Tue, 13 Jul 1999 19:28:49 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 19:28:49 -0700 (PDT) From: Matthew Dillon Message-Id: <199907140228.TAA85839@apollo.backplane.com> To: "Charles M. Hannum" Cc: Noriyuki Soda , Jason Thorpe , "Brian F. Feldman" , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907140155.VAA14113@bikini.ihack.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> swap. How much swap is on this system, by the way? : :I could just as rightfully argue that you're blaming a failure of the :OS on the sysadmin. Fiddling with limits is all fine and dandy, but :it's not even close to flexible enough. Consider, for example, the :specific case of testing a new multi-threaded program. A simple :mistake caused it to chew up a rather considerable amount of memory -- :the per-process limit for each of 32 processes. You could claim :several things here: : :* I should have tested it on another system. That's great, but at $Nm : per system, that's often infeasible. : : Not only that, but it's insulting. Why should I have to buy two : computers, just because the OS can't be bothered to properly protect : my important programs? Yes, it is certainly possible that this could happen. Not likely, but possible. But a non-overcommit is not necessarily going to solve this problem. Your processes could very well obtain all the resources and some other poor user running his 1000 hour simulation will try to allocate something, fail, and go poof. All sorts of problems crop up. For example, if programs cannot handle a malloc failure one might think that all they need to do is to block in the allocation, waiting for memory to become available. The result of that could be a system-wide deadlock! If a program has the capability to checkmark itself that is all well and fine, but then it is something the program could be doing anyway at regular intervals (like once every 2 hours). The amount of lost work would be minimal in both cases. Limits do work. Quite well, in fact. What you do is simply set limits that prevent the more common accidents. For example, it is far more likely that only a few processes will runaway and try to eat their entire address space. So it might be reasonable to set a softlimit of 32 processes and a 64MB address space per process. If a user needs more he ups his limits manually and thus taking on more responsibility. If you have several users doing memory-heavy work, you need a lot of swap no matter what resource model you use. It might be appropriate to run 4 or 8 GB of swap in that case, though personally I doubt you'd ever need that much. It depends on how much main memory you have, of course. A machine with 4G of ram might want 8G or even 16G of swap. A machine with 128MB of ram would be hard pressed to even begin to utilize 1GB of swap even with a dozen runaway programs running. If you are truely paranoid it costs about $150 for a 6G IDE hard drive. That's a lot of swap space! :* I should have allocated enough swap space to cover this situation. : That's great, but if I did, using a no-overcommit policy would have : worked just as well! Not necessarily. The system could have had room for your processes but not room for someone else's, causing the other person's script to fail for no good reason. no-overcommit policies tend to need a much greater amount of swap to yield the same performance and reliability. If you had that much extra swap available to begin with, it would probably have been better to stick with the standard overcommit policy and simply add swap. The arbitrary nature of an overcommit policy is no better then the almost-arbitrary nature of the existing policy, except that what we currently have specifically targets the largest processes rather then 'any' process. :The point is, the OS should have provided *some* mechanism to insure :that the long-running process wasn't affected. It didn't. That's a :clear failure of the OS to provide a reasonable environment for this :type of computing. : :Whether this should be solved by switching to a no-overcommit policy, :fiddling with the overcommit policy in some way, or whatever, is a :different issue. But you have not yet proposed any mechanism that :would have prevented this problem while still permitting me to get :work done. The OS needs to provide no such thing. The OS kills processes as an absolute last resort. It does it when it believes it has no other choice. If you don't want to get to that point there are plenty of ways to avoid it... but the policy is something that you have to implement, the OS can't do it for you. The most common way of doing this is through watcher scripts. The watcher script looks at the memory situation and finds things to kill if it gets critical. It is not that difficult to write a watcher script, but most people don't bother because most people don't have swap problems to begin with. It would be fairly easy for a watcher script to catch a system heading towards swap exhaustion because it generally takes a while to get into the swap exhaustion state. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 20: 7:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 403211538B; Tue, 13 Jul 1999 20:07:07 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA86009; Tue, 13 Jul 1999 20:06:11 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 20:06:11 -0700 (PDT) From: Matthew Dillon Message-Id: <199907140306.UAA86009@apollo.backplane.com> To: David Greenman Cc: "Charles M. Hannum" , Noriyuki Soda , Jason Thorpe , "Brian F. Feldman" , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907140225.TAA14312@implode.root.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : I've long felt that the best solution to problems like this is a per-user :swap space quota. This gives admins a knob to manage the allocation of swap :space while still allowing overcommit. The downside is that it doesn't provide :a graceful way for a program to recover from it's overconsumption sins. I'd :argue, however, that buggy software or incorrectly tuned systems should get :what they deserve. : :-DG : :David Greenman Ooh, cool idea. If I had that at BEST I would use it snap! like that! A per-user swap quota would work a whole lot better then the current numprocs x datasize limit -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 20:20:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp4.erols.com (smtp4.erols.com [207.172.3.237]) by hub.freebsd.org (Postfix) with ESMTP id F105115249 for ; Tue, 13 Jul 1999 20:20:45 -0700 (PDT) (envelope-from jobaldwi@vt.edu) Received: from john.baldwin.cx (207-172-143-123.s60.as1.hgt.md.dialup.rcn.com [207.172.143.123]) by smtp4.erols.com (8.8.8/smtp-v1) with ESMTP id XAA04030; Tue, 13 Jul 1999 23:18:51 -0400 (EDT) Message-Id: <199907140318.XAA04030@smtp4.erols.com> X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199907140004.RAA25629@lestat.nas.nasa.gov> Date: Tue, 13 Jul 1999 23:18:58 -0400 (EDT) From: John Baldwin To: Jason Thorpe Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Cc: tech-userlevel@netbsd.org, freebsd-hackers@FreeBSD.ORG, Matthew Dillon Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 14-Jul-99 Jason Thorpe wrote: > On Tue, 13 Jul 1999 16:56:26 -0700 (PDT) > Matthew Dillon wrote: > > > You have to consider the probability of an event occuring, not just > > the possibility that the event might occur. If the probability is > > one in a million years, then it is not something you need to worry > > about relative to other things that, perhaps, you *should* be worrying > > about. > > Having been a systems programmer and systems administrator at a > university computer science department, dealing with large (well, > they were large back then :-) systems where 60 students log in > simultaneously to do their "Data Structures in C++" homework, I > can guarantee you that the probability that someone else's buggy > program will kill your unrelated application is a lot more than > "once in a million years". > > -- Jason R. Thorpe What does that have to do with overcommit? I student administrate a undergrad CS lab at a university, and when student's programs misbehaved, they generate a fault and are killed. The only machines that reboot on us without be explicitly told to are the NT ones, and yes we run FreeBSD. --- John Baldwin -- http://members.freedomnet.com/~jbaldwin/ PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 20:47:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id D51FA14CA1 for ; Tue, 13 Jul 1999 20:47:34 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id XAA97200; Tue, 13 Jul 1999 23:47:33 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 13 Jul 1999 23:47:33 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Sheldon Hearn Cc: hackers@FreeBSD.org Subject: Re: a BSD identd In-Reply-To: <49928.931911388@axl.noc.iafrica.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG We don't _need_ pidentd anymore. It will load down a system more than the inetd's implementation of ident will. Therefore, pidentd should be phased out. Other than that, pidentd should be using http://www.FreeBSD.org/~green/freebsd4.c and not linking with libkvm. Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 21: 4:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pzero.sandelman.ottawa.on.ca (pzero.sandelman.ottawa.on.ca [209.151.24.8]) by hub.freebsd.org (Postfix) with ESMTP id EBE8314DC5 for ; Tue, 13 Jul 1999 21:04:12 -0700 (PDT) (envelope-from mcr@sandelman.ottawa.on.ca) Received: from morden.sandelman.ottawa.on.ca (localhost [127.0.0.1]) by pzero.sandelman.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA00563; Tue, 13 Jul 1999 23:46:46 -0400 (EDT) Message-Id: <199907140346.XAA00563@pzero.sandelman.ottawa.on.ca> To: freebsd-hackers@freebsd.org, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-reply-to: Your message of "13 Jul 1999 14:58:54 PDT." <87673oyzxd.fsf@redmail.redback.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Tue, 13 Jul 1999 23:46:45 -0400 From: Michael Richardson Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG is there some reason why whether or not to overcommit can't be a kernel compile time option? Or that a process can signal its desire to not get SIGKILL by registering a non-default SIGDANGER (which we'd have to create) handler ala AIX? ] Train travel features AC outlets with no take-off restrictions| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 21:46:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id A65E014D5F for ; Tue, 13 Jul 1999 21:46:11 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id AAA98272; Wed, 14 Jul 1999 00:46:02 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Wed, 14 Jul 1999 00:46:01 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Matthew Dillon Cc: Noriyuki Soda , Jason Thorpe , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.org, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <199907140025.RAA82339@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, Matthew Dillon wrote: > There are other ways. For example, even if a user account is resource > limited, root processes (such as sendmail, popper, identd, and so forth) > are not. Attacks against these servers generally result in very high > loads and sometimes make it difficult to login to fix the problem, but do > not result in running out of swap. Inetd is rate-limited by default nowadays, so this really doesn't apply. > > -Matt > Matthew Dillon > > > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 22:46:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from border.dreamworks.com (dreamworks.com [209.179.64.2]) by hub.freebsd.org (Postfix) with SMTP id 36D8A14F5C for ; Tue, 13 Jul 1999 22:46:37 -0700 (PDT) (envelope-from abs@anim.dreamworks.com) Received: from cynic.anim.dreamworks.com by border.dreamworks.com via smtpd (for hub.FreeBSD.ORG [204.216.27.18]) with SMTP; 14 Jul 1999 05:46:41 UT Received: from localhost (abs@localhost) by cynic.anim.dreamworks.com (8.8.8+Sun/8.8.8) with ESMTP id WAA23132; Tue, 13 Jul 1999 22:43:18 -0700 (PDT) X-Authentication-Warning: cynic.anim.dreamworks.com: abs owned process doing -bs Date: Tue, 13 Jul 1999 22:43:17 -0700 (PDT) From: David Brownlee To: Matthew Dillon Cc: Jason Thorpe , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <199907132156.OAA81180@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, Matthew Dillon wrote: > Jason, I am using real life situations to demonstrate my point. You are > perfectly welcome to use your own REAL-LIFE situations to demonstrate > yours. It is the real-life application that matters, not a worst-case > nightmare theory. No engineer designs systems based on nightmare > theories. Sorry - had to reply to this. I have an Aero-engineer friend who took some exception to that last sentence. They're like that :) Back on topic: Obviously you devote the most time to handling the most common and serious failure modes, but if someone else if willing to put in the work to handle nightmare cases, should you ignore or discard that work? Put more accurately - if someone wants to provide a different rope to permit people to write in a different defensive style, and it does not in any way impact your use of the system: More power to them. David/absolute -=- Sue me, screw me, walk right through me -=- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 23:55:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 5499E15396; Tue, 13 Jul 1999 23:55:15 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id AAA23163; Wed, 14 Jul 1999 00:53:44 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id AAA53151; Wed, 14 Jul 1999 00:52:38 -0600 (MDT) Message-Id: <199907140652.AAA53151@harmony.village.org> To: obrien@NUXI.com Subject: Re: Reading CIS from kernel? Cc: Scott Mitchell , freebsd-xircom@lovett.com, hackers@FreeBSD.ORG, mobile@FreeBSD.ORG In-reply-to: Your message of "Tue, 13 Jul 1999 18:22:03 PDT." <19990713182203.A68393@nuxi.com> References: <19990713182203.A68393@nuxi.com> <19990710162730.60563@goatsucker.org> Date: Wed, 14 Jul 1999 00:52:38 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19990713182203.A68393@nuxi.com> "David O'Brien" writes: : Since no one has repsonded to this querry, I will be un-staticizing these : so they will be available to drivers. No. Please don't. This is the first I've seen this. There will be another cis reading interface as part of the newbusification of pccard stuff and I'd rather not have to fix any more drivers than I have to. I wish I had seen it sooner. The Xircom driver is one of the ones that my first attempt at newbusification would have broken... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 23:55:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 0B11B1539B; Tue, 13 Jul 1999 23:55:28 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id AAA23167; Wed, 14 Jul 1999 00:54:29 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id AAA53164; Wed, 14 Jul 1999 00:53:24 -0600 (MDT) Message-Id: <199907140653.AAA53164@harmony.village.org> To: Ade Lovett Subject: Re: Reading CIS from kernel? Cc: freebsd-xircom@lovett.com, hackers@FreeBSD.ORG, mobile@FreeBSD.ORG In-reply-to: Your message of "Tue, 13 Jul 1999 21:03:37 CDT." <19990713210337.H85742@remarq.com> References: <19990713210337.H85742@remarq.com> <19990710162730.60563@goatsucker.org> <19990713182203.A68393@nuxi.com> Date: Wed, 14 Jul 1999 00:53:24 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19990713210337.H85742@remarq.com> Ade Lovett writes: : This is going to be for both -current and MFC'd back into -stable, yes? The interface for doing this I'll be merging back into -stable. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jul 13 23:56: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rina.naklab.dnj.ynu.ac.jp (rina.naklab.dnj.ynu.ac.jp [133.34.17.16]) by hub.freebsd.org (Postfix) with ESMTP id 25D8014DD4; Tue, 13 Jul 1999 23:55:56 -0700 (PDT) (envelope-from tanimura@naklab.dnj.ynu.ac.jp) Received: from rina.naklab.dnj.ynu.ac.jp (localhost [127.0.0.1]) by rina.naklab.dnj.ynu.ac.jp (8.9.1a/3.7W-Naklab-2.1-19981120) with ESMTP id PAA04958; Wed, 14 Jul 1999 15:54:22 +0900 (JST) Message-Id: <199907140654.PAA04958@rina.naklab.dnj.ynu.ac.jp> To: dfr@nlsystems.com Cc: julian@whistle.com, bde@zeta.org.au, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Cc: Seigo Tanimura Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer) From: Seigo Tanimura In-Reply-To: Your message of "Thu, 8 Jul 1999 09:54:42 +0100 (BST)" References: X-Mailer: Mew version 1.70 on Emacs 19.34.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 14 Jul 1999 15:54:22 +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 8 Jul 1999 09:54:42 +0100 (BST), Doug Rabson said: dfr> If I understand this correctly, you are suggesting that we program timer0 dfr> so that we only take interrupts when a finetimer is due to fire? If so, dfr> then it sounds very good. The idea of taking 6000+ interrupts/sec made me dfr> uneasy, even though most would return without doing any work. I have been reading the i8254 data sheet for another couple of days, to find a new problem. If we have a callout to be made before the timer fires, the counter needs to be reprogrammed with a new value. We cannot reload the new counter value immediately; an i8254 does not load the new value until the currrent period finishes (ie the timer fires) or the gate rises. Thus a callout will have an average delay of 0.5/hz = 50ms. This is too long for a timeout in microseconds. Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 0: 4:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rina.naklab.dnj.ynu.ac.jp (rina.naklab.dnj.ynu.ac.jp [133.34.17.16]) by hub.freebsd.org (Postfix) with ESMTP id 8E4901505C; Wed, 14 Jul 1999 00:04:01 -0700 (PDT) (envelope-from tanimura@naklab.dnj.ynu.ac.jp) Received: from rina.naklab.dnj.ynu.ac.jp (localhost [127.0.0.1]) by rina.naklab.dnj.ynu.ac.jp (8.9.1a/3.7W-Naklab-2.1-19981120) with ESMTP id QAA05202; Wed, 14 Jul 1999 16:03:30 +0900 (JST) Message-Id: <199907140703.QAA05202@rina.naklab.dnj.ynu.ac.jp> To: dfr@nlsystems.com Cc: julian@whistle.com, bde@zeta.org.au, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org Cc: Seigo Tanimura Subject: Re: Rewriting pca(4) using finetimer(9) (was: Re: MPU401 now worksunder New Midi Driver Framework with a Fine Timer) From: Seigo Tanimura In-Reply-To: Your message of "Wed, 14 Jul 1999 15:54:22 +0900" References: <199907140654.PAA04958@rina.naklab.dnj.ynu.ac.jp> X-Mailer: Mew version 1.70 on Emacs 19.34.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 14 Jul 1999 16:03:30 +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 14 Jul 1999 15:54:22 +0900, Seigo Tanimura said: tanimura> Thus a callout will have an average delay of 0.5/hz = 50ms. This is 5ms, I mean... Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 0:30:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 4BF8C1538C for ; Wed, 14 Jul 1999 00:30:11 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id IAA36673; Wed, 14 Jul 1999 08:31:07 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Wed, 14 Jul 1999 08:31:07 +0100 (BST) From: Doug Rabson To: Jon Ribbens Cc: Alfred Perlstein , "Daniel C. Sobral" , freebsd-hackers@freebsd.org, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <19990713100228.C10979@oaktree.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, Jon Ribbens wrote: > Alfred Perlstein wrote: > > You're browsing with netscape and It hits about 32megs in size, > > you click on a multimedia object and netscape execs a helper app. > > vfork() > > > you also have to consider a program wishing to make sparse use > > of its address space, without overcommit it becomes impossible. > > So Don't Do That Then. Overcommit can be used for many reasons. I use it to reserve a large linear address space to mmap alpha i/o spaces to which allows an efficient implementation of inx/outx in user mode: UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 0 43655 43652 7 2 0 12616584 12456 select S ?? 1036:41.62 /usr/X11R6/bin/X -auth /usr/X11R6/lib/X11/xdm/authdir/A:0-w43652 The X server is using 12G of address space.. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 0:35: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 391AE14CE3 for ; Wed, 14 Jul 1999 00:35:06 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id AAA86923; Wed, 14 Jul 1999 00:34:53 -0700 (PDT) (envelope-from dillon) Date: Wed, 14 Jul 1999 00:34:53 -0700 (PDT) From: Matthew Dillon Message-Id: <199907140734.AAA86923@apollo.backplane.com> To: David Brownlee Cc: Jason Thorpe , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : Back on topic: : : Obviously you devote the most time to handling the most common : and serious failure modes, but if someone else if willing to : put in the work to handle nightmare cases, should you ignore or : discard that work? Of course not. But nobody in this thread is even close to doing any actual work and so far the two people I know who can (me and DG) aren't particularly interested. Instead they seem to want someone else to do the work based on what I consider to be entirely unsubtantiated supposition. Would you accept someone's unsupported and untested theories based almost entirely on a nightmare scenario to the exclusion of all other possible (and more likely) problems? I mean come on... read some of this stuff. There are plenty of ways to solve these problems without making the declaration that the overcommit model is flawed beyond repair, and so far nobody has bothered to offer any counter-arguments to the resource management issues involved with actually *implementing* a non-overcommit model... every time I throw up hard numbers the only response I get is a shrug-off with no basis in fact or experience noted anywhere. In the real world, you can't shrug of those sorts of problems. I'm the only one trying to run hard numbers on the problem. Certainly nobody else is. This is hardly something that would actually convince me of the efficy of the model as applied to a UNIX kernel core. Instead, people are pulling out their favorite screwups and then blaming the overcommit model for all their troubles rather then looking for the more obvious answer: A misconfiguration or simply a lack of resources. Some don't even appear to *have* any trouble with the overcommit model, but argue against it anyway basing their entire argument on the possibility that something might happen, again without bothering to calculate the probability or run any hard numbers. The argument is shifting from embedded work to multi-user operations to *hostile* multi-user systems with some people advocating that a non-overcommit model will magically solve all their woes in these very different scenarios, but can't be bothered with actually finding a real-life scenario or using an experience to demonstrate their position. It is all pretty much garbage. No wonder the NetBSD core broke up, if this is what they had to deal with 24 hours a day! : Put more accurately - if someone wants to provide a different rope : to permit people to write in a different defensive style, and it : does not in any way impact your use of the system: More power to them. : : David/absolute As I've said on several occassions now, there is nothing in the current *BSD design that prevents an embedded designer from implementing his or her own memory management subsystem to support the memory requirements of their programs. The current UNIX out-of-memory kill scenario only occurs as a last resort and it is very easy for an embedded system to avoid. It should be considered nothing more then a watchdog for catastrophic failure. To implement the simplest non-overcommit system in the *BSD kernel - returning NULL on an allocation failure due to non-availability of backing store - is virtually useless because it is just as arbitrary as killing processes. It might help a handful of people out of hundreds of thousands do something but they would do a lot better with a watchdog script. It makes no sense to try to build it into the kernel. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 0:55:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from oskar.nanoteq.co.za (oskar.nanoteq.co.za [196.37.91.10]) by hub.freebsd.org (Postfix) with ESMTP id BD4CC14A12 for ; Wed, 14 Jul 1999 00:55:13 -0700 (PDT) (envelope-from rbezuide@oskar.nanoteq.co.za) Received: (from rbezuide@localhost) by oskar.nanoteq.co.za (8.9.0/8.9.0) id JAA02076; Wed, 14 Jul 1999 09:55:43 +0200 (SAT) From: Reinier Bezuidenhout Message-Id: <199907140755.JAA02076@oskar.nanoteq.co.za> Subject: Re: Which device should I make with this error? In-Reply-To: <378B549C.4C511A98@post.com> from eT at "Jul 13, 99 05:00:44 pm" To: eT@post.com Date: Wed, 14 Jul 1999 09:55:43 +0200 (SAT) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi :) put the following line in your kernel config file .. recompile your kernel .. boot .. and then try the make again ... pseudo-device vn 1 to create the floppy ... a vertual node is used .. hope this helps ... Reinier > During a make release for 3.2-RELEASE I get the following error: > > Making the regular boot floppy. > Compressing doc files... > sh -e /usr/src/release/scripts/doFS.sh -s mfsroot /R/stage /mnt 2880 > /R/stage/m > fsfd 8000 minimum2 > vnconfig: open: Device not configured > *** Error code 1 > > Stop. > *** Error code 1 > > What does this mean and how do I fix it? > > Thanks > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 1:13:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (Postfix) with ESMTP id 30C1314D4B for ; Wed, 14 Jul 1999 01:13:31 -0700 (PDT) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg (bragg [129.127.36.34]) by adelphi.physics.adelaide.edu.au (8.8.8/8.8.8/UofA-1.5) with SMTP id RAA15400; Wed, 14 Jul 1999 17:43:30 +0930 (CST) Received: from localhost by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA14675; Wed, 14 Jul 1999 17:43:21 +0930 Date: Wed, 14 Jul 1999 17:43:21 +0930 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: Ted Faber Cc: Matthew Dillon , hackers@freebsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <199907140017.RAA05545@boreas.isi.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, Ted Faber wrote: > Matthew Dillon wrote: > >I said: > >:So, Matt, I understand that you think that the folks who are want to > >:turn off overcommit are looking to hang themselves, but how much does > >:it cost to sell them the rope? > > > > I'm guessing that a simple implementation would be about an hour's > > worth of work on the kernel: [...] > > > > But you would never be able to run normal system programs reliably > > without also going through the entire utility source base and doing a > > whole lot of rewriting. Standard programs such as > > are not going to be happy when the limit is > > hit and this will slowly cause system daemons to disappear from the > > system and for programs to start dying in odd ways when you do anything > > that brings the system close to an 'overcommitted' state. > > If it's a small hunk of work, maybe one of the folks who wants the > overcommit turned off can do the work and get it committed or > post patches. It would allow the arguments to be decided by > experiment. It seems we're well past the point of convincing anyone > verbally. You know, it occurred to me that with all the time wasted typing up messages in this thread someone (e.g. Matt) could have instead coded up a simple non-overcommit model, given it to the nay-sayers and said "Run this and see what I mean about making your system unusable" :-) At least that way people might finally shut up about it all.. Kris ----- "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 1:22:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from 001101.zer0.org (001101.zer0.org [206.24.105.163]) by hub.freebsd.org (Postfix) with ESMTP id 8AB6D14D27 for ; Wed, 14 Jul 1999 01:22:12 -0700 (PDT) (envelope-from gsutter@001101.zer0.org) Received: (from gsutter@localhost) by 001101.zer0.org (8.9.2/8.9.2) id BAA66318; Wed, 14 Jul 1999 01:21:06 -0700 (PDT) (envelope-from gsutter) Date: Wed, 14 Jul 1999 01:21:06 -0700 From: Gregory Sutter To: Kris Kennaway Cc: Ted Faber , Matthew Dillon , hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) Message-ID: <19990714012106.E55060@001101.zer0.org> References: <199907140017.RAA05545@boreas.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Kris Kennaway on Wed, Jul 14, 1999 at 05:43:21PM +0930 Organization: Zer0 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jul 14, 1999 at 05:43:21PM +0930, Kris Kennaway wrote: > > You know, it occurred to me that with all the time wasted typing up messages > in this thread someone (e.g. Matt) could have instead coded up a simple > non-overcommit model, given it to the nay-sayers and said "Run this and see > what I mean about making your system unusable" :-) Or with all the time that Matt wasted typing up messages in this thread, he could have been putting forth his efforts in some worthwhile direction. Now will y'all either do your research and come up with some hard numbers, or kill this poor thread so people can go back to doing their work? (Or in short, put up or shut up.) Greg -- Gregory S. Sutter "Software is like sex; it's better mailto:gsutter@pobox.com when it's free." -- Linus Torvalds http://www.pobox.com/~gsutter/ PGP DSS public key 0x40AE3052 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 1:37:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mauibuilt.com (mauibuilt.com [205.166.249.50]) by hub.freebsd.org (Postfix) with ESMTP id D87F51529D for ; Wed, 14 Jul 1999 01:37:43 -0700 (PDT) (envelope-from freebsd@mauibuilt.com) Received: (from freebsd@localhost) by mauibuilt.com (8.8.8/8.8.7) id WAA11364 for freebsd-hackers@freebsd.org; Tue, 13 Jul 1999 22:40:54 -1000 (HST) (envelope-from freebsd) From: FreeBSD MAIL Message-Id: <199907140840.WAA11364@mauibuilt.com> Subject: WaveLAN broken (repost) To: freebsd-hackers@freebsd.org Date: Tue, 13 Jul 1999 22:40:49 -1000 (HST) X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG this message may have been posted to hacks but I didnt see it come through. I greatly apreciate any help. I have a WaveLAN ISA adaptor. I am trying to run it in a machine equiped with an AMD K6-2 350 processor running at 66mhz bus speed. I am getting the following error while ifconfiging the card. ifconfig wl0 192.168.10.1 wl0: diag() failed; status = 0, inw = 0, outw = e0a0 wl0: diag() failed; status = 0, inw = 0, outw = e0a0 scb_status a000 scb_status a000 scb_command 0 scb_command 0 scb_cbl ffc0 scb_cbl ffc0 cu_cmd 8007 cu_cmd 8007 wl0 init(): trouble resetting board. wl0 init(): trouble resetting board. I belive the issure is some kind of timeing problem because the dos drivers and ptpdiag work and the card works with freebsd in other machines. I have tried about everything I can think of I have set machdep.wl_xmit_delay: up and down as well as played with clock speeds of the CPU and motherboard as well as bios wait states, pnp settings ect. and differant wavelan cards. I even reset the factory setting off 0x300 irq 10 to other ones just to be sure.. I have tried the drivers in 3.0 3.1 and 4.0 current they all do the same thing.. thease are the current dmesg settings wl0 at 0x390-0x39f irq 5 on isa wl0: address 08:00:6a:2b:e3:30, NWID 0x5262, Freq 2422 MHz and the wlconfig info... cray100 /root 6% wlconfig wl0 Board type : ISA Base address options : 0x300, 0x390, 0x3c0, 0x3e0 Waitstates : 0 Bus mode : ISA IRQ : 5 Default MAC address : 08:00:6a:2b:e3:30 Soft MAC address : 00:00:00:00:00:00 Current MAC address : Default Adapter compatability : PCCARD or 1/2 size AT, 915MHz or 2.4GHz Threshold preset : 1 Call code required : NO Subband : 915MHz/see WaveModem Quality threshold : 3 Hardware version : 1 (Rel3) Network ID enable : YES NWID : 0x5262 Datalink security : NO Databus width : 16 (variable) Configuration state : unconfigured CRC-16 : 0xaba1 CRC status : OK If anyone can help in any way or point me to someone who might I would greatly apreciate it. Thanks in advance Richard Puga puga@mauibuilt.com ----- End of forwarded message from freebsd ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 1:55:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.is4b.net (peach.oaktree.net.uk [193.82.129.13]) by hub.freebsd.org (Postfix) with ESMTP id D50AC14FD5 for ; Wed, 14 Jul 1999 01:55:39 -0700 (PDT) (envelope-from jon@chalk.oaktree.net.uk) Received: from chalk.oaktree.net.uk (chalk.oaktree.net.uk [193.82.129.19]) by relay.is4b.net (Postfix) with ESMTP id 596521DC01; Wed, 14 Jul 1999 09:54:00 +0100 (BST) Received: (from jon@localhost) by chalk.oaktree.net.uk (8.9.3/8.9.3) id JAA02427; Wed, 14 Jul 1999 09:54:00 +0100 (BST) Date: Wed, 14 Jul 1999 09:53:59 +0100 From: Jon Ribbens To: Doug Rabson Cc: Alfred Perlstein , "Daniel C. Sobral" , freebsd-hackers@freebsd.org, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) Message-ID: <19990714095359.A13286@oaktree.co.uk> Mail-Followup-To: Doug Rabson , Alfred Perlstein , "Daniel C. Sobral" , freebsd-hackers@freebsd.org, tech-userlevel@netbsd.org, tech@openbsd.org References: <19990713100228.C10979@oaktree.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Doug Rabson on Wed, Jul 14, 1999 at 08:31:07AM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug Rabson wrote: > Overcommit can be used for many reasons. I use it to reserve a large > linear address space to mmap alpha i/o spaces to which allows an efficient > implementation of inx/outx in user mode: > > UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND > 0 43655 43652 7 2 0 12616584 12456 select S ?? 1036:41.62 /usr/X11R6/bin/X -auth /usr/X11R6/lib/X11/xdm/authdir/A:0-w43652 > > The X server is using 12G of address space.. This is not an argument for malloc() to overcommit by default, it is an argument for there to be a way of allocating address space with no swap reserved *when you specifically ask for it*. Of course I would not disagree with this. Cheers Jon -- \/ Jon Ribbens / jon@oaktree.co.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 2:30:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id 8B7D214C15 for ; Wed, 14 Jul 1999 02:30:25 -0700 (PDT) (envelope-from kris@airnet.net) Received: from airnet.net (tc14-216-180-35-172.dialup.HiWAAY.net [216.180.35.172]) by mail.HiWAAY.net (8.9.1a/8.9.0) with ESMTP id EAA14507 for ; Wed, 14 Jul 1999 04:30:02 -0500 (CDT) Message-ID: <378C5899.DFF9F018@airnet.net> Date: Wed, 14 Jul 1999 04:30:01 -0500 From: Kris Kirby Organization: Non Illegitemus Carborundum. X-Mailer: Mozilla 4.08 [en] (X11; U; FreeBSD 3.2-RELEASE i386) MIME-Version: 1.0 To: hackers@freebsd.org Subject: X.25 drivers Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG # These are currently broken and are no longer shipped due to lack # of interest. #options CCITT #X.25 network layer #options ISO #options TPIP #ISO TP class 4 over IP #options TPCONS #ISO TP class 0 over X.25 #options LLC #X.25 link layer for Ethernets #options HDLC #X.25 link layer for serial line s #options EON #ISO CLNP over IP #options NSIP #XNS over IP If they are not shipped, where am I to go to find them? -- Kris Kirby ------------------------------------------- TGIFreeBSD... 'Nuff said. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 2:54: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from aussie.cs.mu.OZ.AU (dhcp2966.ietf.uninett.no [128.39.29.66]) by hub.freebsd.org (Postfix) with ESMTP id 2763314F51 for ; Wed, 14 Jul 1999 02:53:48 -0700 (PDT) (envelope-from kre@cs.mu.OZ.AU) Received: from cs.mu.OZ.AU (localhost [127.0.0.1]) by aussie.cs.mu.OZ.AU (8.8.8/8.8.8) with ESMTP id KAA08264; Wed, 14 Jul 1999 10:53:04 +0200 (CEST) From: Robert Elz To: Matthew Dillon Cc: cgd@netbsd.org (Chris G. Demetriou), Jason Thorpe , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-reply-to: Your message of "Tue, 13 Jul 1999 15:19:43 PDT." <199907132219.PAA81321@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Jul 1999 10:53:04 +0200 Message-ID: <8262.931942384@cs.mu.OZ.AU> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Date: Tue, 13 Jul 1999 15:19:43 -0700 (PDT) From: Matthew Dillon Message-ID: <199907132219.PAA81321@apollo.backplane.com> | There are a billion ways to do it and none of them require a swap | reservation model. Every method you described was exactly a swap reservation model. kre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 2:54: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from aussie.cs.mu.OZ.AU (dhcp2966.ietf.uninett.no [128.39.29.66]) by hub.freebsd.org (Postfix) with ESMTP id 0F3AE14EC3 for ; Wed, 14 Jul 1999 02:53:47 -0700 (PDT) (envelope-from kre@cs.mu.OZ.AU) Received: from cs.mu.OZ.AU (localhost [127.0.0.1]) by aussie.cs.mu.OZ.AU (8.8.8/8.8.8) with ESMTP id LAA08349; Wed, 14 Jul 1999 11:04:16 +0200 (CEST) From: Robert Elz To: Matthew Dillon Cc: Jason Thorpe , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-reply-to: Your message of "Tue, 13 Jul 1999 15:37:26 PDT." <199907132237.PAA81422@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Jul 1999 11:04:15 +0200 Message-ID: <8347.931943055@cs.mu.OZ.AU> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Date: Tue, 13 Jul 1999 15:37:26 -0700 (PDT) From: Matthew Dillon Message-ID: <199907132237.PAA81422@apollo.backplane.com> | allocation - most everything is statically allocated and if the system | tries to use more, it panics and reboots. I'm finding it difficult to continue taking seriously anyone who believes that "crash and reboot" is a suitable response to anything at all. I have implemented embedded systems, they most certainly did dynamic memory allocation (no way to fit in available memory resources if everything was pre-allocated) and "panic and reboot" is not something I would consider as a satisfactory tactic. kre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 2:54:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from aussie.cs.mu.OZ.AU (dhcp2966.ietf.uninett.no [128.39.29.66]) by hub.freebsd.org (Postfix) with ESMTP id 3D32814EC3; Wed, 14 Jul 1999 02:54:19 -0700 (PDT) (envelope-from kre@cs.mu.OZ.AU) Received: from cs.mu.OZ.AU (localhost [127.0.0.1]) by aussie.cs.mu.OZ.AU (8.8.8/8.8.8) with ESMTP id KAA08134; Wed, 14 Jul 1999 10:35:30 +0200 (CEST) From: Robert Elz To: Matthew Dillon Cc: Jason Thorpe , "Brian F. Feldman" , Noriyuki Soda , bright@rush.net, dcs@newsguy.com, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-reply-to: Your message of "Tue, 13 Jul 1999 14:14:52 PDT." <199907132114.OAA80781@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Jul 1999 10:35:29 +0200 Message-ID: <8132.931941329@cs.mu.OZ.AU> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Date: Tue, 13 Jul 1999 14:14:52 -0700 (PDT) From: Matthew Dillon Message-ID: <199907132114.OAA80781@apollo.backplane.com> | If you don't have the disk necessary for a standard overcommit model to | work, you definitely do not have the disk necessary for a non-overcommit | model to work. This is based upon your somewhat strange definition of "work". I assure you that I have run many systems which don't use overcommit, and which I quite frequently run into "out of VM" conditions, and which I can assure you, work just fine. When they're getting to run out of VM, the system is approaching paging death, which is as you'd expect (they're overloaded). That is, adding more VM (more swap space) would be counterproductive. When this stage is reached, the absolute prime requirement of "working" is met though - applications that request memory get that request refused, but absolutely no processes get ungracefully killed. In a sense, no-one really cares what the page allocation policy is, the argument here isn't about overcommit, or the very conservative early BSD version, or any of the intermediate possibilities - all people really care about is what happens when resources are exhausted. What happens until then no-one really cares about (there are some issues of how much space you need to dedicate to paging - most people would probably prefer to not use the early BSD method, where you needed at least as much paging space as RAM, or some of your RAM simply would be left idle). But one absolute requirement for any system that wants to consider itself to be a reliable useable, general purpose system, is that it never simply randomly kill processes of its own volition. If you're happy for random processes to be killed on your workstation, that's fine, I'm not. I run processes which are intended to do specific work, they're not intended to simply go away just because memory is running low (there are other processes, stupid perl scripts and such, which will quite quickly die when a mem request is refused, and return resources, so the processes that matter, which can be very large, can keep on processing). I have no doubt but that you can dream up scenarios where you pander to the laziness of programmers, and make using huge VM space with little of it actually allocated anywhere (or ever touched) then you would indeed need monstrous amounts of paging space, most of which is never actually used for anything - personally I prefer to have the programmers think a little more about the memory footprint of their data structures. Not only does this reduce the VM footprint, it will also usually vastly improving the paging characteristics. Most applications which simply scatter data through a huge VM space simply stop being useable as soon as their RSS exceeds available physical memory - that is, if they start paging, they die (become comatose might be a better description). A little intelligent though as to how to actually make use of the mem resources can make a huge difference. There was an earlier comment on this thread (which no longer has the slightest thing to do with the new version of grep...) which mentioned fortran programs. People, fortran (and huge fortran programs) has been around much longer than VM has been. There are lots of techniques for fortran programmers to use to make use of restricted memory sizes, they've been managing that for decades. kre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 3:18: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay01.indigo.ie (relay01.indigo.ie [194.125.133.225]) by hub.freebsd.org (Postfix) with SMTP id DF1CE14E4E for ; Wed, 14 Jul 1999 03:17:59 -0700 (PDT) (envelope-from niall@pobox.com) Received: (qmail 20871 messnum 238174 invoked from network[194.125.220.103/ts05-103.dublin.indigo.ie]); 14 Jul 1999 10:17:42 -0000 Received: from ts05-103.dublin.indigo.ie (HELO pobox.com) (194.125.220.103) by relay01.indigo.ie (qp 20871) with SMTP; 14 Jul 1999 10:17:42 -0000 Message-ID: <378C7ED5.ACBFA8F7@pobox.com> Date: Wed, 14 Jul 1999 12:13:09 +0000 From: Niall Smart X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: Re: bin/12578: `` subshell taints PWD References: <199907131815.UAA12928@dorifer.heim3.tu-clausthal.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm not sure if XPG4v2 requires command substitution to behave > like that. At least, both Solaris' and DEC UNIX... oops... > True64 UNIX do execute all command substitutions in a subshell > (`pwd` does not affect the surrounding shell), and both claim > XPG4 compliance. They only execute a subshell when they need to: $ echo $$ `echo $$` 14405 14405 $ uname -a SunOS molotov.boi.ie 5.6 Generic_105181-05 sun4u sparc SUNW,Ultra-5_10 Regards, Niall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 3:49: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay02.indigo.ie (relay02.indigo.ie [194.125.133.226]) by hub.freebsd.org (Postfix) with SMTP id B5F2B14D8D for ; Wed, 14 Jul 1999 03:49:03 -0700 (PDT) (envelope-from niall@pobox.com) Received: (qmail 13377 messnum 46325 invoked from network[194.125.220.235/ts06-108.dublin.indigo.ie]); 14 Jul 1999 10:47:40 -0000 Received: from ts06-108.dublin.indigo.ie (HELO pobox.com) (194.125.220.235) by relay02.indigo.ie (qp 13377) with SMTP; 14 Jul 1999 10:47:40 -0000 Message-ID: <378C85DB.70488160@pobox.com> Date: Wed, 14 Jul 1999 12:43:07 +0000 From: Niall Smart X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Jason Thorpe , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132328.QAA25285@lestat.nas.nasa.gov> <199907132333.QAA82004@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Maybe if I call the sysctl "vm.crashmenow". No, that will just make more > people actually try it. It might be doable as a compile-time option, > since you wouldn't be able to run anything approaching standard on > such a system anyway. I don't see much use for it myself. As I said > before, there are easier ways to manage memory that are not quite as > arbitrary as simply refusing a potential overcommit. Perhaps it could be an additional flag to mmap, in this way people wishing to run an overcommited system could do so but those writing programs which must not overcommit for certain memory allocations could ensure they did not do so. Regards, Niall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 3:50:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay02.indigo.ie (relay02.indigo.ie [194.125.133.226]) by hub.freebsd.org (Postfix) with SMTP id 32C7914E02 for ; Wed, 14 Jul 1999 03:50:16 -0700 (PDT) (envelope-from niall@pobox.com) Received: (qmail 14056 messnum 46325 invoked from network[194.125.220.235/ts06-108.dublin.indigo.ie]); 14 Jul 1999 10:50:13 -0000 Received: from ts06-108.dublin.indigo.ie (HELO pobox.com) (194.125.220.235) by relay02.indigo.ie (qp 14056) with SMTP; 14 Jul 1999 10:50:13 -0000 Message-ID: <378C8675.7705FF47@pobox.com> Date: Wed, 14 Jul 1999 12:45:41 +0000 From: Niall Smart X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: David Miller Cc: hackers@freebsd.org Subject: Re: [Off Topic] ODBC and yahoo References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG David Miller wrote: > > Couple of questions which are pretty much off topic.... > > 1) Does anyone know of a way to talk to a remote oracle server via odbc or > oci? Access is required specifically under apache and mod_perl or php, > but we've spent a couple of man-days looking for straightforward answers > and found none:( I know of at least two ways to access Oracle from FreeBSD: use the JDBC type IV driver, or use linux emulated binaries with Oracle for Linux. Regards, Niall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 4: 7:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id B7B1A1528D for ; Wed, 14 Jul 1999 04:07:43 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id NAA15907 for hackers@freebsd.org; Wed, 14 Jul 1999 13:07:42 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 279BD8838; Wed, 14 Jul 1999 13:05:48 +0200 (CEST) (envelope-from roberto) Date: Wed, 14 Jul 1999 13:05:48 +0200 From: Ollivier Robert To: hackers@freebsd.org Subject: Re: X.25 drivers Message-ID: <19990714130548.B23594@keltia.freenix.fr> Mail-Followup-To: hackers@freebsd.org References: <378C5899.DFF9F018@airnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.95.5i In-Reply-To: <378C5899.DFF9F018@airnet.net>; from Kris Kirby on Wed, Jul 14, 1999 at 04:30:01AM -0500 X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5468 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Kris Kirby: > If they are not shipped, where am I to go to find them? In the CVS repository. In the Attic of the various subdirectories. 290 [13:04] roberto@keltia:src/sys> ls Makefile,v ddb/ miscfs/ netiso/ posix4/ alpha/ dev/ modules/ netkey/ scsi/ boot/ gnu/ msdosfs/ netnatm/ svr4/ cam/ i386/ net/ netns/ sys/ cfs/ i4b/ netatalk/ nfs/ ufs/ coda/ isa/ netatm/ ntfs/ vm/ compile/ isofs/ netccitt/ pc98/ conf/ kern/ netinet/ pccard/ contrib/ libkern/ netipx/ pci/ 291 [13:04] roberto@keltia:src/sys> ls netiso/Attic ^^^^^ argo_debug.h,v iso.c,v tp_output.c,v clnl.h,v iso.h,v tp_param.h,v clnp.h,v iso_chksum.c,v tp_pcb.c,v clnp_debug.c,v iso_errno.h,v tp_pcb.h,v clnp_er.c,v iso_pcb.c,v tp_seq.h,v clnp_frag.c,v iso_pcb.h,v tp_stat.h,v clnp_input.c,v iso_proto.c,v tp_states.h,v clnp_options.c,v iso_snpac.c,v tp_states.init,v clnp_output.c,v iso_snpac.h,v tp_subr.c,v clnp_raw.c,v iso_var.h,v tp_subr2.c,v clnp_stat.h,v tp.trans,v tp_timer.c,v clnp_subr.c,v tp_astring.c,v tp_timer.h,v clnp_timer.c,v tp_clnp.h,v tp_tpdu.h,v cltp_usrreq.c,v tp_cons.c,v tp_trace.c,v cltp_var.h,v tp_driver.c,v tp_trace.h,v cons.h,v tp_emit.c,v tp_user.h,v cons_pcb.h,v tp_events.h,v tp_usrreq.c,v eonvar.h,v tp_inet.c,v tuba_subr.c,v esis.c,v tp_input.c,v tuba_table.c,v esis.h,v tp_ip.h,v tuba_table.h,v idrp_usrreq.c,v tp_iso.c,v tuba_usrreq.c,v if_cons.c,v tp_meas.c,v if_eon.c,v tp_meas.h,v -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #72: Mon Jul 12 08:26:43 CEST 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 7: 0: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from www.crb-web.com (ns1.crb-web.com [209.70.120.131]) by hub.freebsd.org (Postfix) with SMTP id 76F7B14CC9 for ; Wed, 14 Jul 1999 07:00:01 -0700 (PDT) (envelope-from wayne@crb.crb-web.com) Received: (qmail 9413 invoked by uid 1001); 14 Jul 1999 14:17:22 -0000 Date: Wed, 14 Jul 1999 10:17:21 -0400 (EDT) From: Wayne Cuddy Reply-To: wayne@crb-web.com To: FreeBSD Hackers List Subject: changing argv[0] after fork() Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a process that forks several times, I want to change the names that the child processes appear as in the process table. Is there a trick to doing this? Thanks, Wayne To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 7: 4: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fionn.sports.gov.uk (dns0.sports.gov.uk [195.89.151.148]) by hub.freebsd.org (Postfix) with ESMTP id 2262415439 for ; Wed, 14 Jul 1999 07:03:59 -0700 (PDT) (envelope-from ad@fionn.sports.gov.uk) Received: from [193.61.66.193] (helo=fionn.sports.gov.uk ident=andrewd) by fionn.sports.gov.uk with esmtp (Exim 2.10 #1) id 114Pbb-0001Gh-00; Wed, 14 Jul 1999 15:01:51 +0100 Message-ID: <378C98CB.E41232CA@fionn.sports.gov.uk> Date: Wed, 14 Jul 1999 15:03:55 +0100 From: Andy Doran X-Mailer: Mozilla 4.6 [en-gb] (WinNT; I) X-Accept-Language: en-GB,en,en-* MIME-Version: 1.0 To: wayne@crb-web.com Cc: FreeBSD Hackers List Subject: Re: changing argv[0] after fork() References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG setproctitle(3) Wayne Cuddy wrote: > > I have a process that forks several times, I want to change the names that the > child processes appear as in the process table. Is there a trick to doing > this? > > Thanks, > Wayne > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 7:21:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 3AAB915103; Wed, 14 Jul 1999 07:21:29 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id XAA14705; Wed, 14 Jul 1999 23:21:19 +0900 (JST) Message-ID: <378C9BFC.A3273D45@newsguy.com> Date: Wed, 14 Jul 1999 23:17:32 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Ladavac Marino Cc: "'Brian F. Feldman'" , Noriyuki Soda , bright@rush.net, freebsd-hackers@FreeBSD.org, jon@oaktree.co.uk, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <55586E7391ACD211B9730000C11002761796F3@r-lmh-wi-100.corpnet.at> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ladavac Marino wrote: > > This topic has been trashed to death a few months ago. There is no > win-win situation in presence of processes which allocate a lot of memory > without actually using it (read: your typical FORTRAN library). This is not about just Fortran libraries. Imagine a reasonably big program, like Netscape or Emacs, of which you usually just use a subset of features. There can easily be many megabytes of code and data in them you never actually use, or you don't _usually_ use (like the people who use emacs like it was vi :). Without overcommit, you need to allocate all that memory for the code, no matter whether you end up using it or not. With overcommit, there is no such problem. And that's not all, either. Hell, people, if overcommit was not useful, everybody wouldn't be doing it. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 7:45:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (Postfix) with ESMTP id AE28614D13 for ; Wed, 14 Jul 1999 07:45:54 -0700 (PDT) (envelope-from nick.hibma@jrc.it) Received: from elect8 (elect8.jrc.it [139.191.71.152]) by mrelay.jrc.it (LMC5692) with SMTP id QAA13126; Wed, 14 Jul 1999 16:44:50 +0200 (MET DST) Date: Wed, 14 Jul 1999 16:44:49 +0200 (MET DST) From: Nick Hibma X-Sender: n_hibma@elect8 Reply-To: Nick Hibma To: Wayne Cuddy Cc: FreeBSD Hackers List Subject: Re: changing argv[0] after fork() In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In C, change argv. Be carefull to not write any strings that are longer then the space available, or replace the pointers. Nick On Wed, 14 Jul 1999, Wayne Cuddy wrote: > I have a process that forks several times, I want to change the names that the > child processes appear as in the process table. Is there a trick to doing > this? > > Thanks, > Wayne > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 7:48: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 1495C14F44; Wed, 14 Jul 1999 07:48:01 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id XAA20939; Wed, 14 Jul 1999 23:47:42 +0900 (JST) Message-ID: <378CA22C.E5537F7A@newsguy.com> Date: Wed, 14 Jul 1999 23:43:56 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Noriyuki Soda Cc: Matthew Dillon , Jason Thorpe , "Brian F. Feldman" , bright@rush.net, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132127.OAA80947@apollo.backplane.com> <199907132139.GAA14890@srapc342.sra.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Noriyuki Soda wrote: > > Running out of swap can be easily done by normal user privilege. > Non-overcommiting system can run important application on the system > which has a normal user, because it never lose critical data, even if > a user on the system make a mistake. (The application might stop, > but it never lose data.) > > 4.4BSD derived system cannot do this, and have to use different > machine for such applications. Incorrect. We can set *limits* to the users, so they won't be able to crash down the system. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 8: 7:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 6136014D13 for ; Wed, 14 Jul 1999 08:07:46 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id AAA26199; Thu, 15 Jul 1999 00:07:32 +0900 (JST) Message-ID: <378CA6D1.F2E0813F@newsguy.com> Date: Thu, 15 Jul 1999 00:03:45 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: "Chris G. Demetriou" Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132110.OAA23817@lestat.nas.nasa.gov> <199907132114.OAA80781@apollo.backplane.com> <877lo4z0pe.fsf@redmail.redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [cutting down on cc's] "Chris G. Demetriou" wrote: > > I'd _really_ like to know how you figure this. > > text data bss dec hex filename > 45024 4096 392 49512 c168 /bin/cat > 311264 12288 9900 333452 5168c /bin/sh > 212960 4096 28492 245548 3bf2c inetd.static > 458720 12288 73716 544724 84fd4 sendmail.static > > None of these are particularly huge. Dynamically linked binaries Fine. Let's see... suppose you have 10 /bin/sh running. You have to allocate 122880 bytes of "data". This is writable, y'know. /bin/sh might decide to write to it, so you need one copy for each instance of /bin/sh running on a non-overcommit system. > * while you certainly need to allocate more backing store than you > would with overcommit, it's _not_ ridiculously more for most > applications(+), and, finally, It comes down to this: in the overcommit model, memory is only allocated *on-demand*. If you are not overcommitting, that is equivalent to having everything "demanded". Now, consider a system which does not overcommit reaching the maximum available memory... this is the point at which the overcommitting ones will kill processes, and the non-overcommitting ones will return failure on malloc(). Select *one* running process, and make it's memory overcommitted. As a result, you'll have *more* memory available, at least for a few more cycles. Repeat this with every other process. Now you have much more memory available, and you are very unlikely to spend it in the next few cycles, unless there is a runaway process (which will be the process killed, if all memory is allocated). So, you would have been better off overcommitting. > * even if you are not willing to pay that price, there _are_ people > who are quite willing to pay that price to get the benefits that they > see (whether it's a matter of perception or not, from their > perspective they may as well be real) of such a scheme. Sure. Point me to +one+ AIX admin that has turned the overcommitting off. > (+): obviously, there are some applications for which no-overcommit is > just silly. However, 'normal' UNIX applications by and large allocate > memory (or map files writeable/private, or map anonymous memory) to > actually use it. I.e. if 'cat' or 'inetd' or 'sendmail' allocates a > page from the system, it's almost certainly going write something to > it, and, while there are undoubtedly a few pages that aren't written > to, they are by far the majority. And, of course, once the page has > been written, it's no longer reserved, it's committed. 8-) Memory allocated is not instantly used. The process might not *need* the memory until other processes have finished. And in addition to my previous comments, these "normal" UNIX applications are also quite small. Memory will be mostly consumed by larger processes, which usually contain big tables, of which only parts will actually be used on each instance. > I would honestly love to know: what do you see huge numbers of > reserved pages being reserved for, if they're not actually being > committed, by 'average' UNIX applications (for any definition of > average that excludes applications which do memory based computation > on sparse dasta). Try any application generated by yacc or lex, or anything that parses. They all have these static data tables... -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 8:23:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.netbsd.org (redmail.netbsd.org [155.53.200.193]) by hub.freebsd.org (Postfix) with SMTP id A47ED14C2F for ; Wed, 14 Jul 1999 08:23:08 -0700 (PDT) (envelope-from cgd@netbsd.org) Received: (qmail 23473 invoked by uid 1000); 14 Jul 1999 15:22:04 -0000 To: Doug Rabson Cc: Jon Ribbens , Alfred Perlstein , "Daniel C. Sobral" , freebsd-hackers@freebsd.org, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) References: From: cgd@netbsd.org (Chris G. Demetriou) Date: 14 Jul 1999 08:22:03 -0700 In-Reply-To: Doug Rabson's message of Wed, 14 Jul 1999 08:31:07 +0100 (BST) Message-ID: <87oghfz278.fsf@redmail.redback.com> Lines: 22 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug Rabson writes: > Overcommit can be used for many reasons. I use it to reserve a large > linear address space to mmap alpha i/o spaces [...] Overcommit can be used for many reasons, but unless you've misdescribed what you're doing, _that's not one of them_. The mapped I/O pages need no backing store to be allocated for them by the VM system. They're backed by hardware. And if you have 'placeholder' pages (I note that you didn't say you mmap all of alpha i/o space, just reserve a large linear address space in which to mmap it), then it should be possible to map them in such a way (e.g. read-only ZFOD) in which they wouldn't count against backing store requirements, either. cgd -- Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html Disclaimer: Not speaking for NetBSD, just expressing my own opinion. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 8:24:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 0B32F14C2F; Wed, 14 Jul 1999 08:24:54 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id AAA00262; Thu, 15 Jul 1999 00:24:44 +0900 (JST) Message-ID: <378CAAD9.AAD7268E@newsguy.com> Date: Thu, 15 Jul 1999 00:20:57 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: "Charles M. Hannum" Cc: Matthew Dillon , Noriyuki Soda , Jason Thorpe , "Brian F. Feldman" , bright@rush.net, freebsd-hackers@FreeBSD.ORG, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907132346.TAA13780@bikini.ihack.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Charles M. Hannum" wrote: > > That's also objectively false. Most such environments I've had > experience with are, in fact, multi-user systems. As you've pointed > out yourself, there is no combination of resource limits and whatnot > that are guaranteed to prevent `crashing' a multi-user system due to > overcommit. My simulation should not be axed because of a bug in > someone else's program. (This is also not hypothetical. There was a > bug in one version of bash that caused it to consume all the memory it > could and then fall over.) In which case the program that consumed all memory will be killed. The program killed is +NOT+ the one demanding memory, it's the one with most of it. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 8:28:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mercury.webnology.com (mercury.webnology.com [209.155.51.2]) by hub.freebsd.org (Postfix) with ESMTP id 7D65314CBA for ; Wed, 14 Jul 1999 08:28:06 -0700 (PDT) (envelope-from jooji@webnology.com) Received: from localhost (jooji@localhost) by mercury.webnology.com (8.9.2/8.9.2) with SMTP id JAA20222 for ; Wed, 14 Jul 1999 09:29:10 -0500 (CDT) Date: Wed, 14 Jul 1999 09:29:10 -0500 (CDT) From: "Jasper O'Malley" To: freebsd-hackers@freebsd.org Subject: Final (maybe) ARP breakage plea Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I realize it's not real high on the list of things to fix, but proxy ARP is still broken in -STABLE. If anyone know the answers to any of these questions, please drop me a line so I can try fixing it: 1) Can anyone explain the difference between "published" ARP table entries, and "published (proxy only)" ARP table entries? 2) What purpose does the sin_other parameter of the sockaddr_inarp structure serve (defined in /usr/include/netinet/if_ether.h, and set to SIN_PROXY for "proxy only" ARP entries)? 3) How about the significance of the RTF_HOST routing message flag (i.e. how does an IP "host" route functionally differ from a "net" route with a /32 netmask)? Or does this only have significance for non-IP routes? 4) What's the purpose of this snippet of code from rtmsg() in src/usr.sbin/arp/arp.c? if (doing_proxy) { if (export_only) sin_m.sin_other = SIN_PROXY; else { rtm->rtm_addrs |= RTA_NETMASK; rtm->rtm_flags &= ~RTF_HOST; } } Cheers, Mick The Reverend Jasper P. O'Malley dotdot:jooji@webnology.com Systems Administrator ringring:asktheadmiral Webnology, LLC woowoo:http://www.webnology.com/~jooji To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 8:30:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pzero.sandelman.ottawa.on.ca (gigabit.solidum.com [216.13.130.242]) by hub.freebsd.org (Postfix) with ESMTP id 97BC814CBA for ; Wed, 14 Jul 1999 08:30:09 -0700 (PDT) (envelope-from mcr@sandelman.ottawa.on.ca) Received: from morden.sandelman.ottawa.on.ca (localhost [127.0.0.1]) by pzero.sandelman.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id JAA04832; Wed, 14 Jul 1999 09:24:02 -0400 (EDT) Message-Id: <199907141324.JAA04832@pzero.sandelman.ottawa.on.ca> To: freebsd-hackers@freebsd.org, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-reply-to: Your message of "Tue, 13 Jul 1999 16:33:41 PDT." <199907132333.QAA82004@apollo.backplane.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Wed, 14 Jul 1999 09:20:52 -0400 From: Michael Richardson Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Matthew" == Matthew Dillon writes: Matthew> Maybe if I call the sysctl "vm.crashmenow". No, that will just make more Matthew> people actually try it. It might be doable as a compile-time option, Matthew> since you wouldn't be able to run anything approaching standard on Matthew> such a system anyway. I don't see much use for it myself. As I said Matthew> before, there are easier ways to manage memory that are not quite as Matthew> arbitrary as simply refusing a potential overcommit. Is there anyway on FreeBSD to a) ask that one not be on the SIGKILL list? b) tune the amount of overcommit? ] Train travel features AC outlets with no take-off restrictions| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 9: 0:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id EBBC414CC9 for ; Wed, 14 Jul 1999 09:00:10 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id AAA07241; Thu, 15 Jul 1999 00:59:05 +0900 (JST) Message-ID: <378CADAA.3CBFF593@newsguy.com> Date: Thu, 15 Jul 1999 00:32:58 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: "Charles M. Hannum" Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907140122.VAA14015@bikini.ihack.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Charles M. Hannum" wrote: > > There are many environments where even the possibility of the > simulation crashing due to external influence is unacceptable. I find > it sad that you resist making FreeBSD robust against such problems, > but that's your concern. FreeBSD is robust against the problems you describe. All it takes is for you to define proper limits for memory usage for each user. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 9: 0:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 2D36414CC9 for ; Wed, 14 Jul 1999 09:00:23 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id AAA07326; Thu, 15 Jul 1999 00:59:36 +0900 (JST) Message-ID: <378CB26D.C0BC0DBE@newsguy.com> Date: Thu, 15 Jul 1999 00:53:17 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Robert Elz Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <8132.931941329@cs.mu.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Robert Elz wrote: > > Date: Tue, 13 Jul 1999 14:14:52 -0700 (PDT) > From: Matthew Dillon > Message-ID: <199907132114.OAA80781@apollo.backplane.com> > > | If you don't have the disk necessary for a standard overcommit model to > | work, you definitely do not have the disk necessary for a non-overcommit > | model to work. > > This is based upon your somewhat strange definition of "work". I assure > you that I have run many systems which don't use overcommit, and which I > quite frequently run into "out of VM" conditions, and which I can assure > you, work just fine. When they're getting to run out of VM, the system > is approaching paging death, which is as you'd expect (they're overloaded). > That is, adding more VM (more swap space) would be counterproductive. Would you care to name such systems? And, btw, a system consuming all memory is *not* necessarily approaching paging death. More likely, it is just storing a lot of data in the swap which will never be used (which is the whole point of overcommit in first place), and, thus, never paged in. > I have no doubt but that you can dream up scenarios where you pander to > the laziness of programmers, and make using huge VM space with little > of it actually allocated anywhere (or ever touched) then you would indeed > need monstrous amounts of paging space, most of which is never actually > used for anything - personally I prefer to have the programmers think > a little more about the memory footprint of their data structures. Not > only does this reduce the VM footprint, it will also usually vastly > improving the paging characteristics. Most applications which simply > scatter data through a huge VM space simply stop being useable as soon > as their RSS exceeds available physical memory - that is, if they start > paging, they die (become comatose might be a better description). > A little intelligent though as to how to actually make use of the mem > resources can make a huge difference. Fine. Stay with the allocation of swap for DATA/BSS of each instance of the same program you are running. That alone is enough. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 9: 1:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 99A6C153E1 for ; Wed, 14 Jul 1999 09:01:26 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id MAA09823; Wed, 14 Jul 1999 12:00:55 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Wed, 14 Jul 1999 12:00:55 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: "Daniel C. Sobral" Cc: "Charles M. Hannum" , Matthew Dillon , Noriyuki Soda , Jason Thorpe , bright@rush.net, freebsd-hackers@FreeBSD.org, jon@oaktree.co.uk, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) In-Reply-To: <378CAAD9.AAD7268E@newsguy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Jul 1999, Daniel C. Sobral wrote: > "Charles M. Hannum" wrote: > > > > That's also objectively false. Most such environments I've had > > experience with are, in fact, multi-user systems. As you've pointed > > out yourself, there is no combination of resource limits and whatnot > > that are guaranteed to prevent `crashing' a multi-user system due to > > overcommit. My simulation should not be axed because of a bug in > > someone else's program. (This is also not hypothetical. There was a > > bug in one version of bash that caused it to consume all the memory it > > could and then fall over.) > > In which case the program that consumed all memory will be killed. > The program killed is +NOT+ the one demanding memory, it's the one > with most of it. So why don't we do something else: when we're down to a certain amount of backing store, start collecting statistics. When we're out, we check the statistics and find what process has been allocating most of it. We kill that process. > > -- > Daniel C. Sobral (8-DCS) > dcs@newsguy.com > dcs@freebsd.org > > "Would you like to go out with me?" > "I'd love to." > "Oh, well, n... err... would you?... ahh... huh... what do I do > next?" > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 9: 3: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 8CD0314D4F for ; Wed, 14 Jul 1999 09:03:02 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id MAA09888; Wed, 14 Jul 1999 12:02:56 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Wed, 14 Jul 1999 12:02:56 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Michael Richardson Cc: freebsd-hackers@FreeBSD.org, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <199907141324.JAA04832@pzero.sandelman.ottawa.on.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 14 Jul 1999, Michael Richardson wrote: > > >>>>> "Matthew" == Matthew Dillon writes: > Matthew> Maybe if I call the sysctl "vm.crashmenow". No, that will just make more > Matthew> people actually try it. It might be doable as a compile-time option, > Matthew> since you wouldn't be able to run anything approaching standard on > Matthew> such a system anyway. I don't see much use for it myself. As I said > Matthew> before, there are easier ways to manage memory that are not quite as > Matthew> arbitrary as simply refusing a potential overcommit. > > Is there anyway on FreeBSD to > a) ask that one not be on the SIGKILL list? > b) tune the amount of overcommit? I think it would be better to find the process(es) trying to use memory so voraciously and send them the SIGKILLs. This should be feasible. > > ] Train travel features AC outlets with no take-off restrictions| firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ > ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 9:39: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 1D49414DF4 for ; Wed, 14 Jul 1999 09:39:03 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (phoenix.cs.rpi.edu [128.113.96.153]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id MAA24302 for ; Wed, 14 Jul 1999 12:39:01 -0400 (EDT) Message-Id: <199907141639.MAA24302@cs.rpi.edu> To: freebsd-hackers@freebsd.org Subject: brooktree 848 OEM card/no sound :( Date: Wed, 14 Jul 1999 12:38:54 -0400 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am helping a freind install FreeBSD on his machine (it is running 4.0-CURRENT now). everything works flawlessly, except his OEM BrookTree 848 based soundcard. The card itself is transplanted from his gateway machine (where it also had the same problems). Here are some specifics: (summary) Machine is a Dual-PII-400 with a SB-AWE64 PCI soundcard. The Bt848 is unrecognized, and I need to sysctl -w hw.bt848.tuner=[49] to get it to work (either one works as far as I can tell with no difference). (dmesg) Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Tue Jul 13 20:33:07 EDT 1999 root@neshej-2.stu.rpi.edu:/usr/src/sys/compile/MABROOK Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183fbff real memory = 268435456 (262144K bytes) avail memory = 258150400 (252100K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec00000 Preloaded elf kernel "kernel" at 0xc02fa000. Pentium Pro MTRR support enabled, default memory type is uncacheable Probing for PnP devices: CSN 1 Vendor ID: CTL00e4 [0xe4008c0e] Serial 0x01c574c8 Comp ID: PNPb02f [0x2fb0d041] pcm1 (SB16pnp sn 0x01c574c8) at 0x220-0x22f irq 5 drq 1 flags 0x15 on isa npx0: on motherboard npx0: INT 16 interface apm0: on motherboard apm: found APM BIOS version 1.2 pcib0: on motherboard pci0: on pcib0 WARNING: "bktr" is usurping "bktr"'s cdevsw[] chip0: at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vga-pci0: irq 17 at device 0.0 on pci1 isab0: at device 7.0 on pci0 ide_pci0: at device 7.1 on pci0 uhci0: at device 7.2 on pci0 uhci0: could not map ports device_probe_and_attach: uhci0 attach returned 6 chip1: at device 7.3 on pci0 vx0: <3COM 3C590 Etherlink III PCI> irq 17 at device 16.0 on pci0 utp/aui/bnc[*utp*]: disable 'auto select' with DOS util! address 00:20:af:ee:32:94 Warning! Defective early revision adapter! isa0: on motherboard fdc0: at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> at fdc0 drive 0 wdc0 at port 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa0 wdc0: unit 0 (wd0): , DMA, 32-bit, multi-block-16 wd0: 13783MB (28229040 sectors), 28005 cyls, 16 heads, 63 S/T, 512 B/S wdc1 at port 0x170-0x177 irq 15 flags 0xa0ffa0ff on isa0 wdc1: unit 0 (atapi): , removable, accel, ovlap, dma, iordis wcd0: drive speed 5512KB/sec, 128KB cache wcd0: supported read types: CD-R, CD-RW, CD-DA, packet track wcd0: Audio: play, 256 volume levels wcd0: Mechanism: ejectable tray wcd0: Medium: CD-ROM 120mm audio disc loaded, unlocked atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: at port 0x3b0-0x3df iomem 0xa0000-0xbffff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0 at port 0x378-0x37f irq 7 flags 0x40 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold plip0: on ppbus 0 lpt0: on ppbus 0 lpt0: Interrupt-driven port ppi0: on ppbus 0 vx0 XXX: driver didn't set ifq_maxlen changing root device to wd0s1a SMP: AP CPU #1 Launched! acd0: read_toc failed (kernel config) machine i386 cpu I686_CPU ident MABROOK maxusers 64 options INET #InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options MFS #Memory Filesystem options NFS #Network Filesystem options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options UCONSOLE #Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options SOFTUPDATES options KTRACE #ktrace(1) syscall trace support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O controller isa0 controller pnp0 # PnP support for ISA controller pci0 controller fdc0 at isa? port IO_FD1 irq 6 drq 2 disk fd0 at fdc0 drive 0 controller wdc0 at isa? port IO_WD1 irq 14 flags 0xa0ffa0ff disk wd0 at wdc0 drive 0 controller wdc1 at isa? port IO_WD2 irq 15 flags 0xa0ffa0ff device wcd0 #IDE CD-ROM controller atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device psm0 at atkbdc? irq 12 device vga0 at isa? port ? conflicts device sc0 at isa? device npx0 at nexus? port IO_NPX irq 13 device apm0 at nexus? flags 0x31 # Advanced Power Management device sio0 at isa? port IO_COM1 flags 0x10 irq 4 device sio1 at isa? port IO_COM2 irq 3 device ppc0 at isa? port? flags 0x40 irq 7 controller ppbus0 # Parallel port bus (required) device lpt0 # Printer device plip0 # TCP/IP over parallel device ppi0 # Parallel port interface device device vx0 # 3Com 3c590, 3c595 (``Vortex'') pseudo-device loop # Network loopback pseudo-device ether # Ethernet support pseudo-device pty 256 # Pseudo-ttys (telnet etc) pseudo-device gzip # Exec gzipped a.out's pseudo-device bpfilter 4 #Berkeley packet filter controller uhci0 # UHCI PCI->USB interface controller ohci0 # OHCI PCI->USB interface controller usb0 # USB Bus (required) device ugen0 # Generic device uhid0 # "Human Interface Devices" device ukbd0 # Keyboard device ulpt0 # Printer device bktr0 controller iicbus0 controller iicbb0 controller smbus0 device ums0 # Mouse device pcm0 at isa? port? irq 5 drq 1 flags 0x15 -- David Cross | email: crossd@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 9:44: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from luna.lyris.net (luna.shelby.com [207.90.155.6]) by hub.freebsd.org (Postfix) with ESMTP id 46AFA14C97; Wed, 14 Jul 1999 09:43:59 -0700 (PDT) (envelope-from kip@lyris.com) Received: from luna.shelby.com by luna.lyris.net (8.9.1b+Sun/SMI-SVR4) id JAA21482; Wed, 14 Jul 1999 09:42:33 -0700 (PDT) Received: from (luna.shelby.com [207.90.155.6]) by luna.shelby.com with SMTP (MailShield v1.50); Wed, 14 Jul 1999 09:42:33 -0700 Date: Wed, 14 Jul 1999 09:42:33 -0700 (PDT) From: Kip Macy X-Sender: kip@luna To: hackers@freebsd.org, stable@freebsd.org Subject: seg fault in mutex_queue_enq Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: luna X-SMTP-MAIL-FROM: kip@lyris.com X-SMTP-RCPT-TO: hackers@freebsd.org,stable@freebsd.org X-SMTP-PEER-INFO: luna.shelby.com [207.90.155.6] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Can someone familiar with the new threads code tell me what is causing the following segmentation fault. Thanks. -Kip Program terminated with signal 11, Segmentation fault. #0 0x82fb15d in mutex_queue_enq (mutex=0x83c3a54, pthread=0x8594e00) at /usr/src/lib/libc_r/uthread/uthread_mutex.c:1281 1281 PTHREAD_PRIOQ_INSERT_HEAD(pthread); (gdb) bt #0 0x82fb15d in mutex_queue_enq (mutex=0x83c3a54, pthread=0x8594e00) at /usr/src/lib/libc_r/uthread/uthread_mutex.c:1281 #1 0x82f9edd in pthread_mutex_lock (mutex=0x83c3ad4) at /usr/src/lib/libc_r/uthread/uthread_mutex.c:387 #2 0x8308199 in localtime_r (timep=0x8da164c, p_tm=0x8da1620) at /usr/src/lib/libc_r/../libc/stdtime/localtime.c:1091 #3 0x8273e49 in os_time::now () at time.cpp:241 #4 0x8154ea3 in lyr_time_now () at lyrdate.cpp:105 #5 0x8154487 in DateTimeStampEasyRead () at lyrdate.cpp:53 #6 0x80df9de in lyris_InMail::appendTransact (this=0x8da2e0c, Setting=@0x8da2818) at inmail.cpp:798 #7 0x80cb47f in lyris_OneIncoming::AppendToInMailTransact (this=0x8da2d20, Message=@0x8da2818) at incoming.cpp:592 #8 0x808b376 in lyris_OneIncoming::do_command_Subscribe (this=0x8da2d20, DefaultEmailAddress=@0x8da2aec, aRealName=@0x8da2afc, aList=@0x8da2d44, TheseOptions=@0x8da29ac) at inclserv.cpp:916 #9 0x80c4fa5 in lyris_OneIncoming::command_Subscribe (this=0x8da2d20, DefaultEmailAddress=@0x8da2aec, DefaultRealName=@0x8da2afc, aList=@0x8da2d44, PossiblePasswords=@0x8da29ac) at inclsrv2.cpp:44 #10 0x8083b71 in lyris_OneIncoming::process_listserv (this=0x8da2d20) at inclserv.cpp:273 #11 0x80c9007 in lyris_OneIncoming::go (this=0x8da2d20) at incoming.cpp:346 #12 0x80cb0f0 in DoProcessOneIncomingMessage (MessageID=@0x8da2fb0) at incoming.cpp:566 #13 0x80cad5e in ProcessOneIncomingMessage (arg=0x92bacc0) at incoming.cpp:541 #14 0x8285836 in _internal_thread_wrapper (parameter=0x92bace0) at thread.cpp:263 #15 0x82f158e in _thread_start () at /usr/src/lib/libc_r/uthread/uthread_create.c:250 #16 0x0 in ?? () Current language: auto; currently c (gdb) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 9:57: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id D034515426; Wed, 14 Jul 1999 09:56:53 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id MAA56824; Wed, 14 Jul 1999 12:56:43 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: <49928.931911388@axl.noc.iafrica.com> Date: Wed, 14 Jul 1999 12:56:39 -0400 To: "Brian F. Feldman" , Sheldon Hearn From: Garance A Drosihn Subject: Re: a BSD identd Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 11:47 PM -0400 7/13/99, Brian F. Feldman wrote: > We don't _need_ pidentd anymore. It will load down a system more > than the inetd's implementation of ident will. Therefore, pidentd > should be phased out. Other than that, pidentd should be using > http://www.FreeBSD.org/~green/freebsd4.c and not linking with > libkvm. I am not sure I understand what you are saying. pident is currently a port, under 'security'. I can understand the idea that maybe it should be under 'net' instead (in fact, that's where I first looked for it when I went to install it on my machine). It sounds like you want it removed from the ports collection. Given that I have yet to see a real specific complaint against it (vague comments about "it loads down the system" or "it's really buggy" have not convinced me of much), I do not see why anyone would care if it remains in the ports collection. There are certainly other ports with bugs (hell, the base OS has bugs), and there are other things which "load down a system" (funny, my system does not seem to be "loaded down" by pident). What is it with this crusade to completely eridicate ("phase out") pident? Or am I missing something here? --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 9:57:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (Postfix) with ESMTP id A778C153FC for ; Wed, 14 Jul 1999 09:57:41 -0700 (PDT) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.8.8/8.8.8) id SAA20332 for freebsd-hackers@FreeBSD.ORG; Wed, 14 Jul 1999 18:57:35 +0200 (CEST) (envelope-from olli) Date: Wed, 14 Jul 1999 18:57:35 +0200 (CEST) From: Oliver Fromme Message-Id: <199907141657.SAA20332@dorifer.heim3.tu-clausthal.de> To: freebsd-hackers@FreeBSD.ORG Subject: Re: bin/12578: `` subshell taints PWD Organization: Administration Heim 3 Reply-To: freebsd-hackers@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: TIN [version 1.2 RZTUC(3) PL2] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Niall Smart wrote in list.freebsd-hackers: > > > I'm not sure if XPG4v2 requires command substitution to behave > > like that. At least, both Solaris' and DEC UNIX... oops... > > True64 UNIX do execute all command substitutions in a subshell > > (`pwd` does not affect the surrounding shell), and both claim > > XPG4 compliance. > > They only execute a subshell when they need to: No, it _always_ spawns a subshell. > $ echo $$ `echo $$` > 14405 14405 > $ uname -a > SunOS molotov.boi.ie 5.6 Generic_105181-05 sun4u sparc SUNW,Ultra-5_10 That doesn't prove anything, because $$ always contains the PID of the "top-level" shell, as I explained in an earlier mail. Try this one: $ echo $$ `( /bin/echo $$ )` 14762 14762 I think you agree that a subshell is spawned in that case, don't you? ;-) Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 10:11:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from www.crb-web.com (ns1.crb-web.com [209.70.120.131]) by hub.freebsd.org (Postfix) with SMTP id EECE4153ED for ; Wed, 14 Jul 1999 10:11:15 -0700 (PDT) (envelope-from wayne@crb.crb-web.com) Received: (qmail 10530 invoked by uid 1001); 14 Jul 1999 17:28:07 -0000 Date: Wed, 14 Jul 1999 13:28:07 -0400 (EDT) From: Wayne Cuddy Reply-To: wayne@crb-web.com To: Andy Doran Cc: FreeBSD Hackers List Subject: Re: changing argv[0] after fork() In-Reply-To: <378C98CB.E41232CA@fionn.sports.gov.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Even though I am developing on FBSD is there a "more portable" way to do this? Thanks, Wayne On Wed, 14 Jul 1999, Andy Doran wrote: > Date: Wed, 14 Jul 1999 15:03:55 +0100 > From: Andy Doran > To: wayne@crb-web.com > Cc: FreeBSD Hackers List > Subject: Re: changing argv[0] after fork() > > setproctitle(3) > > Wayne Cuddy wrote: > > > > I have a process that forks several times, I want to change the names that the > > child processes appear as in the process table. Is there a trick to doing > > this? > > > > Thanks, > > Wayne > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-hackers" in the body of the message > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 10:11:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id E1B6B153EE for ; Wed, 14 Jul 1999 10:11:18 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id CAA16965; Thu, 15 Jul 1999 02:10:28 +0900 (JST) Message-ID: <378CBDAF.1186986A@newsguy.com> Date: Thu, 15 Jul 1999 01:41:19 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: "Chris G. Demetriou" Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907131753.KAA22111@lestat.nas.nasa.gov> <199907131813.LAA79534@apollo.backplane.com> <873dys1hfw.fsf@redmail.redback.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Chris G. Demetriou" wrote: > ... > Overcommit avoidance may not be useful for your particular uses of > these UNIX-like systems. However, if you think that it's not useful > to anybody who uses them (or that people who think it's useful are > deluding themselves 8-), then you're sorely mistaken and have a > ... very wrong-headed attitude about why people find such features > useful. Have you actually tried a system which can work in either overcommit and non-overcommit modes? What it comes down to is that if you have enough memory to run in non-overcommit, you have enough memory to run in overcommit. Setting limits is complex, but it is no more complex than correctly sizing the memory in a non-overcommit system (this is demonstrable). -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 10:11:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 4A62815426 for ; Wed, 14 Jul 1999 10:11:41 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id CAA17003; Thu, 15 Jul 1999 02:10:49 +0900 (JST) Message-ID: <378CC0FF.67EFAFCC@newsguy.com> Date: Thu, 15 Jul 1999 01:55:27 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Matthew Dillon Cc: Jason Thorpe , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132239.PAA24879@lestat.nas.nasa.gov> <199907132252.PAA81592@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > > : > :Heh, really? The camera ships w/ Apache running on it. > : > : -- Jason R. Thorpe > > They obviously have a lot of memory to play with, then. Or they > are crazy. Writing a web server is fairly easy to do. I've > written several, including the one that BEST runs on most of its > servers. For the record, professional digital cameras go into the $100K range, so I'd be expecting it not only to run Apache, but also to come with Doom. :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 10:11:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 1E13C1543A for ; Wed, 14 Jul 1999 10:11:48 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id CAA16993; Thu, 15 Jul 1999 02:10:40 +0900 (JST) Message-ID: <378CC03B.3840B177@newsguy.com> Date: Thu, 15 Jul 1999 01:52:11 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Jason Thorpe Cc: Matthew Dillon , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132230.PAA24729@lestat.nas.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jason Thorpe wrote: > > > There is a lot of hidden 'potential' VM that you haven't considered. > > For example, if the resource limit for a process's stack is 8MB, then > > the process can potentially allocate 8MB of stack even though it may > > actually only allocate 32K of stack. When a process forks, the child > > ...um, so, make the code that deals with faulting in the stack a bit smarter. Uh? Like what? Like overcommitting, for instance? The beauty of overcommitting is that either you do it or you don't. :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 10:13:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 10F7F14BB8; Wed, 14 Jul 1999 10:13:32 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id NAA08162; Wed, 14 Jul 1999 13:11:36 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: <378CAAD9.AAD7268E@newsguy.com> Date: Wed, 14 Jul 1999 13:11:33 -0400 To: "Brian F. Feldman" , "Daniel C. Sobral" From: Garance A Drosihn Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Cc: Matthew Dillon , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 12:00 PM -0400 7/14/99, Brian F. Feldman wrote: > So why don't we do something else: when we're down to a certain > amount of backing store, start collecting statistics. When we're > out, we check the statistics and find what process has been > allocating most of it. We kill that process. Not that I'm really commenting on the above idea (although it does sound fine to me), this reminds me about an earlier thread. Is there any interest in us (BSD's) having a SIGDANGER signal like some other OS's do? That way, key processes (like sshd) could at least make it less likely that THEY are the process which is killed. --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 10:14: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id BF28A14F7D for ; Wed, 14 Jul 1999 10:14:02 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id CAA17011; Thu, 15 Jul 1999 02:10:55 +0900 (JST) Message-ID: <378CC1E0.12A13B6A@newsguy.com> Date: Thu, 15 Jul 1999 01:59:12 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Jason Thorpe Cc: Mike Smith , Ted Faber , Matthew Dillon , hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) References: <199907132327.QAA25268@lestat.nas.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jason Thorpe wrote: > > That's just silly. If people want a no-overcommit system, they have it, > and if they don't, they have that, too. > > That's why you make it a switch. No, really, you *can* just make it > a switch. So, enlighten me, please... how do you switch it in NetBSD? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 10:18:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 40E3414E0A; Wed, 14 Jul 1999 10:18:29 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id NAA45684; Wed, 14 Jul 1999 13:17:18 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <378CAAD9.AAD7268E@newsguy.com> References: <199907132346.TAA13780@bikini.ihack.net> Date: Wed, 14 Jul 1999 13:17:14 -0400 To: "Daniel C. Sobral" From: Garance A Drosihn Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Cc: Matthew Dillon , "Brian F. Feldman" , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote: > In which case the program that consumed all memory will be killed. > The program killed is +NOT+ the one demanding memory, it's the one > with most of it. But that isn't always the best process to have killed off... One of my main freebsd machines is mainly here to run one process, which is a pretty good-sized process (>40meg). If I did get into a memory-shortage problem, I do *not* want that process killed, I'd want some other processes killed. It would be nice to have a way to indicate that, a la SIGDANGER. --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 10:31:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 93A74154A4; Wed, 14 Jul 1999 10:31:46 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id CAA18856; Thu, 15 Jul 1999 02:30:52 +0900 (JST) Message-ID: <378CC473.279E62E@newsguy.com> Date: Thu, 15 Jul 1999 02:10:11 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: "Brian F. Feldman" Cc: freebsd-hackers@FreeBSD.org, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Brian F. Feldman" wrote: > > > In which case the program that consumed all memory will be killed. > > The program killed is +NOT+ the one demanding memory, it's the one > > with most of it. > > So why don't we do something else: when we're down to a certain amount of > backing store, start collecting statistics. When we're out, we check the > statistics and find what process has been allocating most of it. We kill > that process. Because it's not only equally arbitrary but also takes more resources to implement? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 10:34:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by hub.freebsd.org (Postfix) with ESMTP id 634EA14BD8; Wed, 14 Jul 1999 10:34:03 -0700 (PDT) (envelope-from faber@ISI.EDU) Received: from ISI.EDU (vex-e.isi.edu [128.9.160.240]) by boreas.isi.edu (8.8.7/8.8.6) with ESMTP id KAA08910; Wed, 14 Jul 1999 10:33:58 -0700 (PDT) Message-Id: <199907141733.KAA08910@boreas.isi.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: Garance A Drosihn Cc: "Daniel C. Sobral" , Matthew Dillon , "Brian F. Feldman" , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) In-Reply-To: Your message of "Wed, 14 Jul 1999 13:17:14 EDT." X-Url: http://www.isi.edu/~faber Date: Wed, 14 Jul 1999 10:33:58 -0700 From: Ted Faber Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----BEGIN PGP SIGNED MESSAGE----- Garance A Drosihn wrote: >At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote: >> In which case the program that consumed all memory will be killed. >> The program killed is +NOT+ the one demanding memory, it's the one >> with most of it. > >But that isn't always the best process to have killed off... > For every strategy there's a counterstrategy. Killing the biggest is simple to implement and usually right. - ---------------------------------------------------------------------- Ted Faber faber@isi.edu USC/ISI Computer Scientist http://www.isi.edu/~faber (310) 822-1511 x190 PGP Key: http://www.isi.edu/~faber/pubkey.asc -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBN4zKBYb4eisfQ5rpAQFghwQAjKCOA7ubU4NtLrYPO6Nes3pNTtberPSm ssYhHAm3zxV1H/8/elckY+RjYgoFWt9G/SIEgYrVcl62yCpApJmU+0O6PoLcExND CUIPKhUVRdyZsODBF5OrY2i9ITPYm95p/B/EXCtM915UX0iubcNw5iN+9SmCTGk6 ZRW8amrJd/M= =FNnj -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 10:46:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fionn.sports.gov.uk (dns0.sports.gov.uk [195.89.151.148]) by hub.freebsd.org (Postfix) with ESMTP id 3342115470 for ; Wed, 14 Jul 1999 10:46:02 -0700 (PDT) (envelope-from ad@fionn.sports.gov.uk) Received: from [193.61.66.193] (helo=fionn.sports.gov.uk ident=andrewd) by fionn.sports.gov.uk with esmtp (Exim 2.10 #1) id 114T4L-0001jy-00; Wed, 14 Jul 1999 18:43:45 +0100 Message-ID: <378CCCD3.A571BD9B@fionn.sports.gov.uk> Date: Wed, 14 Jul 1999 18:45:55 +0100 From: Andy Doran X-Mailer: Mozilla 4.6 [en-gb] (WinNT; I) X-Accept-Language: en-GB,en,en-* MIME-Version: 1.0 To: wayne@crb-web.com Cc: FreeBSD Hackers List Subject: Re: changing argv[0] after fork() References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wayne Cuddy wrote: > Even though I am developing on FBSD is there a "more portable" way to do this? setproctitle(3) works at least for FreeBSD and NetBSD. Poke around the sources of sendmail(8) for a more ... ported way. I'm sure you'll find something. - ad To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 10:49:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 5067014FC4 for ; Wed, 14 Jul 1999 10:49:44 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id CAA20312; Thu, 15 Jul 1999 02:48:55 +0900 (JST) Message-ID: <378CCB7D.AD8BC57B@newsguy.com> Date: Thu, 15 Jul 1999 02:40:13 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Garance A Drosihn Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907132346.TAA13780@bikini.ihack.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Garance A Drosihn wrote: > > At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote: > > In which case the program that consumed all memory will be killed. > > The program killed is +NOT+ the one demanding memory, it's the one > > with most of it. > > But that isn't always the best process to have killed off... Sure it is. :-) Let's see... > One of my main freebsd machines is mainly here to run one > process, which is a pretty good-sized process (>40meg). If > I did get into a memory-shortage problem, I do *not* want > that process killed, I'd want some other processes killed. Just size your swap so that it becomes unlikely that you run out of memory before a process exceeds 40Mb. And I mean it. I once described in excruciatingly painful details why a number of other techniques would end up being more difficult to implement than the above. If you really want to know, check the archives. The very, *very* least anyone with *real* interest in this thread can do is read the archives on this subject for the past six or seven years. > It would be nice to have a way to indicate that, a la SIGDANGER. Ok, everybody is avoiding this, so I'll comment. Yes, this would be interesting, and a good implementation will very probably be committed. *BUT*, this is not as useful as it seems. Since the correct solution is buy more memory/increase swap (correct solution for our target markets, anyway), there is little incentive to implement it. So, I think people who can answer the above is thinking like "Well, it is useful, but it's not useful enough for me to spend my time on it, and I'm sure as hell don't want to write mini-papers on why it's not that useful". And, for that matter, neither do I. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 10:53:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from vtn1.victoria.tc.ca (vtn1.victoria.tc.ca [199.60.222.3]) by hub.freebsd.org (Postfix) with ESMTP id 841D4153CB for ; Wed, 14 Jul 1999 10:53:36 -0700 (PDT) (envelope-from jnemeth@vtn1.victoria.tc.ca) Received: (from jnemeth@localhost) by vtn1.victoria.tc.ca (8.8.8/8.8.8) id KAA02096; Wed, 14 Jul 1999 10:53:27 -0700 (PDT) Message-Id: <199907141753.KAA02096@vtn1.victoria.tc.ca> From: jnemeth@victoria.tc.ca (John Nemeth) Date: Wed, 14 Jul 1999 10:53:27 -0700 In-Reply-To: "Daniel C. Sobral" "Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))" (Jul 15, 12:20am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Jul 15, 12:20am, "Daniel C. Sobral" wrote: } "Charles M. Hannum" wrote: } > } > That's also objectively false. Most such environments I've had } > experience with are, in fact, multi-user systems. As you've pointed } > out yourself, there is no combination of resource limits and whatnot } > that are guaranteed to prevent `crashing' a multi-user system due to } > overcommit. My simulation should not be axed because of a bug in } > someone else's program. (This is also not hypothetical. There was a } > bug in one version of bash that caused it to consume all the memory it } > could and then fall over.) } } In which case the program that consumed all memory will be killed. } The program killed is +NOT+ the one demanding memory, it's the one } with most of it. On one system I administrate, the largest process is typically rpc.nisd (the NIS+ server daemon). Killing that process would be a bad thing (TM). You're talking about killing random processes. This is no way to run a system. It is not possible for any arbitrary decision to always hit the correct process. That is a decision that must be made by a competent admin. This is the biggest argument against overcommit: there is no way to gracefully recover from an out of memory situation, and that makes for an unreliable system. }-- End of excerpt from "Daniel C. Sobral" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 10:56:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from orthanc.ab.ca (orthanc.ab.ca [207.167.3.130]) by hub.freebsd.org (Postfix) with ESMTP id 1554015146 for ; Wed, 14 Jul 1999 10:56:31 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (localhost.orthanc.ab.ca [127.0.0.1] (may be forged)) by orthanc.ab.ca (8.9.3/8.9.3) with ESMTP id LAA05231 for ; Wed, 14 Jul 1999 11:55:04 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <199907141755.LAA05231@orthanc.ab.ca> To: freebsd-hackers@freebsd.org Subject: Re: Replacement for grep(1) (part 2) In-reply-to: Your message of "Tue, 13 Jul 1999 14:09:56 PDT." <199907132109.OAA80706@apollo.backplane.com> Date: Wed, 14 Jul 1999 11:55:03 -0600 From: lyndon@orthanc.ab.ca Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I mean, jeeze, the reservation for the program stack alone would eat > up all your available swap space! What is a reasonable stack size? The > system defaults to 8MB. Do we rewrite every program to specify its own > stack size? How do we account for architectural differences? The alternative is to rewrite every program that assumes the semantics of malloc() are being followed. The problem I have as an applications writer is that I tend to believe malloc. To pick a specific example, our IMAP client takes steps to ensure it won't run out of memory in critical sections. We maintain a "rainy day" pool block of memory. If we receive a NULL from malloc, we 1) free up whatever memory we can in other parts of the client (possibly using the rainy day pool to stage data out to disk), and 2) if necessary, reduce the size of the rainy day pool. This whole design is predicated on malloc() telling the truth. If instead it gives us a bogus block of memory, then seg faults when we try to use it, the best we can do is try to shut down without losing any of the users mail (and in fact we don't even do that, since there are just too many places where this can happen in third-party libraries that we aren't willing to rewrite). Sending us a kill signal is even worse. (And extremely unfair, since we take pains to not waste memory in the first place.) Has anyone analyzed all those applications people talk about that show huge allocation footprints but don't actually use the memory? That represents the code that needs to be fixed. Breaking malloc() is not a suitable response IMO. As a data point, we routinely disable overcommit on our SGI machines and it doesn't hurt us one bit. And we aren't allocating gigabytes of swap space, either. --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 11: 5:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 4B9F114D1C for ; Wed, 14 Jul 1999 11:05:28 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 114TOW-000GYY-00; Wed, 14 Jul 1999 20:04:36 +0200 From: Sheldon Hearn To: wayne@crb-web.com Cc: Andy Doran , FreeBSD Hackers List Subject: Re: changing argv[0] after fork() In-reply-to: Your message of "Wed, 14 Jul 1999 13:28:07 -0400." Date: Wed, 14 Jul 1999 20:04:36 +0200 Message-ID: <63645.931975476@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 14 Jul 1999 13:28:07 -0400, Wayne Cuddy wrote: > Even though I am developing on FBSD is there a "more portable" way to > do this? See the STANDARDS section of the setproctitle(3) manpage. If you worry that you may port to an operating system whose setproctitle() has a different calling convention, then stick to manipulating argv[0]. If your only concern is whether setproctitle() will be present on other systems, you'll probably want an #ifdef SETPROCTITLE. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 11: 8:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id EA46214C15; Wed, 14 Jul 1999 11:08:21 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id OAA25906; Wed, 14 Jul 1999 14:06:24 -0400 (EDT) Date: Wed, 14 Jul 1999 14:06:24 -0400 (EDT) From: Daniel Eischen Message-Id: <199907141806.OAA25906@pcnet1.pcnet.com> To: hackers@FreeBSD.ORG, kip@lyris.com, stable@FreeBSD.ORG Subject: Re: seg fault in mutex_queue_enq Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Can someone familiar with the new threads code tell me what is causing the > following segmentation fault. Thanks. > > -Kip > > > Program terminated with signal 11, Segmentation fault. > #0 0x82fb15d in mutex_queue_enq (mutex=0x83c3a54, pthread=0x8594e00) > at /usr/src/lib/libc_r/uthread/uthread_mutex.c:1281 > 1281 > PTHREAD_PRIOQ_INSERT_HEAD(pthread); > (gdb) bt > #0 0x82fb15d in mutex_queue_enq (mutex=0x83c3a54, pthread=0x8594e00) > at /usr/src/lib/libc_r/uthread/uthread_mutex.c:1281 > #1 0x82f9edd in pthread_mutex_lock (mutex=0x83c3ad4) > at /usr/src/lib/libc_r/uthread/uthread_mutex.c:387 I take it you're running -stable without any mods to the threads library, right? There are some bugs in libc_r in stable that have been fixed in -current. I think the one that you've hit is an uninitialized TAILQ_HEAD in a statically declared mutex (in localtime). It's probably about time for a MFC. If someone wants to give me the go-ahead, I can do it... In the mean time, you can grab libc_r/uthread/* from -current and rebuild libc_r under -stable. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 11: 9: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id BAA9E14D1C for ; Wed, 14 Jul 1999 11:08:55 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id LAA31669; Wed, 14 Jul 1999 11:07:30 -0700 (PDT) Date: Wed, 14 Jul 1999 11:07:29 -0700 (PDT) From: Julian Elischer To: lyndon@orthanc.ab.ca Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <199907141755.LAA05231@orthanc.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG If you wanted to fix this, you could add a patch to malloc that touched every page that it handed to the application. (and trapped sig11s) On Wed, 14 Jul 1999 lyndon@orthanc.ab.ca wrote: > > > I mean, jeeze, the reservation for the program stack alone would eat > > up all your available swap space! What is a reasonable stack size? The > > system defaults to 8MB. Do we rewrite every program to specify its own > > stack size? How do we account for architectural differences? > > The alternative is to rewrite every program that assumes the semantics > of malloc() are being followed. The problem I have as an applications > writer is that I tend to believe malloc. To pick a specific example, > our IMAP client takes steps to ensure it won't run out of memory in > critical sections. We maintain a "rainy day" pool block of memory. If > we receive a NULL from malloc, we 1) free up whatever memory we can > in other parts of the client (possibly using the rainy day pool to > stage data out to disk), and 2) if necessary, reduce the size of the > rainy day pool. This whole design is predicated on malloc() telling > the truth. If instead it gives us a bogus block of memory, then > seg faults when we try to use it, the best we can do is try to shut > down without losing any of the users mail (and in fact we don't > even do that, since there are just too many places where this can > happen in third-party libraries that we aren't willing to rewrite). > Sending us a kill signal is even worse. (And extremely unfair, since > we take pains to not waste memory in the first place.) > > Has anyone analyzed all those applications people talk about that > show huge allocation footprints but don't actually use the memory? > That represents the code that needs to be fixed. Breaking malloc() > is not a suitable response IMO. > > As a data point, we routinely disable overcommit on our SGI machines > and it doesn't hurt us one bit. And we aren't allocating gigabytes > of swap space, either. > > --lyndon > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 11:11:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id C33C615430; Wed, 14 Jul 1999 11:11:30 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from localhost (doug@localhost) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id LAA27109; Wed, 14 Jul 1999 11:11:16 -0700 (PDT) (envelope-from Doug@gorean.org) Date: Wed, 14 Jul 1999 11:11:16 -0700 (PDT) From: Doug X-Sender: doug@dt054n86.san.rr.com To: Garance A Drosihn Cc: "Brian F. Feldman" , Sheldon Hearn , hackers@FreeBSD.ORG Subject: Re: a BSD identd In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 14 Jul 1999, Garance A Drosihn wrote: > At 11:47 PM -0400 7/13/99, Brian F. Feldman wrote: > > We don't _need_ pidentd anymore. It will load down a system more > > than the inetd's implementation of ident will. Therefore, pidentd > > should be phased out. Other than that, pidentd should be using > > http://www.FreeBSD.org/~green/freebsd4.c and not linking with > > libkvm. > > I am not sure I understand what you are saying. pident is currently > a port, under 'security'. I can understand the idea that maybe it > should be under 'net' instead (in fact, that's where I first looked > for it when I went to install it on my machine). I agree that it shouldn't be under security, but if we move it now there will be a lot of complaining from the people who already know where it is. Not that that is necessarily a bad thing, but there you have it. As for the rest of it, you've wandered into the middle of a fairly silly argument. One camp says, "We don't need to have a built-in FreeBSD version of ident because we have a port of it available to those who need it." The other camp seems to be saying get rid of the port, but what they are really saying is that, "The current ident options all suck, so it would be nice to have a freebsd version that we know will work, and once we have that then people won't need the port, but they can install it if they want to." Frankly I don't see why we're still discussing this, but then again, I do. Hope this helps, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 11:19:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id DF355153FC for ; Wed, 14 Jul 1999 11:19:19 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id OAA05736; Wed, 14 Jul 1999 14:19:01 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: <378C98CB.E41232CA@fionn.sports.gov.uk> Date: Wed, 14 Jul 1999 14:19:00 -0400 To: wayne@crb-web.com From: Garance A Drosihn Subject: Re: changing argv[0] after fork() Cc: FreeBSD Hackers List Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 1:28 PM -0400 7/14/99, Wayne Cuddy wrote: > Even though I am developing on FBSD is there a "more portable" way > to do this? The man page for setproctitle(3) notes that none of the ways to do this are necessarily portable to other systems. That said, I have a routine from a lambdaMOO program which patches the command string, and apparently works on several different unix platforms. On the other hand, I just recently patched that routine so it would "work better" under FreeBSD, as what it was doing wasn't quite ideal. I could point you at that if you're interested. It does make sense that for any platform which DOES have a setproctitle, you should use that instead of other tricks. --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 11:24: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xroads.vthrc.uq.edu.au (xroads.vthrc.uq.edu.au [130.102.4.16]) by hub.freebsd.org (Postfix) with ESMTP id C198715421 for ; Wed, 14 Jul 1999 11:23:58 -0700 (PDT) (envelope-from D.Thomas@vthrc.uq.edu.au) Received: (from fwtk@localhost) by xroads.vthrc.uq.edu.au (8.8.6/8.8.6) id EAA01072; Thu, 15 Jul 1999 04:22:48 +1000 (EST) Received: from d-thomas-mac.vthrc.uq.edu.au(130.102.4.80) by xroads.vthrc.uq.edu.au via smap (V1.3) id sma001070; Thu Jul 15 04:22:31 1999 X-Sender: Vthomas@130.102.4.16 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 Jul 1999 04:22:31 +1000 To: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org From: D.Thomas@vthrc.uq.edu.au (Danny Thomas) Subject: Re: Swap overcommit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ted Faber >For every strategy there's a counterstrategy. exactly: the disappointing thing about this whole thread is there's been little discussion of implementing a (tunable) policy how to handle the situation when resource shortage materialises. Overcommitment can be useful, maybe even for most people... >Killing the biggest is simple to implement and usually right. ... but some people don't want that policy, at least on some of their systems. Does FreeBSD offer alternatives? Is so, they've been conspicuously absent from discussion, which might have taken things into a more productive vein. What do other over-committing systems offer? Danny Thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 11:24:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from luna.lyris.net (luna.shelby.com [207.90.155.6]) by hub.freebsd.org (Postfix) with ESMTP id 6981A1542B; Wed, 14 Jul 1999 11:24:22 -0700 (PDT) (envelope-from kip@lyris.com) Received: from luna.shelby.com by luna.lyris.net (8.9.1b+Sun/SMI-SVR4) id LAA22351; Wed, 14 Jul 1999 11:22:57 -0700 (PDT) Received: from (luna.shelby.com [207.90.155.6]) by luna.shelby.com with SMTP (MailShield v1.50); Wed, 14 Jul 1999 11:22:57 -0700 Date: Wed, 14 Jul 1999 11:22:56 -0700 (PDT) From: Kip Macy X-Sender: kip@luna To: Daniel Eischen Cc: hackers@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: seg fault in mutex_queue_enq In-Reply-To: <199907141806.OAA25906@pcnet1.pcnet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: luna X-SMTP-MAIL-FROM: kip@lyris.com X-SMTP-RCPT-TO: eischen@vigrid.com,hackers@FreeBSD.ORG,stable@FreeBSD.ORG X-SMTP-PEER-INFO: luna.shelby.com [207.90.155.6] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 14 Jul 1999, Daniel Eischen wrote: > > Can someone familiar with the new threads code tell me what is causing the > > following segmentation fault. Thanks. > > > > -Kip > > > > > > Program terminated with signal 11, Segmentation fault. > > #0 0x82fb15d in mutex_queue_enq (mutex=0x83c3a54, pthread=0x8594e00) > > at /usr/src/lib/libc_r/uthread/uthread_mutex.c:1281 > > 1281 > > PTHREAD_PRIOQ_INSERT_HEAD(pthread); > > (gdb) bt > > #0 0x82fb15d in mutex_queue_enq (mutex=0x83c3a54, pthread=0x8594e00) > > at /usr/src/lib/libc_r/uthread/uthread_mutex.c:1281 > > #1 0x82f9edd in pthread_mutex_lock (mutex=0x83c3ad4) > > at /usr/src/lib/libc_r/uthread/uthread_mutex.c:387 > > I take it you're running -stable without any mods to the threads > library, right? > > There are some bugs in libc_r in stable that have been fixed in > -current. I think the one that you've hit is an uninitialized > TAILQ_HEAD in a statically declared mutex (in localtime). It's > probably about time for a MFC. If someone wants to give me the > go-ahead, I can do it... > > In the mean time, you can grab libc_r/uthread/* from -current > and rebuild libc_r under -stable. Yes, I am running -stable. I did upgrade my libc_r a few weeks ago as a result of a problem with infinite recursion in write. When was this bug fixed? Thanks. -Kip > > Dan Eischen > eischen@vigrid.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 11:33: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from orthanc.ab.ca (orthanc.ab.ca [207.167.3.130]) by hub.freebsd.org (Postfix) with ESMTP id B609415421; Wed, 14 Jul 1999 11:33:01 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (localhost.orthanc.ab.ca [127.0.0.1] (may be forged)) by orthanc.ab.ca (8.9.3/8.9.3) with ESMTP id MAA05320; Wed, 14 Jul 1999 12:33:01 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <199907141833.MAA05320@orthanc.ab.ca> To: "Brian F. Feldman" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) In-reply-to: Your message of "Wed, 14 Jul 1999 12:00:55 EDT." Date: Wed, 14 Jul 1999 12:33:00 -0600 From: lyndon@orthanc.ab.ca Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > So why don't we do something else: when we're down to a certain amount of > backing store, start collecting statistics. When we're out, we check the > statistics and find what process has been allocating most of it. We kill > that process. Our IMAP server routinely show a footprint of about 1MB private storage. This is constant for most operations. However, when you get into doing SEARCH and SORT, there are certain cases where we need memory, sometimes a *lot* of memory. Your proposal is that my *well behaved* application should be arbitrarily killed, leaving the client stuck with a) no results and b) no IMAP connection, in this situation. (And think threaded. That one server could be handling *hundreds* of clients.) This is preferable to returning a NULL to the malloc() request, which I can handle gracefully by simply returning a NO response to the IMAP client? What it so evil about having a reasonably intelligent malloc() that tells the truth, and returns unused memory to the system? Overcommit is for lazy programmers, plain and simple. At least the SGI documentation about overcommit admits that (or at least, did at one time). --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 11:40:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from luna.lyris.net (luna.shelby.com [207.90.155.6]) by hub.freebsd.org (Postfix) with ESMTP id 6940D15432; Wed, 14 Jul 1999 11:40:10 -0700 (PDT) (envelope-from kip@lyris.com) Received: from luna.shelby.com by luna.lyris.net (8.9.1b+Sun/SMI-SVR4) id LAA22469; Wed, 14 Jul 1999 11:39:27 -0700 (PDT) Received: from (luna.shelby.com [207.90.155.6]) by luna.shelby.com with SMTP (MailShield v1.50); Wed, 14 Jul 1999 11:39:27 -0700 Date: Wed, 14 Jul 1999 11:39:27 -0700 (PDT) From: Kip Macy X-Sender: kip@luna To: Daniel Eischen Cc: hackers@FreeBSD.ORG, stable@FreeBSD.ORG Subject: new seg fault in thread code In-Reply-To: <199907141806.OAA25906@pcnet1.pcnet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: luna X-SMTP-MAIL-FROM: kip@lyris.com X-SMTP-RCPT-TO: eischen@vigrid.com,hackers@FreeBSD.ORG,stable@FreeBSD.ORG X-SMTP-PEER-INFO: luna.shelby.com [207.90.155.6] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I just rebuilt libc_r and relinked my application. I am now crashing right away as opposed to after several hours as I have been. Program terminated with signal 11, Segmentation fault. #0 0x82fa07c in _thread_kern_sched_state_unlock () (gdb) bt #0 0x82fa07c in _thread_kern_sched_state_unlock () #1 0x82f9891 in _thread_kern_sched () #2 0x82f9d21 in _thread_kern_sched_state () #3 0x8307ee3 in nanosleep (time_to_sleep=0xbfbfd2d4, time_remaining=0xbfbfd2cc) at /usr/src/lib/libc_r/uthread/uthread_nanosleep.c:72 #4 0x8307b9e in sleep (seconds=1) at /usr/src/lib/libc_r/../libc/gen/sleep.c:63 #5 0x8285598 in os_this_thread::sleep (seconds_=1) at thisthrd.cpp:712 #6 0x825bce5 in lyris_CodeBase_Table::open (this=0x85bcd00, Exclusive=false) at cbtable3.cpp:588 #7 0x82342f0 in lyris_Table::open (this=0xbfbfd538, Exclusive=false) at table.cpp:1004 #8 0x8048f9f in lyris_Config::open (this=0xbfbfd4fc, Exclusive=false) at config.cpp:257 #9 0x8048221 in lyris_Config::lyris_Config (this=0xbfbfd4fc) at config.cpp:52 #10 0x814be41 in lyris_CommandLine::RunCommandLine (this=0x85adc90, InArguments=@0xbfbfd788) at lyrcline.cpp:682 #11 0x8160e83 in main (argc=4, argv=0xbfbfd808) at lyrmain.cpp:59 On Wed, 14 Jul 1999, Daniel Eischen wrote: > > Can someone familiar with the new threads code tell me what is causing the > > following segmentation fault. Thanks. > > > > -Kip > > > > > > Program terminated with signal 11, Segmentation fault. > > #0 0x82fb15d in mutex_queue_enq (mutex=0x83c3a54, pthread=0x8594e00) > > at /usr/src/lib/libc_r/uthread/uthread_mutex.c:1281 > > 1281 > > PTHREAD_PRIOQ_INSERT_HEAD(pthread); > > (gdb) bt > > #0 0x82fb15d in mutex_queue_enq (mutex=0x83c3a54, pthread=0x8594e00) > > at /usr/src/lib/libc_r/uthread/uthread_mutex.c:1281 > > #1 0x82f9edd in pthread_mutex_lock (mutex=0x83c3ad4) > > at /usr/src/lib/libc_r/uthread/uthread_mutex.c:387 > > I take it you're running -stable without any mods to the threads > library, right? > > There are some bugs in libc_r in stable that have been fixed in > -current. I think the one that you've hit is an uninitialized > TAILQ_HEAD in a statically declared mutex (in localtime). It's > probably about time for a MFC. If someone wants to give me the > go-ahead, I can do it... > > In the mean time, you can grab libc_r/uthread/* from -current > and rebuild libc_r under -stable. > > Dan Eischen > eischen@vigrid.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 11:42:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id CB3AD14CC0 for ; Wed, 14 Jul 1999 11:42:52 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id OAA13017; Wed, 14 Jul 1999 14:41:13 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Wed, 14 Jul 1999 14:41:12 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: lyndon@orthanc.ab.ca Cc: freebsd-hackers@FreeBSD.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) In-Reply-To: <199907141833.MAA05320@orthanc.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You don't seem to understand that a runaway process/one designed just to take up memory will be much more active than your little IMAP servers, and be the one killed, if this scheme were used. Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 11:44:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 3DEE4154DD; Wed, 14 Jul 1999 11:44:05 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id OAA00851; Wed, 14 Jul 1999 14:42:33 -0400 (EDT) Date: Wed, 14 Jul 1999 14:42:33 -0400 (EDT) From: Daniel Eischen Message-Id: <199907141842.OAA00851@pcnet1.pcnet.com> To: eischen@vigrid.com, kip@lyris.com Subject: Re: seg fault in mutex_queue_enq Cc: hackers@FreeBSD.ORG, stable@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kip Macy wrote: > > In the mean time, you can grab libc_r/uthread/* from -current > > and rebuild libc_r under -stable. > > Yes, I am running -stable. I did upgrade my libc_r a few weeks ago as a > result of a problem with infinite recursion in write. When was this bug > fixed? The fix for static initialization of mutexes went into -current on May 23. Other changes went in June 20th. You can check the logs for more details (http://www.freebsd.org/cgi/cvsweb.cgi). Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 11:44:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from orthanc.ab.ca (orthanc.ab.ca [207.167.3.130]) by hub.freebsd.org (Postfix) with ESMTP id 851D914CC0; Wed, 14 Jul 1999 11:44:31 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (localhost.orthanc.ab.ca [127.0.0.1] (may be forged)) by orthanc.ab.ca (8.9.3/8.9.3) with ESMTP id MAA05368; Wed, 14 Jul 1999 12:44:01 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <199907141844.MAA05368@orthanc.ab.ca> To: "Brian F. Feldman" Cc: freebsd-hackers@FreeBSD.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) In-reply-to: Your message of "Wed, 14 Jul 1999 14:41:12 EDT." Date: Wed, 14 Jul 1999 12:44:01 -0600 From: lyndon@orthanc.ab.ca Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > You don't seem to understand that a runaway process/one designed just > to take up memory will be much more active than your little IMAP servers, > and be the one killed, if this scheme were used. No, what I don't understand is how the current behaviour can tell that my temporary and *valid* need for a large chunk of memory does not make me a runaway process, and therefore subject to death. --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 11:51:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id F01C61543D; Wed, 14 Jul 1999 11:51:06 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id OAA01714; Wed, 14 Jul 1999 14:49:44 -0400 (EDT) Date: Wed, 14 Jul 1999 14:49:44 -0400 (EDT) From: Daniel Eischen Message-Id: <199907141849.OAA01714@pcnet1.pcnet.com> To: eischen@vigrid.com, kip@lyris.com Subject: Re: new seg fault in thread code Cc: hackers@FreeBSD.ORG, stable@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kip Macy wrote: > I just rebuilt libc_r and relinked my application. I am now crashing right > away as opposed to after several hours as I have been. > > Program terminated with signal 11, Segmentation fault. > #0 0x82fa07c in _thread_kern_sched_state_unlock () > (gdb) bt > #0 0x82fa07c in _thread_kern_sched_state_unlock () > #1 0x82f9891 in _thread_kern_sched () > #2 0x82f9d21 in _thread_kern_sched_state () > #3 0x8307ee3 in nanosleep (time_to_sleep=0xbfbfd2d4, > time_remaining=0xbfbfd2cc) > at /usr/src/lib/libc_r/uthread/uthread_nanosleep.c:72 > #4 0x8307b9e in sleep (seconds=1) > at /usr/src/lib/libc_r/../libc/gen/sleep.c:63 > #5 0x8285598 in os_this_thread::sleep (seconds_=1) at thisthrd.cpp:712 > #6 0x825bce5 in lyris_CodeBase_Table::open (this=0x85bcd00, > Exclusive=false) > at cbtable3.cpp:588 > #7 0x82342f0 in lyris_Table::open (this=0xbfbfd538, Exclusive=false) > at table.cpp:1004 > #8 0x8048f9f in lyris_Config::open (this=0xbfbfd4fc, Exclusive=false) > at config.cpp:257 > #9 0x8048221 in lyris_Config::lyris_Config (this=0xbfbfd4fc) at > config.cpp:52 > #10 0x814be41 in lyris_CommandLine::RunCommandLine (this=0x85adc90, > InArguments=@0xbfbfd788) at lyrcline.cpp:682 > #11 0x8160e83 in main (argc=4, argv=0xbfbfd808) at lyrmain.cpp:59 Great, now it should be easy to reproduce! Can you send me something to reproduce it? Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 11:51:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from nothing-going-on.demon.co.uk (nothing-going-on.demon.co.uk [193.237.89.66]) by hub.freebsd.org (Postfix) with ESMTP id E7B52157BC for ; Wed, 14 Jul 1999 11:51:20 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.9.3/8.9.2) id BAA09253; Wed, 14 Jul 1999 01:04:57 +0100 (BST) (envelope-from nik) Date: Wed, 14 Jul 1999 01:04:56 +0100 From: Nik Clayton To: Julian Elischer Cc: Karl Pielorz , crypt0genic , hackers@FreeBSD.ORG Subject: Re: (forw) Message-ID: <19990714010456.A7434@catkin.nothing-going-on.org> References: <3789D346.5682D28A@tdx.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Julian Elischer on Mon, Jul 12, 1999 at 01:22:49PM -0700 Organization: Nik at home, where there's nothing going on Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 12, 1999 at 01:22:49PM -0700, Julian Elischer wrote: < talking about the recent paper on using KLDs to replace FreeBSD syscalls > > I would suggest that a version of this document be incorporated into our > docs. I've already e-mailed the people concerned to ask. I'll let you know what I get back. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <375143b5@cs.colorado.edu> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 12:21: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 19CC51542E for ; Wed, 14 Jul 1999 12:20:55 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id PAA59110; Wed, 14 Jul 1999 15:20:21 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <378CCB7D.AD8BC57B@newsguy.com> References: <199907132346.TAA13780@bikini.ihack.net> Date: Wed, 14 Jul 1999 15:20:19 -0400 To: "Daniel C. Sobral" From: Garance A Drosihn Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 2:40 AM +0900 7/15/99, Daniel C. Sobral wrote: >Garance A Drosihn wrote: >> >> At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote: >> > In which case the program that consumed all memory will be killed. >> > The program killed is +NOT+ the one demanding memory, it's the one >> > with most of it. >> >> But that isn't always the best process to have killed off... > >Sure it is. :-) Let's see... > >> One of my main freebsd machines is mainly here to run one >> process, which is a pretty good-sized process (>40meg). If >> I did get into a memory-shortage problem, I do *not* want >> that process killed, I'd want some other processes killed. > > Just size your swap so that it becomes unlikely that you run out of > memory before a process exceeds 40Mb. > > And I mean it. For the moment I'll pretend that you honestly think that is an answer, and I'll note that the very same machine may have well over 100 processes each of which takes 1-2 meg of memory. If the machine hits a really-out-of-memory error, I would be much much happier to see all 100+ of those processes killed, at once, than the one 40-meg process. Now tell me how I fix my swap under those circumstances. If the answer is "buy infinite memory (ram or disk)", then we don't need any overcommit policy in the first place. Note that the problem might be that these 100 processes start taking up 5 or 10 meg than the 2 meg I'm used to. > I once described in excruciatingly painful details why a number of > other techniques would end up being more difficult to implement than > the above. If you really want to know, check the archives. The very, > *very* least anyone with *real* interest in this thread can do is > read the archives on this subject for the past six or seven years. I once participated in a discussion on this very list where people would discuss SIGDANGER with some degree of intelligence, instead of offhand smart-aleck remarks. That discussion (as I remember) ended with the conclusion that "SIGDANGER can be useful, but there's a fair amount of work to do first". My comment was actually meant as a follow-up to that earlier discussion, just to see if anything had happened to get us closer to this. (as I remember, the first hurdle was something to do with supporting more signal-types). I didn't mean to be casting asperisions on the general idea of overcommitting, or whatever it is that has your shorts all tied up in a knot. --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 12:29:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 6055C14D13 for ; Wed, 14 Jul 1999 12:29:31 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id UAA45182; Wed, 14 Jul 1999 20:29:44 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Wed, 14 Jul 1999 20:29:44 +0100 (BST) From: Doug Rabson To: "Chris G. Demetriou" Cc: Jon Ribbens , Alfred Perlstein , "Daniel C. Sobral" , freebsd-hackers@freebsd.org, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <87oghfz278.fsf@redmail.redback.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 14 Jul 1999, Chris G. Demetriou wrote: > Doug Rabson writes: > > Overcommit can be used for many reasons. I use it to reserve a large > > linear address space to mmap alpha i/o spaces [...] > > Overcommit can be used for many reasons, but unless you've > misdescribed what you're doing, _that's not one of them_. > > The mapped I/O pages need no backing store to be allocated for them by > the VM system. They're backed by hardware. > > And if you have 'placeholder' pages (I note that you didn't say you > mmap all of alpha i/o space, just reserve a large linear address space > in which to mmap it), then it should be possible to map them in such a > way (e.g. read-only ZFOD) in which they wouldn't count against backing > store requirements, either. I certainly don't need or want backing store for these pages. The original reserved region is never touched without first mapping device pages onto it. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 12:38:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from orthanc.ab.ca (orthanc.ab.ca [207.167.3.130]) by hub.freebsd.org (Postfix) with ESMTP id 535D414D13; Wed, 14 Jul 1999 12:38:23 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (localhost.orthanc.ab.ca [127.0.0.1] (may be forged)) by orthanc.ab.ca (8.9.3/8.9.3) with ESMTP id NAA05484; Wed, 14 Jul 1999 13:38:16 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <199907141938.NAA05484@orthanc.ab.ca> To: Ben Rosengart Cc: "Brian F. Feldman" , freebsd-hackers@FreeBSD.ORG Subject: Re: Swap overcommit In-reply-to: Your message of "Wed, 14 Jul 1999 19:02:00 -0000." Date: Wed, 14 Jul 1999 13:38:16 -0600 From: lyndon@orthanc.ab.ca Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > What you don't understand is that no process is going to die unless either > someone is running away (in which case they'll get the bullet) or your > system is horribly misconfigured (in which case you deserve your fate). *Why* the machine is out of memory is not the issue. The issue is what happens when you run out (whether due to stupidity in configuration or otherwise). All of the arguments I've seen so far assume that one process is running off and grabbing all the available memory. That may be the most likely scenario, but it's most certainly not the *only* scenario. What if you have a whole bunch of "middle sized" processes running, all using memory efficiently, but in total using 95% of the available VM. A malloc(5*1024*1024) might work, but I need 10 MB instead of 5MB. And my memory footprint is just a little bit bigger than the other guys. Instead of returning NULL to the malloc() request, *zap* I'm dead. How can you possibly call that sensible behaviour? Yes, the machine is under-resourced. I can't help that -- it's not my machine. The machine belongs to a customer who happens to run my IMAP software, who also happens to have ignored our sizing guidelines. In this situation I have no choice but to deal with the low memory condition, and our code does that, if it's given the chance! At least give me the opportunity to deal with the situation gracefully. What if we decided to defer errors from bind just because there weren't any mbufs available, and later killed the process when it tried to do network I/O? People would howl bloody murder! (<== this is rhetorical, folks) The semantics of malloc() have been defined since almost the dawn of time. From the current manpage: RETURN VALUES The malloc() and calloc() functions return a pointer to the allocated memory if successful; otherwise a NULL pointer is returned. Nowhere does it say that allocated memory might not exist. Nowhere does it say that I have to touch all the allocated pages to make sure they are really there. Nowhere does it say process death at some non-deterministic time in the future might be a side effect of calling malloc(). Applications are written assuming that malloc() behaves in the documented manner. It is *not* acceptable to tell applications writers that they have to provide their own management routines on top of malloc() (SEGV catchers and the like) if they want the long standing semantics of malloc() to be preserved. If the current malloc() cannot behave in the documented and expected manner it needs to be renamed, because malloc() it most certainly isn't. --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 12:38:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail5.svr.pol.co.uk (mail5.svr.pol.co.uk [195.92.193.20]) by hub.freebsd.org (Postfix) with ESMTP id C72F815434; Wed, 14 Jul 1999 12:38:25 -0700 (PDT) (envelope-from s.mitchell@computer.org) Received: from modem-22.neodymium.dialup.pol.co.uk ([62.136.29.150] helo=valis.goatsucker.org) by mail5.svr.pol.co.uk with esmtp (Exim 2.12 #1) id 114UrH-0005UR-00; Wed, 14 Jul 1999 20:38:23 +0100 Received: (from scott@localhost) by valis.goatsucker.org (8.8.8/8.8.7) id SAA04692; Wed, 14 Jul 1999 18:51:01 +0100 (BST) (envelope-from scott) Message-ID: <19990714185101.09845@goatsucker.org> Date: Wed, 14 Jul 1999 18:51:01 +0100 From: Scott Mitchell To: obrien@NUXI.com, imp@village.org, ade@lovett.com, phk@freebsd.org Cc: freebsd-xircom@lovett.com, hackers@FreeBSD.ORG, mobile@FreeBSD.ORG Subject: Re: Reading CIS from kernel? References: <19990713182203.A68393@nuxi.com> <19990710162730.60563@goatsucker.org> <19990713182203.A68393@nuxi.com> <199907140652.AAA53151@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <199907140652.AAA53151@harmony.village.org>; from Warner Losh on Wed, Jul 14, 1999 at 12:52:38AM -0600 X-Operating-System: FreeBSD 2.2.6-RELEASE i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jul 14, 1999 at 12:52:38AM -0600, Warner Losh wrote: > In message <19990713182203.A68393@nuxi.com> "David O'Brien" writes: > : Since no one has repsonded to this querry, I will be un-staticizing these > : so they will be available to drivers. > > No. Please don't. This is the first I've seen this. There will be > another cis reading interface as part of the newbusification of pccard > stuff and I'd rather not have to fix any more drivers than I have to. > I wish I had seen it sooner. The Xircom driver is one of the ones > that my first attempt at newbusification would have broken... > > Warner > Ugh. In that case, can someone back out Poul-Henning's changes to the if_xe.c in the -STABLE tree? That's (I hope) the only thing stopping it from working. At least that way only my code will be bogus :-) Believe me, I know it's ugly, but there's no getting around the fact that the driver needs to read the CIS, and right now there's no clean way to do that in -STABLE (is there?). Scott -- =========================================================================== Scott Mitchell | PGP Key ID | "Eagles may soar, but weasels London, England | 0x54B171B9 | don't get sucked into jet engines" s.mitchell@computer.org | 0xAA775B8B | -- Anon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 12:45: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from border.dreamworks.com (dreamworks.com [209.179.64.2]) by hub.freebsd.org (Postfix) with SMTP id 0F52214D13 for ; Wed, 14 Jul 1999 12:44:52 -0700 (PDT) (envelope-from abs@anim.dreamworks.com) Received: from cynic.anim.dreamworks.com by border.dreamworks.com via smtpd (for hub.FreeBSD.ORG [204.216.27.18]) with SMTP; 14 Jul 1999 19:44:52 UT Received: from localhost (abs@localhost) by cynic.anim.dreamworks.com (8.8.8+Sun/8.8.8) with ESMTP id MAA25420; Wed, 14 Jul 1999 12:40:32 -0700 (PDT) X-Authentication-Warning: cynic.anim.dreamworks.com: abs owned process doing -bs Date: Wed, 14 Jul 1999 12:40:32 -0700 (PDT) From: David Brownlee To: "Daniel C. Sobral" Cc: Matthew Dillon , Jason Thorpe , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <378CC0FF.67EFAFCC@newsguy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Jul 1999, Daniel C. Sobral wrote: > For the record, professional digital cameras go into the $100K > range, so I'd be expecting it not only to run Apache, but also to > come with Doom. :-) Well you have 16MB RAM, 32MB flash memory, a network interface, other bits and NetBSD for ~ $1600. Find yourself a remote display and fire up your compiler :) http://www.brains.co.jp/mmeye/index-e.html David/absolute -=- "Just adding to the wrinkles on his deathly frown" -=- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 12:49:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id AF9A214D13; Wed, 14 Jul 1999 12:49:53 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id VAA30374; Wed, 14 Jul 1999 21:47:48 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Scott Mitchell Cc: obrien@NUXI.com, imp@village.org, ade@lovett.com, freebsd-xircom@lovett.com, hackers@freebsd.org, mobile@freebsd.org Subject: Re: Reading CIS from kernel? In-reply-to: Your message of "Wed, 14 Jul 1999 18:51:01 BST." <19990714185101.09845@goatsucker.org> Date: Wed, 14 Jul 1999 21:47:48 +0200 Message-ID: <30372.931981668@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19990714185101.09845@goatsucker.org>, Scott Mitchell writes: >Ugh. In that case, can someone back out Poul-Henning's changes to the >if_xe.c in the -STABLE tree? Uhm my change has not been applied to STABLE, but the 3.2-PAO import references current rather than stable. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 12:50:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from vtn1.victoria.tc.ca (vtn1.victoria.tc.ca [199.60.222.3]) by hub.freebsd.org (Postfix) with ESMTP id 010A51548B for ; Wed, 14 Jul 1999 12:50:02 -0700 (PDT) (envelope-from jnemeth@vtn1.victoria.tc.ca) Received: (from jnemeth@localhost) by vtn1.victoria.tc.ca (8.8.8/8.8.8) id MAA11413; Wed, 14 Jul 1999 12:49:45 -0700 (PDT) Message-Id: <199907141949.MAA11413@vtn1.victoria.tc.ca> From: jnemeth@victoria.tc.ca (John Nemeth) Date: Wed, 14 Jul 1999 12:49:45 -0700 In-Reply-To: "Daniel C. Sobral" "Re: Replacement for grep(1) (part 2)" (Jul 15, 12:53am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Daniel C. Sobral" Subject: Re: Replacement for grep(1) (part 2) Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Jul 15, 12:53am, "Daniel C. Sobral" wrote: } Robert Elz wrote: } > } > From: Matthew Dillon } > } > | If you don't have the disk necessary for a standard overcommit model to } > | work, you definitely do not have the disk necessary for a non-overcommit } > | model to work. } > } > This is based upon your somewhat strange definition of "work". I assure } > you that I have run many systems which don't use overcommit, and which I } > quite frequently run into "out of VM" conditions, and which I can assure } > you, work just fine. When they're getting to run out of VM, the system } > is approaching paging death, which is as you'd expect (they're overloaded). } > That is, adding more VM (more swap space) would be counterproductive. } } Would you care to name such systems? And, btw, a system consuming } all memory is *not* necessarily approaching paging death. More } likely, it is just storing a lot of data in the swap which will } never be used (which is the whole point of overcommit in first } place), and, thus, never paged in. If the data is stored in swap, then it is committed, whether the data is used or not. Overcommitting only helps with memory that is allocated, but not used. It's bad enough to have people in this debate that have something of a clue, refusing to see the other side; we really don't need people that have no clue at all. } > I have no doubt but that you can dream up scenarios where you pander to } > the laziness of programmers, and make using huge VM space with little } > of it actually allocated anywhere (or ever touched) then you would indeed } > need monstrous amounts of paging space, most of which is never actually } > used for anything - personally I prefer to have the programmers think } > a little more about the memory footprint of their data structures. Not } > only does this reduce the VM footprint, it will also usually vastly } > improving the paging characteristics. Most applications which simply } > scatter data through a huge VM space simply stop being useable as soon } > as their RSS exceeds available physical memory - that is, if they start } > paging, they die (become comatose might be a better description). } > A little intelligent though as to how to actually make use of the mem } > resources can make a huge difference. } } Fine. Stay with the allocation of swap for DATA/BSS of each instance } of the same program you are running. That alone is enough. Yes. In another post, you brought up the issue of TEXT. TEXT is swapped in from the executable file and has been for a very long time. It is simply not an issue. }-- End of excerpt from "Daniel C. Sobral" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 13: 2:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pzero.sandelman.ottawa.on.ca (gigabit.solidum.com [216.13.130.242]) by hub.freebsd.org (Postfix) with ESMTP id 14B361545B for ; Wed, 14 Jul 1999 13:01:35 -0700 (PDT) (envelope-from mcr@sandelman.ottawa.on.ca) Received: from morden.sandelman.ottawa.on.ca (localhost.sandelman.ottawa.on.ca [127.0.0.1]) by pzero.sandelman.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id PAA02088; Wed, 14 Jul 1999 15:58:24 -0400 (EDT) Message-Id: <199907141958.PAA02088@pzero.sandelman.ottawa.on.ca> To: jnemeth@victoria.tc.ca (John Nemeth) Cc: freebsd-hackers@freebsd.org, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) In-reply-to: Your message of "Wed, 14 Jul 1999 10:53:27 PDT." <199907141753.KAA02096@vtn1.victoria.tc.ca> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Wed, 14 Jul 1999 15:58:23 -0400 From: Michael Richardson Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "John" == John Nemeth writes: John> On one system I administrate, the largest process is typically John> rpc.nisd (the NIS+ server daemon). Killing that process would be a John> bad thing (TM). You're talking about killing random processes. John> This is no way to run a system. It is not possible for any John> arbitrary decision to always hit the correct process. That is a John> decision that must be made by a competent admin. This is the John> biggest argument against overcommit: there is no way to gracefully John> recover from an out of memory situation, and that makes for an John> unreliable system. No, I don't agree. This is a biggest argument against solving the overcommit situation with SIGKILL. I have no problem with overcommit as a concept, I have a problem with being unable to keep my possibly big processes (X, rpc.nisd, etc. depending on cicumstances) from being victims. ] Train travel features AC outlets with no take-off restrictions| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 13: 2:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from vtn1.victoria.tc.ca (vtn1.victoria.tc.ca [199.60.222.3]) by hub.freebsd.org (Postfix) with ESMTP id 3149314CD3 for ; Wed, 14 Jul 1999 13:02:54 -0700 (PDT) (envelope-from jnemeth@vtn1.victoria.tc.ca) Received: (from jnemeth@localhost) by vtn1.victoria.tc.ca (8.8.8/8.8.8) id NAA16574; Wed, 14 Jul 1999 13:01:57 -0700 (PDT) Message-Id: <199907142001.NAA16574@vtn1.victoria.tc.ca> From: jnemeth@victoria.tc.ca (John Nemeth) Date: Wed, 14 Jul 1999 13:01:57 -0700 In-Reply-To: "Daniel C. Sobral" "Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))" (Jul 15, 2:40am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Daniel C. Sobral" Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Jul 15, 2:40am, "Daniel C. Sobral" wrote: } Garance A Drosihn wrote: } > At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote: } > > In which case the program that consumed all memory will be killed. } > > The program killed is +NOT+ the one demanding memory, it's the one } > > with most of it. } > } > But that isn't always the best process to have killed off... } } Sure it is. :-) Let's see... This statement is absurd. Only a comptetant admin can decide which process can be killed. No arbitrary decision is going to be correct. } > It would be nice to have a way to indicate that, a la SIGDANGER. } } Ok, everybody is avoiding this, so I'll comment. Yes, this would be The reason I've ignored it, is because SIGDANGER is a hack on top of a very bad hack. } interesting, and a good implementation will very probably be } committed. *BUT*, this is not as useful as it seems. Since the } correct solution is buy more memory/increase swap (correct solution } for our target markets, anyway), there is little incentive to } implement it. In case you hadn't noticed, this debate is cross-posted to NetBSD. NetBSD's target market isn't the same as FreeBSD's target market. This answer is NOT the correct solution for NetBSD's target market. Heck, except for one rather vocal person, FreeBSD's target market may not consider it to be the correct solution either. I most certainly do not consider it to be correct, and I admin a lot of mission critical servers. }-- End of excerpt from "Daniel C. Sobral" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 13: 4: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pzero.sandelman.ottawa.on.ca (gigabit.solidum.com [216.13.130.242]) by hub.freebsd.org (Postfix) with ESMTP id 964541544A for ; Wed, 14 Jul 1999 13:03:57 -0700 (PDT) (envelope-from mcr@sandelman.ottawa.on.ca) Received: from morden.sandelman.ottawa.on.ca (localhost.sandelman.ottawa.on.ca [127.0.0.1]) by pzero.sandelman.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id QAA02130; Wed, 14 Jul 1999 16:01:21 -0400 (EDT) Message-Id: <199907142001.QAA02130@pzero.sandelman.ottawa.on.ca> To: Ben Rosengart Cc: John Nemeth , freebsd-hackers@freebsd.org, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) In-reply-to: Your message of "Wed, 14 Jul 1999 17:57:40 -0000." Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Wed, 14 Jul 1999 16:01:20 -0400 From: Michael Richardson Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Ben" == Ben Rosengart writes: Ben> On Wed, 14 Jul 1999, John Nemeth wrote: >> On one system I administrate, the largest process is typically >> rpc.nisd (the NIS+ server daemon). Killing that process would be a >> bad thing (TM). You're talking about killing random processes. This >> is no way to run a system. It is not possible for any arbitrary >> decision to always hit the correct process. That is a decision that >> must be made by a competent admin. This is the biggest argument >> against overcommit: there is no way to gracefully recover from an out >> of memory situation, and that makes for an unreliable system. Ben> $DEITY on a pogo stick, how many times do we have to hear the same Ben> hypothetical argument? Ben> Tell me, Mr. Nemeth, has this ever happened to you? Have you ever Ben> come *close*? Uh, since we don't run overcommit, the answer is specifically *NO*. We have never had lack of swap space randomly kill one of our processes. This is good, and this is the way we want to keep it. I have had it happen on other systems. (Solaris, AIX) It was very mystifying to diagnose. Sure, the systems were misconfigured for what we were trying to do, but if I wanted build a custom system for every application.... well... I'd be running NT. ] Train travel features AC outlets with no take-off restrictions| firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 13: 9:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lamb.sas.com (lamb.sas.com [192.35.83.8]) by hub.freebsd.org (Postfix) with ESMTP id 5D23614D69 for ; Wed, 14 Jul 1999 13:09:18 -0700 (PDT) (envelope-from jwd@unx.sas.com) Received: from mozart (mozart.unx.sas.com [192.58.184.8]) by lamb.sas.com (8.9.3/8.9.1) with SMTP id QAA18220 for ; Wed, 14 Jul 1999 16:08:45 -0400 (EDT) Received: from bb01f39.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA15674; Wed, 14 Jul 1999 16:08:15 -0400 Received: (from jwd@localhost) by bb01f39.unx.sas.com (8.9.1/8.9.1) id QAA69071 for freebsd-hackers@freebsd.org; Wed, 14 Jul 1999 16:08:14 -0400 (EDT) (envelope-from jwd) From: "John W. DeBoskey" Message-Id: <199907142008.QAA69071@bb01f39.unx.sas.com> Subject: tcp windowsize query? To: freebsd-hackers@freebsd.org Date: Wed, 14 Jul 1999 16:08:14 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I'm trying to dynamically determine the tcp windowsize. Sysctl has the following to say, but the name/value pairs are not documented. net.inet.tcp.rfc1323: 0 net.inet.tcp.rfc1644: 0 net.inet.tcp.mssdflt: 512 net.inet.tcp.rttdflt: 3 net.inet.tcp.keepidle: 14400 net.inet.tcp.keepintvl: 150 net.inet.tcp.sendspace: 16384 net.inet.tcp.recvspace: 16384 net.inet.tcp.keepinit: 150 net.inet.tcp.log_in_vain: 0 net.inet.tcp.delayed_ack: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.pcbcount: 156 net.inet.tcp.always_keepalive: 1 The rfc values are self-explanatory... send/recv space might be what I'm looking for... delayed ack sounds interesting.... Any comments, documentation, or pointers are much appreciated. I'm now off to dig through the kernel... Thanks, john To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 13: 9:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from vtn1.victoria.tc.ca (vtn1.victoria.tc.ca [199.60.222.3]) by hub.freebsd.org (Postfix) with ESMTP id 9A9ED15474 for ; Wed, 14 Jul 1999 13:09:32 -0700 (PDT) (envelope-from jnemeth@vtn1.victoria.tc.ca) Received: (from jnemeth@localhost) by vtn1.victoria.tc.ca (8.8.8/8.8.8) id NAA22442; Wed, 14 Jul 1999 13:09:01 -0700 (PDT) Message-Id: <199907142009.NAA22442@vtn1.victoria.tc.ca> From: jnemeth@victoria.tc.ca (John Nemeth) Date: Wed, 14 Jul 1999 13:09:01 -0700 In-Reply-To: Ben Rosengart "Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))" (Jul 14, 5:57pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Ben Rosengart Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Jul 14, 5:57pm, Ben Rosengart wrote: } On Wed, 14 Jul 1999, John Nemeth wrote: } } > On one system I administrate, the largest process is typically } > rpc.nisd (the NIS+ server daemon). Killing that process would be a } > bad thing (TM). You're talking about killing random processes. This } > is no way to run a system. It is not possible for any arbitrary } > decision to always hit the correct process. That is a decision that } > must be made by a competent admin. This is the biggest argument } > against overcommit: there is no way to gracefully recover from an } > out of memory situation, and that makes for an unreliable system. } } $DEITY on a pogo stick, how many times do we have to hear the same } hypothetical argument? It is not hypothetical in any way. The fact that you refuse to believe the examples given is your problem. } Tell me, Mr. Nemeth, has this ever happened to you? Have you ever come } *close*? The machine in question has run out of swap, due to unforseeable excessive memory demands. This was accompanied by processes complaining about not being able to allocate memory and then cleaning up after themselves. I did not see random processes being killed because of it. That is the way things should be. From this, I can assume that the OS doesn't overcommit. In case, you're wondering, the OS in question is: SunOS 5.5 Generic_103093-25 sun4u sparc }-- End of excerpt from Ben Rosengart To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 13:26:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id 8BA5D14E5F for ; Wed, 14 Jul 1999 13:26:39 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id NAA01388; Wed, 14 Jul 1999 13:21:55 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907142021.NAA01388@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "John W. DeBoskey" Cc: freebsd-hackers@freebsd.org Subject: Re: tcp windowsize query? In-reply-to: Your message of "Wed, 14 Jul 1999 16:08:14 EDT." <199907142008.QAA69071@bb01f39.unx.sas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Jul 1999 13:21:55 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hi, > > I'm trying to dynamically determine the tcp windowsize. Sysctl > has the following to say, but the name/value pairs are not > documented. > > net.inet.tcp.sendspace: 16384 > net.inet.tcp.recvspace: 16384 ... > send/recv space might be what I'm looking for... They're the default send/receive window sizes, yes. You can tweak them with socket ioctls on a per-socket basis. > delayed ack sounds interesting.... Turning that off disables TCP slow-start. It's a huge performance booster for things like SMB service, where you have lots of short-lived TCP connections on a local net. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 13:42:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id F1609154C4 for ; Wed, 14 Jul 1999 13:42:04 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA95895; Wed, 14 Jul 1999 13:40:07 -0700 (PDT) (envelope-from dillon) Date: Wed, 14 Jul 1999 13:40:07 -0700 (PDT) From: Matthew Dillon Message-Id: <199907142040.NAA95895@apollo.backplane.com> To: Mike Smith Cc: "John W. DeBoskey" , freebsd-hackers@FreeBSD.ORG Subject: Re: tcp windowsize query? References: <199907142021.NAA01388@dingo.cdrom.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> net.inet.tcp.recvspace: 16384 :... :> send/recv space might be what I'm looking for... : :They're the default send/receive window sizes, yes. You can tweak them :with socket ioctls on a per-socket basis. : :> delayed ack sounds interesting.... : :Turning that off disables TCP slow-start. It's a huge performance :booster for things like SMB service, where you have lots of short-lived :TCP connections on a local net. Note that you can also tweak TCP send/receive window sizes on a per-route basis. The recvpipe and sendpipe parameters in route table entries can be changed. This will override the sysctl defaults. However, it may be a little complex for some people to grasp. The route table is a radix tree. In order to set the send/receive pipes for particular ip addresses you may have to create a route to that IP address in order to effect it rather then a more global route. For example, if I am getting the route to some host that runs through my default gateway, I get my default route entry. If I were to change this route entry I would be changing it for default, not just for idiom.com: route -n get idiom.com # route -n get idiom.com route to: 209.157.64.1 destination: default mask: default <----- this is not a host route! gateway: 209.157.86.1 <----- this is not a host route! interface: de0 flags: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1500 0 On the other hand, a route to another host on the same ethernet is usually specific: # route -n get lander route to: 209.157.86.6 destination: 209.157.86.6 interface: de0 flags: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 10411044 172 219 0 1500 1131 To change the pipes associated with a route, I would do the following. But in this example if I were to try to change the pipe size to idiom.com, I would actually wind up changing the pipe size for my default route. route -n change idiom.com -sendpipe BYTES -recvpipe BYTES route -n change 209.157.86.6 -sendpipe BYTES -recvpipe BYTES If I really want to change the pipe size just to idiom.com, I would have to first create a specific route to idiom.com, then change that. route add idiom.com default route -n change idiom.com -sendpipe BYTES -recvpipe BYTES -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 13:45:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from aussie.cs.mu.OZ.AU (dhcp2966.ietf.uninett.no [128.39.29.66]) by hub.freebsd.org (Postfix) with ESMTP id ECFF41541C for ; Wed, 14 Jul 1999 13:45:47 -0700 (PDT) (envelope-from kre@cs.mu.OZ.AU) Received: from cs.mu.OZ.AU (localhost [127.0.0.1]) by aussie.cs.mu.OZ.AU (8.8.8/8.8.8) with ESMTP id WAA20353; Wed, 14 Jul 1999 22:35:52 +0200 (CEST) From: Robert Elz To: "Daniel C. Sobral" Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-reply-to: Your message of "Thu, 15 Jul 1999 00:53:17 +0900." <378CB26D.C0BC0DBE@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Jul 1999 22:35:51 +0200 Message-ID: <20351.931984551@cs.mu.OZ.AU> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Date: Thu, 15 Jul 1999 00:53:17 +0900 From: "Daniel C. Sobral" Message-ID: <378CB26D.C0BC0DBE@newsguy.com> | Would you care to name such systems? munnari was one (the system of the From: header, even though this mail isn't actually going anywhere near it). I will describe it a bit lower down. | And, btw, a system consuming | all memory is *not* necessarily approaching paging death. No, of course not, though I didn't say all memory, I said all VM. And while it is possible to have all VM consumed, and no paging activity at all, that would tend to indicate insufficient VM allocated (reaching an artificial barrier). | More | likely, it is just storing a lot of data in the swap which will | never be used (which is the whole point of overcommit in first | place), and, thus, never paged in. The systems I describe were not using overcommit, further, I wouldn't imagine that a system storing anything to swap would be overcommiting - as I understand the term, overcommit only relates to allocating VM resources which aren't backed by anything physical at all ("here's all this address space you can play in if you like, but you had better not actually do that, because if you do it won't work"). Either applied to one process, as that wording suggests, or aggregated over the whole system. If a process was (for some stupid reason) loading a whole bunch of data into the swap space, that would be committed VM, and you have to have the resources to cope with it. Now to munnari. It no longer runs quite like this, but munnari is an alpha, 128MB, runs digital unix (not in overcommit mode, either is possible there). At the time of which I speak it ran two principal applications of note, innd with a VM footprint about 100MB, and named, with a memory footprint (at the time) of about 90MB (as it is now, it no longer runs innd, but its named has grown to > 120MB). It also ran a bunch of small stuff (sendmail, typically 1 or 2 instances, around 3MB each), ftpd (smaller, most often 0 or 1, sometimes 3 or 4,) and the occasional shell (a few hundreds of MB) plus init getty cron syslog and all that associated noise with mem requirements approaching 0. That's fine. Well, not really fine, innd and named would fight each other all day for who had how much of the real memory, and who was relegated to swap, of which there was enough for all this to fit, but not a lot more than that (enough for one of them to fork when it needed to, that's all - not both at once, and yes, overcommit would have allowed both at once, but that was not an aim). Then, because it was running innd, it was also running the perl script that summarises the log file, that could grow to 30MB, maybe more. And because it is running sendmail, every now and then you get the typical sendmail huge queue syndrome (at least for old sendmails, which this was), where you get a dead site, a large queue of processes, and a bunch of sendmails running the queue, spending most of their time hung on connection attempts that aren't working, and gradually growing bigger (maybe 8 or 10 processes at 15Mb each). Somewhere amongst all of this swap would run out, and a good thing too, as by this time the system really would be paging itself to oblivion. Note that all this (large) VM I have described was filled with real data (except for the odd times hen innd or named had just forked), none of it could be overcommitted and just ignored. Whatever policy was in place, the physical VM resources would have run out. Now let's look at what happens with the two methods. With all VM backed by real mem or swap space, processes go about allocating memory - when there is no more left, the allocations start failing. If the process is perl, it just collapses in a heap, and the log file summary doesn't get made that day. So sad... If its sendmail, it issues "OS error, temporary failure" type responses, saves its queue files, and exits. A later sendmail will deliver those messages, no harm. If its a shell, who knows (I forget what the shells do, I think most just keep trying, at least if interactive), but they consume mem at such a slow rate it doesn't matter - fork() would typically fail though, so no new processes could get started. innd would just pause, and wait till a bit later when mem might be available again (those perls and sendmails all gone away). named just the same (at least the named munnari ran). They're the two processes munnari was supposed to be runinng - those two don't just die. Now, with overcommit mode, we get an extra 30 seconds of life, because no doubt there are a few pages floating around that have been allocated to some process, but nothing has bothered to write into yet. An extra 30 seconds if we're lucky (except if we followed the advice given here earlier which would indicate that only 1/8 the amount of swap space would be needed, in which case these processes would never have gotten started in the first place). After that short grace period, during which the kernel has been happily answering requests for more VM with "sure, have as much as you like", something needs an extra page of real storage, there is none available, and we either deadlock, or die. The approach suggested here seems to find the biggest process (which here would be innd or named) and kill -9 it. No thanks. Not an acceptable answer. Sure it would get lots of VM back again, but the system would no longer have been doing what it was supposed to be doing. Adding more swap space would be easy, but the wrong thing to do, that would just have allowed the system to page itself to death, thrashing into eternity - having processes go away is the only solution to this kind of problem. Except it needs to be the right processes, and "right" does not equal "big", nor any other criteria the kernel could possibly figure out for itself. kre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 14: 8: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 082BB153F1 for ; Wed, 14 Jul 1999 14:07:58 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id OAA21468; Wed, 14 Jul 1999 14:05:25 -0700 (PDT) Message-Id: <199907142105.OAA21468@implode.root.com> To: Mike Smith Cc: "John W. DeBoskey" , freebsd-hackers@FreeBSD.ORG Subject: Re: tcp windowsize query? In-reply-to: Your message of "Wed, 14 Jul 1999 13:21:55 PDT." <199907142021.NAA01388@dingo.cdrom.com> From: David Greenman Reply-To: dg@root.com Date: Wed, 14 Jul 1999 14:05:25 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> delayed ack sounds interesting.... > >Turning that off disables TCP slow-start. It's a huge performance >booster for things like SMB service, where you have lots of short-lived >TCP connections on a local net. Uh, that's not what it does. Slow start is a behavior where the sender opens the window slowly - starting with one segment for the window and adding one more segment for each ack that comes back successfully. What the above option does is disable delayed acks on the receiver, thus reducing the round-trip time and increasing the speed of transaction style (small) TCP sends. Actually the real purpose of it is to eliminate the internal overhead that is normally imposed by the delayed ack timers, which can become substantial on large systems like wcarchive. That it has other beneficial side effects is almost accidental. :-) -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 14:12: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id A6797153E1 for ; Wed, 14 Jul 1999 14:11:56 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA96038; Wed, 14 Jul 1999 14:05:20 -0700 (PDT) (envelope-from dillon) Date: Wed, 14 Jul 1999 14:05:20 -0700 (PDT) From: Matthew Dillon Message-Id: <199907142105.OAA96038@apollo.backplane.com> To: Robert Elz Cc: "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <20351.931984551@cs.mu.OZ.AU> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Now let's look at what happens with the two methods. : :With all VM backed by real mem or swap space, processes go about allocating :memory - when there is no more left, the allocations start failing. :If the process is perl, it just collapses in a heap, and the log file :summary doesn't get made that day. So sad... If its sendmail, it :issues "OS error, temporary failure" type responses, saves its queue files, :and exits. A later sendmail will deliver those messages, no harm. :If its a shell, who knows (I forget what the shells do, I think most just :keep trying, at least if interactive), but they consume mem at such a slow :rate it doesn't matter - fork() would typically fail though, so no new :processes could get started. innd would just pause, and wait till a :bit later when mem might be available again (those perls and sendmails :all gone away). named just the same (at least the named munnari ran). :They're the two processes munnari was supposed to be runinng - those two :don't just die. Which means that if one of those two processes happen to be the ones primarily responsible for running the machine out of VM, memory resources will never be released and now you can't even login! Not only that, but if you are running a news subsystem, it is actually *worse* if the news process bogs down and gets behind then it for the news process to simply die and alert someone. When you are pushing news, you cannot afford to get behind. Also, your named is badly misconfigured if it grows to 130MB. We never allow ours to grow past 30MB. Since the machine is basically in an unworking state anyway, and since you can now no longer login, I don't quite see why you are happy that those two processes are still running. From my standpoint, the machine is badly broken and needs to be rebooted and then fixed so the problems do not reoccur and I would be much happier if I could log into the beast to get that done then to have to hit the reset button. :Now, with overcommit mode, we get an extra 30 seconds of life, because :no doubt there are a few pages floating around that have been allocated :to some process, but nothing has bothered to write into yet. An extra 30 :... garbage removed ... :Sure it would get lots of VM back again, but the system would no longer :have been doing what it was supposed to be doing. Adding more swap space The machine isn't doing what it is supposed to be doing in either case once it has run out of VM. Except in the first case you think you should be happy because it didn't kill the news process, when in fact you ought to be trying to figure out why the thing ran out of VM in the first place and then fix it so it never happens again. To me, this whole scenario sounds like a badly configured machine which the sysop isn't willing to fix. I feel sorry for the poor company who hired that sysop! :would be easy, but the wrong thing to do, that would just have allowed :the system to page itself to death, thrashing into eternity - having :processes go away is the only solution to this kind of problem. Except :it needs to be the right processes, and "right" does not equal "big", :nor any other criteria the kernel could possibly figure out for itself. : :kre If you consider this a critical problem, then the only acceptable solution is to write a watchdog script that monitors swap utilization and kills the correct processes if swap starts to get low. If you wait until swap actually runs out, you've already lost because too many things are likely to break in a general purpose computing environment. Of course I suppose you could advocate that programs must be written 'properly' to handle the case... well, more power to you, but in a general computing environment you are running dozens if not hundreds of third party applications and fixing them all is a pipe dream. It seems to me that you are willing to blame the operating system for a situation that is really not the OS's fault, and that you are not willing to sit down and spend the 10 minutes necessary writing a simple watchdog script. I don't bother to write watchdog scripts to check for swap, because my machines DO NOT RUN OUT OF SWAP. If your machines do, then maybe you should consider writing the watchdog script. Personally, I think you would get better reliability by fixing your systems. You are blaming what is essentially a last-resort effort by the kernel for not being nice to your processes. Well Duh! It's a last-resort mechanism, it isn't supposed to be nice. Maybe you shouldn't be depending on last resort mechanisms to keep your machines running. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 14:13:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id D3CD3153EF for ; Wed, 14 Jul 1999 14:13:49 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id QAA11395; Wed, 14 Jul 1999 16:12:48 -0500 (CDT) Received: from free.pcs (free.PCS [148.105.10.51]) by right.PCS (8.6.13/8.6.4) with ESMTP id QAA01682; Wed, 14 Jul 1999 16:12:46 -0500 Received: (from jlemon@localhost) by free.pcs (8.8.6/8.8.5) id QAA10842; Wed, 14 Jul 1999 16:12:46 -0500 (CDT) Date: Wed, 14 Jul 1999 16:12:46 -0500 (CDT) From: Jonathan Lemon Message-Id: <199907142112.QAA10842@free.pcs> To: mike@smith.net.au, hackers@freebsd.org Subject: Re: tcp windowsize query? X-Newsgroups: local.mail.freebsd-hackers In-Reply-To: References: Organization: Architecture and Operating System Fanatics Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: >> delayed ack sounds interesting.... > >Turning that off disables TCP slow-start. It's a huge performance >booster for things like SMB service, where you have lots of short-lived >TCP connections on a local net. Mike probably already knows this, but just a general clarification: No, it does _not_ turn off slow-start. Normally a TCP implementation will delay sending an ACK to the peer until the TCP fasttimer expires, or certain other conditions are met. The goal here is to amortize an ACK over several incoming data packets. Turning off delayed ack forces the receiving end to send an ACK immediately, for every packet it receives. This may or may not result in a performance boost. For short lived connections, where latency is paramount, it usually results in a gain, since there is no delay in sending an ACK. For longer lived connections, it results in more network traffic, usually resulting in a performace drop. Slow start is where the sender builds up to the maximum TCP window size at an exponential rate, proportional to the rate of which ACKs are returned by the peer. It is automatically disabled for hosts on the "local network", but enabled otherwise. I'm considering putting in a sysctl knob to always do slow start, even for a local network. If this happens, it would be conceivable that you could twist it the other way and never do slow start. Note that while this might be useful in certain benchmark corner cases, it would violate the RFC, and be network-unfriendly to boot. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 14:16:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from luna.lyris.net (luna.shelby.com [207.90.155.6]) by hub.freebsd.org (Postfix) with ESMTP id 67DD4153F1; Wed, 14 Jul 1999 14:16:45 -0700 (PDT) (envelope-from kip@lyris.com) Received: from luna.shelby.com by luna.lyris.net (8.9.1b+Sun/SMI-SVR4) id OAA23293; Wed, 14 Jul 1999 14:16:10 -0700 (PDT) Received: from (luna.shelby.com [207.90.155.6]) by luna.shelby.com with SMTP (MailShield v1.50); Wed, 14 Jul 1999 14:16:10 -0700 Date: Wed, 14 Jul 1999 14:16:10 -0700 (PDT) From: Kip Macy X-Sender: kip@luna To: Daniel Eischen Cc: hackers@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: new seg fault in thread code In-Reply-To: <199907141849.OAA01714@pcnet1.pcnet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: luna X-SMTP-MAIL-FROM: kip@lyris.com X-SMTP-RCPT-TO: eischen@vigrid.com,hackers@FreeBSD.ORG,stable@FreeBSD.ORG X-SMTP-PEER-INFO: luna.shelby.com [207.90.155.6] Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Do you want an executable? Anyway, I compiled the tests in /usr/src/lib/libc_r/test/ and they both seg faulted in the exact same way: Note: I had to add the -static to the LDFLAGS in order for gdb to find symbols for them. adsl-216-101-22-188 [libc_r/test/sigwait|14:14|210|]gdb sigwait sigwait.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... Core was generated by `sigwait'. Program terminated with signal 11, Segmentation fault. #0 0x804c6ac in _thread_kern_sched_state_unlock () (gdb) bt #0 0x804c6ac in _thread_kern_sched_state_unlock () #1 0x804bec1 in _thread_kern_sched () #2 0x804c351 in _thread_kern_sched_state () #3 0x804f0ff in nanosleep (time_to_sleep=0xbfbfd7a4, time_remaining=0xbfbfd79c) at /usr/src/lib/libc_r/uthread/uthread_nanosleep.c:72 #4 0x804efc2 in sleep (seconds=1) at /usr/src/lib/libc_r/../libc/gen/sleep.c:63 #5 0x804842e in main () #6 0x804813c in _start (arguments=0xbfbfd904 "sigwait") at /usr/src/lib/csu/i386-elf/crt1.c:95 adsl-216-101-22-188 [libc_r/test/sigsuspend|14:16|214|]gdb sigsuspend sigsuspend.core GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... Core was generated by `sigsuspend'. Program terminated with signal 11, Segmentation fault. #0 0x804c4ec in _thread_kern_sched_state_unlock () (gdb) bt #0 0x804c4ec in _thread_kern_sched_state_unlock () #1 0x804bd01 in _thread_kern_sched () #2 0x804c191 in _thread_kern_sched_state () #3 0x804ef3f in nanosleep (time_to_sleep=0xbfbfd7a0, time_remaining=0xbfbfd798) at /usr/src/lib/libc_r/uthread/uthread_nanosleep.c:72 #4 0x804ee02 in sleep (seconds=1) at /usr/src/lib/libc_r/../libc/gen/sleep.c:63 #5 0x80484a5 in main () #6 0x804813c in _start (arguments=0xbfbfd8fc "./sigsuspend") at /usr/src/lib/csu/i386-elf/crt1.c:95 (gdb) On Wed, 14 Jul 1999, Daniel Eischen wrote: > Kip Macy wrote: > > I just rebuilt libc_r and relinked my application. I am now crashing right > > away as opposed to after several hours as I have been. > > > > Program terminated with signal 11, Segmentation fault. > > #0 0x82fa07c in _thread_kern_sched_state_unlock () > > (gdb) bt > > #0 0x82fa07c in _thread_kern_sched_state_unlock () > > #1 0x82f9891 in _thread_kern_sched () > > #2 0x82f9d21 in _thread_kern_sched_state () > > #3 0x8307ee3 in nanosleep (time_to_sleep=0xbfbfd2d4, > > time_remaining=0xbfbfd2cc) > > at /usr/src/lib/libc_r/uthread/uthread_nanosleep.c:72 > > #4 0x8307b9e in sleep (seconds=1) > > at /usr/src/lib/libc_r/../libc/gen/sleep.c:63 > > #5 0x8285598 in os_this_thread::sleep (seconds_=1) at thisthrd.cpp:712 > > #6 0x825bce5 in lyris_CodeBase_Table::open (this=0x85bcd00, > > Exclusive=false) > > at cbtable3.cpp:588 > > #7 0x82342f0 in lyris_Table::open (this=0xbfbfd538, Exclusive=false) > > at table.cpp:1004 > > #8 0x8048f9f in lyris_Config::open (this=0xbfbfd4fc, Exclusive=false) > > at config.cpp:257 > > #9 0x8048221 in lyris_Config::lyris_Config (this=0xbfbfd4fc) at > > config.cpp:52 > > #10 0x814be41 in lyris_CommandLine::RunCommandLine (this=0x85adc90, > > InArguments=@0xbfbfd788) at lyrcline.cpp:682 > > #11 0x8160e83 in main (argc=4, argv=0xbfbfd808) at lyrmain.cpp:59 > > Great, now it should be easy to reproduce! Can you send me > something to reproduce it? > > Dan Eischen > eischen@vigrid.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 14:27:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id A9AC114DC0 for ; Wed, 14 Jul 1999 14:27:29 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id OAA01681; Wed, 14 Jul 1999 14:27:19 -0700 (PDT) Message-Id: <199907142127.OAA01681@lestat.nas.nasa.gov> To: John Baldwin Cc: tech-userlevel@netbsd.org, freebsd-hackers@FreeBSD.ORG, Matthew Dillon Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Reply-To: Jason Thorpe From: Jason Thorpe Date: Wed, 14 Jul 1999 14:27:19 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999 23:18:58 -0400 (EDT) John Baldwin wrote: > What does that have to do with overcommit? I student administrate a undergrad > CS lab at a university, and when student's programs misbehaved, they generate a > fault and are killed. The only machines that reboot on us without be > explicitly told to are the NT ones, and yes we run FreeBSD. What does it have to do with overcommit? Everthing in the world! If you have a lot of users, all of which have buggy programs which eat a lot of memory, per-user swap quotas don't necessarily save your butt. And maybe the individual programs didn't encounter their resource limits. ...but the sheer number of these runaway things caused the overcommit to be a problem. If malloc() or whatever had actually returned NULL at the right time (i.e. as backing store was about to become overcommitted), then these runaway processes would have stopped running away (they would have gotten a SIGSEGV and died). Anyhow, my "lame undergrads" example comes from a time when PCs weren't really powerful enough for the job (or something; anyhow, we didn't have any in the department :-). My example is from a Sequent Balance (16 ns32032 processors, 64M RAM [I think; been a while], 4.2BSD variant). -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 14:30:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id 4A70914DC0 for ; Wed, 14 Jul 1999 14:30:31 -0700 (PDT) (envelope-from sthaug@nethelp.no) Received: (qmail 1957 invoked by uid 1001); 14 Jul 1999 21:29:57 +0000 (GMT) To: dillon@apollo.backplane.com Cc: kre@munnari.OZ.AU, freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) From: sthaug@nethelp.no In-Reply-To: Your message of "Wed, 14 Jul 1999 14:05:20 -0700 (PDT)" References: <199907142105.OAA96038@apollo.backplane.com> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Wed, 14 Jul 1999 23:29:57 +0200 Message-ID: <1955.931987797@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Also, your named is badly misconfigured if it grows to 130MB. We never > allow ours to grow past 30MB. How do you know what kind of name server configuration kre is running? Here's an example of a name server running *non-recursive*, serving 11.500 zones: PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 27162 root 2 0 70M 57M sleep 271:01 3.27% 3.27% named Are you saying that such configurations should be illegal? Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 15:16:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id E5C27153C5 for ; Wed, 14 Jul 1999 15:16:31 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA96558; Wed, 14 Jul 1999 15:16:15 -0700 (PDT) (envelope-from dillon) Date: Wed, 14 Jul 1999 15:16:15 -0700 (PDT) From: Matthew Dillon Message-Id: <199907142216.PAA96558@apollo.backplane.com> To: sthaug@nethelp.no Cc: kre@munnari.OZ.AU, freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907142105.OAA96038@apollo.backplane.com> <1955.931987797@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :> Also, your named is badly misconfigured if it grows to 130MB. We never :> allow ours to grow past 30MB. : :How do you know what kind of name server configuration kre is running? :Here's an example of a name server running *non-recursive*, serving :11.500 zones: : : PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND :27162 root 2 0 70M 57M sleep 271:01 3.27% 3.27% named : :Are you saying that such configurations should be illegal? : :Steinar Haug, Nethelp consulting, sthaug@nethelp.no I assumed that since the guy said that his named GREW, that he was running a recurisve/caching named. Obviously if you are running a non-recursive named the static size will depend on the zones you are serving. Duh! It is not generally beneficial to allow a caching named to exceed 30MB or so on a system that is doing other things. If the system starts to page (which this person's system is obviously doing), then it is doubly a bad idea to allow a named to grow that large. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 15:20:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 7A74014D32 for ; Wed, 14 Jul 1999 15:20:06 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA96575; Wed, 14 Jul 1999 15:18:50 -0700 (PDT) (envelope-from dillon) Date: Wed, 14 Jul 1999 15:18:50 -0700 (PDT) From: Matthew Dillon Message-Id: <199907142218.PAA96575@apollo.backplane.com> To: Jason Thorpe Cc: John Baldwin , tech-userlevel@netbsd.org, freebsd-hackers@FreeBSD.ORG Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907142127.OAA01681@lestat.nas.nasa.gov> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On Tue, 13 Jul 1999 23:18:58 -0400 (EDT) : John Baldwin wrote: : : > What does that have to do with overcommit? I student administrate a undergrad : > CS lab at a university, and when student's programs misbehaved, they generate a : > fault and are killed. The only machines that reboot on us without be : > explicitly told to are the NT ones, and yes we run FreeBSD. : :What does it have to do with overcommit? Everthing in the world! : :If you have a lot of users, all of which have buggy programs which eat :a lot of memory, per-user swap quotas don't necessarily save your butt. If every single one of your users is trying to crash your machine daily, maybe you should consider throwing them off the system and finding users that are less hostile. This conversation is getting silly. Do you actually believe that an operating system can magically protect itself 100% from armloads of hostile users? Give me a break. You people are crazy. If you have something worthwhile to say i'll listen, but these "the sky is falling!" arguments are idiotic. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 15:21: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id CBF6414EFD; Wed, 14 Jul 1999 15:20:41 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id QAA25702; Wed, 14 Jul 1999 16:19:44 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id QAA58852; Wed, 14 Jul 1999 16:19:39 -0600 (MDT) Message-Id: <199907142219.QAA58852@harmony.village.org> To: Scott Mitchell Subject: Re: Reading CIS from kernel? Cc: obrien@NUXI.com, ade@lovett.com, phk@freebsd.org, freebsd-xircom@lovett.com, hackers@freebsd.org, mobile@freebsd.org In-reply-to: Your message of "Wed, 14 Jul 1999 18:51:01 BST." <19990714185101.09845@goatsucker.org> References: <19990714185101.09845@goatsucker.org> <19990713182203.A68393@nuxi.com> <19990710162730.60563@goatsucker.org> <19990713182203.A68393@nuxi.com> <199907140652.AAA53151@harmony.village.org> Date: Wed, 14 Jul 1999 16:19:39 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19990714185101.09845@goatsucker.org> Scott Mitchell writes: : Ugh. In that case, can someone back out Poul-Henning's changes to the : if_xe.c in the -STABLE tree? That's (I hope) the only thing stopping it : from working. At least that way only my code will be bogus :-) Believe : me, I know it's ugly, but there's no getting around the fact that the : driver needs to read the CIS, and right now there's no clean way to do that : in -STABLE (is there?). Can I get your comments on the following interface? int pccard_map_cis(int slot) Maps the slot's cis into memory. You must call the before any of the following. It returns 0 on success, or an error from /usr/include/sys/errno.h (most likely EBUSY if there are no memory windows available). int pccard_unmap_cis(int slot) Unmaps the CIS. This frees any resource used by the slot to map its CIS. It returns 0 on success, and an errno value if not. vaddr_t pccard_cis_addr(int slot) Return the virtual address of the CIS. The CIS must be mapped before call this function. Drivers may read/write this memory. Reading this memory will get the CIS entries. Drivers are responsible for interpreting the CIS. Writing to CIS locations generally is used to configure the card and does not change the CIS stored on the card. If the card is not mapped, then 0 will be returned. It is not valid to access memory returned by this call after a call to pccard_unmap_cis. Future interfaces may ease the burdon on driver writers, but this interface will be supported for a while. Does this fill your needs? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 15:27:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id 75E3E154EF for ; Wed, 14 Jul 1999 15:27:43 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id PAA02757; Wed, 14 Jul 1999 15:27:07 -0700 (PDT) Message-Id: <199907142227.PAA02757@lestat.nas.nasa.gov> To: Niall Smart Cc: Matthew Dillon , freebsd-hackers@FreeBSD.org, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) Reply-To: Jason Thorpe From: Jason Thorpe Date: Wed, 14 Jul 1999 15:27:06 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 14 Jul 1999 12:43:07 +0000 Niall Smart wrote: > Perhaps it could be an additional flag to mmap, in this way > people wishing to run an overcommited system could do so > but those writing programs which must not overcommit for > certain memory allocations could ensure they did not do so. This has already been mentioned. SVR4 has MAP_NORESERVE specifcally for this purpose. -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 15:29:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id 76BEE15533 for ; Wed, 14 Jul 1999 15:29:15 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id PAA02809; Wed, 14 Jul 1999 15:29:04 -0700 (PDT) Message-Id: <199907142229.PAA02809@lestat.nas.nasa.gov> To: "Daniel C. Sobral" Cc: Matthew Dillon , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) Reply-To: Jason Thorpe From: Jason Thorpe Date: Wed, 14 Jul 1999 15:29:04 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Jul 1999 01:52:11 +0900 "Daniel C. Sobral" wrote: > > ...um, so, make the code that deals with faulting in the stack a bit smarter. > > Uh? Like what? Like overcommitting, for instance? The beauty of > overcommitting is that either you do it or you don't. :-) One option is to special-case overcommit the stack. Another is to set the default stack limits to something more reasonable on a system where overcommit is disabled. -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 15:30:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from nothing-going-on.demon.co.uk (nothing-going-on.demon.co.uk [193.237.89.66]) by hub.freebsd.org (Postfix) with ESMTP id 6481B15583 for ; Wed, 14 Jul 1999 15:29:47 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.9.3/8.9.2) id VAA62218; Wed, 14 Jul 1999 21:56:21 +0100 (BST) (envelope-from nik) Date: Wed, 14 Jul 1999 21:56:17 +0100 From: Nik Clayton To: Nik Clayton Cc: hackers@freebsd.org Subject: Re: dbm_* manpages for review Message-ID: <19990714215617.A61883@catkin.nothing-going-on.org> References: <19990708222247.A2280@catkin.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <19990708222247.A2280@catkin.nothing-going-on.org>; from Nik Clayton on Thu, Jul 08, 1999 at 10:22:47PM +0100 Organization: Nik at home, where there's nothing going on Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 08, 1999 at 10:22:47PM +0100, Nik Clayton wrote: > Tim Singletary has written some man pages for the dbm_* functions in libc, > which are currently undocumented -- we know they are written in terms > of dbopen(), but it's nice to have them documented anyway. > > Could anyone who knows anything about DBM take a look at docs/12557 and > let me know if they are correct? If they are, I'll commit them. I've had one response to this so far, from Mike Pritchard (thanks Mike). He's corrected some of the macro use in the submitted documentation, but said he didn't do a technical review. So I'm still waiting for any DBM hackers out there to take the 10 minutes required to look at this. If there's no response in (say) 3 days, I'll commit Mike's cleaned up version -- if there are any inaccuracies, I'm sure the wider FreeBSD user base will let us know about them. . . N PS: Only half-kidding about that last paragraph. -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <375143b5@cs.colorado.edu> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 15:31:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (Postfix) with ESMTP id 6937D1545F for ; Wed, 14 Jul 1999 15:31:56 -0700 (PDT) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id PAA02838; Wed, 14 Jul 1999 15:30:48 -0700 (PDT) Message-Id: <199907142230.PAA02838@lestat.nas.nasa.gov> To: "Daniel C. Sobral" Cc: Mike Smith , Ted Faber , Matthew Dillon , hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) Reply-To: Jason Thorpe From: Jason Thorpe Date: Wed, 14 Jul 1999 15:30:48 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Jul 1999 01:59:12 +0900 "Daniel C. Sobral" wrote: > > That's why you make it a switch. No, really, you *can* just make it > > a switch. > > So, enlighten me, please... how do you switch it in NetBSD? When the code to do it is implemented (not that hard, really, and it is in the list of things to do with UVM), a sysctl will enable/disable overcommit checking. There would be like 4 or 5 places in the code where this boolean switch would have to be tested. -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 15:32:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from nothing-going-on.demon.co.uk (nothing-going-on.demon.co.uk [193.237.89.66]) by hub.freebsd.org (Postfix) with ESMTP id 7A09F1561C for ; Wed, 14 Jul 1999 15:32:29 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.9.3/8.9.2) id WAA62815; Wed, 14 Jul 1999 22:01:02 +0100 (BST) (envelope-from nik) Date: Wed, 14 Jul 1999 22:01:01 +0100 From: Nik Clayton To: Matthew Dillon Cc: John-Mark Gurney , Matthew Jacob , freebsd-hackers@FreeBSD.ORG Subject: Re: Swap subsystem overhead (was Re: Replacement for grep(1) (part 2)) Message-ID: <19990714220101.B61883@catkin.nothing-going-on.org> References: <199907131920.MAA80146@apollo.backplane.com> <19990713165520.08447@hydrogen.fircrest.net> <199907140012.RAA82237@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199907140012.RAA82237@apollo.backplane.com>; from Matthew Dillon on Tue, Jul 13, 1999 at 05:12:30PM -0700 Organization: Nik at home, where there's nothing going on Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 13, 1999 at 05:12:30PM -0700, Matthew Dillon wrote: > Ok, I will be more specific. > > Under FreeBSD-STABLE *AND* FreeBSD-CURRENT, FreeBSD allocates metadata > structures that scale to the amount of swap space assigned to the system. > However, it is not *precisely* the amount of swap space. > Under FreeBSD-stable, just look under "VM pgdata" to see how much > memory is being wired to support the swap subsystem. This usage covers > both the fixed and dynamic allocations. OK, at the risk of reawakening that particular thread -- if people are a little uneasy about Matt committing to src/*, how about letting him commit to doc/* instead? Matt -- some of these messages of yours could probably turn in to great articles for DaemonNews, or the FreeBSD 'zine, if you were that way inclined. . . N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <375143b5@cs.colorado.edu> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 15:35:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from foobar.franken.de (foobar.franken.de [194.94.249.81]) by hub.freebsd.org (Postfix) with ESMTP id 15A0215870; Wed, 14 Jul 1999 15:35:05 -0700 (PDT) (envelope-from logix@foobar.franken.de) Received: (from logix@localhost) by foobar.franken.de (8.8.8/8.8.5) id AAA04653; Thu, 15 Jul 1999 00:34:20 +0200 (CEST) Message-ID: <19990715003415.A4403@foobar.franken.de> Date: Thu, 15 Jul 1999 00:34:15 +0200 From: Harold Gutch To: "Brian F. Feldman" , Sheldon Hearn Cc: hackers@FreeBSD.ORG Subject: Re: a BSD identd References: <49928.931911388@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Brian F. Feldman on Tue, Jul 13, 1999 at 11:47:33PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 13, 1999 at 11:47:33PM -0400, Brian F. Feldman wrote: > We don't _need_ pidentd anymore. It will load down a system more than > the inetd's implementation of ident will. Therefore, pidentd should be > phased out. Other than that, pidentd should be using > http://www.FreeBSD.org/~green/freebsd4.c and not linking with libkvm. > pidentd supports DES-encrypted tokens as replies instead of the plaintext usernames. As long as your identd (or any other replacement) does not support this, there is still valid use for pidentd. bye, Harold -- Sleep is an abstinence syndrome wich occurs due to lack of caffein. Wed Mar 4 04:53:33 CET 1998 #unix, ircnet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 15:35:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id A9A7C15629 for ; Wed, 14 Jul 1999 15:35:22 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA96843; Wed, 14 Jul 1999 15:34:55 -0700 (PDT) (envelope-from dillon) Date: Wed, 14 Jul 1999 15:34:55 -0700 (PDT) From: Matthew Dillon Message-Id: <199907142234.PAA96843@apollo.backplane.com> To: Jason Thorpe Cc: "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907142229.PAA02809@lestat.nas.nasa.gov> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :One option is to special-case overcommit the stack. Another is to :set the default stack limits to something more reasonable on a system :where overcommit is disabled. : : -- Jason R. Thorpe Try setting all the resource limits to something reasonable on general principles. It would work as well in an overcommit system as it would in a non-overcommit system. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 15:35:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 3E6EF1565E for ; Wed, 14 Jul 1999 15:35:18 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id QAA11267; Wed, 14 Jul 1999 16:34:47 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id QAA29442; Wed, 14 Jul 1999 16:34:46 -0600 Date: Wed, 14 Jul 1999 16:34:46 -0600 Message-Id: <199907142234.QAA29442@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: cgd@netbsd.org (Chris G. Demetriou) Cc: Matthew Dillon , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <871zecyx0k.fsf@redmail.redback.com> References: <199907132110.OAA23817@lestat.nas.nasa.gov> <199907132114.OAA80781@apollo.backplane.com> <877lo4z0pe.fsf@redmail.redback.com> <199907132212.PAA81234@apollo.backplane.com> <871zecyx0k.fsf@redmail.redback.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [ Trimmed CC list a bit ] > > :* even if you are not willing to pay that price, there _are_ people > > :who are quite willing to pay that price to get the benefits that they > > :see (whether it's a matter of perception or not, from their > > :perspective they may as well be real) of such a scheme. > > > > Quite true. In the embedded world we preallocate memory and shape > > the programs to what is available in the system. But if we run out > > of memory we usually panic and reboot - because the code is designed > > to NOT run out of memory and thus running out of memory is a catastrophic > > situation. *ACK* This is unacceptable in many 'embedded' systems. > There's a whole spectrum of embedded devices, and applications that > run on them. That definition works for some of them, but definitely > not all. > Totally agreed. A previous poster brought up the fact that *some* embedded systems are built to deal with 'out of memory' situations, and that the 'total' amount of memory used in the system can be used by other parts of the system. For performance reasons, a particular application may choose to 'cache' data, but in low memory situation it can 'free' up alot of memory. You don't want to put hard-coded limits the process simply because if the memory is there you want it to be able to use it, but you *certainly* don't want to go through a reboot just to get memory back. [ And, I don't want to write my own OS to do this for me. :) ] (However, I agree that for general purpose computing, over-commit is the way to go. But, *BSD is not just for general purpose computing, although that is it's primary market.) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 15:38: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from nothing-going-on.demon.co.uk (nothing-going-on.demon.co.uk [193.237.89.66]) by hub.freebsd.org (Postfix) with ESMTP id B1DB615514 for ; Wed, 14 Jul 1999 15:38:00 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.9.3/8.9.2) id XAA74843; Wed, 14 Jul 1999 23:34:23 +0100 (BST) (envelope-from nik) Date: Wed, 14 Jul 1999 23:34:23 +0100 From: Nik Clayton To: Sheldon Hearn Cc: Nik Clayton , hackers@freebsd.org Subject: Re: docs/12377: doc patch for login_cap. Message-ID: <19990714233423.A71372@catkin.nothing-going-on.org> References: <19990708205958.A91668@catkin.nothing-going-on.org> <88423.931513178@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <88423.931513178@axl.noc.iafrica.com>; from Sheldon Hearn on Fri, Jul 09, 1999 at 11:39:38AM +0200 Organization: Nik at home, where there's nothing going on Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 09, 1999 at 11:39:38AM +0200, Sheldon Hearn wrote: > On Thu, 08 Jul 1999 20:59:58 +0100, Nik Clayton wrote: > > With that in mind, how about this patch (in conjunction with the patch to > > login.conf in the original PR, which just updates a comment)? > > This looks much better. :-) Committing it now. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <375143b5@cs.colorado.edu> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 15:46:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id C77A014E8C for ; Wed, 14 Jul 1999 15:46:27 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA96901; Wed, 14 Jul 1999 15:45:02 -0700 (PDT) (envelope-from dillon) Date: Wed, 14 Jul 1999 15:45:02 -0700 (PDT) From: Matthew Dillon Message-Id: <199907142245.PAA96901@apollo.backplane.com> To: Nate Williams Cc: cgd@netbsd.org (Chris G. Demetriou), freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132110.OAA23817@lestat.nas.nasa.gov> <199907132114.OAA80781@apollo.backplane.com> <877lo4z0pe.fsf@redmail.redback.com> <199907132212.PAA81234@apollo.backplane.com> <871zecyx0k.fsf@redmail.redback.com> <199907142234.QAA29442@mt.sri.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> > :> > Quite true. In the embedded world we preallocate memory and shape :> > the programs to what is available in the system. But if we run out :> > of memory we usually panic and reboot - because the code is designed :> > to NOT run out of memory and thus running out of memory is a catastrophic :> > situation. : :*ACK* This is unacceptable in many 'embedded' systems. Don't confuse a watchdog panic from other conditions. If the embedded system software is supposed to deal with a low-memory condition and can't, the failsafe is all that's left between it and infinity. The statement that the kernel's overcommit methodology somehow prevents one from being able to build embedded systems on top of it is just plain incorrect. The embedded system is perfectly capable of implementing its own memory management to avoid the filesafe provided by the kernel. Most of the embedded work I've done -- mainly remote telemetry units running with flash and a megabyte or so of ram -- panic and reboot if they run out of memory. I have several dozen units in the field each keeping track of several thousand data points on 2 minute intervals which have not ever crashed. The only time we reboot them is when we need to upgrade the OS core. The last time was 4 years ago. *These* units will panic and reboot if they run out of memory because the software is designed not to. It is as simple as that. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 15:50:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id A8F6214E8F for ; Wed, 14 Jul 1999 15:50:05 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id QAA11499; Wed, 14 Jul 1999 16:49:58 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id QAA29554; Wed, 14 Jul 1999 16:49:57 -0600 Date: Wed, 14 Jul 1999 16:49:57 -0600 Message-Id: <199907142249.QAA29554@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matthew Dillon Cc: Nate Williams , cgd@netbsd.org (Chris G. Demetriou), freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <199907142245.PAA96901@apollo.backplane.com> References: <199907132110.OAA23817@lestat.nas.nasa.gov> <199907132114.OAA80781@apollo.backplane.com> <877lo4z0pe.fsf@redmail.redback.com> <199907132212.PAA81234@apollo.backplane.com> <871zecyx0k.fsf@redmail.redback.com> <199907142234.QAA29442@mt.sri.com> <199907142245.PAA96901@apollo.backplane.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :> > Quite true. In the embedded world we preallocate memory and shape > :> > the programs to what is available in the system. But if we run out > :> > of memory we usually panic and reboot - because the code is designed > :> > to NOT run out of memory and thus running out of memory is a catastrophic > :> > situation. > : > :*ACK* This is unacceptable in many 'embedded' systems. > > Don't confuse a watchdog panic from other conditions. If the embedded > system software is supposed to deal with a low-memory condition and can't, > the failsafe is all that's left between it and infinity. > > The statement that the kernel's overcommit methodology somehow prevents > one from being able to build embedded systems on top of it is just plain > incorrect. The embedded system is perfectly capable of implementing its > own memory management to avoid the filesafe provided by the kernel. It is. But, it's not the most effecient/effective way of doing it. Sometimes it's best to let the 'kernel' do the things it does best, and let the users worry about the things they do best. The kernel manages memory alot more effeciently than any userland process can do, so why not let it? > Most of the embedded work I've done -- mainly remote telemetry > units running with flash and a megabyte or so of ram -- panic and > reboot if they run out of memory. Most of the work we've done wouldn't allow this, especially if we were using an OS like FreeBSD with a fairly long bootup time. Especially if it can be avoided. Yes, we could (and did) do our own memory management, but it seems to me that the kernel has alot more information available to it and would do it better than I could. Then again, maybe I'm totally confused about how the VM system 'does its thing', and in reality it's no better at it than our code, just alot more complex for no reason. :) :) :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 15:56: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id 94959154B7 for ; Wed, 14 Jul 1999 15:56:05 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id PAA02200; Wed, 14 Jul 1999 15:51:14 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907142251.PAA02200@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Jonathan Lemon Cc: hackers@freebsd.org Subject: Re: tcp windowsize query? In-reply-to: Your message of "Wed, 14 Jul 1999 16:12:46 CDT." <199907142112.QAA10842@free.pcs> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Jul 1999 15:51:14 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In article you write: > >> delayed ack sounds interesting.... > > > >Turning that off disables TCP slow-start. It's a huge performance > >booster for things like SMB service, where you have lots of short-lived > >TCP connections on a local net. > > Mike probably already knows this, but just a general clarification: > > No, it does _not_ turn off slow-start. Normally a TCP implementation > will delay sending an ACK to the peer until the TCP fasttimer expires, > or certain other conditions are met. The goal here is to amortize an > ACK over several incoming data packets. Yeah, brain fart. Slow start != delayed ACK. Blah. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 16: 3: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 881CA15454 for ; Wed, 14 Jul 1999 16:02:51 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA97044; Wed, 14 Jul 1999 16:02:43 -0700 (PDT) (envelope-from dillon) Date: Wed, 14 Jul 1999 16:02:43 -0700 (PDT) From: Matthew Dillon Message-Id: <199907142302.QAA97044@apollo.backplane.com> To: Nate Williams Cc: cgd@netbsd.org (Chris G. Demetriou), freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132110.OAA23817@lestat.nas.nasa.gov> <199907132114.OAA80781@apollo.backplane.com> <877lo4z0pe.fsf@redmail.redback.com> <199907132212.PAA81234@apollo.backplane.com> <871zecyx0k.fsf@redmail.redback.com> <199907142234.QAA29442@mt.sri.com> <199907142245.PAA96901@apollo.backplane.com> <199907142249.QAA29554@mt.sri.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Most of the work we've done wouldn't allow this, especially if we were :using an OS like FreeBSD with a fairly long bootup time. Especially if :it can be avoided. : :Yes, we could (and did) do our own memory management, but it seems to me :that the kernel has alot more information available to it and would do :it better than I could. Then again, maybe I'm totally confused about :how the VM system 'does its thing', and in reality it's no better at it :than our code, just alot more complex for no reason. :) :) :) : :Nate The kernel just isn't the best place to do this. The level of sophistication required to satisfy the larger set of programming is much greater then anything discussed here. The last thing that the kernel should be doing is returning NULL from malloc() to a program which is operating within its specifications. That doesn't help anyone, least of all the programmer who now has to deal not only with the complexity of the project he is working on, but must also deal with the potential that the OS will step in at any time and give him an error that he must deal with in a sophisticated fashion even when his software is operating properly. The same goes for non-embedded work. Why is it that programs generally exit when they encounter a memory allocation failure? Because it is too damn hard to ensure proper operation at every instance where a program's allocation may fail, especially if the program getting the failure is not responsible for the problem. The glib statement that "programs should deal with memory allocation errors" provides no solution. 98% of the source code in the BSD code base will exit if a memory allocation fails, and I don't know anyone who wants to go through and somehow "fix" it all (and one could argue what the "fix" should be when something like grep or a shell has a memory allocation failure). To require that this code be made twice as sophisticated as it is already in order to deal with a non-overcommit model reliably is a fantasy. Due to the side effects it causes, to put the capability in the kernel in this situation will make things even more unstable then the kernel's current operation. A situation made much worse by the magnitude of the resources necessary to bring such a system up to the same performance levels attainable by a standard overcommit system. The only case where this does not occur is also the case where the programmer can fairly easily manage the memory to avoid the overcommit from occuring in the first place. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 16:10: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id A763814EC0 for ; Wed, 14 Jul 1999 16:09:55 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id RAA11836; Wed, 14 Jul 1999 17:09:53 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id RAA29776; Wed, 14 Jul 1999 17:09:52 -0600 Date: Wed, 14 Jul 1999 17:09:52 -0600 Message-Id: <199907142309.RAA29776@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matthew Dillon Cc: Nate Williams , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <199907142302.QAA97044@apollo.backplane.com> References: <199907132110.OAA23817@lestat.nas.nasa.gov> <199907132114.OAA80781@apollo.backplane.com> <877lo4z0pe.fsf@redmail.redback.com> <199907132212.PAA81234@apollo.backplane.com> <871zecyx0k.fsf@redmail.redback.com> <199907142234.QAA29442@mt.sri.com> <199907142245.PAA96901@apollo.backplane.com> <199907142249.QAA29554@mt.sri.com> <199907142302.QAA97044@apollo.backplane.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :Most of the work we've done wouldn't allow this, especially if we were > :using an OS like FreeBSD with a fairly long bootup time. Especially if > :it can be avoided. > : > :Yes, we could (and did) do our own memory management, but it seems to me > :that the kernel has alot more information available to it and would do > :it better than I could. Then again, maybe I'm totally confused about > :how the VM system 'does its thing', and in reality it's no better at it > :than our code, just alot more complex for no reason. :) :) :) > : > > The kernel just isn't the best place to do this. The level of > sophistication required to satisfy the larger set of programming > is much greater then anything discussed here. The last thing that the > kernel should be doing is returning NULL from malloc() to a program > which is operating within its specifications. You and I disagree on this statement. Returning NULL is completely acceptable, and is the 'specification' for many OS's, including FreeBSD if you set user/process limits. > That doesn't help anyone, least of all the programmer who now has > to deal not only with the complexity of the project he is working > on, but must also deal with the potential that the OS will step in > at any time and give him an error that he must deal with in a > sophisticated fashion even when his software is operating > properly. Returning NULL isn't an error, it's an indication that there is no more memory. Don't think if it as an error, think of it as a hint. General purpose computing tends to make one think that out-of-memory condition is an un-acceptable situation, and the program must exit. FreeBSD exacerbates this by rarely returning NULL and randomly killing off processes which may/may not be involved in the memory fracus. > > The same goes for non-embedded work. Why is it that programs generally > exit when they encounter a memory allocation failure? Because programmer's are lazy. Really, and I do it all the time as well. But, that's because on 'general purpose' computing hardware, re-starting the process or having to wait for a reboot is 'acceptable'. But, to many of my collegues who are running simulations that are running for DAYS and WEEKS, they write code that 'saves the state' of the system when they can't get critical memory, *THEN* abort the application. Yes, it's possible that the process of saving state *may* not work if the system is *really* low on memory, but then again it may work. But, more times than not it *does* (appear) to work, and the work is not lost. > with memory allocation errors" provides no solution. 98% of the source > code in the BSD code base will exit if a memory allocation fails, and > I don't know anyone who wants to go through and somehow "fix" it all > (and one could argue what the "fix" should be when something like grep or > a shell has a memory allocation failure). To require that this code be > made twice as sophisticated as it is already in order to deal with a > non-overcommit model reliably is a fantasy. Who said anything about using the bsd code base in an embedded system? Also, you *can* use limits for that stuff. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 16:16:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 97C8E14DE5 for ; Wed, 14 Jul 1999 16:16:42 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA97134; Wed, 14 Jul 1999 16:16:20 -0700 (PDT) (envelope-from dillon) Date: Wed, 14 Jul 1999 16:16:20 -0700 (PDT) From: Matthew Dillon Message-Id: <199907142316.QAA97134@apollo.backplane.com> To: Nate Williams Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907132110.OAA23817@lestat.nas.nasa.gov> <199907132114.OAA80781@apollo.backplane.com> <877lo4z0pe.fsf@redmail.redback.com> <199907132212.PAA81234@apollo.backplane.com> <871zecyx0k.fsf@redmail.redback.com> <199907142234.QAA29442@mt.sri.com> <199907142245.PAA96901@apollo.backplane.com> <199907142249.QAA29554@mt.sri.com> <199907142302.QAA97044@apollo.backplane.com> <199907142309.RAA29776@mt.sri.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Returning NULL isn't an error, it's an indication that there is no more :memory. Don't think if it as an error, think of it as a hint. It's only a hint if it is returned due to the process resource limit being hit. If it is returned due to the system running out of swap, it would be an error. Look at it this way: Processes run in their own VM address space and should theoretically be unaffected by other processes. If your resource limits allow a process, say, 32MB of ram, the process should be confident in its ability to utilize that much if it needs to without running out of memory. This is what FreeBSD and most UNIX's give to processes. But if you change the rules so that process A can run the system out of swap (or, in the case of a non-overcommit model, out of reservable space), then process B can get allocation errors without even coming close to their allocation limit. This creates a dependancy between two completely independant processes possibly owned two totally unrelated users. This is not acceptable, and is precisely why this sort of behavior does not occur. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 16:19:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 6387314C83 for ; Wed, 14 Jul 1999 16:19:44 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id RAA11951; Wed, 14 Jul 1999 17:18:31 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id RAA29826; Wed, 14 Jul 1999 17:18:30 -0600 Date: Wed, 14 Jul 1999 17:18:30 -0600 Message-Id: <199907142318.RAA29826@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matthew Dillon Cc: Nate Williams , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-Reply-To: <199907142316.QAA97134@apollo.backplane.com> References: <199907132110.OAA23817@lestat.nas.nasa.gov> <199907132114.OAA80781@apollo.backplane.com> <877lo4z0pe.fsf@redmail.redback.com> <199907132212.PAA81234@apollo.backplane.com> <871zecyx0k.fsf@redmail.redback.com> <199907142234.QAA29442@mt.sri.com> <199907142245.PAA96901@apollo.backplane.com> <199907142249.QAA29554@mt.sri.com> <199907142302.QAA97044@apollo.backplane.com> <199907142309.RAA29776@mt.sri.com> <199907142316.QAA97134@apollo.backplane.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :Returning NULL isn't an error, it's an indication that there is no more > :memory. Don't think if it as an error, think of it as a hint. > > It's only a hint if it is returned due to the process resource limit > being hit. If it is returned due to the system running out of swap, > it would be an error. Not necessarily. > This creates a dependancy between two completely independant processes > possibly owned two totally unrelated users. This is not acceptable, > and is precisely why this sort of behavior does not occur. In embedded systems, there are no such things as 'independant' processes that are given unlimited access to the system. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 16:29: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from grebe.prod.itd.earthlink.net (grebe.prod.itd.earthlink.net [207.217.120.100]) by hub.freebsd.org (Postfix) with ESMTP id 50A8614C83 for ; Wed, 14 Jul 1999 16:29:01 -0700 (PDT) (envelope-from evmax@earthlink.net) Received: from earthlink.net (sdn-ar-002njnbruP319.dialsprint.net [168.191.61.97]) by grebe.prod.itd.earthlink.net (8.9.3/8.9.3) with ESMTP id QAA08247 for ; Wed, 14 Jul 1999 16:28:45 -0700 (PDT) Message-ID: <378D1D3F.F704994F@earthlink.net> Date: Wed, 14 Jul 1999 19:29:03 -0400 From: Maksim Yevmenkin X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: misc/12633: CMI8330 chip based integrated sound card produce no output Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I have some minor probem with my CMI8330 chip based integrated sound card on m726 motherboard. Here's the URL where you can find how to fix it: http://www.cslab.vt.edu/~jobaldwi/cmi8330init.tar.gz ============= cut here ============= Thank you very much for your problem report. It has the internal identification `misc/12633'. The individual assigned to look at your report is: freebsd-bugs. >Category: misc >Responsible: freebsd-bugs >Synopsis: CMI8330 chip based integrated sound card produce no output >Arrival-Date: Tue Jul 13 15:30:01 PDT 1999 ================ end =================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 16:44:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from host.kw.igs.net (host.kw.igs.net [216.58.99.2]) by hub.freebsd.org (Postfix) with ESMTP id F104514D9E for ; Wed, 14 Jul 1999 16:44:31 -0700 (PDT) (envelope-from schoedel@kw.igs.net) Received: from [216.58.99.44] (ttyA0c.kw.igs.net [216.58.99.44]) by host.kw.igs.net (8.8.5/8.6.12) with ESMTP id TAA03191; Wed, 14 Jul 1999 19:44:16 -0400 (EDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: In-Reply-To: <378C9BFC.A3273D45@newsguy.com> References: <55586E7391ACD211B9730000C11002761796F3@r-lmh-wi-100.corpnet.at> Date: Wed, 14 Jul 1999 19:45:39 -0400 To: tech-userlevel@netbsd.org, freebsd-hackers@FreeBSD.org From: Kevin Schoedel Subject: Re: Replacement for grep(1) (part 2) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999/07/14 at 11:17pm +0900, "Daniel C. Sobral" wrote: >Ladavac Marino wrote: >> >> This topic has been trashed to death a few months ago. There is no >> win-win situation in presence of processes which allocate a lot of memory >> without actually using it (read: your typical FORTRAN library). > >This is not about just Fortran libraries. OK, I'll bite. I'm curious as to why Fortran's library has been used as an example here. Some years ago I worked on a Fortran compiler; I wrote its library as well as its front end. The targets were (then) high-performance graphics cards, with little memory, no MMU, no swap, and certainly no sparse objects in the intrinsics. (Are you referring to user libraries that try to provide 'large enough' fixed-size arrays? One can't stop people from doing silly things. One *can* try to stop these silly things from interfering with non-silly things.) This thread originated with C's library, however, not with Fortran's -- in particular with malloc(), which is defined by the ANSI standard to either return NULL, or usable memory. Killing the program later for trying to use successfully malloc()'d memory (what the standard would call 'undefined behavior') isn't an option. If a program that calls only standard C functions can die when it uses malloc()'d memory then, as I read the document, the system does not support standard C. In standard C, malloc() returns something functionally equivalent to committed memory, or it returns NULL. On a system that has a writable file system, a standard-conforming version of malloc() could presumably be written by having malloc() create a file, make it non-sparse, and mmap() it. This seems unattractive. >Imagine a reasonably big >program, like Netscape or Emacs, of which you usually just use a >subset of features. There can easily be many megabytes of code and >data in them you never actually use, or you don't _usually_ use >(like the people who use emacs like it was vi :). Without >overcommit, you need to allocate all that memory for the code, no >matter whether you end up using it or not. With overcommit, there is >no such problem. Code, static data, and not-yet-written writable data should be backed by the executable file, not by swap space, so unused code and tables should not be a problem. >And that's not all, either. > >Hell, people, if overcommit was not useful, everybody wouldn't be >doing it. If a program wants uncommitted space, it should request it by means beyond the standard C library functions (e.g. mmap() with MAP_NORESERVE). A program that does so can then deal with the consequences (e.g. a signal when unavailable space is touched), or die, as the case may be. Innocent bystanders should not be hit. (Of course, programs that use standard C functions like malloc() should be prepared to deal with the consequences of *that*, but the consequences should be the ones defined by the C standard, i.e. a NULL return from malloc().) Stack is more interesting. There might be a place for a global overcommit switch. I think I'd be happier with a scheme in which stack the first page or first few pages are committed (so that reasonable programs will never run into trouble) and remaining stack is over-/un-committed by default, along with means for unusual programs to commit (and/or test commitability of) subsequent pages. -- Kevin Schoedel "Sorry, Opus. I only have NetBSD on my computer." "Darn it. There *has* to be a place where I can use some bad software." -- 'User Friendly' 99/06/14 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 17: 7:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id 591F81501F; Wed, 14 Jul 1999 17:07:02 -0700 (PDT) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net (client-151-198-135-2.bellatlantic.net [151.198.135.2]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id UAA05043; Wed, 14 Jul 1999 20:05:46 -0400 (EDT) Message-ID: <378D2682.DA0D38A0@bellatlantic.net> Date: Wed, 14 Jul 1999 20:08:34 -0400 From: Sergey Babkin X-Mailer: Mozilla 4.07 [en] (X11; I; FreeBSD 3.0-980222-SNAP i386) MIME-Version: 1.0 To: Garance A Drosihn Cc: "Daniel C. Sobral" , Matthew Dillon , "Brian F. Feldman" , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907132346.TAA13780@bikini.ihack.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Garance A Drosihn wrote: > > At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote: > > In which case the program that consumed all memory will be killed. > > The program killed is +NOT+ the one demanding memory, it's the one > > with most of it. > > But that isn't always the best process to have killed off... > > One of my main freebsd machines is mainly here to run one > process, which is a pretty good-sized process (>40meg). If > I did get into a memory-shortage problem, I do *not* want > that process killed, I'd want some other processes killed. > > It would be nice to have a way to indicate that, a la SIGDANGER. Another option may be to add something like "importance classes". Suppose we assign an one-byte "importance level" to each process. When we get out of swap we start killing processes with the lowest importance level. This seems to be both easy to implement and a rather robust solution. It can be extended to more flexible policies: say, we divide this 8-bit number into two 4-bit fields. The high field will be "major importance level" the low field will be "importance sublevel". We permit the user processes to change their sublevel to any value as long their major level stays the same or becomes lower. This will allow the users to make differences between their programs but only in certain limits. The initial importance level may be set in /etc/login.conf. One more extension would be to use one bit as the ihneritance flag: if it is set, the child inherits the importance value from the parent. But if it's reset the child inherits its major level from the parent but the sublevel gets reset to 0. It may be useful for transparent calls of system(). Yet another extension would be to use two separate inheritance bits: one as described above, the secone one if reset means that the importance value of the child must be reset to the lowest one. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 17:40:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 528BC14CF8 for ; Wed, 14 Jul 1999 17:40:49 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id UAA40542; Wed, 14 Jul 1999 20:39:30 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <199907142218.PAA96575@apollo.backplane.com> References: <199907142127.OAA01681@lestat.nas.nasa.gov> Date: Wed, 14 Jul 1999 20:39:28 -0400 To: Matthew Dillon , Jason Thorpe From: Garance A Drosihn Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Cc: tech-userlevel@netbsd.org, freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 3:18 PM -0700 7/14/99, Matthew Dillon wrote: > This conversation is getting silly. Do you actually believe > that an operating system can magically protect itself 100% > from armloads of hostile users? > > Give me a break. You people are crazy. If you have something > worthwhile to say i'll listen, but these "the sky is falling!" > arguments are idiotic. Hmm. I didn't notice any sky-is-falling arguments in this thread, so I finally started looking around to see why such nasty replies keep showing up to what I considered reasonable questions... So, I finally looked back into the "replacement for grep" thread (which I have been ignoring ever since it stopped talking about the grep replacement), and I see this topic is being thrashed to death over there. I still think there could be some useful discussion on what I was *trying* to talk about here, but I guess it will have to wait until some other time given how exasperated people are getting. --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 18: 7:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id DEDA214ECF for ; Wed, 14 Jul 1999 18:07:37 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id VAA20478; Wed, 14 Jul 1999 21:07:34 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Wed, 14 Jul 1999 21:07:34 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Harold Gutch Cc: Sheldon Hearn , hackers@FreeBSD.org Subject: Re: a BSD identd In-Reply-To: <19990715003415.A4403@foobar.franken.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Jul 1999, Harold Gutch wrote: > On Tue, Jul 13, 1999 at 11:47:33PM -0400, Brian F. Feldman wrote: > > We don't _need_ pidentd anymore. It will load down a system more than > > the inetd's implementation of ident will. Therefore, pidentd should be > > phased out. Other than that, pidentd should be using > > http://www.FreeBSD.org/~green/freebsd4.c and not linking with libkvm. > > > pidentd supports DES-encrypted tokens as replies instead of the > plaintext usernames. As long as your identd (or any other > replacement) does not support this, there is still valid use for > pidentd. And pidentd will still be supported. Eventually, I'd like to have those huge majority who do not use DES tokens with pidentd move to the inetd identd (when committed)... > > bye, > Harold > > -- > Sleep is an abstinence syndrome wich occurs due to lack of caffein. > Wed Mar 4 04:53:33 CET 1998 #unix, ircnet > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 18:30:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 811A014F54 for ; Wed, 14 Jul 1999 18:30:48 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA05927; Wed, 14 Jul 1999 18:29:50 -0700 (PDT) (envelope-from dillon) Date: Wed, 14 Jul 1999 18:29:50 -0700 (PDT) From: Matthew Dillon Message-Id: <199907150129.SAA05927@apollo.backplane.com> To: Garance A Drosihn Cc: "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907132346.TAA13780@bikini.ihack.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :For the moment I'll pretend that you honestly think that is an :answer, and I'll note that the very same machine may have well :over 100 processes each of which takes 1-2 meg of memory. If :the machine hits a really-out-of-memory error, I would be much :much happier to see all 100+ of those processes killed, at once, :than the one 40-meg process. : :Now tell me how I fix my swap under those circumstances. If :the answer is "buy infinite memory (ram or disk)", then we don't :need any overcommit policy in the first place. Note that the :problem might be that these 100 processes start taking up 5 or :10 meg than the 2 meg I'm used to. Everything scales. If the load on your machine is such that you have hundreds of processes taking 1-2MB of memory, then lets assume that such a machine has a reasonable memory configuration of, say, 256MB of ram, and a reasonable swap configuration of, say, 1GB. Under normal operating conditions perhaps 100MB might be swapped out, giving you 900MB of margin. The actual VM footprint on such a machine might run on the order of 10 GB (rough guess) of which 350MB or so has actually been allocated). With 900MB of margin - which I might add is only about $30 worth of disk space, and reasonable process limits, it seems highly unlikely that the machine will ever run out of swap, even if a user makes an honest mistake. I also rather seriously doubt that a hostile user would have any more or less success blowing away your process with the non-overcommit model verses otherwise. If 1G isn't enough, spend another $30 and throw 2G of swap online. Or perhaps dedicate an entire $150 disk and throw 6+ GB of swap online. The equivalent setup using a non-overcommit model would require considerably more swap to have the same reliability. Plus you have to realize that with either model if you are talking about saving your work, the same code that does the save-and-exit in the non-overcommit model can just as easily do a checkpoint once an hour in the standard overcommit model. Code that can't save/checkpoint would not survive either model. Disk is cheap. Memory isn't (though it's getting better). Everything scales. :I didn't mean to be casting asperisions on the general idea of :overcommitting, or whatever it is that has your shorts all tied :up in a knot. : :--- :Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu :Senior Systems Programmer or drosih@rpi.edu -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 18:52:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 974F515081 for ; Wed, 14 Jul 1999 18:52:22 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id TAA26360; Wed, 14 Jul 1999 19:51:58 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id TAA60252; Wed, 14 Jul 1999 19:51:57 -0600 (MDT) Message-Id: <199907150151.TAA60252@harmony.village.org> To: wayne@crb-web.com Subject: Re: changing argv[0] after fork() Cc: Andy Doran , FreeBSD Hackers List In-reply-to: Your message of "Wed, 14 Jul 1999 13:28:07 EDT." References: Date: Wed, 14 Jul 1999 19:51:57 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Wayne Cuddy writes: : Even though I am developing on FBSD is there a "more portable" way to do this? No. Well, not short of execing. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 19:23:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gizmo.internode.com.au (gizmo.internode.com.au [192.83.231.115]) by hub.freebsd.org (Postfix) with ESMTP id 0B4C814E14; Wed, 14 Jul 1999 19:23:06 -0700 (PDT) (envelope-from newton@gizmo.internode.com.au) Received: (from newton@localhost) by gizmo.internode.com.au (8.9.3/8.9.3) id LAA04075; Thu, 15 Jul 1999 11:51:49 +0930 (CST) (envelope-from newton) From: Mark Newton Message-Id: <199907150221.LAA04075@gizmo.internode.com.au> Subject: Re: Swap overcommit To: lyndon@orthanc.ab.ca Date: Thu, 15 Jul 1999 11:51:49 +0930 (CST) Cc: ben@skunk.org, green@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199907141938.NAA05484@orthanc.ab.ca> from "lyndon@orthanc.ab.ca" at Jul 14, 99 01:38:16 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-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG lyndon@orthanc.ab.ca wrote: > The semantics of malloc() have been defined since almost the dawn of > time. From the current manpage: > RETURN VALUES > The malloc() and calloc() functions return a pointer to the allocated > memory if successful; otherwise a NULL pointer is returned. > Nowhere does it say that allocated memory might not exist. Nowhere > does it say that I have to touch all the allocated pages to make > sure they are really there. Nowhere does it say process death at > some non-deterministic time in the future might be a side effect > of calling malloc(). It's just using a different definition of "successful return of malloc()" to the one you're trying to use :-) - mark ---- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 19:26:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from Hydro.CAM.ORG (Hydro.CAM.ORG [198.168.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 68207153C7 for ; Wed, 14 Jul 1999 19:26:46 -0700 (PDT) (envelope-from intmktg@CAM.ORG) Received: from Stratus.CAM.ORG (Stratus.CAM.ORG [198.168.100.6]) by Hydro.CAM.ORG (8.8.8/8.8.4) with ESMTP id WAA02760 for ; Wed, 14 Jul 1999 22:26:32 -0400 (EDT) Date: Wed, 14 Jul 1999 22:26:44 -0400 (EDT) From: Marc Tardif To: freebsd-hackers@freebsd.org Subject: gdb instead of adb Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is the reason why adb hasn't been ported to freebsd because the source is proprietary? If gdb should suffice for my debugging needs, how can a breakpoint be set at a particular interrupt, or even at any interrupt? The break command only seems to accept functions, offsets, linenumbers and addresses... I'm all out of ideas and the gdb info file isn't helping. Thanks in advance, Marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 20:12:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id F183A14FE6 for ; Wed, 14 Jul 1999 20:12:27 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id MAA15362; Thu, 15 Jul 1999 12:11:04 +0900 (JST) Message-ID: <378D5066.8084BD71@newsguy.com> Date: Thu, 15 Jul 1999 12:07:18 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Garance A Drosihn Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907132346.TAA13780@bikini.ihack.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Garance A Drosihn wrote: > > >> One of my main freebsd machines is mainly here to run one > >> process, which is a pretty good-sized process (>40meg). If > >> I did get into a memory-shortage problem, I do *not* want > >> that process killed, I'd want some other processes killed. > > > > Just size your swap so that it becomes unlikely that you run out of > > memory before a process exceeds 40Mb. > > > > And I mean it. > > For the moment I'll pretend that you honestly think that is an > answer, and I'll note that the very same machine may have well > over 100 processes each of which takes 1-2 meg of memory. If > the machine hits a really-out-of-memory error, I would be much > much happier to see all 100+ of those processes killed, at once, > than the one 40-meg process. > > Now tell me how I fix my swap under those circumstances. If > the answer is "buy infinite memory (ram or disk)", then we don't > need any overcommit policy in the first place. Note that the > problem might be that these 100 processes start taking up 5 or > 10 meg than the 2 meg I'm used to. As a matter of fact, I honestly think that's an answer. If 100 processes start taking 5 or 10 meg, there is something mightly wrong. It *won't* happen. A hostile attack may happen, which can be dealt with limits. Running out of memory is something that happens when you get runaway processes, when you are under attack, or when you have a badly configured system. The first two cases are dealt with limits. _IF_ you have trusted accounts, they better be *trusted* accounts. These may have runaway processes. So, you have to set up the swap to take this into account. This is a matter of *one* process suddenly spiking memory usage. 100 processes suddenly spiking memory usage just *doesn't* happen. If it can happen in normal usage, then, yes, you have to configure swap for that. It's normal usage, after all. Infinite memory? Of course not. Just be realistic. > I once participated in a discussion on this very list where people > would discuss SIGDANGER with some degree of intelligence, instead > of offhand smart-aleck remarks. That discussion (as I remember) > ended with the conclusion that "SIGDANGER can be useful, but there's > a fair amount of work to do first". My comment was actually meant as > a follow-up to that earlier discussion, just to see if anything had > happened to get us closer to this. I made no offhand smart-aleck remarks. Everything I said to you I meant seriously. I was explaining why, imo, no one was answering to repeated mentions of SIGDANGER. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 21: 6:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 3C30D15152 for ; Wed, 14 Jul 1999 21:06:54 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id NAA22579; Thu, 15 Jul 1999 13:06:46 +0900 (JST) Message-ID: <378D535C.FD6D667C@newsguy.com> Date: Thu, 15 Jul 1999 12:19:56 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: John Nemeth Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907141949.MAA11413@vtn1.victoria.tc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Nemeth wrote: > > } > This is based upon your somewhat strange definition of "work". I assure > } > you that I have run many systems which don't use overcommit, and which I > } > quite frequently run into "out of VM" conditions, and which I can assure > } > you, work just fine. When they're getting to run out of VM, the system > } > is approaching paging death, which is as you'd expect (they're overloaded). > } > That is, adding more VM (more swap space) would be counterproductive. > } > } Would you care to name such systems? And, btw, a system consuming > } all memory is *not* necessarily approaching paging death. More > } likely, it is just storing a lot of data in the swap which will > } never be used (which is the whole point of overcommit in first > } place), and, thus, never paged in. > > If the data is stored in swap, then it is committed, whether the data > is used or not. Overcommitting only helps with memory that is allocated, > but not used. It's bad enough to have people in this debate that have > something of a clue, refusing to see the other side; we really don't need > people that have no clue at all. Or trollers. Letting it pass that you did not care to name such systems, let's try to make myself clear. You were talking about systems approaching "out of VM" condition, to use your words. This happens when almost all memory, RAM and swap, have been committed to programs, by definition. This can happen with things as simple as C++ objects being initialized, even if they then proceed to stay mainly inactive (C++ array initialization comes to mind). What I'm saying is that active usage of this committed memory is more unlikely than most of it being inactive, which still consumes swap but does not cause paging. > } Fine. Stay with the allocation of swap for DATA/BSS of each instance > } of the same program you are running. That alone is enough. > > Yes. In another post, you brought up the issue of TEXT. TEXT is > swapped in from the executable file and has been for a very long time. It > is simply not an issue. I never said TEXT. I said *CODE*. Like in Megabytes of modifiable Lisp code used by Emacs, the program I mentioned. Some of us have enough experience not to automatically equate code with TEXT, which is a C-ish thingy. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 21: 7:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id BAB71154C0 for ; Wed, 14 Jul 1999 21:07:38 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id NAA22659; Thu, 15 Jul 1999 13:07:24 +0900 (JST) Message-ID: <378D5742.3A8C3737@newsguy.com> Date: Thu, 15 Jul 1999 12:36:34 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: John Nemeth Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907142001.NAA16574@vtn1.victoria.tc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Nemeth wrote: > > } > But that isn't always the best process to have killed off... > } > } Sure it is. :-) Let's see... > > This statement is absurd. Only a comptetant admin can decide > which process can be killed. No arbitrary decision is going to be > correct. We are talking about what process the OS should kill automatically when it reaches this situation. What is the criteria that should be used? Is the "biggest process" the "best" process to be killed? Or is there another, better criteria? In this context, the statement makes perfect sense, even if you disagree with it. > } interesting, and a good implementation will very probably be > } committed. *BUT*, this is not as useful as it seems. Since the > } correct solution is buy more memory/increase swap (correct solution > } for our target markets, anyway), there is little incentive to > } implement it. > > In case you hadn't noticed, this debate is cross-posted to > NetBSD. NetBSD's target market isn't the same as FreeBSD's target > market. This answer is NOT the correct solution for NetBSD's target > market. Heck, except for one rather vocal person, FreeBSD's target > market may not consider it to be the correct solution either. I most > certainly do not consider it to be correct, and I admin a lot of > mission critical servers. I noticed, but I do not speak for NetBSD. Well, I do not speak for FreeBSD either, but I have well informed opinions on it. What I say, I say about FreeBSD. As for being "correct", it's really simple. Either you have enough memory, or you do not. If you don't have enough memory, a number of programs cannot function correctly. Sure, some programs might be able to deal with low-memory situations, but *other* programs *cannot* deal with it. It's impossible for them to accomplish their tasks if there is not enough memory. So, if you want that server to accomplish it's job, you need more memory. Which, btw, is cheaper than the man-hours needed to implement SIGDANGER. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 21: 8: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id D7F6E15152 for ; Wed, 14 Jul 1999 21:08:00 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id NAA22702; Thu, 15 Jul 1999 13:07:36 +0900 (JST) Message-ID: <378D5ABF.74B3DB2@newsguy.com> Date: Thu, 15 Jul 1999 12:51:27 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Robert Elz Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <20351.931984551@cs.mu.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Robert Elz wrote: > > Note that all this (large) VM I have described was filled with real data > (except for the odd times hen innd or named had just forked), none of it > could be overcommitted and just ignored. Whatever policy was in place, > the physical VM resources would have run out. In a standard Unix system, with standard Unix programs, it is very unlikely that "all this VM" was filled with real data. Take, for instance, the stacks. > Now, with overcommit mode, we get an extra 30 seconds of life, because > no doubt there are a few pages floating around that have been allocated > to some process, but nothing has bothered to write into yet. An extra 30 > seconds if we're lucky (except if we followed the advice given here > earlier which would indicate that only 1/8 the amount of swap space would > be needed, in which case these processes would never have gotten started > in the first place). After that short grace period, during which the Which is what I claim. Have you run it in overcommit mode? Did you actually get just 30 extra seconds? Sure as hell, the AIX systems I ran would have gotten a LOT more than 30 extra seconds going from non-overcommit to overcommit. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 21: 8:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 010C4154D0 for ; Wed, 14 Jul 1999 21:08:35 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id NAA22750; Thu, 15 Jul 1999 13:07:55 +0900 (JST) Message-ID: <378D5C5D.13C65239@newsguy.com> Date: Thu, 15 Jul 1999 12:58:21 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Jason Thorpe Cc: Matthew Dillon , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907142229.PAA02809@lestat.nas.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jason Thorpe wrote: > > > > ...um, so, make the code that deals with faulting in the stack a bit smarter. > > > > Uh? Like what? Like overcommitting, for instance? The beauty of > > overcommitting is that either you do it or you don't. :-) > > One option is to special-case overcommit the stack. Another is to > set the default stack limits to something more reasonable on a system > where overcommit is disabled. And what do you do, then, with the processes that happen to have legitimate use for more stack? Or maybe you just find out how much stack each process uses, and then set limits appropriate for each one? Which is the equivalent of setting limits to each user, of course... -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 21:11:19 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 295C515152 for ; Wed, 14 Jul 1999 21:11:15 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id NAA22759; Thu, 15 Jul 1999 13:08:01 +0900 (JST) Message-ID: <378D5D13.EA7AD97D@newsguy.com> Date: Thu, 15 Jul 1999 13:01:23 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Sergey Babkin Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907132346.TAA13780@bikini.ihack.net> <378D2682.DA0D38A0@bellatlantic.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sergey Babkin wrote: > > > It would be nice to have a way to indicate that, a la SIGDANGER. > > Another option may be to add something like "importance classes". > Suppose we assign an one-byte "importance level" to each process. > When we get out of swap we start killing processes with the lowest > importance level. This seems to be both easy to implement and > a rather robust solution. This is as easy to do as setting limits, which has the added benefit of not having any process killed. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 21:25:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id C2D7214D2F; Wed, 14 Jul 1999 21:25:46 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA06697; Wed, 14 Jul 1999 21:25:31 -0700 (PDT) (envelope-from dillon) Date: Wed, 14 Jul 1999 21:25:31 -0700 (PDT) From: Matthew Dillon Message-Id: <199907150425.VAA06697@apollo.backplane.com> To: lyndon@orthanc.ab.ca Cc: "Brian F. Feldman" , freebsd-hackers@FreeBSD.ORG Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907141833.MAA05320@orthanc.ab.ca> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Our IMAP server routinely show a footprint of about 1MB private storage. :This is constant for most operations. However, when you get into doing :SEARCH and SORT, there are certain cases where we need memory, sometimes :a *lot* of memory. : :Your proposal is that my *well behaved* application should be arbitrarily :killed, leaving the client stuck with a) no results and b) no IMAP :connection, in this situation. (And think threaded. That one server :could be handling *hundreds* of clients.) This is preferable to :returning a NULL to the malloc() request, which I can handle :gracefully by simply returning a NO response to the IMAP client? : :What it so evil about having a reasonably intelligent malloc() that :tells the truth, and returns unused memory to the system? Overcommit :is for lazy programmers, plain and simple. At least the SGI documentation :about overcommit admits that (or at least, did at one time). : :--lyndon If you are running an IMAP server that regularly runs out of swap space, you have a configuration problem which needs to be addressed. It's as simple as that. What you are putting forth is an example of something that will never happen on a properly configured server. In regards to the general case where one is running third-party applications. Here you are assuming that you can go in and modify every single piece of software running on the machine to deal with malloc() returning NULL. Because if you don't, the machine isn't going to be very stable. Not only that, you are assuming that you will make the correct decision on what action to take when malloc() *does* return NULL. If you decide to return an error code but not exit, what happens when a potential blowup situation results in thousands of imap processes being run on the system, and NONE of them exit when their malloc() fails? The problem is a whole lot more complex then simply having the OS return NULL from a malloc(). Currently the OS kills processes as a last resort. The idea is that no nominally running system runs out of swap. Now you propose to take away the kernel's ability to recover some memory as a last resort and instead put it into the hands of the very user or root-run processes that are causing the problem in the first place! A much better solution would be to write a simple watchdog script that notices when swap space is low and does the right thing -- e.g. kills the non-essential processes and leaves the essential ones alone. Then the kernel never actually reaches a state of last-resort. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 21:30: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 4063315144 for ; Wed, 14 Jul 1999 21:29:57 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA06718; Wed, 14 Jul 1999 21:28:34 -0700 (PDT) (envelope-from dillon) Date: Wed, 14 Jul 1999 21:28:34 -0700 (PDT) From: Matthew Dillon Message-Id: <199907150428.VAA06718@apollo.backplane.com> To: D.Thomas@vthrc.uq.edu.au (Danny Thomas) Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Ted Faber :>For every strategy there's a counterstrategy. :exactly: the disappointing thing about this whole thread is there's been :little discussion of implementing a (tunable) policy how to handle the :situation when resource shortage materialises. : :Overcommitment can be useful, maybe even for most people... : :>Killing the biggest is simple to implement and usually right. :... but some people don't want that policy, at least on some of their :systems. Does FreeBSD offer alternatives? Is so, they've been conspicuously :absent from discussion, which might have taken things into a more :productive vein. What do other over-committing systems offer? : :Danny Thomas Here's an alternative: whlie (1) sleep 60 blah blah blah run pstat -s, get available swap. if available swap < 200MB then blow away some non-critical processes if no non-critical processes remain blow away everything not owned by root and yell for help. if no no-root processes remain do nothing. let the kernel blow away the biggest process when swap actually runs out. endif endif endif end How long do you suppose it would take to actually write that script? One hour? Two hours? Not long, I think. Problem solved. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 21:37:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id E7E8E1513C for ; Wed, 14 Jul 1999 21:37:17 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA06766; Wed, 14 Jul 1999 21:37:08 -0700 (PDT) (envelope-from dillon) Date: Wed, 14 Jul 1999 21:37:08 -0700 (PDT) From: Matthew Dillon Message-Id: <199907150437.VAA06766@apollo.backplane.com> To: lyndon@orthanc.ab.ca Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) References: <199907141755.LAA05231@orthanc.ab.ca> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> I mean, jeeze, the reservation for the program stack alone would eat :> up all your available swap space! What is a reasonable stack size? The :> system defaults to 8MB. Do we rewrite every program to specify its own :> stack size? How do we account for architectural differences? : :The alternative is to rewrite every program that assumes the semantics :of malloc() are being followed. The problem I have as an applications :writer is that I tend to believe malloc. To pick a specific example, :our IMAP client takes steps to ensure it won't run out of memory in :critical sections. We maintain a "rainy day" pool block of memory. If :... :--lyndon We just put a cap on the number of imap clients we allow running at any given moment... say, a few hundred. Not only does it work just dandy, it also prevents the machine from overloading and gives us a nice "you may want to look into this" alarm. We do the same thing with sendmail, popper, the web server, named, and every other service which can be forked. This also prevents one subsystem from overly interfering with another. For example, if popper saturates it does not overly interfere with imapd operation. The limit is set to around 3x the monday peak load, and sufficient swap is configured to deal with it should the limit be hit. Problem solved. No fancy modifications required. If any of these subsystems actually ever got close to using all available swap, the other subsystems would be up the creek anyway so, really, it doesn't make much sense hacking the source to allow the subsystem to run into the wall anyway. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 21:42: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id CB261151A0 for ; Wed, 14 Jul 1999 21:42:01 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA06815; Wed, 14 Jul 1999 21:41:25 -0700 (PDT) (envelope-from dillon) Date: Wed, 14 Jul 1999 21:41:25 -0700 (PDT) From: Matthew Dillon Message-Id: <199907150441.VAA06815@apollo.backplane.com> To: jnemeth@victoria.tc.ca (John Nemeth) Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907141753.KAA02096@vtn1.victoria.tc.ca> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :On Jul 15, 12:20am, "Daniel C. Sobral" wrote: :} "Charles M. Hannum" wrote: :} > :} > That's also objectively false. Most such environments I've had :} > experience with are, in fact, multi-user systems. As you've pointed :} > out yourself, there is no combination of resource limits and whatnot :} > that are guaranteed to prevent `crashing' a multi-user system due to :} > overcommit. My simulation should not be axed because of a bug in :} > someone else's program. (This is also not hypothetical. There was a :} > bug in one version of bash that caused it to consume all the memory it :} > could and then fall over.) :} :} In which case the program that consumed all memory will be killed. :} The program killed is +NOT+ the one demanding memory, it's the one :} with most of it. : : On one system I administrate, the largest process is typically :rpc.nisd (the NIS+ server daemon). Killing that process would be a :bad thing (TM). You're talking about killing random processes. This :is no way to run a system. It is not possible for any arbitrary :decision to always hit the correct process. That is a decision that :must be made by a competent admin. This is the biggest argument :against overcommit: there is no way to gracefully recover from an :out of memory situation, and that makes for an unreliable system. : :}-- End of excerpt from "Daniel C. Sobral" ... and the chance of that system running out of swap space is? The machine has hit the wall, the admin can't login. What is the kernel to do? -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 21:54: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id CF4331504C for ; Wed, 14 Jul 1999 21:53:55 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id NAA28999; Thu, 15 Jul 1999 13:53:50 +0900 (JST) Message-ID: <378D64F5.5AA2CC5F@newsguy.com> Date: Thu, 15 Jul 1999 13:35:01 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: John Nemeth Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907141753.KAA02096@vtn1.victoria.tc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Nemeth wrote: > > On one system I administrate, the largest process is typically > rpc.nisd (the NIS+ server daemon). Killing that process would be a > bad thing (TM). You're talking about killing random processes. This > is no way to run a system. It is not possible for any arbitrary > decision to always hit the correct process. That is a decision that > must be made by a competent admin. This is the biggest argument > against overcommit: there is no way to gracefully recover from an > out of memory situation, and that makes for an unreliable system. If you run out of memory, it is either a misconfigured system, or a runaway program. If a program is runaway, then: 1) It is larger than your typical rpc.nisd. 2) You cannot tell the system a priori to kill it, because you don't know about it (or else, you wouldn't be running it in first place). A system running in overcommit assumes that you have it correctly configured so it will *not* run out of memory under normal conditions. This happens to be the same assumption Unix does. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 21:54:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 854F4154EB for ; Wed, 14 Jul 1999 21:54:08 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id NAA29036; Thu, 15 Jul 1999 13:54:04 +0900 (JST) Message-ID: <378D66C9.9AC6C4E4@newsguy.com> Date: Thu, 15 Jul 1999 13:42:49 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Michael Richardson Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907141958.PAA02088@pzero.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Michael Richardson wrote: > > No, I don't agree. > > This is a biggest argument against solving the overcommit situation with > SIGKILL. I have no problem with overcommit as a concept, I have a problem > with being unable to keep my possibly big processes (X, rpc.nisd, > etc. depending on cicumstances) from being victims. It is no more difficult to protect big processes than it is to create user limits. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 21:54:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 4C98E154FF for ; Wed, 14 Jul 1999 21:54:13 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id NAA29059; Thu, 15 Jul 1999 13:54:09 +0900 (JST) Message-ID: <378D6761.A10BF6F2@newsguy.com> Date: Thu, 15 Jul 1999 13:45:21 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Michael Richardson Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907142001.QAA02130@pzero.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Michael Richardson wrote: > > Ben> Tell me, Mr. Nemeth, has this ever happened to you? Have you ever > Ben> come *close*? > > Uh, since we don't run overcommit, the answer is specifically *NO*. And what system do you run? > I have had it happen on other systems. (Solaris, AIX) It was very > mystifying to diagnose. Sure, the systems were misconfigured for what we > were trying to do, but if I wanted build a custom system for every > application.... well... I'd be running NT. I have to agree about the mystifying diagnose... Specially when they *don't* page like hell. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 21:54:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 2256B15510 for ; Wed, 14 Jul 1999 21:54:28 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id NAA29091; Thu, 15 Jul 1999 13:54:16 +0900 (JST) Message-ID: <378D67B3.3E2A703C@newsguy.com> Date: Thu, 15 Jul 1999 13:46:43 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: John Nemeth Cc: Ben Rosengart , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907142009.NAA22442@vtn1.victoria.tc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG John Nemeth wrote: > > The machine in question has run out of swap, due to unforseeable > excessive memory demands. This was accompanied by processes > complaining about not being able to allocate memory and then cleaning > up after themselves. I did not see random processes being killed > because of it. That is the way things should be. From this, I can > assume that the OS doesn't overcommit. In case, you're wondering, the > OS in question is: > > SunOS 5.5 Generic_103093-25 sun4u sparc Uh... like any modern unix, Solaris overcommits. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 21:54:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 6020715516 for ; Wed, 14 Jul 1999 21:54:37 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id NAA29125; Thu, 15 Jul 1999 13:54:31 +0900 (JST) Message-ID: <378D6828.FCC3C120@newsguy.com> Date: Thu, 15 Jul 1999 13:48:40 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Jason Thorpe Cc: tech-userlevel@netbsd.org, freebsd-hackers@FreeBSD.ORG Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907142127.OAA01681@lestat.nas.nasa.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jason Thorpe wrote: > > If you have a lot of users, all of which have buggy programs which eat > a lot of memory, per-user swap quotas don't necessarily save your butt. The chance of these buggy programs running at the same time is not exactly high... > And maybe the individual programs didn't encounter their resource limits. > > ...but the sheer number of these runaway things caused the overcommit to > be a problem. If malloc() or whatever had actually returned NULL at the > right time (i.e. as backing store was about to become overcommitted), then > these runaway processes would have stopped running away (they would have > gotten a SIGSEGV and died). > > Anyhow, my "lame undergrads" example comes from a time when PCs weren't > really powerful enough for the job (or something; anyhow, we didn't have > any in the department :-). My example is from a Sequent Balance (16 > ns32032 processors, 64M RAM [I think; been a while], 4.2BSD variant). So, tell me... when NetBSD gets it's non-overcommit switch, would you use it in the environment you describe? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 21:54:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 27E2A15515 for ; Wed, 14 Jul 1999 21:54:39 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id NAA29022; Thu, 15 Jul 1999 13:53:58 +0900 (JST) Message-ID: <378D6663.E3493581@newsguy.com> Date: Thu, 15 Jul 1999 13:41:07 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: lyndon@orthanc.ab.ca Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907141833.MAA05320@orthanc.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG lyndon@orthanc.ab.ca wrote: > > What it so evil about having a reasonably intelligent malloc() that > tells the truth, and returns unused memory to the system? Overcommit > is for lazy programmers, plain and simple. At least the SGI documentation > about overcommit admits that (or at least, did at one time). Yes. So is high-level languages, as a matter of fact. True memory-conscious programmers will never use anything besides assembler. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 22:45: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (castles537.castles.com [208.214.165.101]) by hub.freebsd.org (Postfix) with ESMTP id D8C7314BE3 for ; Wed, 14 Jul 1999 22:45:01 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id WAA00420; Wed, 14 Jul 1999 22:40:57 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907150540.WAA00420@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Daniel C. Sobral" Cc: Jason Thorpe , Matthew Dillon , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) In-reply-to: Your message of "Thu, 15 Jul 1999 12:58:21 +0900." <378D5C5D.13C65239@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Jul 1999 22:40:57 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > And what do you do, then, with the processes that happen to have > legitimate use for more stack? > > Or maybe you just find out how much stack each process uses, and > then set limits appropriate for each one? Which is the equivalent of > setting limits to each user, of course... You get a little program, like eg. Xenix and Minix had, which lets you modify the executable header to indicate how much stack the system should reserve. If the program decides to use more stack for some reason, then it dies; this is in effect "stack overcommit". 8) -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 22:50:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (castles537.castles.com [208.214.165.101]) by hub.freebsd.org (Postfix) with ESMTP id 3F42714D12 for ; Wed, 14 Jul 1999 22:50:42 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id WAA00453; Wed, 14 Jul 1999 22:45:32 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907150545.WAA00453@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Marc Tardif Cc: freebsd-hackers@freebsd.org Subject: Re: gdb instead of adb In-reply-to: Your message of "Wed, 14 Jul 1999 22:26:44 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Jul 1999 22:45:32 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Is the reason why adb hasn't been ported to freebsd because the source is > proprietary? You make no sense. > If gdb should suffice for my debugging needs, how can a breakpoint be set > at a particular interrupt, or even at any interrupt? The break command > only seems to accept functions, offsets, linenumbers and addresses... > I'm all out of ideas and the gdb info file isn't helping. You make little more sense, unless you are talking about using gdb-remote on a running kernel, in which case you should know that interrupts are vectored through functions, and thus the entire issue is moot. Note also that debugging through interrupt handlers can be problematic on PC hardware. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 22:57:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp11.bellglobal.com (smtp11.bellglobal.com [204.101.251.53]) by hub.freebsd.org (Postfix) with ESMTP id 4F785150F4 for ; Wed, 14 Jul 1999 22:57:12 -0700 (PDT) (envelope-from hoek@FreeBSD.org) Received: from localhost.nowhere (ppp18406.on.bellglobal.com [206.172.130.86]) by smtp11.bellglobal.com (8.8.5/8.8.5) with ESMTP id BAA07564; Thu, 15 Jul 1999 01:58:56 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id BAA98113; Thu, 15 Jul 1999 01:56:20 -0400 (EDT) (envelope-from tim) Date: Thu, 15 Jul 1999 01:56:19 -0400 From: Tim Vanderhoek To: "Daniel C. Sobral" Cc: Jason Thorpe , tech-userlevel@netbsd.org, freebsd-hackers@FreeBSD.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Message-ID: <19990715015619.A97920@mad> References: <199907142127.OAA01681@lestat.nas.nasa.gov> <378D6828.FCC3C120@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <378D6828.FCC3C120@newsguy.com>; from Daniel C. Sobral on Thu, Jul 15, 1999 at 01:48:40PM +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 15, 1999 at 01:48:40PM +0900, Daniel C. Sobral wrote: > > > > If you have a lot of users, all of which have buggy programs which eat > > a lot of memory, per-user swap quotas don't necessarily save your butt. > > The chance of these buggy programs running at the same time is not > exactly high... Well, it is higher than your probably giving credit for. Suppose Professor A. hands-out X assignment. Unfortunately, some piece of code he supplied to his, let's say 200 students ignorant first year students, has this particular memory-eating bug. Being ignorant first-year students, they will notice something is wrong, assume the problem is their fault, and repeat the exact same procedure five or so times. Again, being ignorant first year students, they will probably all be using the same shell server. To make things worse, some wise-ass may have told a bunch of them how to use ulimit or limit in order to push their available resources as high as possible (perhaps very high, since the admin hopefully recognizes that sometimes students need high resource limits to perform research). Fortunately, overcommit rescues the machine and kills those buggy programs instead of letting them spin around for ever in some kind of "malloc() failed ... must be temporary failure, wait and retry". -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 23: 0:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (castles537.castles.com [208.214.165.101]) by hub.freebsd.org (Postfix) with ESMTP id DAAEC1507C for ; Wed, 14 Jul 1999 23:00:11 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id WAA00543; Wed, 14 Jul 1999 22:56:05 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907150556.WAA00543@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Doug Cc: Mike Smith , freebsd-hackers@freebsd.org Subject: Re: more amd hangs: problem really in syslog? In-reply-to: Your message of "Tue, 13 Jul 1999 16:13:23 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Jul 1999 22:56:05 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Tue, 13 Jul 1999, Mike Smith wrote: > > > 'siobi' is someone trying to open the serial console, for whatever > > reason. Without knowing who it was that was stuck there, it's hard to > > guess what is going on. > > D'uh, sorry. Long day. It was amd that was hung in the siobi > state. No way to clear it without rebooting the box. Dang. Now I need that stack dump from amd that you posted and I deleted. Specifically, it'd be handy to know why amd felt it was necessary to open the console. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jul 14 23:18:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zabagek.ihf.rwth-aachen.de (zabagek.ihf.RWTH-Aachen.DE [134.130.90.60]) by hub.freebsd.org (Postfix) with ESMTP id 19D8914E4B; Wed, 14 Jul 1999 23:18:10 -0700 (PDT) (envelope-from tg@zabagek.ihf.rwth-aachen.de) Received: (from tg@localhost) by zabagek.ihf.rwth-aachen.de (8.9.3/8.9.3) id IAA88445; Thu, 15 Jul 1999 08:19:21 +0200 (CEST) (envelope-from tg) To: Daniel Eischen Cc: hackers@FreeBSD.ORG, kip@lyris.com, stable@FreeBSD.ORG Subject: Re: seg fault in mutex_queue_enq References: <199907141806.OAA25906@pcnet1.pcnet.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Thomas Gellekum Date: 15 Jul 1999 08:19:21 +0200 In-Reply-To: Daniel Eischen's message of "Wed, 14 Jul 1999 14:06:24 -0400 (EDT)" Message-ID: Lines: 26 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel Eischen writes: > There are some bugs in libc_r in stable that have been fixed in > -current. I think the one that you've hit is an uninitialized > TAILQ_HEAD in a statically declared mutex (in localtime). It's > probably about time for a MFC. If someone wants to give me the > go-ahead, I can do it... Just Do It (tm). At least you could merge the change from [pthread_private.h] 1.20 Sun Jun 20 8:28:08 1999 UTC by jb Diffs to 1.19 In the words of the author: o The polling mechanism for I/O readiness was changed from select() to poll(). In additon, a wrapped version of poll() is now provided. [...] plus the later formatting fixes. As an aside: some files still lack $Id$'s, and someone should `s/REGENTS/AUTHOR/' in all the copyright statements. tg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 0:33:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dt054n86.san.rr.com (dt054n86.san.rr.com [24.30.152.134]) by hub.freebsd.org (Postfix) with ESMTP id 5D5C714E3A for ; Thu, 15 Jul 1999 00:33:39 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt054n86.san.rr.com (8.8.8/8.8.8) with ESMTP id AAA04476; Thu, 15 Jul 1999 00:33:34 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <378D8ECE.80424336@gorean.org> Date: Thu, 15 Jul 1999 00:33:34 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Mike Smith Cc: freebsd-hackers@freebsd.org Subject: Re: more amd hangs: problem really in syslog? References: <199907150556.WAA00543@dingo.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith wrote: > > > On Tue, 13 Jul 1999, Mike Smith wrote: > > > > > 'siobi' is someone trying to open the serial console, for whatever > > > reason. Without knowing who it was that was stuck there, it's hard to > > > guess what is going on. > > > > D'uh, sorry. Long day. It was amd that was hung in the siobi > > state. No way to clear it without rebooting the box. > > Dang. Now I need that stack dump from amd that you posted and I > deleted. OK, sent under different cover. > Specifically, it'd be handy to know why amd felt it was > necessary to open the console. Yeah, I'm kind of curious myself. BTW, I was going to work on this some more today, but the boss thought that putting the box into production was more important. The good news is that under real world load my freebsd box had 20-40% free cpu and a load average of 1.5. With load as equal as the switch could make it, the linux box had no free cpu and a load average of 8. :) I also (finally) got the approval to install freebsd on the fourth box (there are already two linux machines up) so A) I'm making progress in the office, and B) I should have a chance to pound on the syslog stuff tomorrow. Happy, Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 0:43:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by hub.freebsd.org (Postfix) with ESMTP id 5B056154EE for ; Thu, 15 Jul 1999 00:43:37 -0700 (PDT) (envelope-from michael.schuster@germany.sun.com) Received: from Germany.Sun.COM ([129.157.168.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA01039 for ; Thu, 15 Jul 1999 00:41:18 -0700 (PDT) Received: from emuc05-home by Germany.Sun.COM (SMI-8.6/SMI-SVR4-sd.fkk205) id JAA24768; Thu, 15 Jul 1999 09:41:15 +0200 Received: from germany.sun.com by emuc05-home (SMI-8.6/SMI-SVR4-se.fkk202) id JAA08678; Thu, 15 Jul 1999 09:41:15 +0200 Message-ID: <378D909D.4AB16D77@germany.sun.com> Date: Thu, 15 Jul 1999 09:41:17 +0200 From: Michael Schuster - TSC SunOS Germany Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi everyone, I've been following this discussion almost from the beginning, and I have the feeling that we're not _really_ getting very far. There's good arguments for and against overcommit, depending on your point of view and your requirements. What I do see is a not-so-openly voiced consent that the way resource(sp?) shortages are handled in an overcommitting system (SIGKILL) makes some of us rather unhappy. I therefore suggest those of us who would like to see a change in this area pool their efforts and energies to work on a mechanism that handles resource shortage in a more graceful way. cheerio Michael -- Michael.Schuster@germany.sun.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 0:55:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (castles537.castles.com [208.214.165.101]) by hub.freebsd.org (Postfix) with ESMTP id 4255615500 for ; Thu, 15 Jul 1999 00:55:40 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id AAA01206; Thu, 15 Jul 1999 00:50:32 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907150750.AAA01206@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Mark Newton Cc: hackers@freebsd.org Subject: Re: matcd on an SB16 In-reply-to: Your message of "Fri, 09 Jul 1999 12:58:30 +0930." <199907090328.MAA08098@gizmo.internode.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Jul 1999 00:50:31 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Is the matcd driver known to work on FreeBSD 3.2 ? If not, does anyone > have any estimate of the amount of effort that'd be required to fix it? It "works" for some definitions of "work". Firstly, there are three different CDROM interfaces that can be hung off an SB16; one is the Matsushita drive, there's also a Mutsumi interface (I don't think we support it) and a Sony interface (also, I believe, unsupported). Presuming the drive is a real Matsushita, and it's one of the few listed in the matcd manpage, you should be able to get it to work by following the manpage carefully. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 1: 7: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from metriclient-2.uoregon.edu (metriclient-2.uoregon.edu [128.223.172.2]) by hub.freebsd.org (Postfix) with ESMTP id 040CD154FC for ; Thu, 15 Jul 1999 01:06:51 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by metriclient-2.uoregon.edu (8.9.1/8.8.7) id BAA02401; Thu, 15 Jul 1999 01:05:17 -0700 (PDT) Message-ID: <19990715010517.21550@hydrogen.fircrest.net> Date: Thu, 15 Jul 1999 01:05:17 -0700 From: John-Mark Gurney To: Mike Smith Cc: Mark Newton , hackers@FreeBSD.ORG Subject: Re: matcd on an SB16 References: <199907090328.MAA08098@gizmo.internode.com.au> <199907150750.AAA01206@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199907150750.AAA01206@dingo.cdrom.com>; from Mike Smith on Thu, Jul 15, 1999 at 12:50:31AM -0700 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 3.0-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith scribbled this message on Jul 15: > > Is the matcd driver known to work on FreeBSD 3.2 ? If not, does anyone > > have any estimate of the amount of effort that'd be required to fix it? > > It "works" for some definitions of "work". Firstly, there are three > different CDROM interfaces that can be hung off an SB16; one is the > Matsushita drive, there's also a Mutsumi interface (I don't think we > support it) and a Sony interface (also, I believe, unsupported). actually, only certain drives are supported on the interfaces... this is from -current's LINT: # for the Sony CDU31/33A CDROM device scd0 at isa? port 0x230 # matcd: Matsushita/Panasonic CD-ROM # for the SoundBlaster 16 multicd - up to 4 devices controller matcd0 at isa? port 0x230 # mcd: Mitsumi CD-ROM device mcd0 at isa? port 0x300 irq 10 so, we support all three different interfaces, but the support is quite weak... I'm not even sure if these even work anymore, do people have some hardware they run tests on these interfaces? > Presuming the drive is a real Matsushita, and it's one of the few > listed in the matcd manpage, you should be able to get it to work by > following the manpage carefully. as for getting the code to work, that completely depends upon the code, and if you have the specs for the drive... it'd probably be cheaper to just by a new ide cdrom drive... and a heck of a lot faster... -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 "The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought." -- Ralph Waldo Emerson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 1:13:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.Technion.AC.IL (csa.cs.technion.ac.il [132.68.32.1]) by hub.freebsd.org (Postfix) with ESMTP id 08117154FC for ; Thu, 15 Jul 1999 01:13:20 -0700 (PDT) (envelope-from nadav@cs.technion.ac.il) Received: from csd.cs.technion.ac.il (csd.cs.technion.ac.il [132.68.32.8]) by cs.Technion.AC.IL (8.9.0/8.9.0) with ESMTP id LAA27868; Thu, 15 Jul 1999 11:13:18 +0300 (IDT) Received: from localhost (nadav@localhost) by csd.cs.technion.ac.il (8.9.3/8.9.0) with SMTP id LAA08571; Thu, 15 Jul 1999 11:13:17 +0300 (IDT) X-Authentication-Warning: csd.cs.technion.ac.il: nadav owned process doing -bs Date: Thu, 15 Jul 1999 11:13:17 +0300 (IDT) From: Nadav Eiron X-Sender: nadav@csd To: John-Mark Gurney Cc: Mike Smith , Mark Newton , hackers@freebsd.org Subject: Re: matcd on an SB16 In-Reply-To: <19990715010517.21550@hydrogen.fircrest.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Jul 1999, John-Mark Gurney wrote: > Mike Smith scribbled this message on Jul 15: > > > Is the matcd driver known to work on FreeBSD 3.2 ? If not, does anyone > > > have any estimate of the amount of effort that'd be required to fix it? > > > > It "works" for some definitions of "work". Firstly, there are three > > different CDROM interfaces that can be hung off an SB16; one is the > > Matsushita drive, there's also a Mutsumi interface (I don't think we > > support it) and a Sony interface (also, I believe, unsupported). > > actually, only certain drives are supported on the interfaces... this > is from -current's LINT: > # for the Sony CDU31/33A CDROM > device scd0 at isa? port 0x230 > # matcd: Matsushita/Panasonic CD-ROM > # for the SoundBlaster 16 multicd - up to 4 devices > controller matcd0 at isa? port 0x230 > # mcd: Mitsumi CD-ROM > device mcd0 at isa? port 0x300 irq 10 > > so, we support all three different interfaces, but the support is > quite weak... I'm not even sure if these even work anymore, do > people havesome hardware they run tests on these interfaces? I have a 486 with a matcd drive. Currently it runs 2.2.8R. The CD works, though occasionaly I get errors on it. I intend to upgrade it to 3.2R or -STABLE as soon as I get its monitor fixed (died a few weeks ago :-( )... > > -- > John-Mark Gurney Voice: +1 541 684 8449 > Cu Networking P.O. Box 5693, 97405 > > "The soul contains in itself the event that shall presently befall it. > The event is only the actualizing of its thought." -- Ralph Waldo Emerson > > Nadav To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 1:54:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gidgate.gid.co.uk (gidgate.gid.co.uk [193.123.140.1]) by hub.freebsd.org (Postfix) with ESMTP id B8AA215228 for ; Thu, 15 Jul 1999 01:54:21 -0700 (PDT) (envelope-from rb@gid.co.uk) Received: (from rb@localhost) by gidgate.gid.co.uk (8.8.8/8.8.7) id JAA27087; Thu, 15 Jul 1999 09:53:09 +0100 (BST) (envelope-from rb) Message-Id: <3.0.6.32.19990715095305.007b4490@192.168.255.1> X-Sender: rbmail@192.168.255.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 15 Jul 1999 09:53:05 +0100 To: John-Mark Gurney From: Bob Bishop Subject: Re: matcd on an SB16 Cc: Mike Smith , Mark Newton , hackers@FreeBSD.ORG In-Reply-To: <19990715010517.21550@hydrogen.fircrest.net> References: <199907150750.AAA01206@dingo.cdrom.com> <199907090328.MAA08098@gizmo.internode.com.au> <199907150750.AAA01206@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 01:05 15/07/99 -0700, John-Mark Gurney wrote: >Mike Smith scribbled this message on Jul 15: >> > Is the matcd driver known to work on FreeBSD 3.2 ? If not, does anyone >> > have any estimate of the amount of effort that'd be required to fix it? >> >> It "works" for some definitions of "work". Firstly, there are three >> different CDROM interfaces that can be hung off an SB16; one is the >> Matsushita drive, there's also a Mutsumi interface (I don't think we >> support it) and a Sony interface (also, I believe, unsupported). > >actually, only certain drives are supported on the interfaces... this >is from -current's LINT: ># for the Sony CDU31/33A CDROM >device scd0 at isa? port 0x230 ># matcd: Matsushita/Panasonic CD-ROM ># for the SoundBlaster 16 multicd - up to 4 devices >controller matcd0 at isa? port 0x230 ># mcd: Mitsumi CD-ROM >device mcd0 at isa? port 0x300 irq 10 > >so, we support all three different interfaces, but the support is >quite weak... I'm not even sure if these even work anymore, do >people have some hardware they run tests on these interfaces? I have an mcd (with a Mitsumi controller, not SB16) on a spammable box, it worked last time I tried (2.2.8R). [But that wasn't the original question.] -- Bob Bishop +44 118 977 4017 rb@gid.co.uk fax +44 118 989 4254 (0800-1800 UK) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 2:34:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from logatome.micronet.fr (logatome-2.francenet.fr [193.149.96.2]) by hub.freebsd.org (Postfix) with ESMTP id 1401E1550D; Thu, 15 Jul 1999 02:34:46 -0700 (PDT) (envelope-from Sebastien.Gioria@FranceNet.fr) Received: from gioria.dialup.FranceNet.fr (eku28.francenet.fr [193.149.97.60]) by logatome.micronet.fr (8.8.8/8.8.8) with ESMTP id LAA16629; Thu, 15 Jul 1999 11:32:51 +0200 (CEST) Received: by gioria.dialup.FranceNet.fr (Postfix, from userid 42) id 2637C1FFFF; Thu, 15 Jul 1999 11:34:37 +0200 (CEST) Message-ID: <19990715113437.A8986@FranceNet.fr> Date: Thu, 15 Jul 1999 11:34:37 +0200 From: Sebastien GIORIA To: freebsd-questions@FreeBSD.org Cc: freebsd-hackers@FreeBSD.org Subject: I'll be in Dublin July 19th and July 28th Reply-To: Sebastien GIORIA Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Operating-System: Definitely FreeBSD Function: Security Administrator X-Work-Organization: FranceNet X-Work-Postal-Address: 28 Rue Desaix , 75015 Paris, France, Terre X-Home-Organization: French FreeBSD Documentation Project X-Home-Postal-Address: 32 Rue Baron Le Roy, 75012 Paris, France, Terre X-Operating-System: FreeBSD-STABLE + PAO enabled X-URL-Home: http://www.FreeBSD-fr.org X-URL-Work: http://www.FranceNet.fr Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Is-it any FreeBSD related events near or anybody who want to drink a Beer and help me to visit the Town ? S. -- FranceNet Security Administrator Sebastien.Gioria@FranceNet.fr French FreeBSD Documentation Project gioria@FreeBSD.org Tout FreeBSD en Francais http://www.FreeBSD-fr.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 2:39:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from 001101.zer0.org (001101.zer0.org [206.24.105.163]) by hub.freebsd.org (Postfix) with ESMTP id 2D96D154FC for ; Thu, 15 Jul 1999 02:39:41 -0700 (PDT) (envelope-from gsutter@001101.zer0.org) Received: (from gsutter@localhost) by 001101.zer0.org (8.9.2/8.9.2) id CAA92516; Thu, 15 Jul 1999 02:36:47 -0700 (PDT) (envelope-from gsutter) Date: Thu, 15 Jul 1999 02:36:47 -0700 From: Gregory Sutter To: Mike Smith Cc: Doug , freebsd-hackers@FreeBSD.ORG Subject: Re: more amd hangs: problem really in syslog? Message-ID: <19990715023647.U55060@001101.zer0.org> References: <199907150556.WAA00543@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199907150556.WAA00543@dingo.cdrom.com>; from Mike Smith on Wed, Jul 14, 1999 at 10:56:05PM -0700 Organization: Zer0 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jul 14, 1999 at 10:56:05PM -0700, Mike Smith wrote: > > On Tue, 13 Jul 1999, Mike Smith wrote: > > > > > 'siobi' is someone trying to open the serial console, for whatever > > > reason. Without knowing who it was that was stuck there, it's hard to > > > guess what is going on. > > > > D'uh, sorry. Long day. It was amd that was hung in the siobi > > state. No way to clear it without rebooting the box. > > Dang. Now I need that stack dump from amd that you posted and I > deleted. Specifically, it'd be handy to know why amd felt it was > necessary to open the console. http://www.egroups.com/group/freebsd-hackers/40590.html Greg -- Gregory S. Sutter My reality check just bounced. mailto:gsutter@pobox.com http://www.pobox.com/~gsutter/ PGP DSS public key 0x40AE3052 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 2:45:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bill.profero.com (bill.profero.com [212.36.157.131]) by hub.freebsd.org (Postfix) with ESMTP id 51CE4154FC for ; Thu, 15 Jul 1999 02:45:50 -0700 (PDT) (envelope-from alex@profero.com) Received: from host168.profero.com by bill.profero.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1459.74) id 38KQ4H40; Thu, 15 Jul 1999 10:43:52 +0100 From: "Alex Knowles" To: Subject: printing Date: Thu, 15 Jul 1999 10:44:57 +0100 Message-ID: <000a01becea6$b2fe5d20$a89d24d4@profero.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I hope this is the right place to post, sorry if it's not. I'm really sorry to post what is probably a repeat question, but I've just upgraded to freebsd 3.2-release and I'm having real problems getting the kernel to see my printer ports: here is my kernel device ppc0 at isa? port? flags 0x40 net irq 7 controller ppbus0 device lpt0 at ppbus? device plip0 at ppbus? device ppi0 at ppbus? and here is my dmesg output: ppc0 at 0x3bc irq 7 flags 0x40 on isa ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppi0: on ppbus 0 plip0: on ppbus 0 whenever I try to access lpt0 it says that the device is not configured. If I try and use the old configuration of lpt and I try and build the kernel I get a whole load of make errors. what am I doing wrong!? please help thanks Alex P.S. I'm not actually subscribed to the mailing list, so can you reply to me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 3: 0:48 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay04.indigo.ie (relay04.indigo.ie [194.125.133.228]) by hub.freebsd.org (Postfix) with SMTP id 6D7AD1551E for ; Thu, 15 Jul 1999 03:00:45 -0700 (PDT) (envelope-from niall@pobox.com) Received: (qmail 10672 messnum 46430 invoked from network[194.125.148.47/ts03-047.dublin.indigo.ie]); 15 Jul 1999 09:58:24 -0000 Received: from ts03-047.dublin.indigo.ie (HELO pobox.com) (194.125.148.47) by relay04.indigo.ie (qp 10672) with SMTP; 15 Jul 1999 09:58:24 -0000 Message-ID: <378DCBD4.B3E60C4D@pobox.com> Date: Thu, 15 Jul 1999 11:53:56 +0000 From: Niall Smart X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Brian F. Feldman" Cc: Harold Gutch , Sheldon Hearn , hackers@FreeBSD.org Subject: Re: a BSD identd References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > And pidentd will still be supported. Eventually, I'd like to have those > huge majority who do not use DES tokens with pidentd move to the > inetd identd (when committed)... How about a standalone identd with DES `tokens' and any other nice to haves that it doesn't make sense to implement in a built-in identd? Regards, Niall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 3: 6: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 110C51551E; Thu, 15 Jul 1999 03:05:58 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id GAA09860; Thu, 15 Jul 1999 06:03:12 -0400 (EDT) Date: Thu, 15 Jul 1999 06:03:12 -0400 (EDT) From: Daniel Eischen Message-Id: <199907151003.GAA09860@pcnet1.pcnet.com> To: eischen@vigrid.com, tg@ihf.rwth-aachen.de Subject: Re: seg fault in mutex_queue_enq Cc: hackers@FreeBSD.ORG, kip@lyris.com, stable@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thomas Gellekum wrote: > Daniel Eischen writes: > > > There are some bugs in libc_r in stable that have been fixed in > > -current. I think the one that you've hit is an uninitialized > > TAILQ_HEAD in a statically declared mutex (in localtime). It's > > probably about time for a MFC. If someone wants to give me the > > go-ahead, I can do it... > > Just Do It (tm). At least you could merge the change from > > [pthread_private.h] > 1.20 Sun Jun 20 8:28:08 1999 UTC by jb > Diffs to 1.19 > In the words of the author: > > o The polling mechanism for I/O readiness was changed from > select() to poll(). In additon, a wrapped version of poll() > is now provided. > [...] > > plus the later formatting fixes. The libc_r version number was bumped in -current because of the addition of poll(). Is this allowed in -stable, or something that waits for a -RELEASE? > As an aside: some files still lack $Id$'s, and someone should > `s/REGENTS/AUTHOR/' in all the copyright statements. OK. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 3:22: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zabagek.ihf.rwth-aachen.de (zabagek.ihf.RWTH-Aachen.DE [134.130.90.60]) by hub.freebsd.org (Postfix) with ESMTP id E1EAB14ED9; Thu, 15 Jul 1999 03:21:53 -0700 (PDT) (envelope-from tg@zabagek.ihf.rwth-aachen.de) Received: (from tg@localhost) by zabagek.ihf.rwth-aachen.de (8.9.3/8.9.3) id MAA88785; Thu, 15 Jul 1999 12:22:12 +0200 (CEST) (envelope-from tg) To: Daniel Eischen Cc: hackers@FreeBSD.ORG, kip@lyris.com, stable@FreeBSD.ORG Subject: Re: seg fault in mutex_queue_enq References: <199907151003.GAA09860@pcnet1.pcnet.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Thomas Gellekum Date: 15 Jul 1999 12:22:12 +0200 In-Reply-To: Daniel Eischen's message of "Thu, 15 Jul 1999 06:03:12 -0400 (EDT)" Message-ID: Lines: 12 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel Eischen writes: > The libc_r version number was bumped in -current because of the > addition of poll(). Is this allowed in -stable, or something > that waits for a -RELEASE? Jordan should have to say something about this. AFAIR, bumps are allowed but only by one between releases. We will have to provide libc_r.so.3 in /usr/lib/compat/compat3x, though (we'll have to do this anyway by the time 4.x is released). tg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 3:45:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zabagek.ihf.rwth-aachen.de (zabagek.ihf.RWTH-Aachen.DE [134.130.90.60]) by hub.freebsd.org (Postfix) with ESMTP id 5284914E12; Thu, 15 Jul 1999 03:45:14 -0700 (PDT) (envelope-from tg@zabagek.ihf.rwth-aachen.de) Received: (from tg@localhost) by zabagek.ihf.rwth-aachen.de (8.9.3/8.9.3) id MAA88809; Thu, 15 Jul 1999 12:43:32 +0200 (CEST) (envelope-from tg) To: Daniel Eischen Cc: hackers@FreeBSD.ORG, kip@lyris.com, stable@FreeBSD.ORG Subject: Re: seg fault in mutex_queue_enq References: <199907151003.GAA09860@pcnet1.pcnet.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Thomas Gellekum Date: 15 Jul 1999 12:43:32 +0200 In-Reply-To: Thomas Gellekum's message of "Thu, 15 Jul 1999 12:22:12 +0200" Message-ID: Lines: 10 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thomas Gellekum writes: > libc_r.so.3 in /usr/lib/compat/compat3x, though (we'll have to do this /usr/src/lib/compat/compat3x ^^^^ Sorry. tg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 5:11:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dirac.th.physik.uni-bonn.de (dirac.th.physik.uni-bonn.de [131.220.161.119]) by hub.freebsd.org (Postfix) with ESMTP id 683B515544 for ; Thu, 15 Jul 1999 05:11:45 -0700 (PDT) (envelope-from conrad@th.physik.uni-bonn.de) Received: from merlin.th.physik.uni-bonn.de (merlin.th.physik.uni-bonn.de [131.220.161.121]) by dirac.th.physik.uni-bonn.de (8.8.8/8.8.8) with SMTP id OAA23425 for ; Thu, 15 Jul 1999 14:10:52 +0200 (CEST) (envelope-from conrad@merlin.th.physik.uni-bonn.de) Received: (qmail 10100 invoked by uid 145); 15 Jul 1999 12:10:52 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 15 Jul 1999 12:10:52 -0000 Date: Thu, 15 Jul 1999 14:10:52 +0200 (CEST) From: Jan Conrad To: freebsd-hackers@freebsd.org Cc: Sheldon Hearn , Jan Conrad Subject: NFS problems due to getcwd/realpath Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi everybody, after wondering for two years why FreeBSD (2.2.x ... 3.2) might lock up when an NFS server is down, I think I have found one reason for that (see kern/12609 - I now know it doesn't belong to kern - sorry). It is the implementation of getcwd (src/lib/libc/gen/getcwd.c). When examining the parent dir of a mounted filesystem, getcwd lstats every directory entry prior to the mountpoint to find out the name of the mountpoint (but it would only need the inodes's device to do a rough check....). If one of the prior entries point to another NFS mountpoint and that one is down, getcwd will wait till the mountpoint is up again.... This of course applies to all routines which use getcwd, e.g. realpath. This is especially funny since mountd calls realpath (from the RPC handler!!!!) to check mount points, so when to machines mount dirs from each other, they can lock up, e.g. at boottime (see kern/12609...) I don't fully understand whether the problem is still present in 3.x, since getcwd may call __getcwd to do the job, but as I understand from the sources, __getcwd may fail and then you're back with the problem. Anyhow, how can this be resolved (except for symlinking all mountpoints)? Must getcwd really do an lstat to find out an inodes device?? Is there no other syscall to do that? (I mean: this information must be present somewhere, without going over the net, right?) Unfortunately I don't now such a syscall. In my opinion getcwd should be implemented differently, but maybe some people have a differen opinion on that (And I am not sure how to do that properly). Any suggestions? best regards Jan -- Physikalisches Institut der Universitaet Bonn Nussallee 12 D-53115 Bonn GERMANY To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 5:33:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from iclub.nsu.ru (iclub.nsu.ru [193.124.222.66]) by hub.freebsd.org (Postfix) with ESMTP id 11C0E14D9A for ; Thu, 15 Jul 1999 05:33:08 -0700 (PDT) (envelope-from fjoe@iclub.nsu.ru) Received: from localhost (fjoe@localhost) by iclub.nsu.ru (8.9.3/8.9.3) with ESMTP id TAA36219; Thu, 15 Jul 1999 19:30:45 +0700 (NSS) (envelope-from fjoe@iclub.nsu.ru) Date: Thu, 15 Jul 1999 19:30:45 +0700 (NSS) From: Max Khon To: Chris Costello Cc: hackers@FreeBSD.ORG Subject: Re: rtfm rewritten in C (updated) In-Reply-To: <19990711220003.E71884@holly.dyndns.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hi, there! On Sun, 11 Jul 1999, Chris Costello wrote: > > I've implemented a few new features. First off, strdup() > isn't abused anymore so the program should run much smoother and > smaller, as well as more quickly. Secondly, I have (thanks in > part to Alfred Perlstein) added both case-insensitive searches > (-i) and local FAQ search (can be overridden with -o, "online", > flag). > > Too many others to enumerate. > > As usual, it's at http://www.calldei.com/~chris/rtfm.tar.gz what about to use shell patterns (fnmatch) instead of substring search? :) /fjoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 8:17:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 46AB21502F for ; Thu, 15 Jul 1999 08:17:38 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id AAA13546; Fri, 16 Jul 1999 00:16:16 +0900 (JST) Message-ID: <378DF141.393ECB36@newsguy.com> Date: Thu, 15 Jul 1999 23:33:37 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Kevin Schoedel Cc: tech-userlevel@netbsd.org, freebsd-hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) References: <55586E7391ACD211B9730000C11002761796F3@r-lmh-wi-100.corpnet.at> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kevin Schoedel wrote: > > >Imagine a reasonably big > >program, like Netscape or Emacs, of which you usually just use a > >subset of features. There can easily be many megabytes of code and > >data in them you never actually use, or you don't _usually_ use > >(like the people who use emacs like it was vi :). Without > >overcommit, you need to allocate all that memory for the code, no > >matter whether you end up using it or not. With overcommit, there is > >no such problem. > > Code, static data, and not-yet-written writable data should be backed by > the executable file, not by swap space, so unused code and tables should > not be a problem. TEXT should be backed by the executable, as long a the program doesn't change it to read/write. That's not the code I was refering to. Not-yet-written blah-blah-blah should be backed by: 1) The executable file if you are overcommitting. 2) RAM/Swap if you are not. If you don't do this, you are overcommitting. Proof: let the system exaust it's memory. Change a single byte in the not-yet-written stuff. Now you need more memory than you have to comply with a regular operation (like changing the value of a global variable), which means you overcommitted. Now comes the people saying "don't overcommit in *this* case, and overcommit in *that* case". Irrelevant. Programs are still getting killed because memory was overcommitted (with the added disadvantage of you not having as much memory as in a full overcommit mode). > Stack is more interesting. There might be a place for a global overcommit > switch. I think I'd be happier with a scheme in which stack the first > page or first few pages are committed (so that reasonable programs will > never run into trouble) and remaining stack is over-/un-committed by > default, along with means for unusual programs to commit (and/or test > commitability of) subsequent pages. Eh? Reasonable programs *never* run into trouble. Trouble only happens when you have unreasonable programs around, or did not configure the system correctly. And if you did not configure the system correctly, why do you think you would be able to correctly estimate the stack needed for the various programs? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 8:18: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 4B96015594 for ; Thu, 15 Jul 1999 08:17:55 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id AAA13652; Fri, 16 Jul 1999 00:16:43 +0900 (JST) Message-ID: <378DF2C9.62BF4D81@newsguy.com> Date: Thu, 15 Jul 1999 23:40:09 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Danny Thomas Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Danny Thomas wrote: > > >Killing the biggest is simple to implement and usually right. > ... but some people don't want that policy, at least on some of their > systems. Does FreeBSD offer alternatives? Is so, they've been conspicuously > absent from discussion, which might have taken things into a more > productive vein. What do other over-committing systems offer? Absent, eh? FreeBSD offers soft and hard limits on resources. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 8:18: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 8697C155AC for ; Thu, 15 Jul 1999 08:18:02 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id AAA13697; Fri, 16 Jul 1999 00:16:54 +0900 (JST) Message-ID: <378DF4C8.5E7B4C44@newsguy.com> Date: Thu, 15 Jul 1999 23:48:41 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: lyndon@orthanc.ab.ca Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Swap overcommit References: <199907141938.NAA05484@orthanc.ab.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG lyndon@orthanc.ab.ca wrote: > > All of the arguments I've seen so far assume that one process is > running off and grabbing all the available memory. That may be > the most likely scenario, but it's most certainly not the *only* > scenario. What if you have a whole bunch of "middle sized" processes > running, all using memory efficiently, but in total using 95% of > the available VM. A malloc(5*1024*1024) might work, but I need > 10 MB instead of 5MB. And my memory footprint is just a little > bit bigger than the other guys. Instead of returning NULL to > the malloc() request, *zap* I'm dead. How can you possibly > call that sensible behaviour? No process is killed at malloc() time. A process is killed when (another) process needs more memory and it is not available. > Yes, the machine is under-resourced. I can't help that -- it's not my > machine. The machine belongs to a customer who happens to run my IMAP > software, who also happens to have ignored our sizing guidelines. In > this situation I have no choice but to deal with the low memory > condition, and our code does that, if it's given the chance! At > least give me the opportunity to deal with the situation gracefully. If it was not for overcommit, you wouldn't be running half of what you are running in that machine in first place. So, overcommit is helping you run much more for the same resources. > What if we decided to defer errors from bind just because there > weren't any mbufs available, and later killed the process when it > tried to do network I/O? People would howl bloody murder! (<== this is > rhetorical, folks) Out of mbufs does not result in system deadlock, out of memory does. > The semantics of malloc() have been defined since almost the dawn of > time. From the current manpage: > > RETURN VALUES > The malloc() and calloc() functions return a pointer to the allocated > memory if successful; otherwise a NULL pointer is returned. > > Nowhere does it say that allocated memory might not exist. Nowhere > does it say that I have to touch all the allocated pages to make > sure they are really there. Nowhere does it say process death at > some non-deterministic time in the future might be a side effect > of calling malloc(). And nowhere does it say it does not, of course. But that is beside the point. malloc() works as specified. It is the behavior of the system in a low-resource situation that leads to processes being killed. > Applications are written assuming that malloc() behaves in the > documented manner. It is *not* acceptable to tell applications writers Actually, applications are written assuming that malloc() will not fail, generally speaking. > that they have to provide their own management routines on top of malloc() > (SEGV catchers and the like) if they want the long standing semantics > of malloc() to be preserved. If the current malloc() cannot behave in > the documented and expected manner it needs to be renamed, because > malloc() it most certainly isn't. It's funny how all these FreeBSD systems manage to gain such a good reputation despite such an obvious flaw, isn't it? :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 8:23:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id B331515588 for ; Thu, 15 Jul 1999 08:23:36 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id LAA44070; Thu, 15 Jul 1999 11:22:29 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <199907150129.SAA05927@apollo.backplane.com> References: <199907132346.TAA13780@bikini.ihack.net> Date: Thu, 15 Jul 1999 11:22:26 -0400 To: Matthew Dillon From: Garance A Drosihn Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Cc: "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 6:29 PM -0700 7/14/99, Matthew Dillon wrote: > If 1G isn't enough, spend another $30 and throw 2G of swap > online. Or perhaps dedicate an entire $150 disk and throw > 6+ GB of swap online. > > The equivalent setup using a non-overcommit model would require > considerably more swap to have the same reliability. Please note that we're talking at cross-purposes here, mainly because I didn't realize this same general topic was being beaten to death in the 'replacement for grep' thread (which I have not been following). Speaking for just me myself and I, I have no problems with the current overcommit model. All I'd like to do is have a way to indicate which processes should not get booted first, if the system does indeed run out of swap and needs to boot some processes. However, other people seem much more worked up about this topic than I am, and thus what I (personally) meant as "just casual questions" seem to be taken as "demands that something be done, RIGHT NOW". I now realize that some people are arguing that malloc should return an error if the system runs out of space, but that's not what I am thinking about. So, I think I'll bow out of this discussion for now, and maybe try to discuss my "casual questions" sometime in a different context... --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 8:24: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns1.dynmc.net (ns1.dynmc.net [209.0.37.10]) by hub.freebsd.org (Postfix) with ESMTP id 2F3C7155A4 for ; Thu, 15 Jul 1999 08:23:59 -0700 (PDT) (envelope-from omni@dynmc.net) Received: from localhost (omni@localhost) by ns1.dynmc.net (8.9.2/8.9.1) with ESMTP id IAA41311 for ; Thu, 15 Jul 1999 08:21:58 -0700 (PDT) Date: Thu, 15 Jul 1999 08:21:58 -0700 (PDT) From: "Gregory A. Carter" To: hackers@FreeBSD.ORG Subject: make fails in 3.2-RELEASE for netboot Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Been trying to get nb8390.com compiled under /usr/sys/i386/boot/netboot and every time it does this: (ns2)[6]:/usr/src/sys/i386/boot/netboot# make Warning: Object directory not changed from original /usr/src/sys/i386/boot/netboot cc -O2 -DNFS -DROMSIZE=16384 -DRELOC=0x90000 -DPCI -DPCI_VENDOR=0x10ec -DPCI_DEVICE=0x8029 -DPCI_CLASS=0x02,0x00,0x00 -aout -nostdinc -I/usr/src/sys/i386/boot/netboot/../../../../include -I/usr/src/sys/i386/boot/netboot/../../.. -I/usr/src/sys/i386/boot/netboot -DROMSIZE=16384 -static -o makerom /usr/src/sys/i386/boot/netboot/makerom.c ld: scrt0.o: No such file or directory *** Error code 1 Stop. Now being the resourcful kinda guy I am I looked on another one of my box and it worked fine. On that box I have upgraded all the way from 2.7 so I'm assuming that might have something to do with it. The file scrt0.c does not exist so in a make buildworld it's not created on the new box. The source is fresh as it's a new install so I'm curious as to why the file is missing, and why this was released with netboot as stable is it doesn't compile. Second thing I'm noticing is that, I compiled nb8390.com on the older box and attempted to run it on a machine from boot time. tftp worked great and it attempts to load the kernel from my new box (doesn't matter if I use the new boxes kernel or the old boxes kernel for the client it still fails), I get the following error message: Bad kernel not a valid executable! Of course that is a rough message as I'm at work and the box I'm using it on is at home but that's the important part. It's seeing the kernel file however it's not running it. Now justa long shot but I'm guessing nb8390.com is expecting an aout kernel and it's getting an elf kernel. My last question is why did this program get released with 3.x yet not recognize elf kernels if this is the case? Greg +(Omni@Dynmc.Net)------------------------------------------------------+ | Dynamic Networking Solutions InterX Technologies | | Senior Network Administrator bits/keyID 1024/7DF9C285 | | omni@interx.net omni@itstudio.net omni@undernet.org omni@webpop3.com | +--------[ DC 50 57 59 C3 76 46 E8 EB 75 A8 94 FE 96 9E D3 ]----------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 8:45:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 5DD7914E68 for ; Thu, 15 Jul 1999 08:45:28 -0700 (PDT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 15 Jul 1999 16:45:15 +0100 (BST) To: Jan Conrad Cc: freebsd-hackers@freebsd.org Subject: Re: NFS problems due to getcwd/realpath In-reply-to: Your message of "Thu, 15 Jul 1999 14:10:52 +0200." Date: Thu, 15 Jul 1999 16:45:10 +0100 From: Ian Dowse Message-ID: <199907151645.aa25796@salmon.maths.tcd.ie> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Jan Conrad writes: >after wondering for two years why FreeBSD (2.2.x ... 3.2) might lock up >when an NFS server is down, I think I have found one reason for that (see >kern/12609 - I now know it doesn't belong to kern - sorry). > >It is the implementation of getcwd (src/lib/libc/gen/getcwd.c). When >examining the parent dir of a mounted filesystem, getcwd lstats every >directory entry prior to the mountpoint to find out the name of the >mountpoint (but it would only need the inodes's device to do a rough >check....). This should no longer be an issue with FreeBSD 3.x, as the system normally uses the new _getcwd syscall. The old code is still in getcwd.c, but is only used if the syscall isn't present (e.g. if running a 3.x executable on a 2.2 system). We use the following patch on all our 2.2-stable machines, which works around the problem. This was submitted as PR bin/6658, but it wasn't committed, as a backport of 3.x's _getcwd (which never occurred) was considered to be a more appropriate change. Ian --- getcwd.c.orig Tue Jun 30 15:38:44 1998 +++ getcwd.c Tue Jun 30 15:39:08 1998 @@ -36,6 +36,7 @@ #endif /* LIBC_SCCS and not lint */ #include +#include #include #include @@ -169,7 +170,28 @@ if (dp->d_fileno == ino) break; } - } else + } else { + struct statfs sfs; + char *dirname; + + /* + * Try to get the directory name by using statfs on + * the mount point. + */ + if (!statfs(up[3] ? up + 3 : ".", &sfs) && + (dirname = rindex(sfs.f_mntonname, '/'))) + while((dp = readdir(dir))) { + if (ISDOT(dp)) + continue; + bcopy(dp->d_name, bup, dp->d_namlen+1); + if (!strcmp(dirname + 1, dp->d_name) && + !lstat(up, &s) && + s.st_dev == dev && + s.st_ino == ino) + goto found; + } + rewinddir(dir); + for (;;) { if (!(dp = readdir(dir))) goto notfound; @@ -187,7 +209,9 @@ if (s.st_dev == dev && s.st_ino == ino) break; } + } +found: /* * Check for length of the current name, preceding slash, * leading slash. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 8:50:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lamb.sas.com (lamb.sas.com [192.35.83.8]) by hub.freebsd.org (Postfix) with ESMTP id 9E3E115598 for ; Thu, 15 Jul 1999 08:50:31 -0700 (PDT) (envelope-from jwd@unx.sas.com) Received: from mozart (mozart.unx.sas.com [192.58.184.8]) by lamb.sas.com (8.9.3/8.9.1) with SMTP id LAA11699; Thu, 15 Jul 1999 11:50:18 -0400 (EDT) Received: from bb01f39.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA24297; Thu, 15 Jul 1999 11:49:48 -0400 Received: (from jwd@localhost) by bb01f39.unx.sas.com (8.9.1/8.9.1) id LAA78679; Thu, 15 Jul 1999 11:49:47 -0400 (EDT) (envelope-from jwd) From: "John W. DeBoskey" Message-Id: <199907151549.LAA78679@bb01f39.unx.sas.com> Subject: Re: tcp windowsize query? In-Reply-To: From Matthew Dillon at "Jul 14, 1999 1:40: 7 pm" To: freebsd-hackers@freebsd.org Date: Thu, 15 Jul 1999 11:49:47 -0400 (EDT) Cc: dillon@apollo.backplane.com (Matthew Dillon) X-Mailer: ELM [version 2.4ME+ PL43 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Thanks for the reply(s)... If I understand you correctly, then: %route -n get netapp01 route to: 192.168.21.52 destination: 192.168.21.52 interface: fxp1 flags: recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire 0 0 0 0 0 0 1500 10 says that I have a specific interface route to get to the fileserver... The recv/send values being 0 means that we are using the default memory/window sizes. I'm not sure what the 3rd & 4th columns are... (possibly what I'm looking for below)... From SunOS, I can get the following values: tcp_cwnd_max == 262144 <-- same as recv/send sizes, or windowsize ?? tcp_xmit_hiwat == 8192 tcp_recv_hiwat == 8192 udp_xmit_hiwat == 8192 udp_recv_hiwat == 8192 I'm now trying to determine how to get the hi & lo water marks from FreeBSD... net.inet.tcp.rfc1323: 0 net.inet.tcp.rfc1644: 0 net.inet.tcp.mssdflt: 512 net.inet.tcp.rttdflt: 3 net.inet.tcp.keepidle: 14400 net.inet.tcp.keepintvl: 150 net.inet.tcp.sendspace: 16384 <-- SunOS uses 260k... net.inet.tcp.recvspace: 16384 <-- are these small? net.inet.tcp.keepinit: 150 net.inet.tcp.log_in_vain: 0 net.inet.tcp.delayed_ack: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.pcbcount: 155 net.inet.tcp.always_keepalive: 1 net.inet.udp.checksum: 1 net.inet.udp.maxdgram: 9216 net.inet.udp.recvspace: 41600 net.inet.udp.log_in_vain: 0 If I may re-phrase.. How do I determine if the send/recv spaces are large enough, and if not, how many times I bumped into the wall? Thanks! John > :> net.inet.tcp.recvspace: 16384 > :... > :> send/recv space might be what I'm looking for... > : > :They're the default send/receive window sizes, yes. You can tweak them > :with socket ioctls on a per-socket basis. > : > :> delayed ack sounds interesting.... > : > :Turning that off disables TCP slow-start. It's a huge performance > :booster for things like SMB service, where you have lots of short-lived > :TCP connections on a local net. > > Note that you can also tweak TCP send/receive window sizes on a > per-route basis. The recvpipe and sendpipe parameters in route > table entries can be changed. This will override the sysctl defaults. > > However, it may be a little complex for some people to grasp. The > route table is a radix tree. In order to set the send/receive pipes > for particular ip addresses you may have to create a route to that > IP address in order to effect it rather then a more global route. > > For example, if I am getting the route to some host that runs through > my default gateway, I get my default route entry. If I were to > change this route entry I would be changing it for default, not just > for idiom.com: > > route -n get idiom.com > > # route -n get idiom.com > route to: 209.157.64.1 > destination: default > mask: default <----- this is not a host route! > gateway: 209.157.86.1 <----- this is not a host route! > interface: de0 > flags: > recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire > 0 0 0 0 0 0 1500 0 > > > On the other hand, a route to another host on the same ethernet is usually > specific: > > # route -n get lander > route to: 209.157.86.6 > destination: 209.157.86.6 > interface: de0 > flags: > recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire > 0 0 10411044 172 219 0 1500 1131 > > > To change the pipes associated with a route, I would do the following. > But in this example if I were to try to change the pipe size to idiom.com, > I would actually wind up changing the pipe size for my default route. > > route -n change idiom.com -sendpipe BYTES -recvpipe BYTES > route -n change 209.157.86.6 -sendpipe BYTES -recvpipe BYTES > > If I really want to change the pipe size just to idiom.com, I would have > to first create a specific route to idiom.com, then change that. > > route add idiom.com default > route -n change idiom.com -sendpipe BYTES -recvpipe BYTES > > -Matt > Matthew Dillon > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > > ------------------------------ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 8:58:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from io.yi.org (24.66.174.118.bc.wave.home.com [24.66.174.118]) by hub.freebsd.org (Postfix) with ESMTP id 6D5BA14E68 for ; Thu, 15 Jul 1999 08:58:35 -0700 (PDT) (envelope-from jake@checker.org) Received: from io.yi.org (localhost [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id 3EDD51F0C; Thu, 15 Jul 1999 08:57:57 -0700 (PDT) X-Mailer: exmh version 2.0.2 2/24/98 To: Mike Smith Cc: hackers@FreeBSD.ORG Subject: Re: matcd on an SB16 In-reply-to: Your message of "Thu, 15 Jul 1999 00:50:31 PDT." <199907150750.AAA01206@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Jul 1999 08:57:57 -0700 From: Jake Burkholder Message-Id: <19990715155757.3EDD51F0C@io.yi.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > Is the matcd driver known to work on FreeBSD 3.2 ? If not, does anyone > > have any estimate of the amount of effort that'd be required to fix it? > > It "works" for some definitions of "work". Firstly, there are three > different CDROM interfaces that can be hung off an SB16; one is the > Matsushita drive, there's also a Mutsumi interface (I don't think we > support it) and a Sony interface (also, I believe, unsupported). > > Presuming the drive is a real Matsushita, and it's one of the few > listed in the matcd manpage, you should be able to get it to work by > following the manpage carefully. FYI this no longer works in -current. FreeBSD 4.0-CURRENT #2: Sun Jul 11 23:42:24 PDT 1999 jake@io.yi.org:/usr/src/sys/compile/JAKE I have a Matsushita 2x drive and a sb16; the drive stopped being probed around when newbus went in. No probe message at all. It shows up in visual kernel config, but not after. I figured it was just rot due to the newbus switch, but it hasn't been fixed. I also imagine I'm the only person in the world running -current with one of these :) probably the driver could just be ripped out; these are ancient drives, and consume horendous amounts of CPU. also, something's gone amiss in the reorganization of GENERIC and/or LINT GENERIC: device matcd0 at isa? port 0x230 LINT: controller matcd0 at isa? port 0x230 The man page says it should be controller. Thanks -- we are but packets in the internet of life To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 9:28: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from electra.znyx.com (electra.znyx.com [209.0.10.2]) by hub.freebsd.org (Postfix) with ESMTP id EC51D15598 for ; Thu, 15 Jul 1999 09:27:57 -0700 (PDT) (envelope-from Tim_Hayes@znyx.com) Received: from machine240.znyx.com (machine240.znyx.com [207.71.204.240] (may be forged)) by electra.znyx.com (8.8.7/8.8.7) with SMTP id JAA04530 for ; Thu, 15 Jul 1999 09:27:49 -0700 Received: by machine240.znyx.com with Microsoft Mail id <01BECEA4.BE780E50@machine240.znyx.com>; Thu, 15 Jul 1999 09:30:57 -0700 Message-ID: <01BECEA4.BE780E50@machine240.znyx.com> From: Tim Hayes To: "'freebsd-hackers@FreeBSD.ORG'" Subject: Major Device Number for High Availability Ethernet Driver Date: Thu, 15 Jul 1999 09:30:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greetings Hackers, We are in the process of releasing a FreeBSD v 3.2 Ethernet driver that = detects link failures and executes failovers, supports Cisco's FEC = trunking, and system-to-system trunking. To support these features, = some configuration is required...the configuration utility requires a = "/dev/zrm" device with a major character device #. The driver (unfortunately a binary only release) also needs to know the = major device #. We would greatly appreciate some advice on which device # to use and how = to let our driver know which one has been assigned. http://www.freebsd.org/FAQ/FAQ253.html says we can use character device = # 32 - ... what if someone else is already using it..don't these have to = be unique ? /usr/src/sys/i386/conf/majors.i386 says 200-255 are available for "local = use" ... is there a way a configuration utility can determine the next available = ? is there a way my driver can tell which # is used for our "/dev/zrm" = character device ? ( the driver uses "cdevsw_add( )" to register routines for the device - = major dev # is required ) Advice here would be greatly appreciated. Thanks Tim Tim Hayes ZNYX Corporation 187 S Patterson Suite C Santa Barbara CA 93111 Tim_Hayes@znyx.com v: 805 683 8841 f: 805 683 1171 p: 800 376 2942 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 9:40:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 0F39B155BA; Thu, 15 Jul 1999 09:40:11 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id JAA01989; Thu, 15 Jul 1999 09:36:54 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Thomas Gellekum Cc: Daniel Eischen , hackers@FreeBSD.ORG, kip@lyris.com, stable@FreeBSD.ORG Subject: Re: seg fault in mutex_queue_enq In-reply-to: Your message of "15 Jul 1999 12:22:12 +0200." Date: Thu, 15 Jul 1999 09:36:54 -0700 Message-ID: <1985.932056614@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Jordan should have to say something about this. AFAIR, bumps are > allowed but only by one between releases. We will have to provide > libc_r.so.3 in /usr/lib/compat/compat3x, though (we'll have to do this > anyway by the time 4.x is released). I'd prefer not to bump it... John Birrell and I are already not entirely in agreement that the change required a version bump at all. It didn't change any interfaces. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 9:49:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from vulture.dmem.strath.ac.uk (vulture.dmem.strath.ac.uk [130.159.232.158]) by hub.freebsd.org (Postfix) with ESMTP id 48257155B8 for ; Thu, 15 Jul 1999 09:49:24 -0700 (PDT) (envelope-from jen@vulture.dmem.strath.ac.uk) Received: from vulture.dmem.strath.ac.uk (vulture [130.159.232.158]) by vulture.dmem.strath.ac.uk (8.9.3/8.9.3) with ESMTP id RAA07108 for ; Thu, 15 Jul 1999 17:48:04 +0100 (BST) (envelope-from jen@vulture.dmem.strath.ac.uk) Message-ID: <378E10C4.9AD7979E@vulture.dmem.strath.ac.uk> Date: Thu, 15 Jul 1999 17:48:04 +0100 From: Jennifer Clark X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Advice on deriving accurate time values from the kernel? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I am in the process of developing a device driver for the purpose of stepper motor control. The timing of each pulse is determined by external timing hardware on an I/O board, which will fire an interrupt after the time requested. Using this method, I am able to generate streams of pulses at approximately 5000Hz on a Pentium II 400MHz system. Everything seems to be working well, but I'd really like to gather some accurate timing data in order to derive some statistics to from the system. Intuition tells me I'll need a clock with a tick rate of at least 20000 Hz to derive this. So, is such a thing available in the kernel? I've searched through various mailing list archives and have found reference to the "HZ" option to the kernel, which works to a point. However, it is not ideal as setting HZ to high values generates far too much kernel overhead. Also being considered is additional external timing hardware, but this is something I'd rather avoid for many reasons. What I am after is not a "timer" as such - all I need to do is derive a time value at an initial time, and a subsequent value at a later time. I've used "getmicrouptime", but this appears dependent on the "Hz" option, and as such is of limited use. I've just had some input from a colleauge who has suggested using the Pentium profiling registers, which we are currently investigating... Any advice gratefully received, -- Jennifer Clark http://telepresence.dmem.strath.ac.uk http://www.crmjewellery.co.uk http://www.furniturenet.co.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 9:57: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from guru.phone.net (guru.phone.net [209.157.82.120]) by hub.freebsd.org (Postfix) with SMTP id B09D214EDB for ; Thu, 15 Jul 1999 09:56:57 -0700 (PDT) (envelope-from mwm@phone.net) Received: (qmail 30133 invoked by uid 100); 15 Jul 1999 16:56:50 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 15 Jul 1999 16:56:50 -0000 Date: Thu, 15 Jul 1999 09:56:50 -0700 (PDT) From: Mike Meyer To: "Jordan K. Hubbard" Cc: Thomas Gellekum , Daniel Eischen , hackers@FreeBSD.ORG, kip@lyris.com, stable@FreeBSD.ORG Subject: Re: seg fault in mutex_queue_enq In-Reply-To: <1985.932056614@zippy.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Jul 1999, Jordan K. Hubbard wrote: :->> Jordan should have to say something about this. AFAIR, bumps are :->> allowed but only by one between releases. We will have to provide :->> libc_r.so.3 in /usr/lib/compat/compat3x, though (we'll have to do this :->> anyway by the time 4.x is released). :-> :->I'd prefer not to bump it... John Birrell and I are already not :->entirely in agreement that the change required a version bump at :->all. It didn't change any interfaces. Which failure is better: An error that you don't have a recent enough version of the library, or one that the routine poll() can't be found at run time? ; Thu, 15 Jul 1999 10:01:42 -0700 (PDT) (envelope-from rminnich@acl.lanl.gov) Received: from tbp.acl.lanl.gov (root@tbp.acl.lanl.gov [128.165.147.10]) by acl.lanl.gov (8.8.8/8.8.5) with ESMTP id LAA497410 for ; Thu, 15 Jul 1999 11:00:26 -0600 (MDT) Received: from localhost (rminnich@localhost) by tbp.acl.lanl.gov (8.8.7/8.8.8) with ESMTP id LAA12212 for ; Thu, 15 Jul 1999 11:00:11 -0600 X-Authentication-Warning: tbp.acl.lanl.gov: rminnich owned process doing -bs Date: Thu, 15 Jul 1999 11:00:11 -0600 (MDT) From: "Ronald G. Minnich" To: hackers@freebsd.org Subject: Another take on /proc statistics (joke of the day) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I thought this amusing. Take the following program, designed to suck stats out of /proc for the network devices: #include #include #include main() { char stuff[4096]; int fd = open("/proc/net/dev", 0); while(1) { int amount = read(fd, stuff, sizeof(stuff)); if (amount > 0) write(1, stuff, amount); sleep(1); lseek(fd, (off_t) 0, SEEK_SET); } } Run this on linux, and you'll get the same values for all the stats. how to make it work right? #include #include #include main() { char stuff[4096]; while(1) { int fd = open("/proc/net/dev", 0); int amount; amount = read(fd, stuff, sizeof(stuff)); if (amount > 0) write(1, stuff, amount); close(fd); sleep(1); } } What are the implications of this? Well, if you have an rstatd that uses /proc for statistics, it will have to (for every request) open the status files, read them, and close them. Net result: very very poor performance for an rstatd (not even counting the fact that the rstatd has to parse formatted output back to a binary format ...) ron p.s. the rstatd I have for redhat does indeed read stats out of /proc ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 10:10:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 7C88015591 for ; Thu, 15 Jul 1999 10:10:25 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA11425; Thu, 15 Jul 1999 10:08:29 -0700 (PDT) (envelope-from dillon) Date: Thu, 15 Jul 1999 10:08:29 -0700 (PDT) From: Matthew Dillon Message-Id: <199907151708.KAA11425@apollo.backplane.com> To: "John W. DeBoskey" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: tcp windowsize query? References: <199907151549.LAA78679@bb01f39.unx.sas.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : If I may re-phrase.. How do I determine if the send/recv spaces :are large enough, and if not, how many times I bumped into the :wall? : :Thanks! :John It depends entirely on the type of traffic your machine is handling. A large web server usually uses relatively small (16K or 32K) window sizes in order to avoid wasting memory. It might be handling a thousand active connections. A machine that is running over a long haul fiber or over a very fast link might want to use larger window sizes to keep the pipeline full, but only if it really needs to max out per-connection bandwidth. A machine that is running over slower links can make due with smaller tcp window sizes. Or perhaps if you have a machine running over a very slow link, like a modem link, you may want to significantly reduce the tcp window size for bulk transfers in order to get better interactive performance. e.g. working over a remote connection while at the same time downloading a big tar file via ftp or a browser. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 10:11:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 632F4155AA; Thu, 15 Jul 1999 10:10:48 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id NAA03267; Thu, 15 Jul 1999 13:08:45 -0400 (EDT) Date: Thu, 15 Jul 1999 13:08:45 -0400 (EDT) From: Daniel Eischen Message-Id: <199907151708.NAA03267@pcnet1.pcnet.com> To: jkh@zippy.cdrom.com, tg@ihf.rwth-aachen.de Subject: Re: seg fault in mutex_queue_enq Cc: eischen@vigrid.com, hackers@FreeBSD.ORG, kip@lyris.com, stable@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Jordan should have to say something about this. AFAIR, bumps are > > allowed but only by one between releases. We will have to provide > > libc_r.so.3 in /usr/lib/compat/compat3x, though (we'll have to do this > > anyway by the time 4.x is released). > > I'd prefer not to bump it... John Birrell and I are already not > entirely in agreement that the change required a version bump at > all. It didn't change any interfaces. I don't care one way or the other. I could leave out the wrapped poll() very easily and avoid the issue all together. This would provide -stable with everything -current has, except of course poll(). I'd prefer to add poll, though... If you don't bump the version in -stable, then you could end up with two versions of libc_r that are not different (assuming -current doesn't make any subsequent changes that warrant a version bump). Just tell me what to do, and I'll do it :-) Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 10:23: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 32B1614D13 for ; Thu, 15 Jul 1999 10:22:51 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA11524; Thu, 15 Jul 1999 10:20:41 -0700 (PDT) (envelope-from dillon) Date: Thu, 15 Jul 1999 10:20:41 -0700 (PDT) From: Matthew Dillon Message-Id: <199907151720.KAA11524@apollo.backplane.com> To: Jennifer Clark Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Advice on deriving accurate time values from the kernel? References: <378E10C4.9AD7979E@vulture.dmem.strath.ac.uk> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Hi, : :I am in the process of developing a device driver for the purpose of :stepper motor control. The timing of each pulse is determined by :external timing hardware on an I/O board, which will fire an interrupt :after the time requested. Using this method, I am able to generate :streams of pulses at approximately 5000Hz on a Pentium II 400MHz system. : :Everything seems to be working well, but I'd really like to gather some :accurate timing data in order to derive some statistics to from the :system. Intuition tells me I'll need a clock with a tick rate of at :least 20000 Hz to derive this. : :So, is such a thing available in the kernel? I've searched through :various mailing list archives and have found reference to the "HZ" :option to the kernel, which works to a point. However, it is not ideal :as setting HZ to high values generates far too much kernel overhead. :Also being considered is additional external timing hardware, but this :is something I'd rather avoid for many reasons. : :What I am after is not a "timer" as such - all I need to do is derive a :time value at an initial time, and a subsequent value at a later time. :I've used "getmicrouptime", but this appears dependent on the "Hz" :option, and as such is of limited use. : :I've just had some input from a colleauge who has suggested using the :Pentium profiling registers, which we are currently investigating... : :Any advice gratefully received, : :-- :Jennifer Clark Hmm. FreeBSD does not guarentee interrupt timing. If the system is busy doing other things your interrupts can be significantly delays (by microseconds, even milliseconds). I would definitely not try to control a stepper motor from an interrupt! What I recommend instead is that you put a microcontroller on the I/O board and have it do all the sensitive stepper motor timing, then write a device driver that does supervisory management of the microcontroller. For example, a small 68HC11F1 or an 8xC51 type of microcontrollor would work well. I prefer the 68HC11F1 myself because it has automatically timed output registers that make it easy to generate perfect waveforms. In regards to your question on accumulating statistics... that's a hard one. An external interrupt pulse is probably the easiest way to do it even though you do not like the idea. It may also be sufficient to call getmicrouptime from the interrupt you are already getting from the I/O board. Another possibility would be to write a user-level process with access to the I/O space (via /dev/mem or /dev/io) to poll in a tight loop and collect statistics that way. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 10:39: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2]) by hub.freebsd.org (Postfix) with ESMTP id 0DACA14C86 for ; Thu, 15 Jul 1999 10:39:01 -0700 (PDT) (envelope-from soda@sra.co.jp) Received: from sranhf.sra.co.jp (sranhf [133.137.28.3]) by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id CAA19890; Fri, 16 Jul 1999 02:38:22 +0900 (JST) Received: from srapc342.sra.co.jp (srapc342 [133.137.28.111]) by sranhf.sra.co.jp (8.8.7/3.6Wbeta7-srambox) with ESMTP id CAA07823; Fri, 16 Jul 1999 02:38:21 +0900 (JST) Received: (from soda@localhost) by srapc342.sra.co.jp (8.8.8/3.4W-sra) id CAA10933; Fri, 16 Jul 1999 02:38:22 +0900 (JST) Date: Fri, 16 Jul 1999 02:38:22 +0900 (JST) Message-Id: <199907151738.CAA10933@srapc342.sra.co.jp> From: Noriyuki Soda To: freebsd-hackers@FreeBSD.ORG Cc: tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) In-Reply-To: References: <378D67B3.3E2A703C@newsguy.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Thu, 15 Jul 1999, Daniel C. Sobral wrote: >> Uh... like any modern unix, Solaris overcommits. >>>>> On Thu, 15 Jul 1999 08:46:36 -0700 (PDT), "Eduardo E. Horvath" said: > Where do you guys get this misinformation? : > Note the `19464k reserved'; that space has been reserved but not yet > allocated. Both Dillon and Sobral mistakenly claimed that "Solaris overcommits", this fact seems to be somewhat suggestive. And also, the followings are allocated memory and reserved memory in my environment. (This table also includes Eduardo's example) SunOS allocated reserved total total/allocated ----- --------- -------- -------- ------------ 4.1.4 4268k 1248k 5516k 1.2924 4.1.2 7732k 1492k 9224k 1.193 4.1.4 8848k 3080k 11928k 1.3481 4.1.4 13532k 6772k 20304k 1.5004 5.5.1 15312k 5092k 20404k 1.3325 4.1.3 16112k 6512k 22624k 1.4042 4.1.2 26356k 1620k 27976k 1.0615 4.1.4 26560k 3756k 30316k 1.1414 5.5 26076k 11348k 37424k 1.4352 4.1.4 32984k 5556k 38540k 1.1684 5.6 32448k 7072k 39520k 1.2179 4.1.4 38056k 3692k 41748k 1.097 4.1.4 49064k 7672k 56736k 1.1564 4.1.4 67012k 7800k 74812k 1.1164 4.1.4 99348k 16956k 116304k 1.1707 4.1.4 118288k 11780k 130068k 1.0996 5.6 231968k 18880k 250848k 1.0814 5.7 307240k 19464k 326704k 1.0634 (sorted by total amount of used swap) In those examples, non-overcommiting system requires 1.06x ... 1.50x more swap space than overcommiting system. This table also indicates that in proportion as total used swap increase the ratio will decrease. And extra swap space required on non-overcommiting system is approximately several tens mega bytes. i.e. The extra cost of non-overcommiting system is less than ten dollers in my environment. Matt Dillon claimed that non-overcommiting system requires 8x or more swap space than overcommiting system. That's just wrong as above. (There might be cases which requires 8x swap, but it is not typical like Dillon said.) If you don't want non-overcommiting system, because you don't want to pay it's cost. That's OK, but please don't force us to accept your limited view. -- soda To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 11:10: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id BCCC914E12 for ; Thu, 15 Jul 1999 11:09:56 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA11823; Thu, 15 Jul 1999 11:09:01 -0700 (PDT) (envelope-from dillon) Date: Thu, 15 Jul 1999 11:09:01 -0700 (PDT) From: Matthew Dillon Message-Id: <199907151809.LAA11823@apollo.backplane.com> To: Noriyuki Soda Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <378D67B3.3E2A703C@newsguy.com> <199907151738.CAA10933@srapc342.sra.co.jp> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Both Dillon and Sobral mistakenly claimed that "Solaris overcommits", :this fact seems to be somewhat suggestive. : :And also, the followings are allocated memory and reserved memory :in my environment. (This table also includes Eduardo's example) : : SunOS allocated reserved total total/allocated : ----- --------- -------- -------- ------------ : 4.1.4 4268k 1248k 5516k 1.2924 : 4.1.2 7732k 1492k 9224k 1.193 : 4.1.4 8848k 3080k 11928k 1.3481 : 4.1.4 13532k 6772k 20304k 1.5004 : 5.5.1 15312k 5092k 20404k 1.3325 : 4.1.3 16112k 6512k 22624k 1.4042 : 4.1.2 26356k 1620k 27976k 1.0615 : 4.1.4 26560k 3756k 30316k 1.1414 : 5.5 26076k 11348k 37424k 1.4352 : 4.1.4 32984k 5556k 38540k 1.1684 : 5.6 32448k 7072k 39520k 1.2179 : 4.1.4 38056k 3692k 41748k 1.097 : 4.1.4 49064k 7672k 56736k 1.1564 : 4.1.4 67012k 7800k 74812k 1.1164 : 4.1.4 99348k 16956k 116304k 1.1707 : 4.1.4 118288k 11780k 130068k 1.0996 : 5.6 231968k 18880k 250848k 1.0814 : 5.7 307240k 19464k 326704k 1.0634 : : (sorted by total amount of used swap) : :In those examples, non-overcommiting system requires 1.06x ... 1.50x :... :soda Umm... how are you getting the reserved numbers? Are you sure that isn't simply cached swap blocks? I.E. when something gets swapped out and then is swapped back in and dirtied, Solaris may be holding the swap block assignment rather then letting it go. FreeBSD-stable does the same thing. FreeBSD-current does not -- it lets it go in order to be able to reallocate it later as part of a contiguous swath for performance reasons. These 'extra' swap blocks are effectively reserved but not actually allocated. They can be reassigned. The numbers above are very similar to what you would see in a redirtying-cache swap block situation on a FreeBSD-stable system. If I add up all the unshared writeable segments on my home box - that is, all segments for which one would potentially have to reserve swap space - I get a total of around 382MB. The machine is currently eating around 100MB of ram and 5MB of swap, or around a 3.5:1 ratio in this case. A non-overcommit model would have to reserve swap space for 382MB - 100MB = 282MB verses the 5MB of swap the machine actually allocates. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 11:19:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2]) by hub.freebsd.org (Postfix) with ESMTP id 6E539151AD for ; Thu, 15 Jul 1999 11:19:38 -0700 (PDT) (envelope-from soda@sra.co.jp) Received: from sranhf.sra.co.jp (sranhf [133.137.28.3]) by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id DAA20806; Fri, 16 Jul 1999 03:19:30 +0900 (JST) Received: from srapc342.sra.co.jp (srapc342 [133.137.28.111]) by sranhf.sra.co.jp (8.8.7/3.6Wbeta7-srambox) with ESMTP id DAA07859; Fri, 16 Jul 1999 03:19:29 +0900 (JST) Received: (from soda@localhost) by srapc342.sra.co.jp (8.8.8/3.4W-sra) id DAA11342; Fri, 16 Jul 1999 03:19:30 +0900 (JST) Date: Fri, 16 Jul 1999 03:19:30 +0900 (JST) Message-Id: <199907151819.DAA11342@srapc342.sra.co.jp> From: Noriyuki Soda To: freebsd-hackers@FreeBSD.ORG Cc: tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) In-Reply-To: <199907151809.LAA11823@apollo.backplane.com> References: <378D67B3.3E2A703C@newsguy.com> <199907151738.CAA10933@srapc342.sra.co.jp> <199907151809.LAA11823@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> On Thu, 15 Jul 1999 11:09:01 -0700 (PDT), Matthew Dillon said: > Umm... how are you getting the reserved numbers? "pstat -s" on SunOS4, and "swap -s" on SunOS5. From Solaris man page: : -s Print summary information about total swap : space usage and availability: : : allocated The total amount of swap space : (in 1024-byte blocks) : currently allocated for use as : backing store. : : reserved The total amount of swap space : (in 1024-bytes blocks) not : currently allocated, but : claimed by memory mappings for : possible future use. : : used The total amount of swap space : (in 1024-byte blocks) that is : either allocated or reserved. -- soda To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 11:23:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 6200E14E7A for ; Thu, 15 Jul 1999 11:23:34 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA11926; Thu, 15 Jul 1999 11:23:12 -0700 (PDT) (envelope-from dillon) Date: Thu, 15 Jul 1999 11:23:12 -0700 (PDT) From: Matthew Dillon Message-Id: <199907151823.LAA11926@apollo.backplane.com> To: Noriyuki Soda Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <378D67B3.3E2A703C@newsguy.com> <199907151738.CAA10933@srapc342.sra.co.jp> <199907151809.LAA11823@apollo.backplane.com> <199907151819.DAA11342@srapc342.sra.co.jp> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :"pstat -s" on SunOS4, and "swap -s" on SunOS5. From Solaris man page: : :: -s Print summary information about total swap :: space usage and availability: :: :: allocated The total amount of swap space :: (in 1024-byte blocks) :: currently allocated for use as :: backing store. :: :: reserved The total amount of swap space :: (in 1024-bytes blocks) not :: currently allocated, but :: claimed by memory mappings for :: possible future use. :: :: used The total amount of swap space :: (in 1024-byte blocks) that is :: either allocated or reserved. :-- :soda Yah, that's what I thought. A solaris expert could tell us for sure but I am pretty sure those are simply cached swap blocks after-the-fact, not actual reservations on potentially swappable space. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 11:25:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zibbi.mikom.csir.co.za (zibbi.mikom.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id A5137155CC for ; Thu, 15 Jul 1999 11:25:24 -0700 (PDT) (envelope-from jhay@zibbi.mikom.csir.co.za) Received: (from jhay@localhost) by zibbi.mikom.csir.co.za (8.9.3/8.9.3) id UAA70423; Thu, 15 Jul 1999 20:24:58 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <199907151824.UAA70423@zibbi.mikom.csir.co.za> Subject: Re: Advice on deriving accurate time values from the kernel? In-Reply-To: <378E10C4.9AD7979E@vulture.dmem.strath.ac.uk> from Jennifer Clark at "Jul 15, 1999 05:48:04 pm" To: jen@vulture.dmem.strath.ac.uk (Jennifer Clark) Date: Thu, 15 Jul 1999 20:24:58 +0200 (SAT) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG If you only want to timestamp events and not generate the event, you can use microtime() or nanotime(). On a 400MHz PII non-SMP you should get 2.5 ns resolution with nanotime(). On a normal kernel with kern.timecounter.method at the default of 0, the get... versions give you time at the last tick or even worse, so they are no good for that. John -- John Hay -- John.Hay@mikom.csir.co.za > Hi, > > I am in the process of developing a device driver for the purpose of > stepper motor control. The timing of each pulse is determined by > external timing hardware on an I/O board, which will fire an interrupt > after the time requested. Using this method, I am able to generate > streams of pulses at approximately 5000Hz on a Pentium II 400MHz system. > > Everything seems to be working well, but I'd really like to gather some > accurate timing data in order to derive some statistics to from the > system. Intuition tells me I'll need a clock with a tick rate of at > least 20000 Hz to derive this. > > So, is such a thing available in the kernel? I've searched through > various mailing list archives and have found reference to the "HZ" > option to the kernel, which works to a point. However, it is not ideal > as setting HZ to high values generates far too much kernel overhead. > Also being considered is additional external timing hardware, but this > is something I'd rather avoid for many reasons. > > What I am after is not a "timer" as such - all I need to do is derive a > time value at an initial time, and a subsequent value at a later time. > I've used "getmicrouptime", but this appears dependent on the "Hz" > option, and as such is of limited use. > > I've just had some input from a colleauge who has suggested using the > Pentium profiling registers, which we are currently investigating... > > Any advice gratefully received, > > -- > Jennifer Clark > http://telepresence.dmem.strath.ac.uk > http://www.crmjewellery.co.uk > http://www.furniturenet.co.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 11:25:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id EC66415191 for ; Thu, 15 Jul 1999 11:25:51 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA11948; Thu, 15 Jul 1999 11:25:39 -0700 (PDT) (envelope-from dillon) Date: Thu, 15 Jul 1999 11:25:39 -0700 (PDT) From: Matthew Dillon Message-Id: <199907151825.LAA11948@apollo.backplane.com> To: Noriyuki Soda Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <378D67B3.3E2A703C@newsguy.com> <199907151738.CAA10933@srapc342.sra.co.jp> <199907151809.LAA11823@apollo.backplane.com> <199907151819.DAA11342@srapc342.sra.co.jp> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :: -s Print summary information about total swap :: space usage and availability: :: :: allocated The total amount of swap space :: (in 1024-byte blocks) :: currently allocated for use as :: backing store. :: :: reserved The total amount of swap space :: (in 1024-bytes blocks) not :: currently allocated, but :: claimed by memory mappings for :: possible future use. :: :: used The total amount of swap space :: (in 1024-byte blocks) that is :: either allocated or reserved. :-- :soda It would be really easy to test this. Write a program that malloc's 32MB of space and touches it, then sleeps 10 seconds and forks, with both child and parent sleeping afterwords. ( the parent and the forked child should not touch the memory after the fork occurs ). Do a pstat -s before, after the initial touch, and after the fork. If you do not see the reserved swap space jump by 32MB after the fork, it isn't what you thought it was. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 12:52:39 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from search.sparks.net (search.sparks.net [208.5.188.60]) by hub.freebsd.org (Postfix) with ESMTP id 04F3C151C9 for ; Thu, 15 Jul 1999 12:52:33 -0700 (PDT) (envelope-from dmiller@search.sparks.net) Received: by search.sparks.net (Postfix, from userid 100) id 2B7A2258; Thu, 15 Jul 1999 15:50:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by search.sparks.net (Postfix) with SMTP id 1C6701FA for ; Thu, 15 Jul 1999 15:50:17 -0400 (EDT) Date: Thu, 15 Jul 1999 15:50:16 -0400 (EDT) From: David Miller To: freebsd-hackers@freebsd.org Subject: 650 MB MFS? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Are there any design limits to mfs? I want to use cdrecord to write to a dozen or so CD's at once, and fear making lots of coasters if I run them all off a single on-disk file. However, a CD only holds 650 MB, so it seems like I could have the image on mfs and sleep well sans coasters. Would FreeBSD handle an mfs of this size? Thanks! --- David Miller To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 13: 7:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 48A0B155E8 for ; Thu, 15 Jul 1999 13:07:09 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA12783; Thu, 15 Jul 1999 13:06:48 -0700 (PDT) (envelope-from dillon) Date: Thu, 15 Jul 1999 13:06:48 -0700 (PDT) From: Matthew Dillon Message-Id: <199907152006.NAA12783@apollo.backplane.com> To: David Miller Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: 650 MB MFS? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Are there any design limits to mfs? I want to use cdrecord to write to a :dozen or so CD's at once, and fear making lots of coasters if I run them :all off a single on-disk file. However, a CD only holds 650 MB, so it :seems like I could have the image on mfs and sleep well sans coasters. : :Would FreeBSD handle an mfs of this size? : :Thanks! : :--- David Miller Well, if you have 650MB of ram available... I suppose. Otherwise MFS is just going to shove the data into swap. The answer is, yes you can create an MFS partition that large. You have to make sure that you have sufficient swap available and that your datasize resource limit is big enough. So, checklist: * You will need 650MB of swap, possibly even more. (unless you have 650MB+ of ram in your system) * from csh, 'unlimit data' then type 'limit' to see what your maximum datasize limit is. You may have to reconfigure your kernel to increase it: options "MAXDSIZ=(1024*1024*1024)" * Look into using the VN device instead of MFS. VN allows you to create a 'disk file' and then turn it into a partition that you can then mount and use normally. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 13: 7:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 66DC2155FE for ; Thu, 15 Jul 1999 13:07:24 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id NAA06753; Thu, 15 Jul 1999 13:05:51 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id NAA29119; Thu, 15 Jul 1999 13:05:51 -0700 Received: from softweyr.com (dyn2.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA03570; Thu, 15 Jul 99 13:05:44 PDT Message-Id: <378E3F17.717FBF6C@softweyr.com> Date: Thu, 15 Jul 1999 14:05:43 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Mike Smith Cc: Marc Tardif , freebsd-hackers@FreeBSD.ORG Subject: Re: gdb instead of adb References: <199907150545.WAA00453@dingo.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith wrote: > > > Is the reason why adb hasn't been ported to freebsd because the source is > > proprietary? > > You make no sense. > > > If gdb should suffice for my debugging needs, how can a breakpoint be set > > at a particular interrupt, or even at any interrupt? The break command > > only seems to accept functions, offsets, linenumbers and addresses... > > I'm all out of ideas and the gdb info file isn't helping. > > You make little more sense, unless you are talking about using > gdb-remote on a running kernel, in which case you should know that > interrupts are vectored through functions, and thus the entire issue is > moot. > > Note also that debugging through interrupt handlers can be problematic > on PC hardware. Logic analyzers and/or ICEs are your friends here. Expensive friends. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 13:47:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.palmerharvey.co.uk (mail.palmerharvey.co.uk [62.172.109.58]) by hub.freebsd.org (Postfix) with ESMTP id E5C11155FA for ; Thu, 15 Jul 1999 13:47:50 -0700 (PDT) (envelope-from Dom.Mitchell@palmerharvey.co.uk) Received: from ho-nt-01.pandhm.co.uk (unverified) by mail.palmerharvey.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 15 Jul 1999 21:45:56 +0100 Received: from voodoo.pandhm.co.uk (VOODOO [10.100.35.12]) by ho-nt-01.pandhm.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 3WRWC5C5; Thu, 15 Jul 1999 21:46:44 +0100 Received: from dom by voodoo.pandhm.co.uk with local (Exim 2.10 #1) id 114sOb-0000U7-00; Thu, 15 Jul 1999 21:46:21 +0100 Date: Thu, 15 Jul 1999 21:46:21 +0100 To: Alex Knowles Cc: freebsd-hackers@freebsd.org Subject: Re: printing Message-Id: <19990715214620.C1728@palmerharvey.co.uk> References: <000a01becea6$b2fe5d20$a89d24d4@profero.com> MIME-Version: 1.0 X-Mailer: Mutt 0.95.6i In-Reply-To: <000a01becea6$b2fe5d20$a89d24d4@profero.com>; from Alex Knowles on Thu, Jul 15, 1999 at 10:44:57AM +0100 From: Dominic Mitchell Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 15, 1999 at 10:44:57AM +0100, Alex Knowles wrote: > I hope this is the right place to post, sorry if it's not. > I'm really sorry to post what is probably a repeat question, but I've just > upgraded to freebsd 3.2-release and I'm having real problems getting the > kernel to see my printer ports: > > here is my kernel > device ppc0 at isa? port? flags 0x40 net irq 7 > controller ppbus0 > device lpt0 at ppbus? > device plip0 at ppbus? > device ppi0 at ppbus? > > and here is my dmesg output: > ppc0 at 0x3bc irq 7 flags 0x40 on isa > ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode > ppi0: on ppbus 0 > plip0: on ppbus 0 > > whenever I try to access lpt0 it says that the device is not configured. > If I try and use the old configuration of lpt and I try and build the kernel > I get a whole load of make errors. Quick guess: Remove your device entries in /dev/ and recreate them with /dev/MAKEDEV. There may well be a different major/minor number for the new device. -- Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ********************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 13:55: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from freja.webgiro.com (freja.webgiro.com [212.209.29.10]) by hub.freebsd.org (Postfix) with ESMTP id CC276155FD for ; Thu, 15 Jul 1999 13:54:56 -0700 (PDT) (envelope-from abial@webgiro.com) Received: by freja.webgiro.com (Postfix, from userid 1001) id EBE151908; Thu, 15 Jul 1999 22:54:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by freja.webgiro.com (Postfix) with ESMTP id EAFA149CC; Thu, 15 Jul 1999 22:54:08 +0200 (CEST) Date: Thu, 15 Jul 1999 22:54:08 +0200 (CEST) From: Andrzej Bialecki To: John Nemeth Cc: "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) In-Reply-To: <199907142001.NAA16574@vtn1.victoria.tc.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 14 Jul 1999, John Nemeth wrote: > On Jul 15, 2:40am, "Daniel C. Sobral" wrote: > } Garance A Drosihn wrote: > } > At 12:20 AM +0900 7/15/99, Daniel C. Sobral wrote: > } > > In which case the program that consumed all memory will be killed. > } > > The program killed is +NOT+ the one demanding memory, it's the one > } > > with most of it. > } > > } > But that isn't always the best process to have killed off... > } > } Sure it is. :-) Let's see... > > This statement is absurd. Only a comptetant admin can decide > which process can be killed. No arbitrary decision is going to be > correct. > > } > It would be nice to have a way to indicate that, a la SIGDANGER. How about assigning something like a class to process, which gives VM a hint which processes should be killed first without much thinking, and which the last (or never)? In other words, let's say class 10 means "totally disposable, kill whenever you want", and class 1 means "never try to kill me". Of course, most processes would get some default value, and superuser could "renice" them to more resistant class. This way both sides of the discussion would be satisfied :-) Andrzej Bialecki // WebGiro AB, Sweden (http://www.webgiro.com) // ------------------------------------------------------------------- // ------ FreeBSD: The Power to Serve. http://www.freebsd.org -------- // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 14: 1: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id A0802155FD; Thu, 15 Jul 1999 14:01:01 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id NAA02766; Thu, 15 Jul 1999 13:59:31 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Daniel Eischen Cc: tg@ihf.rwth-aachen.de, hackers@FreeBSD.ORG, kip@lyris.com, stable@FreeBSD.ORG Subject: Re: seg fault in mutex_queue_enq In-reply-to: Your message of "Thu, 15 Jul 1999 13:08:45 EDT." <199907151708.NAA03267@pcnet1.pcnet.com> Date: Thu, 15 Jul 1999 13:59:31 -0700 Message-ID: <2762.932072371@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I don't care one way or the other. I could leave out the wrapped > poll() very easily and avoid the issue all together. This would > provide -stable with everything -current has, except of course > poll(). I'd prefer to add poll, though... I'm OK with adding poll(), it just seemed odd that the version number bumped with no API interface changes taking place. Handle it however you best see fit. :) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 14:42:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from bingnet2.cc.binghamton.edu (mailbox.adm.binghamton.edu [128.226.10.60]) by hub.freebsd.org (Postfix) with ESMTP id B906014E44 for ; Thu, 15 Jul 1999 14:42:46 -0700 (PDT) (envelope-from zzhang@cs.binghamton.edu) Received: from cs.binghamton.edu (bing49.net107.binghamton.edu [128.226.107.49]) by bingnet2.cc.binghamton.edu (8.9.3/8.9.3) with ESMTP id RAA25907 for ; Thu, 15 Jul 1999 17:40:14 -0400 (EDT) Message-ID: <378E553B.E6C71B0B@cs.binghamton.edu> Date: Thu, 15 Jul 1999 17:40:12 -0400 From: Zhihui Zhang Reply-To: zzhang@cs.binghamton.edu Organization: SUNY - Binghamton X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Help with PCI code understanding Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Can someone outline the initialization process of PCI devices in FreeBSD? I know many of the basic stuff of PCI introduced in the book "PCI System Architecture". I just want to know how each driver is registered into some linker set and its probe routine gets called. In other words, I want to know the major data structures and routines and their relationship. I wonder if there is already a document somewhere. Any help is appreciated. -Zhihui To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 15:16: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id B126415179 for ; Thu, 15 Jul 1999 15:15:55 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 114tmt-000Kg9-00; Fri, 16 Jul 1999 00:15:31 +0200 From: Sheldon Hearn To: Garance A Drosihn Cc: Paul Hart , freebsd-hackers@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) In-reply-to: Your message of "Thu, 15 Jul 1999 17:33:29 -0400." Date: Fri, 16 Jul 1999 00:15:31 +0200 Message-ID: <79492.932076931@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [Hijacked from freebsd-security] On Thu, 15 Jul 1999 17:33:29 -0400, Garance A Drosihn wrote: > What I wanted to do was have "estr" routines, where the destination > is specified as the starting point and the ending point of the area > available for the string (as two parameters). The routines would > return the position of the current string-terminator. So you could > do things like: As I understand it, the goal here is to return to the caller the number of bytes copied (however you represent it), so that the caller can easily determine whether or not dst is safe for operations demanding a null-terminated string. If that is true, then I think the interface you propose is overly complex. Looking at the existing functions, their only flaw is that they return known (and therefore useless) information, "wasting" the return value. All we need is: size_t foocpy(char *dst, const char *src) size_t fooncpy(char *dst, const char *src, size_t len) size_t foocat(char *s, const char *append) size_t fooncat(char *s, const char *append, size_t count) where the return value is the number of bytes {copied,appended}. Since the goal is simply to make it easier to do what is already possible, I think that this approach is better than what you're suggesting, since the pointer arithmetic required in the caller is simpler. And since the prototypes for fooncpy and fooncat above match exactly those of the proposed strlcpy and strlcat respectively (just had a look before I "hit the send button"), I'd say that the latter two are definitely the functions you want. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 15:32:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id B727F14E2E for ; Thu, 15 Jul 1999 15:32:12 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id AAA14446 for hackers@FreeBSD.ORG; Fri, 16 Jul 1999 00:31:55 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 3B9548888; Fri, 16 Jul 1999 00:12:40 +0200 (CEST) (envelope-from roberto) Date: Fri, 16 Jul 1999 00:12:40 +0200 From: Ollivier Robert To: hackers@FreeBSD.ORG Subject: Re: make fails in 3.2-RELEASE for netboot Message-ID: <19990716001240.A39324@keltia.freenix.fr> Mail-Followup-To: hackers@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.95.5i In-Reply-To: ; from Gregory A. Carter on Thu, Jul 15, 1999 at 08:21:58AM -0700 X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5468 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Gregory A. Carter: > I'm assuming that might have something to do with it. The file scrt0.c This is the old a.out crt code. The one in 3.0+ is crt1.c, look into /usr/src/lib/csu/i386-elf/. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #72: Mon Jul 12 08:26:43 CEST 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 15:34: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp13.bellglobal.com (smtp13.bellglobal.com [204.101.251.52]) by hub.freebsd.org (Postfix) with ESMTP id B0BC815616 for ; Thu, 15 Jul 1999 15:34:04 -0700 (PDT) (envelope-from hoek@FreeBSD.org) Received: from localhost.nowhere (ppp18340.on.bellglobal.com [206.172.130.20]) by smtp13.bellglobal.com (8.8.5/8.8.5) with ESMTP id SAA11897; Thu, 15 Jul 1999 18:35:29 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id SAA53768; Thu, 15 Jul 1999 18:34:42 -0400 (EDT) (envelope-from tim) Date: Thu, 15 Jul 1999 18:34:42 -0400 From: Tim Vanderhoek To: Sheldon Hearn Cc: Garance A Drosihn , Paul Hart , freebsd-hackers@FreeBSD.org Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Message-ID: <19990715183442.A53661@mad> References: <79492.932076931@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <79492.932076931@axl.noc.iafrica.com>; from Sheldon Hearn on Fri, Jul 16, 1999 at 12:15:31AM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 16, 1999 at 12:15:31AM +0200, Sheldon Hearn wrote: > > As I understand it, the goal here is to return to the caller the number > of bytes copied (however you represent it), so that the caller can > easily determine whether or not dst is safe for operations demanding a > null-terminated string. [...] > size_t > fooncat(char *s, const char *append, size_t count) > > where the return value is the number of bytes {copied,appended}. Eeks! This will quickly lead to code like if (fooncat(string, append, sizeof(string)) != strlen(append)) ... which is rather evil, given that the second strlen(append) would be completely gratuitous if it weren't for the interface you're suggesting. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 15:37:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 50BA715614 for ; Thu, 15 Jul 1999 15:37:47 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA13341; Thu, 15 Jul 1999 15:37:31 -0700 (PDT) (envelope-from dillon) Date: Thu, 15 Jul 1999 15:37:31 -0700 (PDT) From: Matthew Dillon Message-Id: <199907152237.PAA13341@apollo.backplane.com> To: "D. Rock" Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907152123.XAA00753@server.rock> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Before program start: :total: 20000k bytes allocated + 4792k reserved = 24792k used, 191048k available : :After malloc, before touch: :total: 18756k bytes allocated + 37500k reserved = 56256k used, 159580k available : :After malloc + touch: :total: 52804k bytes allocated + 4852k reserved = 57656k used, 158184k available : :After fork: :total: 52928k bytes allocated + 37644k reserved = 90572k used, 125264k available : :[there has been a little background activity, but the numbers speak for themselves] : : :Daniel Assuming the allocated field is not inclusive of real memory, what we have is swap reservation under solaris for clean pages, and allocation and assignment for dirty pages. The grand total will tell you the total VM potential for malloc'd space but does not appear to tell you how much swap is actually active - i.e. was written to and contains valid data. It would be interesting to see if the stack segment is included in the reservation. Try setting the stack resource limit to 32m and run the same program, except without bothering to malloc() or touch anything. See if the stack segment is included in the reservation field. It would also be interesting to see how solaris deals with MAP_PRIVATE mmap's. If this is correct, then solaris is using a VMSPACE = SWAPSPACE model. FreeBSD uses a VMSPACE = SWAPSPACE + REALMEM model. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 15:44:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from sumatra.americantv.com (sumatra.americantv.com [208.139.222.227]) by hub.freebsd.org (Postfix) with ESMTP id 235F5155E8 for ; Thu, 15 Jul 1999 15:44:43 -0700 (PDT) (envelope-from jlemon@americantv.com) Received: from right.PCS (right.PCS [148.105.10.31]) by sumatra.americantv.com (8.8.5/8.8.5) with ESMTP id RAA17105 for ; Thu, 15 Jul 1999 17:44:28 -0500 (CDT) Received: from free.pcs (free.PCS [148.105.10.51]) by right.PCS (8.6.13/8.6.4) with ESMTP id RAA07054 for ; Thu, 15 Jul 1999 17:44:26 -0500 Received: (from jlemon@localhost) by free.pcs (8.8.6/8.8.5) id RAA12439; Thu, 15 Jul 1999 17:44:25 -0500 (CDT) Date: Thu, 15 Jul 1999 17:44:25 -0500 (CDT) From: Jonathan Lemon Message-Id: <199907152244.RAA12439@free.pcs> To: hackers@freebsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) X-Newsgroups: local.mail.freebsd-hackers In-Reply-To: References: Organization: Architecture and Operating System Fanatics Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you write: >:: -s Print summary information about total swap >:: space usage and availability: >:: >:: allocated The total amount of swap space >:: (in 1024-byte blocks) >:: currently allocated for use as >:: backing store. >:: >:: reserved The total amount of swap space >:: (in 1024-bytes blocks) not >:: currently allocated, but >:: claimed by memory mappings for >:: possible future use. >:: >:: used The total amount of swap space >:: (in 1024-byte blocks) that is >:: either allocated or reserved. >:-- >:soda > > It would be really easy to test this. > > Write a program that malloc's 32MB of space and touches it, > then sleeps 10 seconds and forks, with both child and parent > sleeping afterwords. ( the parent and the forked child should > not touch the memory after the fork occurs ). > > Do a pstat -s before, after the initial touch, and after > the fork. If you do not see the reserved swap space jump > by 32MB after the fork, it isn't what you thought it was. aladdin[5:32pm]> prtconf System Configuration: Sun Microsystems i86pc Memory size: 128 Megabytes aladdin[5:41pm]> uname -a SunOS aladdin 5.6 Generic_105182-14 i86pc i386 total: 67280k bytes allocated + 28668k reserved = 95948k used, 196460k avail malloced 32MB... total: 67320k bytes allocated + 61460k reserved = 128780k used, 163592k avail touched... total: 100084k bytes allocated + 28696k reserved = 128780k used, 163732k avail forking... total: 100092k bytes allocated + 61520k reserved = 161612k used, 130864k avail touching again (parent)... touching again (child)... total: 132864k bytes allocated + 28748k reserved = 161612k used, 130760k avail exiting... exiting... total: 67248k bytes allocated + 28700k reserved = 95948k used, 196448k avail -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 15:48:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id 1614115616 for ; Thu, 15 Jul 1999 15:48:35 -0700 (PDT) (envelope-from sthaug@nethelp.no) Received: (qmail 23934 invoked by uid 1001); 15 Jul 1999 22:46:49 +0000 (GMT) To: dillon@apollo.backplane.com Cc: rock@dead-end.net, freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) From: sthaug@nethelp.no In-Reply-To: Your message of "Thu, 15 Jul 1999 15:37:31 -0700 (PDT)" References: <199907152237.PAA13341@apollo.backplane.com> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Fri, 16 Jul 1999 00:46:48 +0200 Message-ID: <23932.932078808@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > If this is correct, then solaris is using a VMSPACE = SWAPSPACE > model. FreeBSD uses a VMSPACE = SWAPSPACE + REALMEM model. AFAIK it has been stated quite explicitly by the Solaris folks that Solaris 2.x uses VMSPACE = SWAPSPACE + REALMEM. This is *different* from SunOS 4.1.x. Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 15:50:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id A6788155E8 for ; Thu, 15 Jul 1999 15:50:43 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id PAA01458; Thu, 15 Jul 1999 15:44:51 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907152244.PAA01458@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Tim Vanderhoek Cc: Sheldon Hearn , Garance A Drosihn , Paul Hart , freebsd-hackers@FreeBSD.org Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) In-reply-to: Your message of "Thu, 15 Jul 1999 18:34:42 EDT." <19990715183442.A53661@mad> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Jul 1999 15:44:51 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Fri, Jul 16, 1999 at 12:15:31AM +0200, Sheldon Hearn wrote: > > > > As I understand it, the goal here is to return to the caller the number > > of bytes copied (however you represent it), so that the caller can > > easily determine whether or not dst is safe for operations demanding a > > null-terminated string. > [...] > > size_t > > fooncat(char *s, const char *append, size_t count) > > > > where the return value is the number of bytes {copied,appended}. > > Eeks! This will quickly lead to code like > > if (fooncat(string, append, sizeof(string)) != strlen(append)) > ... > > which is rather evil, given that the second strlen(append) would be > completely gratuitous if it weren't for the interface you're > suggesting. What's really stupid is that most of the time you're trying to use these functions to fix code that looks like: strcpy(buf, str1); strcat(buf, str2); strcat(buf, str3); without overflowing buf. This is dumb! Use asprintf instead: asprinf(&buf, "%s%s%s", str1, str2, str3); If you can't keep all of the string elements together at once, try: asprinf(&buf, "%s%s", str1, str2); ... asprintf(&buf2, "%s%s", buf, str3); free(buf); No, it's not fast, but it _is_ robust. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 15:54:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 1773D15640 for ; Thu, 15 Jul 1999 15:54:20 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 114uNN-000Kpp-00; Fri, 16 Jul 1999 00:53:13 +0200 From: Sheldon Hearn To: Tim Vanderhoek Cc: freebsd-hackers@FreeBSD.org Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) In-reply-to: Your message of "Thu, 15 Jul 1999 18:34:42 -0400." <19990715183442.A53661@mad> Date: Fri, 16 Jul 1999 00:53:13 +0200 Message-ID: <80092.932079193@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Jul 1999 18:34:42 -0400, Tim Vanderhoek wrote: > if (fooncat(string, append, sizeof(string)) != strlen(append)) > ... > > which is rather evil, given that the second strlen(append) would be > completely gratuitous if it weren't for the interface you're > suggesting. Tim, you're doing that "I'm right, but too concise to be understood" thing again. What are you saying here? :-) If all you're saying is that you want an API that doesn't require a test against the known length of src (append in your example), then you won't like strl*. :-) You'd probably prefer the functions to return the number of bytes which they did not manage to {copy,append}, yes? Lazy bastard [1]. :-) While this might be something we add, it shouldn't be called strl{cpy,cat}. And the original question was whether or not we'd add the strl{cpy,cat} functions to libc. If we do, I seriously hope I'll be given the opportunity to submit a replacement manpage, since theirs sucks. Ciao, Sheldon. [1] It's usually the lazy guy who demands the best API, provided his demands are tempered by the pedantic guy. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 16: 4:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 39FE41562F for ; Thu, 15 Jul 1999 16:04:34 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id QAA04599; Thu, 15 Jul 1999 16:04:13 -0700 (PDT) Date: Thu, 15 Jul 1999 16:04:12 -0700 (PDT) From: Julian Elischer To: Mike Smith Cc: Tim Vanderhoek , Sheldon Hearn , Garance A Drosihn , Paul Hart , freebsd-hackers@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) In-Reply-To: <199907152244.PAA01458@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Jul 1999, Mike Smith wrote: > > What's really stupid is that most of the time you're trying to use > these functions to fix code that looks like: > > strcpy(buf, str1); > strcat(buf, str2); > strcat(buf, str3); > without overflowing buf. This is dumb! Use asprintf instead: There was a talk on these (strlcpy(3) and strlcat(3)) at USENIX. The logic as to their design was presented and I agree totally with the way that the logic was played out into the functions. They are described in the FreeNIX proceedings on page 175. I feel they make a lot more sense that teh present version sand we should support OpenBSD's application to Posix to make them standard. They lead to faster overall code, (people using present functions often re-count the size of result strings, or check the end of the buffer for a 0) and lead to more readable code. All of these age a "Good Thing" (TM). > > asprinf(&buf, "%s%s%s", str1, str2, str3); > Very nice but not always applicable. Particularly when compiling strings under algorythmic control. > If you can't keep all of the string elements together at once, try: > > asprinf(&buf, "%s%s", str1, str2); > ... > asprintf(&buf2, "%s%s", buf, str3); > free(buf); > > No, it's not fast, but it _is_ robust. Why not be fast AND robust? :-) I like the new functions and would like to see them supported. julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 16:21:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gatekeeper.veriohosting.com (gatekeeper.veriohosting.com [192.41.0.2]) by hub.freebsd.org (Postfix) with ESMTP id 39AF314F60 for ; Thu, 15 Jul 1999 16:21:50 -0700 (PDT) (envelope-from hart@iserver.com) Received: by gatekeeper.veriohosting.com; Thu, 15 Jul 1999 17:21:50 -0600 (MDT) Received: from unknown(192.168.1.109) by gatekeeper.veriohosting.com via smap (V3.1.1) id xma004796; Thu, 15 Jul 99 17:21:47 -0600 Received: (hart@localhost) by anchovy.orem.iserver.com (8.9.2) id RAA22743; Thu, 15 Jul 1999 17:20:52 -0600 (MDT) Date: Thu, 15 Jul 1999 17:20:52 -0600 (MDT) From: Paul Hart X-Sender: hart@anchovy.orem.iserver.com To: Julian Elischer Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Jul 1999, Julian Elischer wrote: > There was a talk on these (strlcpy(3) and strlcat(3)) at USENIX. > The logic as to their design was presented and I agree totally with > the way that the logic was played out into the functions. > > They are described in the FreeNIX proceedings on page 175. > I feel they make a lot more sense that teh present version sand we should > support OpenBSD's application to Posix to make them standard. Yes, this discussion started out on freebsd-security and when I first wrote about it, I mentioned the paper at USENIX by Todd Miller and Theo de Raadt. It was later mentioned that the paper and accompanying slides are available at: http://www.openbsd.org/papers/strlcpy-paper.ps http://www.openbsd.org/papers/strlcpy-slides.ps I think each function is well thought out and I think they'd be a great addition to FreeBSD. Paul Hart -- Paul Robert Hart ><8> ><8> ><8> Verio Web Hosting, Inc. hart@iserver.com ><8> ><8> ><8> http://www.iserver.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 16:22:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id B615F14FF8 for ; Thu, 15 Jul 1999 16:22:54 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA13667; Thu, 15 Jul 1999 16:22:41 -0700 (PDT) (envelope-from dillon) Date: Thu, 15 Jul 1999 16:22:41 -0700 (PDT) From: Matthew Dillon Message-Id: <199907152322.QAA13667@apollo.backplane.com> To: sthaug@nethelp.no Cc: rock@dead-end.net, freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907152237.PAA13341@apollo.backplane.com> <23932.932078808@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Here is what I get from one of BEST's mail & www proxy machines. ~dillon/br adds the object size's together. 'swap' and 'default' objects refers to unbacked VM objects - and none of the processes running fork shared unbacked objects so we don't have to worry about that. The 'swap' designation means that at least one page in the object has been assigned swap. The default designation means that no pages have been assigned swap. The pages can be dirty or clean. Typical /proc/PID/map output looks like this (taken from one of the sendmail processes). The lines I've marked are the ones being counted as unbacked/swap-backed VM. The rest are vnode-backed and not counted. 0x1000 0x4b000 66 0 r-x COW vnode 0x4b000 0x4e000 3 3 rwx COW vnode 0x4e000 0x87000 53 43 rwx COW swap <--- 0x87000 0x373000 738 738 rwx default <--- 0x2004b000 0x2005a000 2 0 r-x COW vnode 0x2005a000 0x2005c000 2 0 rwx COW vnode 0x2005c000 0x20065000 6 2 rwx COW swap <--- 0x20068000 0x2006d000 3 0 r-x COW vnode 0x2006d000 0x2006e000 1 1 rwx COW vnode 0x2006e000 0x200cc000 70 0 r-x COW vnode 0x200cc000 0x200d0000 4 4 rwx COW vnode 0x200d0000 0x200e7000 8 6 rwx COW swap <--- 0xefbde000 0xefbfe000 14 14 rwx COW swap <--- proxy1:/tmp# cat /proc/*/map | egrep 'swap|default' | ~dillon/br 639168K proxy1:/tmp# pstat -s Device 1K-blocks Used Avail Capacity Type /dev/sd0b 524288 12596 511628 2% Interleaved This machine has 256MB of ram of which around 200MB is in use, we will assume the entire 200MB is used by VM spaces for processes. It is an active machine with around 205 processes at the time of the test. So. 200MB of ram + 12MB of swap = 212MB of actual storage being used out of 639MB of total swap-backable VM. About a factor of 3.2:1. Actual swap utilization is sitting at 2%. If no overcommit were allowed, and assuming a VMSPACE = REALMEM + SWAP model, 200MB of ram would be active and 439MB worth of swap would be either allocated or reserved ( though only 12MB would be actually written, that part doesn't change ). 439MB of swap verses 12MB of swap. In that scenario, the 512MB of swap I assigned to this machine would be dangerously low. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 16:27:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id 454341562D for ; Thu, 15 Jul 1999 16:27:18 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id QAA01649; Thu, 15 Jul 1999 16:18:08 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907152318.QAA01649@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Julian Elischer Cc: Mike Smith , Tim Vanderhoek , Sheldon Hearn , Garance A Drosihn , Paul Hart , freebsd-hackers@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) In-reply-to: Your message of "Thu, 15 Jul 1999 16:04:12 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Jul 1999 16:18:08 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > What's really stupid is that most of the time you're trying to use > > these functions to fix code that looks like: > > > > strcpy(buf, str1); > > strcat(buf, str2); > > strcat(buf, str3); > > without overflowing buf. This is dumb! Use asprintf instead: > > There was a talk on these (strlcpy(3) and strlcat(3)) at USENIX. > The logic as to their design was presented and I agree totally with > the way that the logic was played out into the functions. I'm inclined to disagree, simply because they take too fine-grained an approach to the problem. > > asprinf(&buf, "%s%s%s", str1, str2, str3); > > > > Very nice but not always applicable. Particularly when compiling > strings under algorythmic control. I'm not sure what "compiling strings under algorithmic control" is actually meant to mean. The only addition I'd want to make to asprintf() is reasprintf() which reallocs and appends to the end of an already existing string. > > No, it's not fast, but it _is_ robust. > > Why not be fast AND robust? > :-) The two are generally not compatible. > I like the new functions and would like to see them supported. Obviously, I'm not in agreement here. The original trend (assembling strings piecemeal) was expedient but not really a great idea in the long term. Likewise there are a plethora of hand-rolled string parsers that could be replaced with sscanf() these days. Adding fancier piecemeal operators just continues to encourage the old, unsafe style. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 16:34:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id 130601562D for ; Thu, 15 Jul 1999 16:34:13 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id QAA01720; Thu, 15 Jul 1999 16:29:53 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907152329.QAA01720@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Paul Hart Cc: Julian Elischer , freebsd-hackers@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) In-reply-to: Your message of "Thu, 15 Jul 1999 17:20:52 MDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Jul 1999 16:29:53 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Thu, 15 Jul 1999, Julian Elischer wrote: > > > There was a talk on these (strlcpy(3) and strlcat(3)) at USENIX. > > The logic as to their design was presented and I agree totally with > > the way that the logic was played out into the functions. > > > > They are described in the FreeNIX proceedings on page 175. > > I feel they make a lot more sense that teh present version sand we should > > support OpenBSD's application to Posix to make them standard. > > Yes, this discussion started out on freebsd-security and when I first > wrote about it, I mentioned the paper at USENIX by Todd Miller and Theo de > Raadt. It was later mentioned that the paper and accompanying slides are > available at: > > http://www.openbsd.org/papers/strlcpy-paper.ps > http://www.openbsd.org/papers/strlcpy-slides.ps > > I think each function is well thought out and I think they'd be a great > addition to FreeBSD. Ugh. Take the first example in the paper; it rewrites as len = asprintf(&path, "%s/.foorc"); as opposed to strlcat(path, homedir, sizeof(path)); strlcat(path, "/", sizeof(path)); strlcat(path, ".foord", sizeof(path)); len = strlen(path); Yes, they're a better str*cat/cpy, but they're not the solution that they claim to be. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 16:37:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id 6C3D91562C for ; Thu, 15 Jul 1999 16:37:52 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id QAA01747; Thu, 15 Jul 1999 16:32:25 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907152332.QAA01747@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Mike Smith Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) In-reply-to: Your message of "Thu, 15 Jul 1999 16:29:53 PDT." <199907152329.QAA01720@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Jul 1999 16:32:25 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Ugh. Take the first example in the paper; it rewrites as > > len = asprintf(&path, "%s/.foorc"); ^ , homedir Whoops. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 16:40:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gatekeeper.veriohosting.com (gatekeeper.veriohosting.com [192.41.0.2]) by hub.freebsd.org (Postfix) with ESMTP id 28B9415638 for ; Thu, 15 Jul 1999 16:40:07 -0700 (PDT) (envelope-from hart@iserver.com) Received: by gatekeeper.veriohosting.com; Thu, 15 Jul 1999 17:39:24 -0600 (MDT) Received: from unknown(192.168.1.109) by gatekeeper.veriohosting.com via smap (V3.1.1) id xma007354; Thu, 15 Jul 99 17:39:11 -0600 Received: (hart@localhost) by anchovy.orem.iserver.com (8.9.2) id RAA23182; Thu, 15 Jul 1999 17:38:16 -0600 (MDT) Date: Thu, 15 Jul 1999 17:38:16 -0600 (MDT) From: Paul Hart X-Sender: hart@anchovy.orem.iserver.com To: Mike Smith Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) In-Reply-To: <199907152329.QAA01720@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Jul 1999, Mike Smith wrote: > Ugh. Take the first example in the paper; it rewrites as > > len = asprintf(&path, "%s/.foorc"); > > as opposed to > > strlcat(path, homedir, sizeof(path)); > strlcat(path, "/", sizeof(path)); > strlcat(path, ".foord", sizeof(path)); > len = strlen(path); > > Yes, they're a better str*cat/cpy, but they're not the solution that > they claim to be. I don't think that anyone has intended them to be anything other than a better replacement for strcpy/strcat than strncpy/strncat (which they certainly are). Sure, you could go around telling people "use snprintf instead" or "use asprintf instead", but is that the issue at hand? Paul Hart -- Paul Robert Hart ><8> ><8> ><8> Verio Web Hosting, Inc. hart@iserver.com ><8> ><8> ><8> http://www.iserver.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 16:45:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp11.bellglobal.com (smtp11.bellglobal.com [204.101.251.53]) by hub.freebsd.org (Postfix) with ESMTP id 0248A1562C for ; Thu, 15 Jul 1999 16:45:10 -0700 (PDT) (envelope-from hoek@FreeBSD.org) Received: from localhost.nowhere (ppp18386.on.bellglobal.com [206.172.130.66]) by smtp11.bellglobal.com (8.8.5/8.8.5) with ESMTP id TAA01878; Thu, 15 Jul 1999 19:45:50 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id TAA54221; Thu, 15 Jul 1999 19:42:04 -0400 (EDT) (envelope-from tim) Date: Thu, 15 Jul 1999 19:42:03 -0400 From: Tim Vanderhoek To: Sheldon Hearn Cc: freebsd-hackers@FreeBSD.org Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Message-ID: <19990715194203.A54146@mad> References: <19990715183442.A53661@mad> <80092.932079193@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <80092.932079193@axl.noc.iafrica.com>; from Sheldon Hearn on Fri, Jul 16, 1999 at 12:53:13AM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 16, 1999 at 12:53:13AM +0200, Sheldon Hearn wrote: > > If all you're saying is that you want an API that doesn't require a test > against the known length of src (append in your example), then you won't > like strl*. :-) Well, if I read your message correctly, the difference between fooncat() and strlcat() would be that strlcat() returns the total number of chars in (or would be in) the destination string, whereas fooncat() returns the total number of chars copied. The former, strlcat(), avoids the problem I was noting. Looking at OpenBSD's actual definition of strlcat() which returns the number of chars that would have been in the final string is potentially non-useful, but not really toooooo terrible. [If I'm using strlcat() in the first place, am I _really_ going to care how many chars would have been copied? Maybe in legacy code, but in anything newer...] > You'd probably prefer the functions to return the number of bytes which > they did not manage to {copy,append}, yes? Lazy bastard [1]. :-) Hmm... That's an interesting idea... > strl{cpy,cat}. And the original question was whether or not we'd add the > strl{cpy,cat} functions to libc. If we do, I seriously hope I'll be Ahh, well, you did hijack this off of the -security list. Adding strlcpy() and strlcat() is probably a good idea. > given the opportunity to submit a replacement manpage, since theirs > sucks. Bah. You're in avail now. Just commit ontop of whatever manpage gets imported. ;-) If your replacement is good, no one will object. :) -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 16:45:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id AFE3B15659 for ; Thu, 15 Jul 1999 16:45:40 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id TAA54994; Thu, 15 Jul 1999 19:43:49 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <79492.932076931@axl.noc.iafrica.com> References: Your message of "Thu, 15 Jul 1999 17:33:29 -0400." Date: Thu, 15 Jul 1999 19:43:47 -0400 To: Sheldon Hearn From: Garance A Drosihn Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Cc: Paul Hart , freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 12:15 AM +0200 7/16/99, Sheldon Hearn wrote: >[Hijacked from freebsd-security] For those who missed the original article, here's the initial topic (from Paul Hart, but truncated a bit): I was just reviewing the proceedings from the USENIX 1999 Annual Technical Conference where Todd Miller and Theo de Raadt presented a paper on two new functions that OpenBSD has integrated into libc. The new functions, strlcpy(3) and strlcat(3), are intended to provide an easily understood means of safe string copying and concatenation to programmers. I was impressed by the paper and wondered if anyone besides myself would be amenable to including them in FreeBSD's libc. If you are a USENIX member you can access the text of the paper at: http://www.usenix.org/events/usenix99/millert.html (or check:) Paper: http://www.openbsd.org/papers/strlcpy-paper.ps Slides (worth looking at too): http://www.openbsd.org/papers/strlcpy-slides.ps In reply to that, I mentioned some routines that I have been meaning to write, to address what I saw as the problems with using strncat and strncpy (before I had heard of the strl* routines). Sheldon is arguing against the routines I was talking about, not the strl* routines that Paul referred to... >On Thu, 15 Jul 1999 17:33:29 -0400, Garance A Drosihn wrote: >> What I wanted to do was have "estr" routines, where the >> destination is specified as the starting point and the >> ending point of the area available for the string (as two >> parameters). The routines would return the position of >> the current string-terminator. So you could do things like: > > As I understand it, the goal here is to return to the caller > the number of bytes copied (however you represent it), so > that the caller can easily determine whether or not it is > safe for operations demanding a null-terminated string. Um, no. that certainly was not my intention with the estr* ideas... It was noticed as a side-effect of what I ended up with, but it wasn't the main objective. > And since the prototypes for fooncpy and fooncat above match > exactly those of the proposed strlcpy and strlcat respectively > (just had a look before I "hit the send button"), I'd say that > the latter two are definitely the functions you want. Well, they aren't exactly the functions *I* would want, but that isn't really the point. I do think the strl* routines are a good idea to have. I would like to see them included in "standard C" (or at least FreeBSD), because they are better (IMO) than using strncat and strncpy to avoid buffer overflows. Even looking over my OWN code, I come across times that I've used strncat or strncpy wrong. So, while I still SLIGHTLY prefer my estr* ideas over the strl* ideas, it isn't enough that I would argue against the strl* routines being standard. (and the more platforms that have them, the better). --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 16:54:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from orthanc.ab.ca (orthanc.ab.ca [207.167.3.130]) by hub.freebsd.org (Postfix) with ESMTP id 123B814CB7 for ; Thu, 15 Jul 1999 16:54:49 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (localhost.orthanc.ab.ca [127.0.0.1] (may be forged)) by orthanc.ab.ca (8.9.3/8.9.3) with ESMTP id RAA35007; Thu, 15 Jul 1999 17:53:53 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <199907152353.RAA35007@orthanc.ab.ca> To: Matthew Dillon Cc: sthaug@nethelp.no, rock@dead-end.net, freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) In-reply-to: Your message of "Thu, 15 Jul 1999 16:22:41 PDT." <199907152322.QAA13667@apollo.backplane.com> Date: Thu, 15 Jul 1999 17:53:52 -0600 From: lyndon@orthanc.ab.ca Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In that scenario, the 512MB of swap I assigned to this machine would be > dangerously low. With 13GB disks available for a couple of hundred bucks, my machines aren't going to run out of swap space any time soon, even if I commit to disk. All I want for Christmas is a knob to disable overcommit. --lyndon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 16:57:40 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns1.dynmc.net (ns1.dynmc.net [209.0.37.10]) by hub.freebsd.org (Postfix) with ESMTP id 9AA5D14CB7 for ; Thu, 15 Jul 1999 16:57:39 -0700 (PDT) (envelope-from omni@dynmc.net) Received: from localhost (omni@localhost) by ns1.dynmc.net (8.9.2/8.9.1) with ESMTP id QAA52927; Thu, 15 Jul 1999 16:53:23 -0700 (PDT) Date: Thu, 15 Jul 1999 16:53:22 -0700 (PDT) From: "Gregory A. Carter" To: Ollivier Robert Cc: hackers@FreeBSD.ORG Subject: Re: make fails in 3.2-RELEASE for netboot In-Reply-To: <19990716001240.A39324@keltia.freenix.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ollivier Robert [Re: make fails in 3.2-RELEASE for netboot] 7.16.1999 ...................................................................... . According to Gregory A. Carter: . > I'm assuming that might have something to do with it. The file scrt0.c . . This is the old a.out crt code. The one in 3.0+ is crt1.c, look into . /usr/src/lib/csu/i386-elf/. . -- . Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr . FreeBSD keltia.freenix.fr 4.0-CURRENT #72: Mon Jul 12 08:26:43 CEST 1999 ...................................................................... I found it when I went searching however I still can't get the netboot to compile as it was designed for aout. Any ideas of why it wasn't moved to elf along with the rest of the OS? Or if not how *I* can port it to elf instead? Greg +(Omni@Dynmc.Net)------------------------------------------------------+ | Dynamic Networking Solutions InterX Technologies | | Senior Network Administrator bits/keyID 1024/7DF9C285 | | omni@interx.net omni@itstudio.net omni@undernet.org omni@webpop3.com | +--------[ DC 50 57 59 C3 76 46 E8 EB 75 A8 94 FE 96 9E D3 ]----------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 16:58:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 16CF514CB7 for ; Thu, 15 Jul 1999 16:58:21 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 114vMv-000L2F-00; Fri, 16 Jul 1999 01:56:49 +0200 From: Sheldon Hearn To: lyndon@orthanc.ab.ca Cc: Matthew Dillon , sthaug@nethelp.no, rock@dead-end.net, freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) In-reply-to: Your message of "Thu, 15 Jul 1999 17:53:52 CST." <199907152353.RAA35007@orthanc.ab.ca> Date: Fri, 16 Jul 1999 01:56:49 +0200 Message-ID: <80862.932083009@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Jul 1999 17:53:52 CST, lyndon@orthanc.ab.ca wrote: > All I want for Christmas is a knob to disable overcommit. And what I'm pretty sure the majority of the readers on this list want is for those of you who really think it's necessary to do it yourselves. What? Nobody who wants to disable the policy knows how to do it? Hmmm, I wonder whether that's significant... Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 17: 4:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id ECE3914E2E for ; Thu, 15 Jul 1999 17:04:11 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id QAA01894 for ; Thu, 15 Jul 1999 16:58:53 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907152358.QAA01894@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-hackers@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) In-reply-to: Your message of "Thu, 15 Jul 1999 17:38:16 MDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Jul 1999 16:58:52 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Thu, 15 Jul 1999, Mike Smith wrote: > > > Ugh. Take the first example in the paper; it rewrites as > > > > len = asprintf(&path, "%s/.foorc"); > > > > as opposed to > > > > strlcat(path, homedir, sizeof(path)); > > strlcat(path, "/", sizeof(path)); > > strlcat(path, ".foord", sizeof(path)); > > len = strlen(path); > > > > Yes, they're a better str*cat/cpy, but they're not the solution that > > they claim to be. > > I don't think that anyone has intended them to be anything other than a > better replacement for strcpy/strcat than strncpy/strncat (which they > certainly are). Sure, you could go around telling people "use snprintf > instead" or "use asprintf instead", but is that the issue at hand? In context, yes it is. The paper talks about dealing with the construction of composite strings into static buffers, and points out that there's a real problem when you hit the edge of the buffer (overflow, truncation, etc.) But they don't address the core of the problem, which is the use of a static buffer in the first place. This and other habitual programming style items are what's at the real core of the "C is an insecure language" argument; people are so used to these idiomatic programming techniques they refuse to look for better solutions to the larger problem. Going back to the example they gave, let's put it in context. You probably have something like this: { struct passwd *pw; char buf[MAXPATHLEN]; FILE *fp; pw = getpwuid(getuid()); strlcpy(buf, pw->dir, sizeof(buf)); strlcat(buf, "/.appname/", sizeof(buf)); strlcat(buf, conffilename, sizeof(buf)); if (strlen(buf) >= sizeof(buf)) return(error); fp = fopen(buf, "r"); ... That works, as long as MAXPATHLEN is actually long enough. In this particular case it will be (because fopen will fail otherwise), but there's no guarantee that you're going to know in advance. OTOH, here it is with asprintf: { struct passwd *pw; char *buf; FILE *fp; pw = getpwuid(getuid()); if (asprintf(&buf, "%s/.appname/%s", pw->dir, conffilename) == -1) return(error); fp = fopen(buf, "r"); free(buf); ... The latter has a few really clear advantages: - you can see what the string is meant to look like. - it doesn't matter how long any of the components are. - the constructed value is on the heap, so you can return it (just imagine how much nicer ctime() would be if it did this). -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 17:10:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from m4.c2.telstra-mm.net.au (m4.c2.telstra-mm.net.au [24.192.3.19]) by hub.freebsd.org (Postfix) with ESMTP id 6ADC315653 for ; Thu, 15 Jul 1999 17:10:29 -0700 (PDT) (envelope-from a.reilly@lake.com.au) Received: from m5.c2.telstra-mm.net.au (m5.c2.telstra-mm.net.au [24.192.3.20]) by m4.c2.telstra-mm.net.au (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA14175 for ; Fri, 16 Jul 1999 10:08:07 +1000 (EST) X-BPC-Relay-Envelope-From: a.reilly@lake.com.au X-BPC-Relay-Envelope-To: X-BPC-Relay-Sender-Host: m5.c2.telstra-mm.net.au [24.192.3.20] X-BPC-Relay-Info: Message delivered directly. Received: from areilly.bpc-users.org (CPE-24-192-48-172.nsw.bigpond.net.au [24.192.48.172]) by m5.c2.telstra-mm.net.au (8.8.6 (PHNE_14041)/8.8.6) with SMTP id KAA18882 for ; Fri, 16 Jul 1999 10:08:06 +1000 (EST) Received: (qmail 93266 invoked by uid 1000); 16 Jul 1999 00:08:08 -0000 From: "Andrew Reilly" Date: Fri, 16 Jul 1999 10:08:08 +1000 To: "Daniel C. Sobral" Cc: lyndon@orthanc.ab.ca, freebsd-hackers@FreeBSD.ORG Subject: Re: Swap overcommit Message-ID: <19990716100808.A92294@gurney.reilly.home> References: <199907141938.NAA05484@orthanc.ab.ca> <378DF4C8.5E7B4C44@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <378DF4C8.5E7B4C44@newsguy.com>; from Daniel C. Sobral on Thu, Jul 15, 1999 at 11:48:41PM +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 15, 1999 at 11:48:41PM +0900, Daniel C. Sobral wrote: > Actually, applications are written assuming that malloc() will not > fail, generally speaking. Is this really the case? I'm pretty sure I've _never_ ignored the possibility of a NULL return from malloc, and I've been using it for nearly 20 years. I usually print a message and exit, but I never ignore it. I thought that was pretty standard practise. This is just a random comment, orthogonal to the overcommit issue, but I've seen both you and Matthew say this now, and I was surprised both times. -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 17:16:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id EFE4B156A5 for ; Thu, 15 Jul 1999 17:16:26 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id RAA07554; Thu, 15 Jul 1999 17:14:32 -0700 (PDT) Date: Thu, 15 Jul 1999 17:14:31 -0700 (PDT) From: Julian Elischer To: Mike Smith Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) In-Reply-To: <199907152358.QAA01894@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG but what about While ( more data items) { copy data items onto end of buffer if full{ write out buffer clear buffer, copy in rest of last item. } } I'd certainly not want to use xxprintf() for that On Thu, 15 Jul 1999, Mike Smith wrote: > > On Thu, 15 Jul 1999, Mike Smith wrote: > > > > > Ugh. Take the first example in the paper; it rewrites as > > > > > > len = asprintf(&path, "%s/.foorc"); > > > > > > as opposed to > > > > > > strlcat(path, homedir, sizeof(path)); > > > strlcat(path, "/", sizeof(path)); > > > strlcat(path, ".foord", sizeof(path)); > > > len = strlen(path); > > > > > > Yes, they're a better str*cat/cpy, but they're not the solution that > > > they claim to be. > > > > I don't think that anyone has intended them to be anything other than a > > better replacement for strcpy/strcat than strncpy/strncat (which they > > certainly are). Sure, you could go around telling people "use snprintf > > instead" or "use asprintf instead", but is that the issue at hand? > > In context, yes it is. > > The paper talks about dealing with the construction of composite > strings into static buffers, and points out that there's a real problem > when you hit the edge of the buffer (overflow, truncation, etc.) > > But they don't address the core of the problem, which is the use of a > static buffer in the first place. This and other habitual programming > style items are what's at the real core of the "C is an insecure > language" argument; people are so used to these idiomatic programming > techniques they refuse to look for better solutions to the larger > problem. > > Going back to the example they gave, let's put it in context. You > probably have something like this: > > > { > struct passwd *pw; > char buf[MAXPATHLEN]; > FILE *fp; > > pw = getpwuid(getuid()); > strlcpy(buf, pw->dir, sizeof(buf)); > strlcat(buf, "/.appname/", sizeof(buf)); > strlcat(buf, conffilename, sizeof(buf)); > if (strlen(buf) >= sizeof(buf)) > return(error); > fp = fopen(buf, "r"); > ... > > That works, as long as MAXPATHLEN is actually long enough. In this > particular case it will be (because fopen will fail otherwise), but > there's no guarantee that you're going to know in advance. > > OTOH, here it is with asprintf: > > { > struct passwd *pw; > char *buf; > FILE *fp; > > pw = getpwuid(getuid()); > if (asprintf(&buf, "%s/.appname/%s", pw->dir, conffilename) == -1) > return(error); > fp = fopen(buf, "r"); > free(buf); > ... > > The latter has a few really clear advantages: > > - you can see what the string is meant to look like. > - it doesn't matter how long any of the components are. > - the constructed value is on the heap, so you can return it (just > imagine how much nicer ctime() would be if it did this). > > -- > \\ The mind's the standard \\ Mike Smith > \\ of the man. \\ msmith@freebsd.org > \\ -- Joseph Merrick \\ msmith@cdrom.com > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 17:19: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id D1C89156BE for ; Thu, 15 Jul 1999 17:19:01 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id RAA01977; Thu, 15 Jul 1999 17:14:21 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907160014.RAA01977@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Julian Elischer Cc: Mike Smith , freebsd-hackers@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) In-reply-to: Your message of "Thu, 15 Jul 1999 17:14:31 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Jul 1999 17:14:21 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > but what about > > While ( more data items) > { > copy data items onto end of buffer > if full{ > write out buffer > clear buffer, copy in rest of last item. > } > } > > > I'd certainly not want to use xxprintf() for that This is what stdio does, funnily enough. See fwrite() etc. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 17:20:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 9018A14D13 for ; Thu, 15 Jul 1999 17:20:13 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id SAA29698; Thu, 15 Jul 1999 18:20:09 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id SAA01121; Thu, 15 Jul 1999 18:20:09 -0600 (MDT) Message-Id: <199907160020.SAA01121@harmony.village.org> To: Mike Smith Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Thu, 15 Jul 1999 16:58:52 PDT." <199907152358.QAA01894@dingo.cdrom.com> References: <199907152358.QAA01894@dingo.cdrom.com> Date: Thu, 15 Jul 1999 18:20:08 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199907152358.QAA01894@dingo.cdrom.com> Mike Smith writes: : if (strlen(buf) >= sizeof(buf)) : return(error); This can never be true with the strl functions.... They don't run off the end, so strlen(buf) is always going to be < sizeof(buf) since it doesn't include the traling null. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 17:25:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 6D6E015751 for ; Thu, 15 Jul 1999 17:25:52 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id SAA29708; Thu, 15 Jul 1999 18:24:26 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id SAA01153; Thu, 15 Jul 1999 18:24:25 -0600 (MDT) Message-Id: <199907160024.SAA01153@harmony.village.org> To: Mike Smith Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Cc: Tim Vanderhoek , Sheldon Hearn , Garance A Drosihn , Paul Hart , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Thu, 15 Jul 1999 15:44:51 PDT." <199907152244.PAA01458@dingo.cdrom.com> References: <199907152244.PAA01458@dingo.cdrom.com> Date: Thu, 15 Jul 1999 18:24:25 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199907152244.PAA01458@dingo.cdrom.com> Mike Smith writes: : What's really stupid is that most of the time you're trying to use : these functions to fix code that looks like: : strcpy(buf, str1); : strcat(buf, str2); : strcat(buf, str3); : without overflowing buf. This is dumb! Use asprintf instead: : : asprinf(&buf, "%s%s%s", str1, str2, str3); : : If you can't keep all of the string elements together at once, try: : : asprinf(&buf, "%s%s", str1, str2); : ... : asprintf(&buf2, "%s%s", buf, str3); : free(buf); : : No, it's not fast, but it _is_ robust. That is true for this case, but not always true. I think these APIs have an excellent role to play. Sure, there are other ways to do it, but there are a growing number of systems that have strl* on them (OpenBSD, Linux and Solaris), which is reason enough to improve our portability by using them. The asprintf isn't completely robust becuase you must free() the routine, or face a memory leak. It won't overflow, but it might introduce another bug. The whole point of these APIs was to transition old code to new in a safe manner that isn't prone to potentiall programming errors. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 17:26:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 84C691577B for ; Thu, 15 Jul 1999 17:26:37 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id SAA29721; Thu, 15 Jul 1999 18:26:36 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id SAA01181; Thu, 15 Jul 1999 18:26:36 -0600 (MDT) Message-Id: <199907160026.SAA01181@harmony.village.org> To: Mike Smith Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Cc: Paul Hart , Julian Elischer , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Thu, 15 Jul 1999 16:29:53 PDT." <199907152329.QAA01720@dingo.cdrom.com> References: <199907152329.QAA01720@dingo.cdrom.com> Date: Thu, 15 Jul 1999 18:26:36 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199907152329.QAA01720@dingo.cdrom.com> Mike Smith writes: : Ugh. Take the first example in the paper; it rewrites as : : len = asprintf(&path, "%s/.foorc"); : : as opposed to : : strlcat(path, homedir, sizeof(path)); : strlcat(path, "/", sizeof(path)); : strlcat(path, ".foord", sizeof(path)); : len = strlen(path); : : Yes, they're a better str*cat/cpy, but they're not the solution that : they claim to be. You've forgotten the free(path) sometime later in your code... That's a can of warms you conveniently ignore... And can be big problems for library routines whose API is defined to return stuff into a static buffer... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 17:29:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id A9E3315779 for ; Thu, 15 Jul 1999 17:29:19 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id RAA02029; Thu, 15 Jul 1999 17:23:15 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907160023.RAA02029@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Warner Losh Cc: Mike Smith , freebsd-hackers@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) In-reply-to: Your message of "Thu, 15 Jul 1999 18:20:08 MDT." <199907160020.SAA01121@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Jul 1999 17:23:15 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message <199907152358.QAA01894@dingo.cdrom.com> Mike Smith writes: > : if (strlen(buf) >= sizeof(buf)) > : return(error); > > This can never be true with the strl functions.... They don't run off > the end, so strlen(buf) is always going to be < sizeof(buf) since it > doesn't include the traling null. I actually should have copied the original example from the paper, which was disgustingly more verbose; I mistransposed it for the abovem which should probably have been (strlen(buf) == (sizeof(buf) - 1)) or similar. They recommend using: len = strlcpy(path, homedir, sizeof(path)); if (len >= sizeof(path)) return(ENAMETOOLONG) etc. I still think this is the wrong way to deal with the problem. 8) -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 17:29:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from darwin.ntu.edu.au (darwin.ntu.edu.au [138.80.128.3]) by hub.freebsd.org (Postfix) with ESMTP id 710F9157AB for ; Thu, 15 Jul 1999 17:29:37 -0700 (PDT) (envelope-from grog@lemis.com) Received: from mojave.lemis.com ([138.80.54.116]) by darwin.ntu.edu.au (8.8.8/8.8.8) with ESMTP id JAA21687; Fri, 16 Jul 1999 09:58:43 +0930 (CST) Received: (grog@localhost) by mojave.lemis.com (8.9.3/8.6.12) id XAA00606; Thu, 15 Jul 1999 23:38:37 +0930 (CST) Message-ID: <19990715233837.17211@mojave.lemis.com> Date: Thu, 15 Jul 1999 23:38:37 +0930 From: Greg Lehey To: Mike Smith , Marc Tardif Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: gdb instead of adb References: <199907150545.WAA00453@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <199907150545.WAA00453@dingo.cdrom.com>; from Mike Smith on Wed, Jul 14, 1999 at 10:45:32PM -0700 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, 14 July 1999 at 22:45:32 -0700, Mike Smith wrote: >> Is the reason why adb hasn't been ported to freebsd because the source is >> proprietary? > > You make no sense. What don't you understand? It makes plenty of sense to me (and the answer is: yes). >> If gdb should suffice for my debugging needs, how can a breakpoint be set >> at a particular interrupt, or even at any interrupt? The break command >> only seems to accept functions, offsets, linenumbers and addresses... >> I'm all out of ideas and the gdb info file isn't helping. > > You make little more sense, unless you are talking about using > gdb-remote on a running kernel, in which case you should know that > interrupts are vectored through functions, and thus the entire issue is > moot. Translation: to set a breakpoint on an "interrupt", set the breakpoint on its interrupt handler. > Note also that debugging through interrupt handlers can be > problematic on PC hardware. On all hardware. But if Marc has used adb to set breakpoints on interrupt handlers, he'll know that. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 17:30:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 47B0315779 for ; Thu, 15 Jul 1999 17:30:48 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id SAA29737; Thu, 15 Jul 1999 18:28:52 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id SAA01218; Thu, 15 Jul 1999 18:28:52 -0600 (MDT) Message-Id: <199907160028.SAA01218@harmony.village.org> To: Tim Vanderhoek Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Cc: Sheldon Hearn , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Thu, 15 Jul 1999 19:42:03 EDT." <19990715194203.A54146@mad> References: <19990715194203.A54146@mad> <19990715183442.A53661@mad> <80092.932079193@axl.noc.iafrica.com> Date: Thu, 15 Jul 1999 18:28:52 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19990715194203.A54146@mad> Tim Vanderhoek writes: : Looking at OpenBSD's actual definition of strlcat() which returns the : number of chars that would have been in the final string is : potentially non-useful, but not really toooooo terrible. No. It is useful. If you look at the return value, you can detect that an overflow would have happened and bail w/o having the overflow actually happen. That is useful (and even documented in the man page by a nice example). : > given the opportunity to submit a replacement manpage, since theirs : > sucks. : : Bah. You're in avail now. Just commit ontop of whatever manpage gets : imported. ;-) If your replacement is good, no one will object. :) I'm planning on committing their man page. I don't see problems with it, purhaps people could point them out to me so that both our man pages and theirs could be better. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 17:32:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 87E8015788 for ; Thu, 15 Jul 1999 17:32:28 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id SAA29759; Thu, 15 Jul 1999 18:32:22 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id SAA01282; Thu, 15 Jul 1999 18:32:22 -0600 (MDT) Message-Id: <199907160032.SAA01282@harmony.village.org> To: Mike Smith Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Thu, 15 Jul 1999 17:23:15 PDT." <199907160023.RAA02029@dingo.cdrom.com> References: <199907160023.RAA02029@dingo.cdrom.com> Date: Thu, 15 Jul 1999 18:32:22 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199907160023.RAA02029@dingo.cdrom.com> Mike Smith writes: : I still think this is the wrong way to deal with the problem. 8) We mildly disagree here. The strl* functions are the end all, be all of security. They are just designed to make the existing code that uses static buffers easy to make more robust w/o radically altering that code. Of course, strings have always been weak in 'C'. You make them static and they overflow. You malloc them, and often people forget to free them later leading to other problems... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 17:35: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 8C2FF15779 for ; Thu, 15 Jul 1999 17:34:42 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id SAA29770; Thu, 15 Jul 1999 18:34:20 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id SAA01333; Thu, 15 Jul 1999 18:34:19 -0600 (MDT) Message-Id: <199907160034.SAA01333@harmony.village.org> Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) To: Mike Smith , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Thu, 15 Jul 1999 18:32:22 MDT." <199907160032.SAA01282@harmony.village.org> References: <199907160032.SAA01282@harmony.village.org> <199907160023.RAA02029@dingo.cdrom.com> Date: Thu, 15 Jul 1999 18:34:19 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199907160032.SAA01282@harmony.village.org> Warner Losh writes: : We mildly disagree here. The strl* functions are the end all, be all : of security. NOTE: This should have read: We mildly disagree here. The strl* functions are NOT the end all, be all of security. which changes its meaning quite a bit... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 17:37:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id E794914CB7 for ; Thu, 15 Jul 1999 17:37:12 -0700 (PDT) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.02 #1) id 114vyv-000LGr-00; Fri, 16 Jul 1999 02:36:05 +0200 From: Sheldon Hearn To: Warner Losh Cc: Tim Vanderhoek , freebsd-hackers@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) In-reply-to: Your message of "Thu, 15 Jul 1999 18:28:52 CST." <199907160028.SAA01218@harmony.village.org> Date: Fri, 16 Jul 1999 02:36:05 +0200 Message-ID: <81768.932085365@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Jul 1999 18:28:52 CST, Warner Losh wrote: > I'm planning on committing their man page. I don't see problems with > it, purhaps people could point them out to me so that both our man > pages and theirs could be better. As I've said already, there's too much in DESCRIPTION that should be in HISTORY or IMPLEMENTATION NOTES. I almost get the feeling that the manpage doubles as a marketing brochure. The reason I see this as a problem is that there is a great deal of consistency in the string(3) family manpages. This consistency makes it very easy to move from one manpage to the next and spot differences. The strlcpy manpage breaks this style badly. While that's fine when you read it on its own, it's a PITA when you're missioning around the strings(3) manpages. If you see my point, let me know and I'll send you an alternative strlcpy.3 . Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 17:37:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id D5A2915658 for ; Thu, 15 Jul 1999 17:37:30 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id RAA02110; Thu, 15 Jul 1999 17:32:18 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907160032.RAA02110@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Warner Losh Cc: Mike Smith , freebsd-hackers@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) In-reply-to: Your message of "Thu, 15 Jul 1999 18:32:22 MDT." <199907160032.SAA01282@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Jul 1999 17:32:18 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message <199907160023.RAA02029@dingo.cdrom.com> Mike Smith writes: > : I still think this is the wrong way to deal with the problem. 8) > > We mildly disagree here. The strl* functions are the end all, be all > of security. They are just designed to make the existing code that > uses static buffers easy to make more robust w/o radically altering > that code. > > Of course, strings have always been weak in 'C'. You make them static > and they overflow. You malloc them, and often people forget to free > them later leading to other problems... With the addition of a "not" in your first paragraph, I actually think we're in agreement here. I'm just maintaining that in most of the in-tree cases where static buffers are used, a dynamic buffer would have been a better design choice; you might want to disagree there too of course. 8) Regardless, we should definitely adopt these functions for no other reason than portability, no argument there. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msmith@freebsd.org \\ -- Joseph Merrick \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 17:43:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id B969614FA5 for ; Thu, 15 Jul 1999 17:43:11 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id SAA29806; Thu, 15 Jul 1999 18:40:17 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id SAA01415; Thu, 15 Jul 1999 18:40:17 -0600 (MDT) Message-Id: <199907160040.SAA01415@harmony.village.org> To: Sheldon Hearn Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Cc: Tim Vanderhoek , freebsd-hackers@FreeBSD.ORG In-reply-to: Your message of "Fri, 16 Jul 1999 02:36:05 +0200." <81768.932085365@axl.noc.iafrica.com> References: <81768.932085365@axl.noc.iafrica.com> Date: Thu, 15 Jul 1999 18:40:17 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <81768.932085365@axl.noc.iafrica.com> Sheldon Hearn writes: : If you see my point, let me know and I'll send you an alternative : strlcpy.3 . I can see your point. I don't know if I'll like your man pages better or not, but I'd be willing to give them a spin. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 17:43:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from m2-33-dbn.dial-up.net (m2-33-dbn.dial-up.net [196.34.155.97]) by hub.freebsd.org (Postfix) with ESMTP id E6C0B1565F for ; Thu, 15 Jul 1999 17:43:36 -0700 (PDT) (envelope-from rnordier@nordier.com) Received: (from rnordier@localhost) by m2-33-dbn.dial-up.net (8.8.7/8.6.12) id CAA01807; Fri, 16 Jul 1999 02:41:14 +0200 (SAST) From: Robert Nordier Message-Id: <199907160041.CAA01807@m2-33-dbn.dial-up.net> Subject: Re: make fails in 3.2-RELEASE for netboot In-Reply-To: from "Gregory A. Carter" at "Jul 15, 1999 04:53:22 pm" To: omni@dynmc.net (Gregory A. Carter) Date: Fri, 16 Jul 1999 02:41:12 +0200 (SAST) Cc: roberto@keltia.freenix.fr (Ollivier Robert), hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I found it when I went searching however I still can't get the netboot to > compile as it was designed for aout. Any ideas of why it wasn't moved to > elf along with the rest of the OS? Or if not how *I* can port it to elf > instead? The intention is that loader(8) will provide the same functionality, and the framework is already in place for this. I suggest you use etherboot in the ports collection, at least until the loader support is completed. -- Robert Nordier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 17:46:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 7F02814F92 for ; Thu, 15 Jul 1999 17:46:23 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id JAA14217; Fri, 16 Jul 1999 09:45:47 +0900 (JST) Message-ID: <378E7FD7.3D607199@newsguy.com> Date: Fri, 16 Jul 1999 09:41:59 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Andrew Reilly Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Swap overcommit References: <199907141938.NAA05484@orthanc.ab.ca> <378DF4C8.5E7B4C44@newsguy.com> <19990716100808.A92294@gurney.reilly.home> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Andrew Reilly wrote: > > On Thu, Jul 15, 1999 at 11:48:41PM +0900, Daniel C. Sobral wrote: > > Actually, applications are written assuming that malloc() will not > > fail, generally speaking. > > Is this really the case? I'm pretty sure I've _never_ ignored the > possibility of a NULL return from malloc, and I've been using it > for nearly 20 years. I usually print a message and exit, but I > never ignore it. I thought that was pretty standard practise. You are always free to inspect how applications deal with malloc(), as far as open source software goes. Anyway, your "usual" behavior is to expect malloc() will not fail. To print a message and exit is to treat it as a fatal error, don't you agree? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 17:49:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id EC39A15557 for ; Thu, 15 Jul 1999 17:49:54 -0700 (PDT) (envelope-from jgreco@aurora.sol.net) Received: (from jgreco@localhost) by aurora.sol.net (8.9.2/8.9.2/SNNS-1.02) id TAA21505; Thu, 15 Jul 1999 19:48:23 -0500 (CDT) From: Joe Greco Message-Id: <199907160048.TAA21505@aurora.sol.net> Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) In-Reply-To: <199907160014.RAA01977_dingo.cdrom.com@ns.sol.net> from Mike Smith at "Jul 16, 1999 0:22:40 am" To: mike@smith.net.au (Mike Smith) Date: Thu, 15 Jul 1999 19:48:23 -0500 (CDT) Cc: julian@whistle.com, hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > but what about > > > > While ( more data items) > > { > > copy data items onto end of buffer > > if full{ > > write out buffer > > clear buffer, copy in rest of last item. > > } > > } > > > > > > I'd certainly not want to use xxprintf() for that > > This is what stdio does, funnily enough. See fwrite() etc. I do like the idea of these functions... just ran into a problem a day or two ago which would be completely awful to do with *printf, since it involved assembling a line of text through two functions and a for() loop... I thought briefly about trying to do it with strncat but I gagged a bit at the obtuse way it would have needed to have been done. ... Joe ------------------------------------------------------------------------------- Joe Greco - Systems Administrator jgreco@ns.sol.net Solaria Public Access UNIX - Milwaukee, WI 414/342-4847 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 17:50:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from splode.eterna.com.au (splode.eterna.com.au [203.15.111.1]) by hub.freebsd.org (Postfix) with ESMTP id 9D65B14F92 for ; Thu, 15 Jul 1999 17:50:04 -0700 (PDT) (envelope-from mrg@eterna.com.au) Received: from splode.eterna.com.au (localhost [127.0.0.1]) by splode.eterna.com.au (Postfix) with ESMTP id 6B7CE3CA7; Fri, 16 Jul 1999 10:49:06 +1000 (EST) To: Sheldon Hearn Cc: freebsd-hackers@FreeBSD.ORG, tech-kern@netbsd.org subject: re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) in-reply-to: your message of "Fri, 16 Jul 1999 01:56:49 +0200." <80862.932083009@axl.noc.iafrica.com> organisation: people's front against (bozotic) www (softwar foundation) x-other-organisation: The NetBSD Foundation. Date: Fri, 16 Jul 1999 10:49:05 +1000 Message-ID: <19866.932086145@splode.eterna.com.au> From: matthew green Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > All I want for Christmas is a knob to disable overcommit. And what I'm pretty sure the majority of the readers on this list want is for those of you who really think it's necessary to do it yourselves. What? Nobody who wants to disable the policy knows how to do it? Hmmm, I wonder whether that's significant... that's an impressively bold statement to make. by my reconning, at least 4 people who have posted "wanting no overcommit" are more than capable of programming this for NetBSD. .mrg. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 17:58: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 9163F14D13 for ; Thu, 15 Jul 1999 17:58:05 -0700 (PDT) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.3/8.9.1) with ESMTP id UAA70943; Thu, 15 Jul 1999 20:55:16 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <199907160055.UAA70943@whizzo.transsys.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Jennifer Clark Cc: freebsd-hackers@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: Advice on deriving accurate time values from the kernel? References: <378E10C4.9AD7979E@vulture.dmem.strath.ac.uk> In-reply-to: Your message of "Thu, 15 Jul 1999 17:48:04 BST." <378E10C4.9AD7979E@vulture.dmem.strath.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Jul 1999 20:55:16 -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've done some work on measuring things like interrupt response times and the interval between two interesting events or steps in processing. A cheap way to do this is to use the TSC register in the CPU, though you then need to calibrate the frequency that the CPU really runs at. If you're willing to spend some money, you can get hardware to plug into a PCI slot that can return timestamps in 100ns units, as well as generating interrupt at some time in the future, etc. See http://www.bancomm.com/cbc637PCI.htm for one example of such hardware. I have a device driver for FreeBSD for this board which even allows user processes to get precise timing by mmap()'ing the device registers into user space for easy access. The driver will be contributed to the FreeBSD project "soon." I was pretty close to doing so just prior to the newbus conversion and now need to update the driver for a more recent -current. louie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 18: 5:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gizmo.internode.com.au (gizmo.internode.com.au [192.83.231.115]) by hub.freebsd.org (Postfix) with ESMTP id AECE814F92 for ; Thu, 15 Jul 1999 18:05:40 -0700 (PDT) (envelope-from newton@gizmo.internode.com.au) Received: (from newton@localhost) by gizmo.internode.com.au (8.9.3/8.9.3) id KAA07821; Fri, 16 Jul 1999 10:35:24 +0930 (CST) (envelope-from newton) From: Mark Newton Message-Id: <199907160105.KAA07821@gizmo.internode.com.au> Subject: Re: matcd on an SB16 To: mike@smith.net.au (Mike Smith) Date: Fri, 16 Jul 1999 10:35:24 +0930 (CST) Cc: newton@internode.com.au, hackers@freebsd.org In-Reply-To: <199907150750.AAA01206@dingo.cdrom.com> from "Mike Smith" at Jul 15, 99 00:50:31 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-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith wrote: > > Is the matcd driver known to work on FreeBSD 3.2 ? If not, does anyone > > have any estimate of the amount of effort that'd be required to fix it? > > It "works" for some definitions of "work". Firstly, there are three > different CDROM interfaces that can be hung off an SB16; one is the > Matsushita drive, there's also a Mutsumi interface (I don't think we > support it) and a Sony interface (also, I believe, unsupported). Ghods, you're going through some old mail! [ and how was DEFCON, btw? :-) ] FWIW, the guy I was talking about embarked on a network install from another machine with a CD-ROM drive and an NFS server; the network install failed for slightly related reasons, having to do with the idea the hardware in this box is generally crap. The disappointing thing is that Linux works on it, though :-/ - mark ---- Mark Newton Email: newton@internode.com.au (W) Network Engineer Email: newton@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 19: 7:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from fusion.qse.tohoku.ac.jp (saturn.qse.tohoku.ac.jp [130.34.70.56]) by hub.freebsd.org (Postfix) with ESMTP id AA93715648 for ; Thu, 15 Jul 1999 19:07:12 -0700 (PDT) (envelope-from kueda@jupiter.qse.tohoku.ac.jp) Received: from localhost (localhost [127.0.0.1]) by fusion.qse.tohoku.ac.jp (8.9.3/8.9.3) with ESMTP id WAA03167; Sun, 11 Jul 1999 22:26:40 +0900 (JST) (envelope-from kueda@jupiter.qse.tohoku.ac.jp) To: joe@pavilion.net, niall@pobox.com Cc: hackers@FreeBSD.ORG Subject: re: HELP!! Slice info disappeared From: Kazukiyo UEDA In-Reply-To: Your message of "Fri, 9 Jul 1999 10:01:16 +0100" <19990709100116.G50525@pavilion.net> References: <19990709100116.G50525@pavilion.net> X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) X-fingerprint: 8F 5E EB B1 89 A9 83 A0 CF 6B 62 13 DE 02 F5 DA X-URL: http://jupiter.qse.tohoku.ac.jp/security/pgp/kueda.pgp Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990711222640R.kueda@jupiter.qse.tohoku.ac.jp> Date: Sun, 11 Jul 1999 22:26:40 +0900 X-Dispatcher: imput version 980905(IM100) Lines: 44 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello Niall and Josef, Thanks for your great help. Finally I get all data on the disk back after the struggle on the weekend :) I run the program you sent me, but I got nothing from it. I guess the reason as follows: (1) The program fetches each chunks of 16 blocks from the disk and check if they are superblocks. (2) My disk is sliced into 3 parts. The fist one is for MS-DOS (FAT format), and the rest of them are FFS. It's highly possible that the offset block of the beginning of FFS slice is not a multiple of 16. (3) So I did: # for i in 0 1 2 3 ... 15; do # ./findsb /dev/wd2 $[ (estimated end of block for FAT slice)*512 + $i*512 ] # done After I got the info from the superblocks, getting back data was easy. Again, thanks much for your great help. You saved a lot of my time to reconstruct the data from scratch. Sincerely yours, -- Kazukiyo Ueda From: Josef Karthauser Subject: re: HELP!! Slice info disappeared Date: Fri, 9 Jul 1999 10:01:16 +0100 > Hi Kazukiyo, > > This is certainly possible. I've enclosed a hack from Niall Smart that should > generated enough information to for you to reconstruct it. I'm working on a > general solution to this for inclusion FreeBSD as shipped, but it's at home > and I'm at work, that said it's Niall's basic code saved my harddisk a few weeks > ago :) > > Joe > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 19:14:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail-01.cdsnet.net (mail-01.cdsnet.net [206.107.16.35]) by hub.freebsd.org (Postfix) with SMTP id 304B914BD2 for ; Thu, 15 Jul 1999 19:14:32 -0700 (PDT) (envelope-from mrcpu@internetcds.com) Received: (qmail 27783 invoked from network); 16 Jul 1999 02:14:29 -0000 Received: from schizo.cdsnet.net (204.118.244.32) by mail.cdsnet.net with SMTP; 16 Jul 1999 02:14:29 -0000 Date: Thu, 15 Jul 1999 19:14:03 -0700 (PDT) From: Jaye Mathisen X-Sender: mrcpu@schizo.cdsnet.net To: hackers@freebsd.org Subject: VMWare plug/quickie tests. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've been running VM Ware under NT for a few days now, booting FreeBSD and other OS's. In some quick testing: The host machine is NT 4.0, SP5, 384MB RAM, dual 450 PII's. The guest OS is FreeBSD 3.2-RELEASE, configured with the VMWARE 512MB disk, and 32MB RAM allocated Compiling a generic kernel from scratch came out: 156.7u 64.3s 5:04.63 72.5%, ...149pf On a PII 300 with IDE disks, 128MB RAM, it was: (3.2-stable) 205.7u 17.9s 6:56.37 53.7%, ...32pf+0w All in all, not too shabby. So far it hasn't crashed, although I am not running X in the guest session yet, just using it in console mode. It has some weird pauses and stuff when it boots up, and the boot loader spinner creeps along, but once it's up and running, it's fine. I can see the utility of this pretty easily. Just wish it wasn't 400 bucks. I'm going to do some testing between VM's and such, and see how it goes. Next stop, 4.0-current. It doesn't consume any CPU cycles that I can see while idle, and running it at the standard priorities isn't affecting my NT stuff at all... I could grow to like it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 19:16:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by hub.freebsd.org (Postfix) with ESMTP id 94F4614BD2 for ; Thu, 15 Jul 1999 19:16:55 -0700 (PDT) (envelope-from alk@saphire.East.Sun.COM) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA12990 for ; Thu, 15 Jul 1999 19:16:30 -0700 (PDT) Received: from saphire.East.Sun.COM (saphire.East.Sun.COM [129.148.180.27]) by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA29620 for ; Thu, 15 Jul 1999 22:16:29 -0400 (EDT) Received: (from alk@localhost) by saphire.East.Sun.COM (8.8.8+Sun/8.8.8) id WAA22434; Thu, 15 Jul 1999 22:16:29 -0400 (EDT) From: Anthony Kimball - High Performance Computing MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 15 Jul 1999 22:16:29 -0400 (EDT) X-Face: \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO 5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed Reply-To: alk@pobox.com To: hackers@freebsd.org Subject: predictability in an unpredictable world X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14222.38020.69854.294391@saphire> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG If there were a mechanism whereby one could opt out of the SIGKILL, most if not all of the complaints would go away. SIGDANGER would suffice, but even a rude hack would do in a pinch, such as the one included below (untested). If you mmap real disk instead of sbrk'ing, and use this procfs control then the overcommit world won't interfere with your process (but take care of thrashing stack/text of course). No more need to fight the holy war! 3.2-STABLE: === diff -u vm/vm_pageout.c ../../src3.2/sys/vm/vm_pageout.c --- vm/vm_pageout.c Thu Jul 15 20:40:56 1999 +++ ../../src3.2/sys/vm/vm_pageout.c Thu Mar 18 17:28:39 1999 @@ -1144,7 +1144,7 @@ /* * if this is a system process, skip it */ - if ((p->p_flag & (P_PRECIOUS|P_SYSTEM|P_NOSWAP)) || (p->p_pid == 1) || + if ((p->p_flag & (P_SYSTEM|P_NOSWAP)) || (p->p_pid == 1) || ((p->p_pid < 48) && (vm_swap_size != 0))) { continue; } === diff -u sys/proc.h ../../src3.2/sys/sys/proc.h --- sys/proc.h Thu Jul 15 20:41:50 1999 +++ ../../src3.2/sys/sys/proc.h Fri May 14 01:32:41 1999 @@ -268,8 +268,6 @@ #define P_NOCLDWAIT 0x400000 /* No zombies if child dies */ -#define P_PRECIOUS 0x800000 /* Please, please let me live */ - /* * MOVE TO ucred.h? === diff -u miscfs/procfs/procfs_ctl.c ../../src3.2/sys/miscfs/procfs/procfs_ctl.c --- miscfs/procfs/procfs_ctl.c Thu Jul 15 20:40:59 1999 +++ ../../src3.2/sys/miscfs/procfs/procfs_ctl.c Sat Aug 2 09:32:10 1997 @@ -69,8 +69,6 @@ #define PROCFS_CTL_STEP 3 #define PROCFS_CTL_RUN 4 #define PROCFS_CTL_WAIT 5 -#define PROCFS_CTL_PRECIOUS 6 -#define PROCFS_CTL_NOPRECIOUS 7 static vfs_namemap_t ctlnames[] = { /* special /proc commands */ @@ -79,8 +77,6 @@ { "step", PROCFS_CTL_STEP }, { "run", PROCFS_CTL_RUN }, { "wait", PROCFS_CTL_WAIT }, - { "precious", PROCFS_CTL_PRECIOUS }, - { "noprecious", PROCFS_CTL_NOPRECIOUS }, { 0 }, }; @@ -255,14 +251,6 @@ } } return (error); - - case PROCFS_CTL_PRECIOUS: - p->p_flag |= P_PRECIOUS; - return 0; - - case PROCFS_CTL_NOPRECIOUS: - p->p_flag &= ~P_PRECIOUS; - return 0; default: panic("procfs_control"); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 19:32:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from orthanc.ab.ca (orthanc.ab.ca [207.167.3.130]) by hub.freebsd.org (Postfix) with ESMTP id 2D75E14BD2 for ; Thu, 15 Jul 1999 19:32:09 -0700 (PDT) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (localhost.orthanc.ab.ca [127.0.0.1] (may be forged)) by orthanc.ab.ca (8.9.3/8.9.3) with ESMTP id UAA47694; Thu, 15 Jul 1999 20:30:58 -0600 (MDT) (envelope-from lyndon@orthanc.ab.ca) Message-Id: <199907160230.UAA47694@orthanc.ab.ca> To: Sheldon Hearn Cc: Matthew Dillon , sthaug@nethelp.no, rock@dead-end.net, freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) In-reply-to: Your message of "Fri, 16 Jul 1999 01:56:49 +0200." <80862.932083009@axl.noc.iafrica.com> Date: Thu, 15 Jul 1999 20:30:57 -0600 From: lyndon@orthanc.ab.ca Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > And what I'm pretty sure the majority of the readers on this list want > is for those of you who really think it's necessary to do it yourselves. > > What? Nobody who wants to disable the policy knows how to do it? Hmmm, I > wonder whether that's significant... Sheldon, if you can't contribute something useful, then shut up. If I have to do it myself, I will. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 20: 2:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id C433614D6E for ; Thu, 15 Jul 1999 20:02:20 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA14677; Thu, 15 Jul 1999 20:00:36 -0700 (PDT) (envelope-from dillon) Date: Thu, 15 Jul 1999 20:00:36 -0700 (PDT) From: Matthew Dillon Message-Id: <199907160300.UAA14677@apollo.backplane.com> To: "Andrew Reilly" Cc: "Daniel C. Sobral" , lyndon@orthanc.ab.ca, freebsd-hackers@FreeBSD.ORG Subject: Re: Swap overcommit References: <199907141938.NAA05484@orthanc.ab.ca> <378DF4C8.5E7B4C44@newsguy.com> <19990716100808.A92294@gurney.reilly.home> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> fail, generally speaking. : :Is this really the case? I'm pretty sure I've _never_ ignored the :possibility of a NULL return from malloc, and I've been using it :for nearly 20 years. I usually print a message and exit, but I :never ignore it. I thought that was pretty standard practise. : :This is just a random comment, orthogonal to the overcommit issue, :but I've seen both you and Matthew say this now, and I was surprised :both times. : :-- :Andrew The are dozens of libc routines which call malloc internally and return allocated storage. strdup(), opendir(), fopen(), setvbuf(), asprintf(), and so forth. Dozens. And while we might check some of these for NULL, we don't check them all, and the ones we do check we tend to conclude a failure other then a memory failure. We would assume that the directory or file does not exist, for example. How many programmers check errno after such a failure? Very few. How many programmers bother to even *clear* errno before making these calls (since some system calls do not set errno if it already non-zero). Virtually nobody. Having malloc() return NULL due to some *unrelated* process running the system out of swap is unnacceptable as it would result in serious instability to a great many programs that were never designed to deal with the case. Rather then crying about the system killing your favorite process, you would be crying about half a dozen processes that are still running no longer being stable. As a sysop, I would reboot a system in such a state instantly. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 20: 8:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 3452414C03 for ; Thu, 15 Jul 1999 20:08:44 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA14782; Thu, 15 Jul 1999 20:08:15 -0700 (PDT) (envelope-from dillon) Date: Thu, 15 Jul 1999 20:08:15 -0700 (PDT) From: Matthew Dillon Message-Id: <199907160308.UAA14782@apollo.backplane.com> To: lyndon@orthanc.ab.ca Cc: sthaug@nethelp.no, rock@dead-end.net, freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907152353.RAA35007@orthanc.ab.ca> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> In that scenario, the 512MB of swap I assigned to this machine would be :> dangerously low. : :With 13GB disks available for a couple of hundred bucks, my machines aren't :going to run out of swap space any time soon, even if I commit to disk. : :All I want for Christmas is a knob to disable overcommit. : :--lyndon If your machines aren't going to run out of swap, then the overcommit isn't going to hurt you in a million years. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 20:21: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from chai.torrentnet.com (chai.torrentnet.com [198.78.51.73]) by hub.freebsd.org (Postfix) with ESMTP id B945014E64 for ; Thu, 15 Jul 1999 20:20:57 -0700 (PDT) (envelope-from bakul@torrentnet.com) Received: from chai.torrentnet.com (localhost [127.0.0.1]) by chai.torrentnet.com (8.8.8/8.8.5) with ESMTP id XAA03039 for ; Thu, 15 Jul 1999 23:20:04 -0400 (EDT) Message-Id: <199907160320.XAA03039@chai.torrentnet.com> To: freebsd-hackers@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Date: Thu, 15 Jul 1999 23:20:04 -0400 From: Bakul Shah Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Any use of str{,n}cat makes me gag. In the past I have used a composable function that may be of interest. Composable in the sense that the result can be immediately used as an arg to another call and it doesn't have the O(N^2) behavior of strcat. Such a function can be totally safe. Something like: char* r; r = scpy(char* dst, char* const dst_end, const char* src) where the following post-conditions hold: dst_end >= dst r == MIN(dst + strlen(src)), dst_end) r[0] == '\0' That is, the returned ptr points in `dst' _just_ past the copied data. Note that `dst_end' points to the _last_ char of `dst'. Example: char* string[N]; ... char str[STRSIZE]; char* const strend = str + sizeof str - 1; char* t = str; for (int i = 0; i < N && t < strend; i++) t = scpy(t, strend, string[i]); or scpy(scpy(str, strend, "this"), strend, " and that")); Here is the implementation: char* scpy(char* d, char* const e, const char* s) { while (*s && d < e) *d++ = *s++; *d = '\0'; return d; } This is far too simple to merit a paper or a long name :-) And I am sure a zillion others have come up with the same idea. -- bakul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 20:47:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 5865714FE8 for ; Thu, 15 Jul 1999 20:47:45 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id XAA49176; Thu, 15 Jul 1999 23:45:29 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Thu, 15 Jul 1999 23:45:29 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Matthew Dillon Cc: Andrew Reilly , "Daniel C. Sobral" , lyndon@orthanc.ab.ca, freebsd-hackers@FreeBSD.org Subject: Re: Swap overcommit In-Reply-To: <199907160300.UAA14677@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Jul 1999, Matthew Dillon wrote: > > The are dozens of libc routines which call malloc internally and return > allocated storage. strdup(), opendir(), fopen(), setvbuf(), asprintf(), > and so forth. Dozens. And while we might check some of these for NULL, > we don't check them all, and the ones we do check we tend to conclude > a failure other then a memory failure. We would assume that the directory > or file does not exist, for example. How many programmers check errno > after such a failure? Very few. How many programmers bother to even > *clear* errno before making these calls (since some system calls do not ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ We're not supposed to have to clear errno unless we have to explicitly test if it has changed. We're not supposed to clear it before any system call which could possibly fail and set errno. > set errno if it already non-zero). Virtually nobody. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Erm... WTF?!?! If so, why the HELL are we doing that?!? > > -Matt > Matthew Dillon > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 21:32:14 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id BCAC514E7B for ; Thu, 15 Jul 1999 21:32:08 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id NAA20068; Fri, 16 Jul 1999 13:31:56 +0900 (JST) Message-ID: <378EB49D.331D46DA@newsguy.com> Date: Fri, 16 Jul 1999 13:27:09 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Cc: tech-kern@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <19866.932086145@splode.eterna.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Technical follow-up: Contrary to what I previously said, a number of tests reveal that Solaris, indeed, does not overcommit. All non-read only segments, and all malloc()ed memory is reserved upon exec() or fork(), and the reserved memory is not allowed to exceed the total memory. It makes extensive use of read only DATA segments, and has a NON_RESERVE mmap() flag. Though the foot firmly planted in my mouth ought to prevent me from saying anything else, I must say that it does explain a few things to me... -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 21:52:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 7E02214F6A; Thu, 15 Jul 1999 21:52:56 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA15530; Thu, 15 Jul 1999 21:52:56 -0700 (PDT) (envelope-from dillon) Date: Thu, 15 Jul 1999 21:52:56 -0700 (PDT) From: Matthew Dillon Message-Id: <199907160452.VAA15530@apollo.backplane.com> To: "Brian F. Feldman" Cc: Andrew Reilly , "Daniel C. Sobral" , lyndon@orthanc.ab.ca, freebsd-hackers@FreeBSD.ORG Subject: Re: Swap overcommit References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> The are dozens of libc routines which call malloc internally and return :> allocated storage. strdup(), opendir(), fopen(), setvbuf(), asprintf(), :> and so forth. Dozens. And while we might check some of these for NULL, :> we don't check them all, and the ones we do check we tend to conclude :> a failure other then a memory failure. We would assume that the directory :> or file does not exist, for example. How many programmers check errno :> after such a failure? Very few. How many programmers bother to even :> *clear* errno before making these calls (since some system calls do not : ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ :We're not supposed to have to clear errno unless we have to explicitly :test if it has changed. We're not supposed to clear it before any system :call which could possibly fail and set errno. : :> set errno if it already non-zero). Virtually nobody. : ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ :Erm... WTF?!?! If so, why the HELL are we doing that?!? No, wait, I got that wrong I think. Oh yah, I remember now. Hmm. How odd. I came across a case where read() could return -1 and not set errno properly if errno was already set, but a perusal of the kernel code seems to indicate that this can't happen. Very weird. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 21:57:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id CC1C0155AD for ; Thu, 15 Jul 1999 21:57:51 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA15580; Thu, 15 Jul 1999 21:57:31 -0700 (PDT) (envelope-from dillon) Date: Thu, 15 Jul 1999 21:57:31 -0700 (PDT) From: Matthew Dillon Message-Id: <199907160457.VAA15580@apollo.backplane.com> To: "Daniel C. Sobral" Cc: freebsd-hackers@FreeBSD.ORG, tech-kern@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <19866.932086145@splode.eterna.com.au> <378EB49D.331D46DA@newsguy.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Technical follow-up: : :Contrary to what I previously said, a number of tests reveal that :Solaris, indeed, does not overcommit. All non-read only segments, :and all malloc()ed memory is reserved upon exec() or fork(), and the :reserved memory is not allowed to exceed the total memory. It makes :extensive use of read only DATA segments, and has a NON_RESERVE :mmap() flag. : :Though the foot firmly planted in my mouth ought to prevent me from :saying anything else, I must say that it does explain a few things :to me... : :-- :Daniel C. Sobral (8-DCS) :dcs@newsguy.com Something is weird here. If the solaris people are using a SWAPSIZE + REALMEM VM model, they have to allow the allocated + reserved space go +REALMEM bytes over available swap space. If not they are using only a SWAPSIZE VM model. Wait - does Solaris normally use swap files or swap partitions? Or is it that weird /tmp filesystem stuff? If it normally uses swap files and allows holes then that explains everything. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 22: 3:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from celery.dragondata.com (celery.dragondata.com [205.253.12.6]) by hub.freebsd.org (Postfix) with ESMTP id 8B0A815691; Thu, 15 Jul 1999 22:03:28 -0700 (PDT) (envelope-from toasty@celery.dragondata.com) Received: (from toasty@localhost) by celery.dragondata.com (8.9.3/8.9.3) id AAA28122; Fri, 16 Jul 1999 00:02:55 -0500 (CDT) (envelope-from toasty) From: Kevin Day Message-Id: <199907160502.AAA28122@celery.dragondata.com> Subject: Re: Swap overcommit In-Reply-To: <199907160452.VAA15530@apollo.backplane.com> from Matthew Dillon at "Jul 15, 1999 09:52:56 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Fri, 16 Jul 1999 00:02:55 -0500 (CDT) Cc: green@FreeBSD.ORG (Brian F. Feldman), a.reilly@lake.com.au (Andrew Reilly), dcs@newsguy.com (Daniel C. Sobral), lyndon@orthanc.ab.ca, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :> The are dozens of libc routines which call malloc internally and return > :> allocated storage. strdup(), opendir(), fopen(), setvbuf(), asprintf(), > :> and so forth. Dozens. And while we might check some of these for NULL, > :> we don't check them all, and the ones we do check we tend to conclude > :> a failure other then a memory failure. We would assume that the directory > :> or file does not exist, for example. How many programmers check errno > :> after such a failure? Very few. How many programmers bother to even > :> *clear* errno before making these calls (since some system calls do not > : ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > :We're not supposed to have to clear errno unless we have to explicitly > :test if it has changed. We're not supposed to clear it before any system > :call which could possibly fail and set errno. > : > :> set errno if it already non-zero). Virtually nobody. > : ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > :Erm... WTF?!?! If so, why the HELL are we doing that?!? > > No, wait, I got that wrong I think. > > Oh yah, I remember now. Hmm. How odd. I came across a case where > read() could return -1 and not set errno properly if errno > was already set, but a perusal of the kernel code seems to indicate > that this can't happen. Very weird. > I thought I saw this somewhere too, but I thought it was more of a case that it was somewhere *inside* read that errno had to be preserved. i.e. errno gets set somewhere at the top of the code, and if it was already set at a certain point, failure was expected, and to pass along the original errno, not the new one. Or perhaps we're sharing a hallucination. :) Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 22:24:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from krdl.org.sg (rodin.krdl.org.sg [192.122.139.27]) by hub.freebsd.org (Postfix) with ESMTP id 0C67414C59 for ; Thu, 15 Jul 1999 22:24:32 -0700 (PDT) (envelope-from vasu@krdl.org.sg) Received: from mailhost.krdl.org.sg (mailbox.krdl.org.sg [192.122.134.30]) by krdl.org.sg (8.9.3/8.9.3) with ESMTP id NAA01999 for ; Fri, 16 Jul 1999 13:29:54 +0800 (SGT) Received: from boderek (boderek [192.122.135.157]) by mailhost.krdl.org.sg (8.9.3/8.9.3) with SMTP id NAA27050; Fri, 16 Jul 1999 13:22:22 +0800 (SGT) Date: Fri, 16 Jul 1999 13:07:40 +0800 (SGT) From: Vasudha Ramnath X-Sender: vasu@boderek To: hackers@freebsd.org Cc: Vasudha Ramnath Subject: implementing poll() in a device driver (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Got no response from freebsd-questions. can anyone here help ? Please cc your reply to my email a/c. thanks --Vasudha ---------- Forwarded message ---------- Date: Thu, 15 Jul 1999 14:42:34 +0800 (SGT) From: Vasudha Ramnath To: freebsd-questions@freebsd.org Subject: implementing poll() in a device driver I'm running FreeBSD 3.1-RELEASE. Could someone explain what the poll() function in a device driver should do ? Can it return POLLERR or POLLHUP ? I have a test driver that returns these values from the poll() function. However, the application that called the select() is not getting an error. Instead, the select is returning that the particular file descriptor is, in this case, 'readable' ! Am I missing something ? Any insight appreciated. thank you --Vasudha To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 22:32:42 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id BA9B514CD1; Thu, 15 Jul 1999 22:32:40 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (phoenix.cs.rpi.edu [128.113.96.153]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id BAA54322; Fri, 16 Jul 1999 01:32:27 -0400 (EDT) Message-Id: <199907160532.BAA54322@cs.rpi.edu> To: Kevin Day Cc: dillon@apollo.backplane.com (Matthew Dillon), green@FreeBSD.ORG (Brian F. Feldman), a.reilly@lake.com.au (Andrew Reilly), dcs@newsguy.com (Daniel C. Sobral), lyndon@orthanc.ab.ca, freebsd-hackers@FreeBSD.ORG, crossd@cs.rpi.edu Subject: Re: Swap overcommit In-Reply-To: Message from Kevin Day of "Fri, 16 Jul 1999 00:02:55 CDT." <199907160502.AAA28122@celery.dragondata.com> Date: Fri, 16 Jul 1999 01:32:17 -0400 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > No, wait, I got that wrong I think. > > > > Oh yah, I remember now. Hmm. How odd. I came across a case where > > read() could return -1 and not set errno properly if errno > > was already set, but a perusal of the kernel code seems to indicate > > that this can't happen. Very weird. > > > > I thought I saw this somewhere too, but I thought it was more of a case that > it was somewhere *inside* read that errno had to be preserved. i.e. errno > gets set somewhere at the top of the code, and if it was already set at a > certain point, failure was expected, and to pass along the original errno, > not the new one. > > Or perhaps we're sharing a hallucination. :) Well, set/getpriority(2), certainly can return "-1" and not be an error. You would need to clear out errno before that call and check it on return. This is where excpetions would be a great gain. It could also be used to force programmers to check their system calls more closely. Oops, you didn't handle excpetion foo? SIGBADPROGRAMMER. -- David Cross | email: crossd@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jul 15 23:15:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from zabagek.ihf.rwth-aachen.de (zabagek.ihf.RWTH-Aachen.DE [134.130.90.60]) by hub.freebsd.org (Postfix) with ESMTP id 379C214C0F; Thu, 15 Jul 1999 23:15:38 -0700 (PDT) (envelope-from tg@zabagek.ihf.rwth-aachen.de) Received: (from tg@localhost) by zabagek.ihf.rwth-aachen.de (8.9.3/8.9.3) id IAA95028; Fri, 16 Jul 1999 08:17:03 +0200 (CEST) (envelope-from tg) To: Daniel Eischen Cc: jkh@zippy.cdrom.com, hackers@FreeBSD.ORG, kip@lyris.com, stable@FreeBSD.ORG Subject: Re: seg fault in mutex_queue_enq References: <199907151708.NAA03267@pcnet1.pcnet.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Thomas Gellekum Date: 16 Jul 1999 08:17:03 +0200 In-Reply-To: Daniel Eischen's message of "Thu, 15 Jul 1999 13:08:45 -0400 (EDT)" Message-ID: Lines: 10 X-Mailer: Gnus v5.6.34/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel Eischen writes: > Just tell me what to do, and I'll do it :-) I won't go that far, but I'd suggest keeping the versions in -current and -stable in sync (after testing new stuff in -current, of course). There's (yet) no technical reason not to do so and it makes maintenance much easier. tg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 0:36: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rdc1.sfba.home.com (ha1.rdc1.sfba.home.com [24.0.0.66]) by hub.freebsd.org (Postfix) with ESMTP id 8590A15581 for ; Fri, 16 Jul 1999 00:36:01 -0700 (PDT) (envelope-from adsharma@c62443-a.frmt1.sfba.home.com) Received: from c62443-a.frmt1.sfba.home.com ([24.0.69.165]) by mail.rdc1.sfba.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19990716073500.WSET8807.mail.rdc1.sfba.home.com@c62443-a.frmt1.sfba.home.com>; Fri, 16 Jul 1999 00:35:00 -0700 Received: (from adsharma@localhost) by c62443-a.frmt1.sfba.home.com (8.8.7/8.8.7) id AAA06026; Fri, 16 Jul 1999 00:34:59 -0700 To: Vasudha Ramnath Cc: hackers@FreeBSD.ORG Subject: Re: implementing poll() in a device driver (fwd) References: From: Arun Sharma Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: 16 Jul 1999 00:34:59 -0700 In-Reply-To: Vasudha Ramnath's message of "Fri, 16 Jul 1999 13:07:40 +0800 (SGT)" Message-ID: Lines: 24 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Vasudha Ramnath writes: > > I'm running FreeBSD 3.1-RELEASE. > > Could someone explain what the poll() function in a device driver should > do ? > > Can it return POLLERR or POLLHUP ? > > I have a test driver that returns these values from the poll() function. > However, the application > that called the select() is not getting an error. Instead, the select > is returning that the particular file descriptor is, in this case, > 'readable' ! Take a look at "selscan" algorithm in /usr/src/sys/kern/sys_generic.c if you wish to learn more. Basically, if your driver doesn't implement the poll() functionality, it can always return 0. This will ensure that select never wakes up because of a file descriptor associated with your driver. -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 0:51:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.palmerharvey.co.uk (mail.palmerharvey.co.uk [62.172.109.58]) by hub.freebsd.org (Postfix) with ESMTP id 65E1A14FB6 for ; Fri, 16 Jul 1999 00:51:34 -0700 (PDT) (envelope-from Dom.Mitchell@palmerharvey.co.uk) Received: from ho-nt-01.pandhm.co.uk (unverified) by mail.palmerharvey.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Fri, 16 Jul 1999 08:49:53 +0100 Received: from voodoo.pandhm.co.uk (VOODOO [10.100.35.12]) by ho-nt-01.pandhm.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 3WRWC5HJ; Fri, 16 Jul 1999 08:50:41 +0100 Received: from dom by voodoo.pandhm.co.uk with local (Exim 2.10 #1) id 1152l8-000CfH-00; Fri, 16 Jul 1999 08:50:18 +0100 Date: Fri, 16 Jul 1999 08:50:18 +0100 To: Matthew Dillon Cc: "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG, tech-kern@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Message-Id: <19990716085017.B48601@palmerharvey.co.uk> References: <19866.932086145@splode.eterna.com.au> <378EB49D.331D46DA@newsguy.com> <199907160457.VAA15580@apollo.backplane.com> MIME-Version: 1.0 X-Mailer: Mutt 0.95.6i In-Reply-To: <199907160457.VAA15580@apollo.backplane.com>; from Matthew Dillon on Thu, Jul 15, 1999 at 09:57:31PM -0700 From: Dominic Mitchell Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 15, 1999 at 09:57:31PM -0700, Matthew Dillon wrote: > Something is weird here. If the solaris people are using a > SWAPSIZE + REALMEM VM model, they have to allow the > allocated + reserved space go +REALMEM bytes over available swap > space. If not they are using only a SWAPSIZE VM model. > > Wait - does Solaris normally use swap files or swap partitions? > Or is it that weird /tmp filesystem stuff? If it normally uses swap > files and allows holes then that explains everything. No, swap is slice based in Solaris. tmpfs is just a filesystem (much like MFS) which uses swap as backing store. I will admit to never quite understanding the relationship of how much swap tmpfs is willing to steal though... Maybe I should go and read the answerbook (http://docs.sun.com if you want a peek). -- Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ********************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 1:12:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gw-nl3.philips.com (gw-nl3.philips.com [192.68.44.35]) by hub.freebsd.org (Postfix) with ESMTP id BFD4A14E86 for ; Fri, 16 Jul 1999 01:12:10 -0700 (PDT) (envelope-from Jos.Backus@nl.origin-it.com) Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl3.philips.com with ESMTP id KAA12606 for ; Fri, 16 Jul 1999 10:12:09 +0200 (MEST) (envelope-from Jos.Backus@nl.origin-it.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl3.philips.com via mwrap (4.0a) id xma012596; Fri, 16 Jul 99 10:12:09 +0200 Received: from hal.mpn.cp.philips.com (hal.mpn.cp.philips.com [130.139.64.195]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with SMTP id KAA14384 for ; Fri, 16 Jul 1999 10:12:07 +0200 (MET DST) Received: (qmail 16322 invoked by uid 666); 16 Jul 1999 08:12:29 -0000 Date: Fri, 16 Jul 1999 10:12:29 +0200 From: Jos Backus To: freebsd-hackers@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Message-ID: <19990716101229.C15838@hal.mpn.cp.philips.com> Reply-To: Jos Backus Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I just can't resist mentioning Dan Bernstein's implementation of a similar idea: stralloc - dynamically allocated strings. -- Jos Backus _/ _/_/_/ "Reliability means never _/ _/ _/ having to say you're sorry." _/ _/_/_/ -- D. J. Bernstein _/ _/ _/ _/ Jos.Backus@nl.origin-it.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 1:17:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.palmerharvey.co.uk (mail.palmerharvey.co.uk [62.172.109.58]) by hub.freebsd.org (Postfix) with ESMTP id 12C4B14C09 for ; Fri, 16 Jul 1999 01:17:42 -0700 (PDT) (envelope-from Dom.Mitchell@palmerharvey.co.uk) Received: from ho-nt-01.pandhm.co.uk (unverified) by mail.palmerharvey.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Fri, 16 Jul 1999 09:14:54 +0100 Received: from voodoo.pandhm.co.uk (VOODOO [10.100.35.12]) by ho-nt-01.pandhm.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 3WRWC5H0; Fri, 16 Jul 1999 09:15:41 +0100 Received: from dom by voodoo.pandhm.co.uk with local (Exim 2.10 #1) id 11539L-000CiN-00; Fri, 16 Jul 1999 09:15:19 +0100 Date: Fri, 16 Jul 1999 09:15:19 +0100 To: Jos Backus Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Message-Id: <19990716091518.A48864@palmerharvey.co.uk> References: <19990716101229.C15838@hal.mpn.cp.philips.com> MIME-Version: 1.0 X-Mailer: Mutt 0.95.6i In-Reply-To: <19990716101229.C15838@hal.mpn.cp.philips.com>; from Jos Backus on Fri, Jul 16, 1999 at 10:12:29AM +0200 From: Dominic Mitchell Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 16, 1999 at 10:12:29AM +0200, Jos Backus wrote: > I just can't resist mentioning Dan Bernstein's implementation of a similar > idea: stralloc - dynamically allocated strings. Has he actually LICENSEd any of his code yet? -- Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ********************************************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 1:24:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gw-nl3.philips.com (gw-nl3.philips.com [192.68.44.35]) by hub.freebsd.org (Postfix) with ESMTP id 8FE9414E86 for ; Fri, 16 Jul 1999 01:24:13 -0700 (PDT) (envelope-from Jos.Backus@nl.origin-it.com) Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl3.philips.com with ESMTP id KAA21903 for ; Fri, 16 Jul 1999 10:23:55 +0200 (MEST) (envelope-from Jos.Backus@nl.origin-it.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl3.philips.com via mwrap (4.0a) id xma021899; Fri, 16 Jul 99 10:23:56 +0200 Received: from hal.mpn.cp.philips.com (hal.mpn.cp.philips.com [130.139.64.195]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with SMTP id KAA23331 for ; Fri, 16 Jul 1999 10:23:54 +0200 (MET DST) Received: (qmail 16421 invoked by uid 666); 16 Jul 1999 08:24:16 -0000 Date: Fri, 16 Jul 1999 10:24:16 +0200 From: Jos Backus To: Dominic Mitchell Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Message-ID: <19990716102416.E15838@hal.mpn.cp.philips.com> Reply-To: Jos Backus References: <19990716101229.C15838@hal.mpn.cp.philips.com> <19990716091518.A48864@palmerharvey.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <19990716091518.A48864@palmerharvey.co.uk>; from Dominic Mitchell on Fri, Jul 16, 1999 at 09:15:19AM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 16, 1999 at 09:15:19AM +0100, Dominic Mitchell wrote: > On Fri, Jul 16, 1999 at 10:12:29AM +0200, Jos Backus wrote: > > I just can't resist mentioning Dan Bernstein's implementation of a similar > > idea: stralloc - dynamically allocated strings. > > Has he actually LICENSEd any of his code yet? Dunno. There's ftp://koobera.math.uic.edu/www/softwarelaw.html though. -- Jos Backus _/ _/_/_/ "Reliability means never _/ _/ _/ having to say you're sorry." _/ _/_/_/ -- D. J. Bernstein _/ _/ _/ _/ Jos.Backus@nl.origin-it.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 2:35:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from kozlik.carrier.kiev.ua (kozlik.carrier.kiev.ua [193.193.193.111]) by hub.freebsd.org (Postfix) with ESMTP id E745514BDE for ; Fri, 16 Jul 1999 02:35:29 -0700 (PDT) (envelope-from nx@nn.kiev.ua) Received: from nn.UUCP (uucp@localhost) by kozlik.carrier.kiev.ua (8.The.Best/UUCP_FOREVER) with UUCP id MAA29337 for freebsd-hackers@freebsd.org; Fri, 16 Jul 1999 12:30:15 +0300 (EEST) (envelope-from nx@nn.kiev.ua) Received: from nn.UUCP (uucp@localhost) by kozlik.carrier.kiev.ua (rmail mypid=29336 childpid=29337) with UUCP; Fri, 16 Jul 1999 09:30:15 +0000 GMT Received: by nn.kiev.ua (UUPC/@ v7.00, 29Jul97) id AA06197; Fri, 16 Jul 1999 12:24:47 +0300 (EDT) To: freebsd-hackers@freebsd.org X-Comment-To: Mike Smith References: <199907152358.QAA01894@dingo.cdrom.com> Message-ID: From: "Valentin Nechayev" Date: Fri, 16 Jul 1999 12:24:47 +0300 (EDT) X-Mailer: dMail [Demos Mail for DOS v2.06] Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 42 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith wrote: > pw = getpwuid(getuid()); > strlcpy(buf, pw->dir, sizeof(buf)); > strlcat(buf, "/.appname/", sizeof(buf)); > strlcat(buf, conffilename, sizeof(buf)); > if (strlen(buf) >= sizeof(buf)) > return(error); > fp = fopen(buf, "r"); > ... > > That works, as long as MAXPATHLEN is actually long enough. In this It is incorrect in two places. 1st, strlen(buf) always will be less than buffer size (it is told here yet). 2nd, if the last addition to buffer is zero-length, you cannot check the overflow using return value of last strlcat() (it was not in your code, but I have seen it in idea in your code;)) To check overflow, you can either 1) check result of _each_ strlcpy/strlcat function, 2) [this is hack, but beauty hack;))] create buffer of size {max_possible_length}+2 and test string length after all catenations; if it is more then {max_possible_length}, the overflow was there. > if (asprintf(&buf, "%s/.appname/%s", pw->dir, conffilename) == -1) > return(error); > fp = fopen(buf, "r"); > free(buf); > ... > > The latter has a few really clear advantages: > > - you can see what the string is meant to look like. > - it doesn't matter how long any of the components are. > - the constructed value is on the heap, so you can return it (just > imagine how much nicer ctime() would be if it did this). Yes, let you wrap around ctime() with asprintf() ;) -- NN To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 3: 8:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cackle.proxima.alt.za (cackle.proxima.alt.za [196.28.218.141]) by hub.freebsd.org (Postfix) with ESMTP id 3E9D514BF6 for ; Fri, 16 Jul 1999 03:08:22 -0700 (PDT) (envelope-from lucio@cackle.proxima.alt.za) Received: (from lucio@localhost) by cackle.proxima.alt.za (8.9.3/8.8.8) id MAA02971; Fri, 16 Jul 1999 12:07:22 +0200 (SAST) Date: Fri, 16 Jul 1999 12:07:21 +0200 From: Lucio De Re To: tech-userlevel@netbsd.org, freebsd-hackers@freebsd.org Subject: Overcommitment - some sanity? Message-ID: <19990716120721.B557@cackle.proxima.alt.za> Reply-To: lucio@proxima.alt.za Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Let's try to bring this discussion into focus, because it seems worthwhile, despite it having degenerated into a religious war. Let's start from the other end: If *BSD _did_not_have_ the means to overcommit, would one want to add them? I think the obvious answer here is a resounding "Yes", so we should accept Matthew Dillon's perspective as valid on this score.. In general, the point the anti-over-commitment camp keeps raising is always quite correctly shot down by Matthew, if you're not going to run out of swap, then overcommitment can't hurt you. On the other hand, just because there is a hammer solution, that does not mean that all problems are nails. There has to be a mechanism to protect valuable processes from accidental or intentional abuse of resources. Adding more disk space is not always a solution and Matthew himself pointed out that there comes a time when swapping turns to thrashing, at which point too much swap space is a liability not an advantage. If you have _no_ swap space, you're no better off. Personally, I think over-commitment should be switchable on and off at the process level, and there should be an inheritance flag for child processes to do the right thing too. In addition, a global danger signal, probably providing a bit mask that indicates _which_ condition is creating a crisis, some hysteresis as Jason (I seem to recall) requested, and possibly some means of retrieving the identification of the last process to trigger a crisis, should all be available in the overcommit context. Unless I'm reading the debate wrong, SIGDANGER is not required when the system returns NULL if memory is exhausted. Of course, there's nothing that says the semantics of SIGDANGER may include some hysteresis, in which case it could be useful in either context. It may be preferable to combine all these semantics into a single library function (don't ask me, I'm only a user :-) that simplifies the otherwise complex interface. But the bottom layer must be there for those who may want to do some fine tuning. ++L To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 3:18:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by hub.freebsd.org (Postfix) with ESMTP id 5080814FCC for ; Fri, 16 Jul 1999 03:18:04 -0700 (PDT) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (haldjas.folklore.ee [172.17.2.1] (may be forged)) by haldjas.folklore.ee (8.8.8/8.8.4) with SMTP id NAA27975; Fri, 16 Jul 1999 13:15:55 +0300 (EEST) Date: Fri, 16 Jul 1999 13:15:55 +0300 (EEST) From: Narvi To: lyndon@orthanc.ab.ca Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) In-Reply-To: <199907152353.RAA35007@orthanc.ab.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [cc: list trimmed] On Thu, 15 Jul 1999 lyndon@orthanc.ab.ca wrote: > > In that scenario, the 512MB of swap I assigned to this machine would be > > dangerously low. > > With 13GB disks available for a couple of hundred bucks, my machines aren't > going to run out of swap space any time soon, even if I commit to disk. > > All I want for Christmas is a knob to disable overcommit. > > --lyndon > CVSup the source repository and start writing. Sander There is no love, no good, no happiness and no future - all these are just illusions. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 3:52: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 2917314FFF for ; Fri, 16 Jul 1999 03:51:58 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id TAA12826; Fri, 16 Jul 1999 19:49:16 +0900 (JST) Message-ID: <378F0E28.BE5CE95E@newsguy.com> Date: Fri, 16 Jul 1999 19:49:12 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG, "Daniel C. Sobral" Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <19866.932086145@splode.eterna.com.au> <378EB49D.331D46DA@newsguy.com> <199907160457.VAA15580@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > > Something is weird here. If the solaris people are using a > SWAPSIZE + REALMEM VM model, they have to allow the > allocated + reserved space go +REALMEM bytes over available swap > space. If not they are using only a SWAPSIZE VM model. I did not check if the model was a SWAPSIZE+REALMEM or a SWAPSIZE model. Anyway, I think you are assuming that the "swap -s" command shows as total memory just the swap space... Maybe, maybe not. I don't know. But the space against which I reached the ceiling *was* the one reported in the "swap -s" command. > Wait - does Solaris normally use swap files or swap partitions? > Or is it that weird /tmp filesystem stuff? If it normally uses swap > files and allows holes then that explains everything. I'd say partitions. While perusing man pages, I caught briefly the comment that a swap partition could overwrite a normal partition, in a man page about a special command to create swap partitions. Anything you'd like me to check in particular? If you have any source code you'd like me to run, just send it to capo@comp.cs.gunma-u.ac.jp, though I can only run them at the earliest on monday. Well, at least my monday is your sunday night... :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 3:53:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gate.nitek.ru (nitek.east.ru [195.170.63.240]) by hub.freebsd.org (Postfix) with ESMTP id EB88114FFF for ; Fri, 16 Jul 1999 03:52:54 -0700 (PDT) (envelope-from maillist@nitek.ru) Received: from nitek.ru (localhost [127.0.0.1]) by gate.nitek.ru (8.9.1/8.9.1) with SMTP id OAA15551 for hackers@FreeBSD.org; Fri, 16 Jul 1999 14:52:53 +0400 (MSD) Date: 16 Jul 1999 14:52:53 +0400 From: "Daniel C. Sobral" To: hackers@FreeBSD.org Message-ID: <378F0E28.BE5CE95E@newsguy.com> Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > > Something is weird here. If the solaris people are using a > SWAPSIZE + REALMEM VM model, they have to allow the > allocated + reserved space go +REALMEM bytes over available swap > space. If not they are using only a SWAPSIZE VM model. I did not check if the model was a SWAPSIZE+REALMEM or a SWAPSIZE model. Anyway, I think you are assuming that the "swap -s" command shows as total memory just the swap space... Maybe, maybe not. I don't know. But the space against which I reached the ceiling *was* the one reported in the "swap -s" command. > Wait - does Solaris normally use swap files or swap partitions? > Or is it that weird /tmp filesystem stuff? If it normally uses swap > files and allows holes then that explains everything. I'd say partitions. While perusing man pages, I caught briefly the comment that a swap partition could overwrite a normal partition, in a man page about a special command to create swap partitions. Anything you'd like me to check in particular? If you have any source code you'd like me to run, just send it to capo@comp.cs.gunma-u.ac.jp, though I can only run them at the earliest on monday. Well, at least my monday is your sunday night... :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 3:55:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gate.nitek.ru (nitek.east.ru [195.170.63.240]) by hub.freebsd.org (Postfix) with ESMTP id 2E22E14C3C for ; Fri, 16 Jul 1999 03:55:10 -0700 (PDT) (envelope-from maillist@nitek.ru) Received: from nitek.ru (localhost [127.0.0.1]) by gate.nitek.ru (8.9.1/8.9.1) with SMTP id OAA15630 for hackers@FreeBSD.org; Fri, 16 Jul 1999 14:54:51 +0400 (MSD) Date: 16 Jul 1999 14:54:51 +0400 From: "Daniel C. Sobral" To: hackers@FreeBSD.org Message-ID: <378F0E28.BE5CE95E@newsguy.com> Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > > Something is weird here. If the solaris people are using a > SWAPSIZE + REALMEM VM model, they have to allow the > allocated + reserved space go +REALMEM bytes over available swap > space. If not they are using only a SWAPSIZE VM model. I did not check if the model was a SWAPSIZE+REALMEM or a SWAPSIZE model. Anyway, I think you are assuming that the "swap -s" command shows as total memory just the swap space... Maybe, maybe not. I don't know. But the space against which I reached the ceiling *was* the one reported in the "swap -s" command. > Wait - does Solaris normally use swap files or swap partitions? > Or is it that weird /tmp filesystem stuff? If it normally uses swap > files and allows holes then that explains everything. I'd say partitions. While perusing man pages, I caught briefly the comment that a swap partition could overwrite a normal partition, in a man page about a special command to create swap partitions. Anything you'd like me to check in particular? If you have any source code you'd like me to run, just send it to capo@comp.cs.gunma-u.ac.jp, though I can only run them at the earliest on monday. Well, at least my monday is your sunday night... :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 4: 0: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dirac.th.physik.uni-bonn.de (dirac.th.physik.uni-bonn.de [131.220.161.119]) by hub.freebsd.org (Postfix) with ESMTP id 1796614C3E for ; Fri, 16 Jul 1999 04:00:01 -0700 (PDT) (envelope-from conrad@th.physik.uni-bonn.de) Received: from merlin.th.physik.uni-bonn.de (merlin.th.physik.uni-bonn.de [131.220.161.121]) by dirac.th.physik.uni-bonn.de (8.8.8/8.8.8) with SMTP id MAA06971 for ; Fri, 16 Jul 1999 12:59:48 +0200 (CEST) (envelope-from conrad@merlin.th.physik.uni-bonn.de) Received: (qmail 21762 invoked by uid 145); 16 Jul 1999 10:59:48 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 16 Jul 1999 10:59:48 -0000 Date: Fri, 16 Jul 1999 12:59:48 +0200 (CEST) From: Jan Conrad To: Ian Dowse Cc: freebsd-hackers@freebsd.org Subject: Re: NFS problems due to getcwd/realpath In-Reply-To: <199907151645.aa25796@salmon.maths.tcd.ie> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dear Ian, thanks a lot for your answer! (I was searching the bug reports but didn't find bin/6658...). Are you really sure about the following? On Thu, 15 Jul 1999, Ian Dowse wrote: > This should no longer be an issue with FreeBSD 3.x, as the system normally > uses the new _getcwd syscall. The old code is still in getcwd.c, but is > only used if the syscall isn't present (e.g. if running a 3.x executable > on a 2.2 system). The CVS log for getcwd says: 1.11 Sun Sep 14 16:57:16 1997 UTC by phk Diffs to 1.10 Add __getcwd() syscall, and have getcwd() take a shot at it. If your kernel doesn't support __getcwd() or if __getcwd() cannot ^^^^^^^^^^^^^^^^^^^^ deliver because of cache expiry, it does the canonical thing. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ So you say this never can happen? (The code of getcwd explicitly handles that case, at least as I understand it, and I can't tell from the kernel sources...) If so, one sould close my own bug report (kern/12609) Do you know whom sould I send an email to do that? Or is a followup enough? If not so, one should change the canonical part of getcwd as in your patch... best regards and thanks for the patch.. Jan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 4: 6:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from kozlik.carrier.kiev.ua (kozlik.carrier.kiev.ua [193.193.193.111]) by hub.freebsd.org (Postfix) with ESMTP id E4D7414C3E for ; Fri, 16 Jul 1999 04:06:27 -0700 (PDT) (envelope-from nx@nn.kiev.ua) Received: from nn.UUCP (uucp@localhost) by kozlik.carrier.kiev.ua (8.The.Best/UUCP_FOREVER) with UUCP id OAA17170 for freebsd-hackers@freebsd.org; Fri, 16 Jul 1999 14:05:49 +0300 (EEST) (envelope-from nx@nn.kiev.ua) Received: from nn.UUCP (uucp@localhost) by kozlik.carrier.kiev.ua (rmail mypid=17169 childpid=17170) with UUCP; Fri, 16 Jul 1999 11:05:49 +0000 GMT Received: by nn.kiev.ua (UUPC/@ v7.00, 29Jul97) id AA06197; Fri, 16 Jul 1999 14:00:16 +0300 (EDT) To: freebsd-hackers@freebsd.org X-Comment-To: "Daniel C. Sobral" References: <378DF141.393ECB36@newsguy.com> Message-ID: From: "Valentin Nechayev" Date: Fri, 16 Jul 1999 14:00:16 +0300 (EDT) X-Mailer: dMail [Demos Mail for DOS v2.06] Subject: Re: Replacement for grep(1) (part 2) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 47 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel C. Sobral wrote: > Eh? Reasonable programs *never* run into trouble. Trouble only > happens when you have unreasonable programs around, or did not > configure the system correctly. And if you did not configure the > system correctly, why do you think you would be able to correctly > estimate the stack needed for the various programs? Your words are bad words. Exhausting of any of main resources - virtual memory, disk space, process descriptors, file descriptors - is a terrible situation, but one must not fight against headache with headcutting. Every system can fall in uncontrolled state and eat all of some resource, and kernel stack is to prevent process pool part from this, not to destruct it. I had seen two boxes where swap was out misfortunately with bad results: on first (FreeBSD 2.2.7), system kills the cron (sic!) process, on second (Linux) syslogd, sendmail and some others became poisoned without any warnings. It is totally bad behavior; kernel must be friend, not enemy. Actions supposed enough by me for first (!) time: 1) Count in some kernel variables (readable by sysctl) overflows of virtual memory, file descriptors, process descriptors and other critical resources. This data must be available for watchdogs; for some systems, it is right to reboot them immediately after some overflow, not to try to work in poisoned state. 2) Run (in standard setup!) cron, syslogd and other important daemons from special init slot (as Linux and possibly other systems allow), not from startup scripts. Reason: they must be restarted when die without admin intervention and without wrappers which can also be killed on memory low. 3) Declare thresholds for critical resources; for example, when more than 80% of virtual memory is used, prevent everybody except euid==0 or egid==0 from allocating new memory. 4) Provide special signal (SIGXMEM?) to send messages that there is memory low and all have to shorten their memory. Daemons should interpret this signal similarly to SIGHUP, with exec() itself and restart. > Now comes the people saying "don't overcommit in *this* case, and > overcommit in *that* case". Irrelevant. Programs are still getting > killed because memory was overcommitted (with the added disadvantage > of you not having as much memory as in a full overcommit mode). Kernel can kill processes that try to get unexistent memory. But when it did not prevent system from falling into overflow, it plays unfair game. -- Netch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 4:10: 4 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id 4CAD914E64 for ; Fri, 16 Jul 1999 04:09:49 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id OAA13643; Fri, 16 Jul 1999 14:02:14 +0300 (EEST) (envelope-from will) To: julian@whistle.com (Julian Elischer) Cc: hackers@freebsd.org Subject: Re: Replacement for grep(1) (part 2) References: <199907141755.LAA05231@orthanc.ab.ca> From: Ville-Pertti Keinonen Date: 16 Jul 1999 14:02:14 +0300 In-Reply-To: julian@whistle.com's message of "14 Jul 1999 21:10:44 +0300" Message-ID: <86k8s0n9hl.fsf@not.demophon.com> Lines: 33 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG julian@whistle.com (Julian Elischer) writes: > If you wanted to fix this, you could add a patch to malloc that touched > every page that it handed to the application. (and trapped sig11s) How would you expect that to work? Several misunderstandings seem to be common regarding this issue (most not directed at you): - malloc almost never fails with NULL. This is not true, if resource limits are set properly, any one program using huge amounts of memory is going to hit them long before swap space is exhausted. - The program currently trying to get the page is the one that is killed. - Actually paging in all memory is going to protect a program from getting killed. This is going to make it *more likely* for it to be killed. - Not overcommitting doesn't consume huge amounts of reserve space unless programs do something special. A rough sum of memory usage can be computed by summing up all of the process VSZs plus your stack limit times the number of processes. How many of you would be willing to configure that much swap space? If you really wanted to run without overcommit, you'd only run statically linked binaries and set your stack limits to small values. This could be desirable for some (but not general-purpose) systems, an option for doing this wouldn't be entirely bogus. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 4:10:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mcclure.tinet.ie (mcclure.tinet.ie [159.134.237.31]) by hub.freebsd.org (Postfix) with ESMTP id ACD0B14D66 for ; Fri, 16 Jul 1999 04:10:23 -0700 (PDT) (envelope-from crypt0genic@tinet.ie) Received: from p55.as1.cork1.tinet.ie ([159.134.228.55] helo=tweak.home) by mcclure.tinet.ie with esmtp (Exim 2.05 #23) id 1155rp-0007oz-00 for hackers@freebsd.org; Fri, 16 Jul 1999 12:09:25 +0100 Received: (from crypt0genic@localhost) by tweak.home (8.9.3/8.9.3) id MAA00638 for hackers@freebsd.org; Fri, 16 Jul 1999 12:07:48 GMT Date: Fri, 16 Jul 1999 12:07:48 +0000 From: crypt0genic To: hackers@freebsd.org Subject: poor ethernet performance? Message-ID: <19990716120748.A629@ecad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hey all, I have two freeBSD machines one 3.1 -STABLE and the other 3.2 -STABLE, I was ftp ing a very large file from one machine to abother over are lan, it began to get extremely slow and began to stall. I suspected two much traffic on our hub (A N etgear 24port 10base-T) so i switched the two machines onto a 8 port Compaq Nett elligent hub. Now there are only these two machines on the hub and they are stil l stalling. I tried ftping both ways but it was the same thing. By looking at the lights on the hob it seems that a burst of data would come for 2 seconds and then it would be dead for 10. I have 3com 3c905b FastEthernet car ds in both machines, and up until now I have never had these kind of problems. Any Ideas? -Emil -- Reverse engineering, the most phun and usually the most effective way to tackle a problem or learn something new. Public PGP key: http://www.ecad.org/crypt0genic_pgp_key Website: http://www.ecad.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 4:16:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id 4A57514E64 for ; Fri, 16 Jul 1999 04:16:09 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id OAA13658; Fri, 16 Jul 1999 14:09:08 +0300 (EEST) (envelope-from will) To: cgd@netbsd.org (Chris G. Demetriou) Cc: hackers@freebsd.org, dillon@apollo.backplane.com Subject: Re: Replacement for grep(1) (part 2) References: <199907132110.OAA23817@lestat.nas.nasa.gov> <871zecyx0k.fsf@redmail.redback.com> From: Ville-Pertti Keinonen Date: 16 Jul 1999 14:09:07 +0300 In-Reply-To: cgd@netbsd.org's message of "14 Jul 1999 02:03:32 +0300" Message-ID: <86iu7kn964.fsf@not.demophon.com> Lines: 36 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG cgd@netbsd.org (Chris G. Demetriou) writes: > Matthew Dillon writes: > > The text size of a program is irrelevant, because swap is never > > allocated for it. The data and BSS are only relevant when they No, you can mprotect read-only vnode mappings to writable. Most things wouldn't be hurt badly if this changed, though, I suspect that this already varies between operating systems. > > are modified. > > > > The only thing swap is ever used for is the dynamic allocation of memory. > > There are three ways to do it: sbrk(), mmap(... MAP_ANON), or > > mmap(... MAP_PRIVATE). > yup, almost: not all MAP_PRIVATE mappings need backing store, only > MAP_PRIVATE and writeable mappings. (MAP_PRIVATE does _not_ guarantee > that you won't see modifications made via other MAP_SHARED mappings.) ...but in *this* case, you certainly shouldn't allow mprotect to fail (with what, ENOMEM?). It's certainly counterintuitive to me that mprotect could fail due to a resource shortage. > Actually, only now have you brought that up. And, that's very system > dependent. On NetBSD/i386 the default is 2MB, and, it's worth noting > that you only need to reserve as much as the current stack limit > allows (after that, you're going to get a signal anyway, and if more So what setrlimit accepts depends on how much memory is available? Ok, programs changing their stack limit are rare, but this would still be another API change. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 4:26:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dns0.sports.gov.uk (dns0.sports.gov.uk [195.89.151.148]) by hub.freebsd.org (Postfix) with ESMTP id 65F5614DA2 for ; Fri, 16 Jul 1999 04:26:27 -0700 (PDT) (envelope-from ad@fionn.sports.gov.uk) Message-ID: <378F16A6.C2541AD0@fionn.sports.gov.uk> Date: Fri, 16 Jul 1999 12:25:26 +0100 From: Andy Doran X-Accept-Language: en-GB,en,en-* MIME-Version: 1.0 To: crypt0genic Cc: hackers@freebsd.org Subject: Re: poor ethernet performance? References: <19990716120748.A629@ecad.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG What does 'netstat -in' say? - ad crypt0genic wrote: > > Hey all, > > I have two freeBSD machines one 3.1 -STABLE and the other 3.2 -STABLE, I was ftp > ing a very large file from one machine to abother over are lan, it began to get > extremely slow and began to stall. I suspected two much traffic on our hub (A N > etgear 24port 10base-T) so i switched the two machines onto a 8 port Compaq Nett > elligent hub. Now there are only these two machines on the hub and they are stil > l stalling. I tried ftping both ways but it was the same thing. > > By looking at the lights on the hob it seems that a burst of data would come for > 2 seconds and then it would be dead for 10. I have 3com 3c905b FastEthernet car > ds in both machines, and up until now I have never had these kind of problems. > > Any Ideas? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 4:29:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from henry.newn.cam.ac.uk (henry.newn.cam.ac.uk [131.111.204.130]) by hub.freebsd.org (Postfix) with ESMTP id 1459F15688 for ; Fri, 16 Jul 1999 04:29:22 -0700 (PDT) (envelope-from prlw1@newn.cam.ac.uk) Received: from [131.111.204.180] (helo=quartz.newn.cam.ac.uk) by henry.newn.cam.ac.uk with esmtp (Exim 2.12 #1) id 11569a-0006sF-00; Fri, 16 Jul 1999 12:27:46 +0100 Received: from prlw1 by quartz.newn.cam.ac.uk with local (Exim 2.12 #1) id 11569T-0003dF-00; Fri, 16 Jul 1999 12:27:39 +0100 Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) To: dillon@apollo.backplane.com (Matthew Dillon) Date: Fri, 16 Jul 1999 12:27:39 +0100 (BST) From: "Patrick Welche" Cc: thorpej@nas.nasa.gov, jobaldwi@vt.edu, tech-userlevel@netbsd.org, freebsd-hackers@FreeBSD.ORG Reply-To: prlw1@cam.ac.uk In-Reply-To: <199907142218.PAA96575@apollo.backplane.com> from "Matthew Dillon" at Jul 14, 99 03:18:50 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1277 Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > > :On Tue, 13 Jul 1999 23:18:58 -0400 (EDT) > : John Baldwin wrote: > : > : > What does that have to do with overcommit? I student administrate a undergrad > : > CS lab at a university, and when student's programs misbehaved, they generate a > : > fault and are killed. The only machines that reboot on us without be > : > explicitly told to are the NT ones, and yes we run FreeBSD. > : > :What does it have to do with overcommit? Everthing in the world! > : > :If you have a lot of users, all of which have buggy programs which eat > :a lot of memory, per-user swap quotas don't necessarily save your butt. > > If every single one of your users is trying to crash your machine daily, > maybe you should consider throwing them off the system and finding users > that are less hostile. > > This conversation is getting silly. Do you actually believe that > an operating system can magically protect itself 100% from armloads of > hostile users? > > Give me a break. You people are crazy. If you have something worthwhile > to say i'll listen, but these "the sky is falling!" arguments are idiotic. > > -Matt > students != hostile users Making mistakes is part of learning. Patrick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 4:42:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 231C214C37 for ; Fri, 16 Jul 1999 04:42:20 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id UAA19937; Fri, 16 Jul 1999 20:41:25 +0900 (JST) Message-ID: <378F1A60.F73E9327@newsguy.com> Date: Fri, 16 Jul 1999 20:41:20 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: prlw1@cam.ac.uk Cc: tech-userlevel@netbsd.org, freebsd-hackers@FreeBSD.ORG Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Patrick Welche wrote: > > students != hostile users We obviously have known different students... :-) > Making mistakes is part of learning. A hostile user is one which will act in a non-friendly manner. Whether intentionaly or not is irrelevant from the point of view of the administrator, as far as protecting the system goes. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 5: 7:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from kozlik.carrier.kiev.ua (kozlik.carrier.kiev.ua [193.193.193.111]) by hub.freebsd.org (Postfix) with ESMTP id 6D0C214C37 for ; Fri, 16 Jul 1999 05:07:27 -0700 (PDT) (envelope-from nx@nn.kiev.ua) Received: from nn.UUCP (uucp@localhost) by kozlik.carrier.kiev.ua (8.The.Best/UUCP_FOREVER) with UUCP id PAA28525 for freebsd-hackers@freebsd.org; Fri, 16 Jul 1999 15:03:16 +0300 (EEST) (envelope-from nx@nn.kiev.ua) Received: from nn.UUCP (uucp@localhost) by kozlik.carrier.kiev.ua (rmail mypid=28524 childpid=28525) with UUCP; Fri, 16 Jul 1999 12:03:16 +0000 GMT Received: by nn.kiev.ua (UUPC/@ v7.00, 29Jul97) id AA06197; Fri, 16 Jul 1999 15:00:56 +0300 (EDT) To: freebsd-hackers@freebsd.org X-Comment-To: "Daniel C. Sobral" References: <378CA22C.E5537F7A@newsguy.com> Message-ID: From: "Valentin Nechayev" Date: Fri, 16 Jul 1999 15:00:56 +0300 (EDT) X-Mailer: dMail [Demos Mail for DOS v2.06] Subject: Re: Replacement for grep(1) (part 2) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 23 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel C. Sobral wrote: > > 4.4BSD derived system cannot do this, and have to use different > > machine for such applications. > > Incorrect. We can set *limits* to the users, so they won't be able > to crash down the system. No. Really, not all users are used system in the same time. And it is too cruel to set too small limits. And, average system has user limits quite more than (total_resource*2/3)/n_users (2/3 is sub-optimal modifier). But, if too many users began to use system, they can overflow the resource. Group limits can make problem softer, but not more than a little. I don't remember now English word for soft barrier, the Russian word is 'dempfer' ;) System must provide such soft barrier to prevent overflow long far from the real overflow. Imho, 20% of typical critical resource must be prevented. -- Netch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 5:14:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from kodos.tinet.ie (kodos.tinet.ie [159.134.237.29]) by hub.freebsd.org (Postfix) with ESMTP id 645C114C37 for ; Fri, 16 Jul 1999 05:14:28 -0700 (PDT) (envelope-from crypt0genic@tinet.ie) Received: from p55.as1.cork1.tinet.ie ([159.134.228.55] helo=tweak.home) by kodos.tinet.ie with esmtp (Exim 2.05 #23) id 1156sj-000588-00; Fri, 16 Jul 1999 13:14:26 +0100 Received: (from crypt0genic@localhost) by tweak.home (8.9.3/8.9.3) id NAA00807; Fri, 16 Jul 1999 13:12:42 GMT Date: Fri, 16 Jul 1999 13:12:38 +0000 From: crypt0genic To: Andy Doran Cc: hackers@freebsd.org Subject: Re: poor ethernet performance? Message-ID: <19990716131238.A658@ecad.org> References: <19990716120748.A629@ecad.org> <378F16A6.C2541AD0@fionn.sports.gov.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <378F16A6.C2541AD0@fionn.sports.gov.uk>; from Andy Doran on Fri, Jul 16, 1999 at 12:25:26PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Andy Doran (ad@fionn.sports.gov.uk) [990716 12:25]: > What does 'netstat -in' say? Machine 1 (Tweak) # netstat -in Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll xl0 1500 00.10.5a.d8.8f.b8 41804 0 73961 174 18255 xl0 1500 10/24 10.0.0.64 41804 0 73961 174 18255 ---------- Machine 2 (Manson) $ netstat -in Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll xl0 1500 00.10.4b.b6.1c.ed 130585 171 76642 0 17938 xl0 1500 10 10.0.2.2 130585 171 76642 0 17938 xl0 1500 10 10.0.0.3 130585 171 76642 0 17938 xl0 1500 10 10.0.2.3 130585 171 76642 0 17938 -Emil -- Reverse engineering, the most phun and usually the most effective way to tackle a problem or learn something new. Public PGP key: http://www.ecad.org/crypt0genic_pgp_key Website: http://www.ecad.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 5:45:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dns0.sports.gov.uk (dns0.sports.gov.uk [195.89.151.148]) by hub.freebsd.org (Postfix) with ESMTP id 59AC314D11 for ; Fri, 16 Jul 1999 05:45:44 -0700 (PDT) (envelope-from ad@fionn.sports.gov.uk) Message-ID: <378F28EB.7E577B22@fionn.sports.gov.uk> Date: Fri, 16 Jul 1999 13:43:23 +0100 From: Andy Doran X-Accept-Language: en-GB,en,en-* MIME-Version: 1.0 To: crypt0genic Cc: hackers@freebsd.org Subject: Re: poor ethernet performance? References: <19990716120748.A629@ecad.org> <378F16A6.C2541AD0@fionn.sports.gov.uk> <19990716131238.A658@ecad.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'd guess that you're running these cards in full duplex mode. You can't do that with them plugged into a hub. ifconfig xl0 mediaopt half-duplex - ad crypt0genic wrote: > > * Andy Doran (ad@fionn.sports.gov.uk) [990716 12:25]: > > What does 'netstat -in' say? > > Machine 1 (Tweak) > > # netstat -in > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > xl0 1500 00.10.5a.d8.8f.b8 41804 0 73961 174 18255 > xl0 1500 10/24 10.0.0.64 41804 0 73961 174 18255 > ---------- > Machine 2 (Manson) > > $ netstat -in > Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll > xl0 1500 00.10.4b.b6.1c.ed 130585 171 76642 0 17938 > xl0 1500 10 10.0.2.2 130585 171 76642 0 17938 > xl0 1500 10 10.0.0.3 130585 171 76642 0 17938 > xl0 1500 10 10.0.2.3 130585 171 76642 0 17938 > > -Emil > > -- > Reverse engineering, the most phun and usually the most effective way to tackle a problem or learn something new. > Public PGP key: http://www.ecad.org/crypt0genic_pgp_key > Website: http://www.ecad.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 5:52:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp11.bellglobal.com (smtp11.bellglobal.com [204.101.251.53]) by hub.freebsd.org (Postfix) with ESMTP id 29E9315676 for ; Fri, 16 Jul 1999 05:52:50 -0700 (PDT) (envelope-from hoek@FreeBSD.org) Received: from localhost.nowhere (Hamilton-ppp44850.sympatico.ca [206.172.76.43]) by smtp11.bellglobal.com (8.8.5/8.8.5) with ESMTP id IAA23520; Fri, 16 Jul 1999 08:56:01 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id DAA55985; Fri, 16 Jul 1999 03:34:53 -0400 (EDT) (envelope-from tim) Date: Fri, 16 Jul 1999 03:34:53 -0400 From: Tim Vanderhoek To: Bakul Shah Cc: freebsd-hackers@FreeBSD.org Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Message-ID: <19990716033453.D54146@mad> References: <199907160320.XAA03039@chai.torrentnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199907160320.XAA03039@chai.torrentnet.com>; from Bakul Shah on Thu, Jul 15, 1999 at 11:20:04PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 15, 1999 at 11:20:04PM -0400, Bakul Shah wrote: > > That is, the returned ptr points in `dst' _just_ past the > copied data. Note that `dst_end' points to the _last_ char > of `dst'. This sounds a lot like the GNU stpcpy() except that stpcpy() doesn't take the middle argument dst_end (and therefore isn't as easy to make secure). Adding stpcpy() and pstpcpy() ("p", for pointer? I dunno...) wouldn't bother me one iota. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 5:53: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp13.bellglobal.com (smtp13.bellglobal.com [204.101.251.52]) by hub.freebsd.org (Postfix) with ESMTP id 4AA6E156A0 for ; Fri, 16 Jul 1999 05:52:55 -0700 (PDT) (envelope-from hoek@FreeBSD.org) Received: from localhost.nowhere (Hamilton-ppp44850.sympatico.ca [206.172.76.43]) by smtp13.bellglobal.com (8.8.5/8.8.5) with ESMTP id IAA05598; Fri, 16 Jul 1999 08:54:22 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id DAA55974; Fri, 16 Jul 1999 03:30:18 -0400 (EDT) (envelope-from tim) Date: Fri, 16 Jul 1999 03:30:18 -0400 From: Tim Vanderhoek To: Warner Losh Cc: Sheldon Hearn , freebsd-hackers@FreeBSD.org Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Message-ID: <19990716033018.C54146@mad> References: <19990715194203.A54146@mad> <19990715183442.A53661@mad> <80092.932079193@axl.noc.iafrica.com> <19990715194203.A54146@mad> <199907160028.SAA01218@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199907160028.SAA01218@harmony.village.org>; from Warner Losh on Thu, Jul 15, 1999 at 06:28:52PM -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 15, 1999 at 06:28:52PM -0600, Warner Losh wrote: > > : Looking at OpenBSD's actual definition of strlcat() which returns the > : number of chars that would have been in the final string is > : potentially non-useful, but not really toooooo terrible. > > No. It is useful. If you look at the return value, you can detect > that an overflow would have happened and bail w/o having the overflow No, they could simply return sizeof(buf) + 1 and have the same effect. Running through the whole length of the string that would have been created is potentially non-useful [sic]. It also potentially slows strlcat() down, particularly is some programmers start to rely on its behaviour to find the new amount of memory needed to allocate instead of doing the math themselves. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 5:53:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp13.bellglobal.com (smtp13.bellglobal.com [204.101.251.52]) by hub.freebsd.org (Postfix) with ESMTP id 8017415685 for ; Fri, 16 Jul 1999 05:53:07 -0700 (PDT) (envelope-from hoek@FreeBSD.org) Received: from localhost.nowhere (Hamilton-ppp44850.sympatico.ca [206.172.76.43]) by smtp13.bellglobal.com (8.8.5/8.8.5) with ESMTP id IAA05647; Fri, 16 Jul 1999 08:54:30 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id DAA56010; Fri, 16 Jul 1999 03:37:01 -0400 (EDT) (envelope-from tim) Date: Fri, 16 Jul 1999 03:37:01 -0400 From: Tim Vanderhoek To: Mike Smith Cc: Julian Elischer , Sheldon Hearn , Garance A Drosihn , Paul Hart , freebsd-hackers@FreeBSD.org Subject: Re: OpenBSD's strlcpy(3) and strlcat(3) Message-ID: <19990716033700.E54146@mad> References: <199907152318.QAA01649@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199907152318.QAA01649@dingo.cdrom.com>; from Mike Smith on Thu, Jul 15, 1999 at 04:18:08PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 15, 1999 at 04:18:08PM -0700, Mike Smith wrote: > > The only addition I'd want to make to > asprintf() is reasprintf() which reallocs and appends to the end of > an already existing string. And don't forget reasprintff() (a-la reallocf()). Ugh. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 6: 2:55 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (Postfix) with SMTP id 29FB614F0D for ; Fri, 16 Jul 1999 06:02:46 -0700 (PDT) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id JAA20604; Fri, 16 Jul 1999 09:01:34 -0400 From: Bill Paul Message-Id: <199907161301.JAA20604@skynet.ctr.columbia.edu> Subject: Re: poor ethernet performance? To: crypt0genic@ecad.org (crypt0genic) Date: Fri, 16 Jul 1999 09:01:32 -0400 (EDT) Cc: hackers@freebsd.org In-Reply-To: <19990716120748.A629@ecad.org> from "crypt0genic" at Jul 16, 99 12:07:48 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2611 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Of all the gin joints in all the towns in all the world, crypt0genic had to walk into mine and say: > Hey all, > I have two freeBSD machines one 3.1 -STABLE and the other 3.2 -STABLE, 3.2-STABLE *FROM WHEN*. What date does it say when you run uname -a! > I was ftping a very large file from one machine to abother over are > lan, it began to get extremely slow and began to stall. I suspected two > much traffic on our hub (A Netgear 24port 10base-T) so i switched the > two machines onto a 8 port Compaq Nettelligent hub. Now there are only > these two machines on the hub and they are still stalling. I tried > ftping both ways but it was the same thing. You changed out the "hub" just because one FTP transfer didn't go as fast as you would have liked? Did you reset the interfaces (or reboot the machines) when you reconnected them? It sounds a lot to me like you have the duplex modes on the cards set wrong, or that the cards are autonegotiating wrong (which is not impossible -- some switches that have full duplex ports don't do NWAY correctly). The cards must agree with their link partners: if you have them plugged into full duplex ports, then they must also be set to full duplex. If the cards are plugged into half duplex ports, then they also have to be half duplex. Now you're going to ask me how to set the duplex mode on the interface because why read the instructions when you can just ask somebody "on the web" instead, right? Grrr. # ifconfig xl0 media 10baseT/UTP mediaopt full-duplex # ifconfig xl0 media 10baseT/UTP mediaopt half-duplex > By looking at the lights on the hob it seems that a burst of data > would come for 2 seconds and then it would be dead for 10. I have 3com > 3c905b FastEthernet cards in both machines, and up until now I have > never had these kind of problems. Er. I don't get it. You're implying that the bug fairy just visited you one night while you were asleep. This doesn't happen. If you're having trouble now and you weren't before, then you changed something. Stands to reason, doesn't it? -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 ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 6:24: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from kodos.tinet.ie (kodos.tinet.ie [159.134.237.29]) by hub.freebsd.org (Postfix) with ESMTP id A20AC14F0D for ; Fri, 16 Jul 1999 06:24:00 -0700 (PDT) (envelope-from crypt0genic@tinet.ie) Received: from p55.as1.cork1.tinet.ie ([159.134.228.55] helo=tweak.home) by kodos.tinet.ie with esmtp (Exim 2.05 #23) id 1157xW-0007NX-00; Fri, 16 Jul 1999 14:23:26 +0100 Received: (from crypt0genic@localhost) by tweak.home (8.9.3/8.9.3) id OAA00967; Fri, 16 Jul 1999 14:21:00 GMT Date: Fri, 16 Jul 1999 14:20:44 +0000 From: crypt0genic To: Bill Paul Cc: hackers@freebsd.org Subject: Re: poor ethernet performance? Message-ID: <19990716142044.A844@ecad.org> References: <19990716120748.A629@ecad.org> <199907161301.JAA20604@skynet.ctr.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: <199907161301.JAA20604@skynet.ctr.columbia.edu>; from Bill Paul on Fri, Jul 16, 1999 at 09:01:32AM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Bill Paul (wpaul@skynet.ctr.columbia.edu) [990716 13:58]: > > I have two freeBSD machines one 3.1 -STABLE and the other 3.2 -STABLE, > > 3.2-STABLE *FROM WHEN*. What date does it say when you run uname -a! FreeBSD TWEAK.HOME 3.1-STABLE FreeBSD 3.1-STABLE #3: Wed Jun 30 11:00:45 IST 199 9 root@TWEAK.HOME:/usr/src/sys/compile/TWEAK i386 FreeBSD MANSON.HOME 3.2-STABLE FreeBSD 3.2-STABLE #0: Thu Jun 24 20:54:25 IST 1999 root@MANSON.HOME:/usr/src/sys/compile/MANSON i386 I was unsure when i wrote that in the first place so I even checked. > You changed out the "hub" just because one FTP transfer didn't go as > fast as you would have liked? Did you reset the interfaces (or reboot > the machines) when you reconnected them? I changed the hub because I was planning on doing so for some time anyway, I also rebooted the machines. > > It sounds a lot to me like you have the duplex modes on the cards set > wrong, or that the cards are autonegotiating wrong (which is not > impossible -- some switches that have full duplex ports don't do NWAY > correctly). The cards must agree with their link partners: if you have > them plugged into full duplex ports, then they must also be set to full > duplex. If the cards are plugged into half duplex ports, then they also > have to be half duplex. > > Now you're going to ask me how to set the duplex mode on the interface > because why read the instructions when you can just ask somebody "on > the web" instead, right? Grrr. > > # ifconfig xl0 media 10baseT/UTP mediaopt full-duplex > # ifconfig xl0 media 10baseT/UTP mediaopt half-duplex That worked, except after a few minutes i got an error on TWEAK reading "xl0: watchdog timeout" seeing as your allready reading this have you anyideas? > > Er. I don't get it. You're implying that the bug fairy just visited > you one night while you were asleep. This doesn't happen. If you're > having trouble now and you weren't before, then you changed something. > Stands to reason, doesn't it? Indeed it does, I noticed some slight network performance problems before, but nothing this severe, Also fariys only tend to visit me after too much Gin, which I havent indulged in for quiet some time. Thanks for your help Bill, and also Andy who followed up the thread. -Emil -- Reverse engineering, the most phun and usually the most effective way to tackle a problem or learn something new. Public PGP key: http://www.ecad.org/crypt0genic_pgp_key Website: http://www.ecad.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 7: 3: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from kronos.alcnet.com (kronos.alcnet.com [63.69.28.22]) by hub.freebsd.org (Postfix) with ESMTP id BA0B5150AB for ; Fri, 16 Jul 1999 07:03:03 -0700 (PDT) (envelope-from kbyanc@alcnet.com) X-Provider: ALC Communications, Inc. http://www.alcnet.com/ Received: from kbyanc (ws-41.alcnet.com [63.69.28.41]) by kronos.alcnet.com (8.9.3/8.9.3/antispam) with SMTP id KAA73518 for ; Fri, 16 Jul 1999 10:17:57 -0400 (EDT) From: "Kelly Yancey" To: Subject: RE: freebsd-hackers-digest V4 #549 Date: Fri, 16 Jul 1999 10:13:48 -0400 Message-ID: <000801becf95$6c007a80$291c453f@kbyanc.alcnet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Date: Fri, 16 Jul 1999 10:08:08 +1000 > From: "Andrew Reilly" > Subject: Re: Swap overcommit > > On Thu, Jul 15, 1999 at 11:48:41PM +0900, Daniel C. Sobral wrote: > > Actually, applications are written assuming that malloc() will not > > fail, generally speaking. > > Is this really the case? I'm pretty sure I've _never_ ignored the > possibility of a NULL return from malloc, and I've been using it > for nearly 20 years. I usually print a message and exit, but I > never ignore it. I thought that was pretty standard practise. > > This is just a random comment, orthogonal to the overcommit issue, > but I've seen both you and Matthew say this now, and I was surprised > both times. > > - -- > Andrew > I have to concur, I have only been programming in C for about 8 years (although programming in other languages for about 15), and I am always sure to check for the failure of dynamic memory allocation. Almost all malloc calls I've written look something like (taken from actually source code): if((current = malloc(sizeof(struct clientinfo))) == NULL) die("Out of memory"); where die is simply a function which calls fprintf to write the message out to stderr and then exit's the program with an error level of 1. Some programs I've gotten fancier and added a second parameter to die() to specify the error level to return. In any event, I like to hope that everyone checks for malloc returning null (since FreeBSD still returns NULL when the resource limit is hit). I always have just assumed everyone did (actually, before this thread, I just assumed returning NULL was more common than it is). I'm all for overcommit, before this thread I never thought one way or the other about it, but I feel that the case for overcommit has been made. And, as is always the case, the offer has been extended for the proponents of non-overcommit to put their source where their mouth is....needless to say no one has stepped up. The argument over overcommit vs. non-overcommit then is irrelevant until someone from the non-overcommit produces patches so the world can see for themselves what they are talking about. I would like to see the discussion die. On the other hand, I find the discussion about the merits of overcommit and the (albeit not always in-depth) explanations of the FreeBSD VM system educational. It would be nice if would could just extract the small amount of signal from this discussion and put it into documentation somewhere. Also, it has got me thinking: does FreeBSD overcommit memory allocated by calloc()? Seems that it would be difficult since the page would have had to have been touched in order be zeroed, but I was curious. Thanks, Kelly ~kbyanc@posi.net~ FreeBSD - The Power To Serve - http://www.freebsd.org/ Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 7:13:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from voyager.fisicc-ufm.edu (ip-46-094.guate.net [200.12.46.94]) by hub.freebsd.org (Postfix) with ESMTP id 3A54214E3D for ; Fri, 16 Jul 1999 07:13:12 -0700 (PDT) (envelope-from obonilla@voyager.fisicc-ufm.edu) Received: (from obonilla@localhost) by voyager.fisicc-ufm.edu (8.9.3/8.9.3) id UAA15071 for freebsd-hackers@freebsd.org; Thu, 15 Jul 1999 20:03:36 -0600 (CST) (envelope-from obonilla) Date: Thu, 15 Jul 1999 20:03:36 -0600 From: Oscar Bonilla To: freebsd-hackers@freebsd.org Subject: PAM & LDAP in FreeBSD Message-ID: <19990715200336.A15050@fisicc-ufm.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG While trying to use the pam_ldap module available from www.padl.com I discovered the following problem. although the module authenticates just fine (using openldap) the login program fails to permit logins. I traced the problem to login.c --- the following code is from login.c my questions are at the bottom. **************************************************************************** pwd = getpwnam(username); --------- at this point pwd == NULL due to the fact that the user --------- does not exist on the local passwd database... see below /* * if we have a valid account name, and it doesn't have a * password, or the -f option was specified and the caller * is root or the caller isn't changing their uid, don't * authenticate. */ if (pwd != NULL) { if (pwd->pw_uid == 0) rootlogin = 1; if (fflag && (uid == (uid_t)0 || uid == (uid_t)pwd->pw_uid)) { /* already authenticated */ break; } else if (pwd->pw_passwd[0] == '\0') { if (!rootlogin || rootok) { /* pretend password okay */ rval = 0; goto ttycheck; } } } fflag = 0; (void)setpriority(PRIO_PROCESS, 0, -4); #ifndef NO_PAM /* * Try to authenticate using PAM. If a PAM system error * occurs, perhaps because of a botched configuration, * then fall back to using traditional Unix authentication. */ if ((rval = auth_pam()) == -1) ------------- This returns PAM_SUCCESS since the pam_ldap module has ------------- successfully identified and authenticated the user. #endif /* NO_PAM */ rval = auth_traditional(); (void)setpriority(PRIO_PROCESS, 0, 0); #ifndef NO_PAM /* * PAM authentication may have changed "pwd" to the * entry for the template user. Check again to see if * this is a root login after all. */ if (pwd != NULL && pwd->pw_uid == 0) rootlogin = 1; #endif /* NO_PAM */ ttycheck: /* * If trying to log in as root without Kerberos, * but with insecure terminal, refuse the login attempt. */ ------------- This next if is the problem: pwd == NULL from above, ------------- and the user doesn't get in. if (pwd && !rval) { if (rootlogin && !rootok) refused(NULL, "NOROOT", 0); else /* valid password & authenticated */ break; } (void)printf("Login incorrect\n"); failures++; **************************************************************************** 1. what would be the right way to fix this? 2. after the user successfully logs in he still won't have an entry in the /etc/passwd database, so all syscalls having to do with identifying the user will fail... how can I have these funcions get their info from LDAP? I'm willing to patch and submit these programs, but would like some feedback about the right way to integrate this. I checked with a friend who uses linux, and it appears linux doesn't have this problem since they use the /etc/nsswithc.conf to tell the system where to get info from. The nsswitch (resolver?) thing seems to understand ldap. Thanks folks, -Oscar -- For PGP Public Key: finger obonilla@fisicc-ufm.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 7:54:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from asa.co.uk (mailgate.asa.co.uk [195.173.171.146]) by hub.freebsd.org (Postfix) with ESMTP id C1CB114C01 for ; Fri, 16 Jul 1999 07:54:36 -0700 (PDT) (envelope-from sean.witham@asa.co.uk) Received: from mailgate.asa.co.uk ([195.173.171.146] helo=bentley.asa.co.uk) by asa.co.uk with esmtp (Exim 2.05 #2) id 1159Ib-0005hY-00; Fri, 16 Jul 1999 15:49:17 +0100 Received: from cooch.asa.co.uk ([193.195.233.4] helo=asa.co.uk) by bentley.asa.co.uk with esmtp (Exim 2.05 #3) id 1159Gv-0005hG-00; Fri, 16 Jul 1999 15:47:33 +0100 Message-ID: <378F458F.4BEEB674@asa.co.uk> Date: Fri, 16 Jul 1999 15:45:35 +0100 From: Sean Witham X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "Daniel C. Sobral" Cc: Garance A Drosihn , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907132346.TAA13780@bikini.ihack.net> <378CCB7D.AD8BC57B@newsguy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel C. Sobral" wrote: > > It would be nice to have a way to indicate that, a la SIGDANGER. > > Ok, everybody is avoiding this, so I'll comment. Yes, this would be > interesting, and a good implementation will very probably be > committed. *BUT*, this is not as useful as it seems. Since the > correct solution is buy more memory/increase swap (correct solution > for our target markets, anyway), there is little incentive to > implement it. > > So, I think people who can answer the above is thinking like "Well, > it is useful, but it's not useful enough for me to spend my time on > it, and I'm sure as hell don't want to write mini-papers on why it's > not that useful". > For those who wish to develop code for safety related systems that is not good enough. They have to prove that all code can handle the degradation of resources gracefully. Such code relies on guaranteed memory allocations or in the very least warnings of memory shortage and prioritized allocations. So the least important sub-systems die first. --Sean To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 9: 6:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id AC171156A8 for ; Fri, 16 Jul 1999 09:06:14 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA19963; Fri, 16 Jul 1999 09:03:10 -0700 (PDT) (envelope-from dillon) Date: Fri, 16 Jul 1999 09:03:10 -0700 (PDT) From: Matthew Dillon Message-Id: <199907161603.JAA19963@apollo.backplane.com> To: Sean Witham Cc: "Daniel C. Sobral" , Garance A Drosihn , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907132346.TAA13780@bikini.ihack.net> <378CCB7D.AD8BC57B@newsguy.com> <378F458F.4BEEB674@asa.co.uk> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :For those who wish to develop code for safety related systems that is :not good enough. They have to prove that all code can handle the :degradation :of resources gracefully. Such code relies on guaranteed memory :allocations :or in the very least warnings of memory shortage and prioritized :allocations. :So the least important sub-systems die first. : :--Sean I'm sorry, but when you write code for a safety related system you do not dynamically allocate memory at all. It's all essentially static. There is no issue with the memory resource. Besides, none of the BSD's are certified for any of that stuff that I know of. What's next: A space shot? These what-if scenarios are getting ridiculous. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 9: 6:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mail1.its.rpi.edu (mail1.its.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id D007B156BF; Fri, 16 Jul 1999 09:06:19 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail1.its.rpi.edu (8.8.8/8.8.6) with ESMTP id MAA22734; Fri, 16 Jul 1999 12:04:09 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <199907160452.VAA15530@apollo.backplane.com> References: Date: Fri, 16 Jul 1999 12:04:08 -0400 To: Matthew Dillon , "Brian F. Feldman" From: Garance A Drosihn Subject: Re: Swap overcommit Cc: freebsd-hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 9:52 PM -0700 7/15/99, Matthew Dillon wrote: >:> ... How many programmers bother to even *clear* errno before >:> making these calls (since some system calls do not set errno >: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >:> if it already non-zero). Virtually nobody. >: ^^^^^^^^^^^^^^^^^^^^^^^ >: >:Erm... WTF?!?! If so, why the HELL are we doing that?!? > > No, wait, I got that wrong I think. > > Oh yah, I remember now. Hmm. How odd. I came across a case > where read() could return -1 and not set errno properly if > errno was already set, but a perusal of the kernel code seems > to indicate that this can't happen. Very weird. For what it's worth, I know I've run into situations where errno had to be cleared before calling some system routine (but I don't think it was read, and I am sure it wasn't on freebsd). As I remember it, it was some case where "sysrtn1" called another system routine (and you would be calling "sysrtn1"). If the call to the inner system routine failed, then the inner routine would set errno and "sysrtn" would return it's own error. However, "sysrtn1" would return the SAME error in some other circumstances, circumstances which did not set errno. So, if you wanted to check errno when you got an error return from "sysrtn1", you had to be sure to zero it out before calling "sysrtn1". This was a lesson taught after a long wild-goose chase trying to track down the wrong reason for an error-return from "sysrtn1" (whatever that routine was...), because we had NOT zeroed out errno first. --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 9:26:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from border.dreamworks.com (dreamworks.com [209.179.64.2]) by hub.freebsd.org (Postfix) with SMTP id 38C8414C4F for ; Fri, 16 Jul 1999 09:26:36 -0700 (PDT) (envelope-from abs@anim.dreamworks.com) Received: from cynic.anim.dreamworks.com by border.dreamworks.com via smtpd (for hub.FreeBSD.ORG [204.216.27.18]) with SMTP; 16 Jul 1999 16:26:37 UT Received: from localhost (abs@localhost) by cynic.anim.dreamworks.com (8.8.8+Sun/8.8.8) with ESMTP id JAA02966; Fri, 16 Jul 1999 09:21:51 -0700 (PDT) X-Authentication-Warning: cynic.anim.dreamworks.com: abs owned process doing -bs Date: Fri, 16 Jul 1999 09:21:50 -0700 (PDT) From: David Brownlee To: Matthew Dillon Cc: Sean Witham , "Daniel C. Sobral" , Garance A Drosihn , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) In-Reply-To: <199907161603.JAA19963@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 16 Jul 1999, Matthew Dillon wrote: > I'm sorry, but when you write code for a safety related system you > do not dynamically allocate memory at all. It's all essentially static. > There is no issue with the memory resource. Besides, none of the BSD's are > certified for any of that stuff that I know of. > > What's next: A space shot? These what-if scenarios are getting > ridiculous. Well, NetBSD is slated to be used in the 'Space Acceleration Measurement System II', measuring the microgravity environment on the International Space Station using a distributed system based on several NetBSD/i386 boxes. Sometimes your 'what-if' senarios are others' standard operating procedures. David/absolute What _is_, what _should be_, and what _could be_ are all distinct. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 9:48:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 95F5514E07 for ; Fri, 16 Jul 1999 09:48:25 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA20156; Fri, 16 Jul 1999 09:45:47 -0700 (PDT) (envelope-from dillon) Date: Fri, 16 Jul 1999 09:45:47 -0700 (PDT) From: Matthew Dillon Message-Id: <199907161645.JAA20156@apollo.backplane.com> To: David Brownlee Cc: Sean Witham , "Daniel C. Sobral" , Garance A Drosihn , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : Well, NetBSD is slated to be used in the 'Space Acceleration : Measurement System II', measuring the microgravity environment on : the International Space Station using a distributed system based : on several NetBSD/i386 boxes. : : Sometimes your 'what-if' senarios are others' standard operating : procedures. : : David/absolute : : What _is_, what _should be_, and what _could be_ are all distinct. Ummm... this doesn't sound like a critical system to me. It sounds like an experiment. None of the BSD's (nor NT, nor any other complex general purpose operating system) are certified for critical systems in space. The reason is simple: None of these operating systems can deal with memory faults caused by radiation. You might see it for internal communications or non-critical sensing, but you aren't going to see it for external communications or thruster control. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 10: 0: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from border.dreamworks.com (dreamworks.com [209.179.64.2]) by hub.freebsd.org (Postfix) with SMTP id 1E6B914E31 for ; Fri, 16 Jul 1999 09:59:58 -0700 (PDT) (envelope-from ahorn@anim.dreamworks.com) Received: from mail.anim.dreamworks.com by border.dreamworks.com via smtpd (for hub.FreeBSD.ORG [204.216.27.18]) with SMTP; 16 Jul 1999 16:59:59 UT Received: from juice.anim.dreamworks.com (ahorn@juice.anim.dreamworks.com [172.16.20.37]) by mail.anim.dreamworks.com (8.8.8/8.8.8) with SMTP id JAA28212; Fri, 16 Jul 1999 09:55:33 -0700 (PDT) Received: from localhost by juice.anim.dreamworks.com via ESMTP (950413.SGI.8.6.12/940406.SGI) id JAA01744; Fri, 16 Jul 1999 09:56:59 -0700 Date: Fri, 16 Jul 1999 09:56:57 -0700 From: "Alan C. Horn" To: Matthew Dillon Cc: David Brownlee , Sean Witham , "Daniel C. Sobral" , Garance A Drosihn , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) In-Reply-To: <199907161645.JAA20156@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 16 Jul 1999, Matthew Dillon wrote: > >: Well, NetBSD is slated to be used in the 'Space Acceleration >: Measurement System II', measuring the microgravity environment on >: the International Space Station using a distributed system based >: on several NetBSD/i386 boxes. >: >: Sometimes your 'what-if' senarios are others' standard operating >: procedures. >: >: David/absolute >: >: What _is_, what _should be_, and what _could be_ are all distinct. > > Ummm... this doesn't sound like a critical system to me. It sounds like > an experiment. > It's probably an awfully expensive experiment (putting things into space is not cheap) From a financial viewpoint that may be considered critical. Cheers, Al -- Alan Horn - Sysadmin - Dreamworks (+1 818 695 6256) - ahorn@anim.dreamworks.com I am Connor MacLeod of the Clan MacLeod. I was born in 1518 in the village of Glenfinnan on the shores of Loch Sheil, and I am immortal. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 10:18: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 8F05314E34 for ; Fri, 16 Jul 1999 10:18:01 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id NAA19250; Fri, 16 Jul 1999 13:16:40 -0400 (EDT) Date: Fri, 16 Jul 1999 13:16:40 -0400 (EDT) From: Daniel Eischen Message-Id: <199907161716.NAA19250@pcnet1.pcnet.com> To: dillon@apollo.backplane.com, sean.witham@asa.co.uk Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Cc: dcs@newsguy.com, drosih@rpi.edu, freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm sorry, but when you write code for a safety related system you > do not dynamically allocate memory at all. It's all essentially static. > There is no issue with the memory resource. Besides, none of the BSD's are > certified for any of that stuff that I know of. Sometimes it's not feasible to statically allocate memory. You dynamically allocate all the memory you need at program initialization (and no, we don't want to manage a pool of memory ourselves - that's what the OS is for). Note that languages such as Ada raise exceptions when memory allocation fails. The underlying run-time relies on malloc returning null in order to raise an exception. Normally, programs written in Ada take great care to gracefully handle these exceptions. All the C programs that we've ever written also take great care in handling NULL returns from malloc. I have no problem with overcommit, but I can see the need that some folks have for turning it off. If you don't want to write the code to allow this, that's fine - you don't want/need it, so why should you? But if other folks see a need for it, let _them_ write the hooks for it :-) Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 10:42:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 7DA2114BFE for ; Fri, 16 Jul 1999 10:42:44 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA20451; Fri, 16 Jul 1999 10:42:28 -0700 (PDT) (envelope-from dillon) Date: Fri, 16 Jul 1999 10:42:28 -0700 (PDT) From: Matthew Dillon Message-Id: <199907161742.KAA20451@apollo.backplane.com> To: Daniel Eischen Cc: sean.witham@asa.co.uk, dcs@newsguy.com, drosih@rpi.edu, freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907161716.NAA19250@pcnet1.pcnet.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> I'm sorry, but when you write code for a safety related system you :> do not dynamically allocate memory at all. It's all essentially static. :> There is no issue with the memory resource. Besides, none of the BSD's are :> certified for any of that stuff that I know of. : :Sometimes it's not feasible to statically allocate memory. You :dynamically allocate all the memory you need at program initialization :(and no, we don't want to manage a pool of memory ourselves - that's :what the OS is for). :... :Note that languages such as Ada raise exceptions when memory allocation :fails. The underlying run-time relies on malloc returning null in :order to raise an exception. Normally, programs written in Ada Simply set a resource limit. You are making the classic mistake of assuming that a fail-safe in the O.S. must be integrated all the way down into the user level when, in fact, it is simply a matter of setting a resource limit. When you are running an embedded system and have full control over the software being run, setting resource limits will do what you want. By doing so you are effectively managing the software modules on a module-by-module basis and not allowing one module to indirectly effect another. This is what you want to do in an embedded system: You do not want to create a situation where a failure in one module cascades into others. -Matt Matthew Dillon :take great care to gracefully handle these exceptions. All the C :programs that we've ever written also take great care in handling :NULL returns from malloc. : :I have no problem with overcommit, but I can see the need that :some folks have for turning it off. If you don't want to write :the code to allow this, that's fine - you don't want/need it, :so why should you? But if other folks see a need for it, let :_them_ write the hooks for it :-) : :Dan Eischen :eischen@vigrid.com : To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 11:16: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 130C614C11 for ; Fri, 16 Jul 1999 11:16:07 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id OAA65884; Fri, 16 Jul 1999 14:14:13 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Fri, 16 Jul 1999 14:14:13 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Matthew Dillon Cc: Daniel Eischen , sean.witham@asa.co.uk, dcs@newsguy.com, drosih@rpi.edu, freebsd-hackers@FreeBSD.org, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) In-Reply-To: <199907161742.KAA20451@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Can we kill this thread already? This resolves nothing. The only good to come of this is all of the nice doc-proj input Matt is providing (and providing well, I might add.) There is no point that hasn't been rehashed a dozen times over, and you (the ones who want overcommitting turned off) are not helping the S/N ratio. Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 11:34:25 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 0545214BF9 for ; Fri, 16 Jul 1999 11:34:22 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id LAA20104; Fri, 16 Jul 1999 11:31:09 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id LAA01465; Fri, 16 Jul 1999 11:31:09 -0700 Received: from softweyr.com (dyn2.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA06960; Fri, 16 Jul 99 11:31:03 PDT Message-Id: <378F7A67.F4C28EEB@softweyr.com> Date: Fri, 16 Jul 1999 12:31:03 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Mark Newton Cc: Mike Smith , hackers@FreeBSD.ORG Subject: Re: matcd on an SB16 References: <199907160105.KAA07821@gizmo.internode.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mark Newton wrote: > > Mike Smith wrote: > > > > Is the matcd driver known to work on FreeBSD 3.2 ? If not, does anyone > > > have any estimate of the amount of effort that'd be required to fix it? > > > > It "works" for some definitions of "work". Firstly, there are three > > different CDROM interfaces that can be hung off an SB16; one is the > > Matsushita drive, there's also a Mutsumi interface (I don't think we > > support it) and a Sony interface (also, I believe, unsupported). > > Ghods, you're going through some old mail! [ and how was DEFCON, btw? :-) ] > > FWIW, the guy I was talking about embarked on a network install from > another machine with a CD-ROM drive and an NFS server; the network > install failed for slightly related reasons, having to do with the > idea the hardware in this box is generally crap. > > The disappointing thing is that Linux works on it, though :-/ Uh, no, that's the way it's supposed to be. They support every stupid dongle and widget on the planet, remember? ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 11:54:22 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dialup124.zpr.Uni-Koeln.DE (dialup124.zpr.Uni-Koeln.DE [134.95.219.124]) by hub.freebsd.org (Postfix) with ESMTP id F3BF1156C2; Fri, 16 Jul 1999 11:53:59 -0700 (PDT) (envelope-from se@dialup124.zpr.Uni-Koeln.DE) Received: (from se@localhost) by dialup124.zpr.Uni-Koeln.DE (8.9.3/8.9.3) id TAA01289; Fri, 16 Jul 1999 19:33:37 +0200 (CEST) (envelope-from se) Date: Fri, 16 Jul 1999 19:33:37 +0200 From: Stefan Esser To: Zhihui Zhang Cc: freebsd-hackers@FreeBSD.ORG, Stefan Esser Subject: Re: Help with PCI code understanding Message-ID: <19990716193337.A1213@dialup124.mi.uni-koeln.de> Reply-To: se@FreeBSD.ORG Mail-Followup-To: Zhihui Zhang , freebsd-hackers@FreeBSD.ORG References: <378E553B.E6C71B0B@cs.binghamton.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <378E553B.E6C71B0B@cs.binghamton.edu>; from Zhihui Zhang on Thu, Jul 15, 1999 at 05:40:12PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 1999-07-15 17:40 -0400, Zhihui Zhang wrote: > Can someone outline the initialization process of PCI devices in > FreeBSD? I know many of the basic stuff of PCI introduced in the book > "PCI System Architecture". I just want to know how each driver is > registered into some linker set and its probe routine gets called. In > other words, I want to know the major data structures and routines and > their relationship. I wonder if there is already a document somewhere. I'll explain what the PCI code in -stable (my code) does. There is a new device framework in -current, which emulates the old interfaces, but will require changes to device drivers for simplicity and full support of the newly offered features. For now, you can assume the PCI code as in -stable, which will continue to be supported for some more time, AFAIK ;-) If you are only interested in the PCI probe, then you best look at one of the small wrappers /sys/pci/if_ed_p.c or /sys/pci/if_lnc_p.c, for example. You provide the PCI code with a struct pci_device, that specifies the name of the driver, the address of the probe function, the address of the attach function, the address of a unit number counter and finally the address of a shutdown function (NULL in most drivers). The probe function receives as the first argument an opaque value, that is used to identify this particular device to the other PCI subroutines, and the PCI vendor and device ID as a 32 bit value as the second argument. The probe function returns a NULL pointer if the probe fails, a string that identifies the device in case of a match, or an empty string in case the device was recognized but should be silently ignored. The attach function receives the same first argument as probe, and the unit number to assign to thos device as the second argument. The unit number is not necessarily just one more than for the previous device attached by the PCI code. (There is support for "wired" devices, i.e. assignment of unit numbers to controllers in specified PCI slots, for example if you have several SCSI cards and do not want your controllers (and drives) be renumbered in case one card is not present or defective. But this is a little used and hidden feature ...) PCI devices can be compiled as modules and will be probed/attached exactly as explained above after being dynamically linked into the running kernel. Let me know if you have any further questions. Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 13:10:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from backup.af.speednet.com.au (af.speednet.com.au [202.135.206.244]) by hub.freebsd.org (Postfix) with ESMTP id 48FB8156B3 for ; Fri, 16 Jul 1999 13:10:02 -0700 (PDT) (envelope-from andyf@speednet.com.au) Received: from localhost (localhost [127.0.0.1]) by backup.zippynet.iol.net.au (8.9.3/8.9.3) with ESMTP id FAA99526; Sat, 17 Jul 1999 05:42:42 +1000 (EST) (envelope-from andyf@speednet.com.au) Date: Sat, 17 Jul 1999 05:42:42 +1000 (EST) From: Andy Farkas X-Sender: andyf@localhost To: hackers@FreeBSD.ORG Cc: Mark Newton Subject: Re: matcd on an SB16 In-Reply-To: <378F7A67.F4C28EEB@softweyr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 16 Jul 1999, Wes Peters wrote: > Mark Newton wrote: > > > > Is the matcd driver known to work on FreeBSD 3.2 ? If not, does anyone > > > > have any estimate of the amount of effort that'd be required to fix it? > > > > > > It "works" for some definitions of "work". Firstly, there are three > > > different CDROM interfaces that can be hung off an SB16; one is the > > > Matsushita drive, there's also a Mutsumi interface (I don't think we > > > support it) and a Sony interface (also, I believe, unsupported). > > It works for me... # uname -v FreeBSD 3.2-STABLE #0: Thu Jul 8 19:56:09 EST 1999 # dmesg ... matcd - Matsushita (Panasonic) CD-ROM Driver by FDIV, Version 1(26) 18-Oct-95 matcdc0 at 0x230-0x233 on isa matcdc0 Host interface type 0 matcd0: [CR-5625.00] ... sb0 at 0x220 irq 5 drq 1 on isa snd0: sbxvi0 at drq 5 on isa snd0: sbmidi0 at 0x330 on isa snd0: # mount ... /dev/matcd0a on /mnt (local, read-only) # dd if=/mnt/Media/previews/media/hw.mpg of=/dev/null 17500+1 records in 17500+1 records out 8960004 bytes transferred in 40.894391 secs (219101 bytes/sec) -- :{ andyf@speednet.com.au Andy Farkas System Administrator Speed Internet Services http://www.speednet.com.au/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 15:10: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mich.bolingbroke.com (mich.bolingbroke.com [206.253.250.210]) by hub.freebsd.org (Postfix) with ESMTP id 7793B14D01 for ; Fri, 16 Jul 1999 15:09:58 -0700 (PDT) (envelope-from ken@bolingbroke.com) Received: from localhost (ken@localhost) by mich.bolingbroke.com (8.9.3/8.9.3) with ESMTP id QAA21176 for ; Fri, 16 Jul 1999 16:08:41 -0600 (MDT) Date: Fri, 16 Jul 1999 15:08:41 -0700 (PDT) From: Ken Bolingbroke To: hackers@freebsd.org Subject: Benchmarking server app on FreeBSD Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm benchmarking the performance of a server application on various platforms. To do so, I've developed a program on FreeBSD 3.x to generate heavy loads. This program can, for example, generate 200 simultaneous connections to the server and process them all appropriately, and I have it running on a bunch of machines to simulate high load on the server. However, I'm running into an unexpected problem on a server running FreeBSD 3.2-RELEASE. If a single client opens 200 simultaneous connections to the FreeBSD server, all but 30 to 40 of those get an immediate "Connection refused". If a whole row of clients open 200 simultaneous connections each, they still get only 30 to 40 each, but the server is now accepting upwards of 200 connections all at once. This seems to indicate that it's not a server load question, but rather that the server will not accept more than ~40 connections at once from the same client. I've tried the same test using the FreeBSD clients against a Solaris server, and the Solaris server accepts all 200 connections from each client machine without refusing any connections, so I'm sure it's not on the client end. A fellow admin suggested that my load simulation program quite possibly looks like a SYN attack and FreeBSD might be rejecting it for that reason. Since Solaris doesn't have the same SYN attack protection, that would account for the difference. If this is the case, how would I disable the SYN attack protection for these tests? Or is it something else limiting FreeBSD? For reference, the FreeBSD server has a custom kernel compiles with MAXUSERS set to 512, and other performance enhancements I've gleaned off these lists. Thanks, Ken Bolingbroke hacker@bolingbroke.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 15:17: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id A53BD14D01 for ; Fri, 16 Jul 1999 15:17:03 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id PAA15030; Fri, 16 Jul 1999 15:16:46 -0700 (PDT) Message-Id: <199907162216.PAA15030@implode.root.com> To: Ken Bolingbroke Cc: hackers@FreeBSD.ORG Subject: Re: Benchmarking server app on FreeBSD In-reply-to: Your message of "Fri, 16 Jul 1999 15:08:41 PDT." From: David Greenman Reply-To: dg@root.com Date: Fri, 16 Jul 1999 15:16:46 -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG What do you have the listen queue limit set for? What is the kern.somaxconn sysctl variable set to? -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com >I'm benchmarking the performance of a server application on various >platforms. To do so, I've developed a program on FreeBSD 3.x to generate >heavy loads. This program can, for example, generate 200 simultaneous >connections to the server and process them all appropriately, and I have >it running on a bunch of machines to simulate high load on the server. > >However, I'm running into an unexpected problem on a server running >FreeBSD 3.2-RELEASE. If a single client opens 200 simultaneous >connections to the FreeBSD server, all but 30 to 40 of those get an >immediate "Connection refused". If a whole row of clients open 200 >simultaneous connections each, they still get only 30 to 40 each, but the >server is now accepting upwards of 200 connections all at once. This >seems to indicate that it's not a server load question, but rather that >the server will not accept more than ~40 connections at once from the same >client. > >I've tried the same test using the FreeBSD clients against a Solaris >server, and the Solaris server accepts all 200 connections from each >client machine without refusing any connections, so I'm sure it's not on >the client end. > >A fellow admin suggested that my load simulation program quite possibly >looks like a SYN attack and FreeBSD might be rejecting it for that reason. >Since Solaris doesn't have the same SYN attack protection, that would >account for the difference. > >If this is the case, how would I disable the SYN attack protection for >these tests? Or is it something else limiting FreeBSD? > >For reference, the FreeBSD server has a custom kernel compiles with >MAXUSERS set to 512, and other performance enhancements I've gleaned off >these lists. > >Thanks, > >Ken Bolingbroke >hacker@bolingbroke.com > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 15:44: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pop3-3.enteract.com (pop3-3.enteract.com [207.229.143.32]) by hub.freebsd.org (Postfix) with SMTP id 29C2D14DE4 for ; Fri, 16 Jul 1999 15:44:01 -0700 (PDT) (envelope-from dscheidt@enteract.com) Received: (qmail 17458 invoked from network); 16 Jul 1999 22:42:57 -0000 Received: from shell-3.enteract.com (dscheidt@207.229.143.42) by pop3-3.enteract.com with SMTP; 16 Jul 1999 22:42:57 -0000 Date: Fri, 16 Jul 1999 17:42:57 -0500 (CDT) From: David Scheidt To: "Daniel C. Sobral" Cc: freebsd-hackers@FreeBSD.ORG, tech-kern@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) In-Reply-To: <378EB49D.331D46DA@newsguy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 16 Jul 1999, Daniel C. Sobral wrote: > Technical follow-up: > > Contrary to what I previously said, a number of tests reveal that > Solaris, indeed, does not overcommit. All non-read only segments, Neither does HP/UX 10.x. (Haven't got an 11 box handy to check.) The memory allocation process is something like this: 1) reserve is allocated from a swap area. Preference is given to swap devices, even if a swap file system has a higher priority. 2) If there is no space on a swap device, swap is allocated from a swap filesystem, if one is configured. If there is nothing to be allocated in a swap filesystem, the kernel attempts to grow the swap file on a filesystem by swchunk (a tunable, default 2MB, I think). (Swap on filesystems starts at zero or swchunck, and is grown as needed up to the limit spec'd at swapon(1M) time.) 3) If this fails, either because there is no space on the file system, or the swapfile has reached its limit, memory (actual core) is allocated. The system tunable swapmem_on determines whether memory is used for swap reserve or not. Default is to use it. 4) If there isn't swap to reserve, the request fails, even if none of the reserved swap is used. The swapinfo(1M) man page makes this quite clear: + Requests for more paging space will fail when they cannot be satisfied by reserving device, file system, or memory paging, even if some of the reserved paging space is not yet in use. Thus it is possible for requests for more paging space to be denied when some, or even all, of the paging areas show zero usage - space in those areas is completely reserved. The upside of this is that if you do run out of swap, the kernel doesn't kill random processes. The downside is, I have seen 4GB boxes, with plenty of swap, run out with less than a gig of memory actually in use. Oh, and if you swap to a filesystem, you can fill it up, without actually using any of the space. I don't know which behaviors is more bogus. David Scheidt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 16:10:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from venus.GAIANET.NET (venus.GAIANET.NET [207.211.200.51]) by hub.freebsd.org (Postfix) with ESMTP id 8407014DE4 for ; Fri, 16 Jul 1999 16:10:44 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Received: from localhost (vince@localhost) by venus.GAIANET.NET (8.9.3/8.9.3) with ESMTP id QAA09607; Fri, 16 Jul 1999 16:10:16 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Date: Fri, 16 Jul 1999 16:10:16 -0700 (PDT) From: Vincent Poy To: Bill Paul Cc: crypt0genic , hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? In-Reply-To: <199907161301.JAA20604@skynet.ctr.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Speaking about ethernet performance, doesn't the quality of cable affect it too? I noticed that there are cables that are 350Mhz and higher over the standard CAT5 100Mhz cables. Has anyone used the higher frequency cables and gotten any better results? And generally for CAT5 cable, is there a difference in quality between BerkTek and Belden? Cheers, Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 16:28: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id CB5FF14F00 for ; Fri, 16 Jul 1999 16:28:05 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA22115; Fri, 16 Jul 1999 16:27:14 -0700 (PDT) (envelope-from dillon) Date: Fri, 16 Jul 1999 16:27:14 -0700 (PDT) From: Matthew Dillon Message-Id: <199907162327.QAA22115@apollo.backplane.com> To: Vincent Poy Cc: Bill Paul , crypt0genic , hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : Speaking about ethernet performance, doesn't the quality of cable :affect it too? I noticed that there are cables that are 350Mhz and higher :over the standard CAT5 100Mhz cables. Has anyone used the higher :frequency cables and gotten any better results? And generally for CAT5 :cable, is there a difference in quality between BerkTek and Belden? : : :Cheers, :Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ :Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] 10BaseT is 10BaseT, as long as it is in spec it is not going to perform any better or worse based on the quality of the cable. So if standard Cat5 cable works for you, getting a higher grade cable is not going to make it work better. Same with 100BaseT and 1000BaseT. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 16:30: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from console.prisa.com (gatekeeper.prisa.com [204.94.67.66]) by hub.freebsd.org (Postfix) with SMTP id 5CB5D14E78 for ; Fri, 16 Jul 1999 16:29:59 -0700 (PDT) (envelope-from nschein@prisa.com) Received: from nschein ([172.16.129.137]) by console.prisa.com (8.6.12/8.6.12) with SMTP id QAA01395 for ; Fri, 16 Jul 1999 16:37:04 -0700 From: "Nathaniel Schein" To: "Freebsd-Hackers" Subject: FW: Mail relay Date: Fri, 16 Jul 1999 16:34:18 -0700 Message-ID: <004401becfe3$b939eea0$898110ac@nschein.prisa.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -----Original Message----- From: Nathaniel Schein [mailto:nschein@prisa.com] Sent: Friday, July 16, 1999 4:27 PM To: Owner-Freebsd-Questions Subject: Mail relay The sendmail.cf file comes set by default to deny mail relay. What changes must one make to enable relay? Nathaniel Schein To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 16:34:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from pau-amma.whistle.com (pau-amma.whistle.com [207.76.205.64]) by hub.freebsd.org (Postfix) with ESMTP id 5CDC614E78 for ; Fri, 16 Jul 1999 16:34:22 -0700 (PDT) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.9.2/8.9.2) id QAA01782; Fri, 16 Jul 1999 16:34:21 -0700 (PDT) Date: Fri, 16 Jul 1999 16:34:21 -0700 (PDT) From: David Wolfskill Message-Id: <199907162334.QAA01782@pau-amma.whistle.com> To: freebsd-hackers@FreeBSD.ORG, nschein@prisa.com Subject: Re: FW: Mail relay In-Reply-To: <004401becfe3$b939eea0$898110ac@nschein.prisa.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >From: "Nathaniel Schein" >Date: Fri, 16 Jul 1999 16:34:18 -0700 >The sendmail.cf file comes set by default to deny mail relay. What changes >must one make to enable relay? See /usr/src/contrib/sendmail/cf/README, especially lines 763 - 809. Cheers, david -- David Wolfskill dhw@whistle.com UNIX System Administrator voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 16:43:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from venus.GAIANET.NET (venus.GAIANET.NET [207.211.200.51]) by hub.freebsd.org (Postfix) with ESMTP id 8193914EF0 for ; Fri, 16 Jul 1999 16:43:17 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Received: from localhost (vince@localhost) by venus.GAIANET.NET (8.9.3/8.9.3) with ESMTP id QAA09772; Fri, 16 Jul 1999 16:39:32 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Date: Fri, 16 Jul 1999 16:39:32 -0700 (PDT) From: Vincent Poy To: Matthew Dillon Cc: Bill Paul , crypt0genic , hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? In-Reply-To: <199907162327.QAA22115@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 16 Jul 1999, Matthew Dillon wrote: > : Speaking about ethernet performance, doesn't the quality of cable > :affect it too? I noticed that there are cables that are 350Mhz and higher > :over the standard CAT5 100Mhz cables. Has anyone used the higher > :frequency cables and gotten any better results? And generally for CAT5 > :cable, is there a difference in quality between BerkTek and Belden? > > 10BaseT is 10BaseT, as long as it is in spec it is not going to perform > any better or worse based on the quality of the cable. So if standard > Cat5 cable works for you, getting a higher grade cable is not going > to make it work better. Same with 100BaseT and 1000BaseT. Good point but I think it's like how much of 100Mhz a 100BaseTX can push. If it pushes 100%, then it might be wise to have a little more room for overhead. Kinda like a car, better to have reserve power when you need it then pushing it to the max. In regards to 1000BaseT, I thought there was no standards for that yet, atleast all the Gigabit stuff is all fiber and not copper. Quality of cable does matter, atleast in high-end audio/video it does and I'm sure data would be more picky than human ears. Cheers, Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 16:44:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from wenet.net (pm3-45.ppp.wenet.net [206.15.85.45]) by hub.freebsd.org (Postfix) with ESMTP id 7ACA114F00 for ; Fri, 16 Jul 1999 16:44:10 -0700 (PDT) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@localhost) by wenet.net (8.9.3/8.9.1) with ESMTP id OAA01099; Fri, 16 Jul 1999 14:20:31 -0700 (PDT) (envelope-from garbanzo@hooked.net) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Fri, 16 Jul 1999 14:20:31 -0700 (PDT) From: Alex Zepeda To: Wes Peters Cc: hackers@FreeBSD.ORG Subject: Re: matcd on an SB16 In-Reply-To: <378F7A67.F4C28EEB@softweyr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 16 Jul 1999, Wes Peters wrote: > Uh, no, that's the way it's supposed to be. They support every stupid > dongle and widget on the planet, remember? ;^) Execpt this dongle happens to be reasonably useful and common, and ignored by FreeBSD :^) - alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 16:44:23 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 0D3BF14EF0 for ; Fri, 16 Jul 1999 16:44:19 -0700 (PDT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 17 Jul 1999 00:44:16 +0100 (BST) Date: Sat, 17 Jul 1999 00:44:15 +0100 From: David Malone To: Ken Bolingbroke Cc: hackers@freebsd.org Subject: Re: Benchmarking server app on FreeBSD Message-ID: <19990717004415.A5800@walton.maths.tcd.ie> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Ken Bolingbroke on Fri, Jul 16, 1999 at 03:08:41PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Jul 16, 1999 at 03:08:41PM -0700, Ken Bolingbroke wrote: > However, I'm running into an unexpected problem on a server running > FreeBSD 3.2-RELEASE. If a single client opens 200 simultaneous > connections to the FreeBSD server, all but 30 to 40 of those get an > immediate "Connection refused". Does the service run through inetd? Could you be tickling its rate limiting per IP stuff? David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 16:56: 1 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id CB56F14EF0 for ; Fri, 16 Jul 1999 16:55:59 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA22402; Fri, 16 Jul 1999 16:55:29 -0700 (PDT) (envelope-from dillon) Date: Fri, 16 Jul 1999 16:55:29 -0700 (PDT) From: Matthew Dillon Message-Id: <199907162355.QAA22402@apollo.backplane.com> To: Vincent Poy Cc: Bill Paul , crypt0genic , hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : Good point but I think it's like how much of 100Mhz a 100BaseTX :can push. If it pushes 100%, then it might be wise to have a little more :room for overhead. Kinda like a car, better to have reserve power when :you need it then pushing it to the max. In regards to 1000BaseT, I :thought there was no standards for that yet, atleast all the Gigabit stuff :is all fiber and not copper. Quality of cable does matter, atleast in :high-end audio/video it does and I'm sure data would be more picky than :human ears. : : :Cheers, :Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ :Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] The copper gigabit standard isn't out yet, but I was under the impression that they were pretty close. In regards to audio/video verses ethernet, you have to remember that audio and video are *analog*, not digital. The cable quality matters for analog, but it only needs to be "good enough" for digital. If you don't get any bit errors (and you shouldn't) then a better cable is not going to make a difference. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 17: 0:16 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from venus.GAIANET.NET (venus.GAIANET.NET [207.211.200.51]) by hub.freebsd.org (Postfix) with ESMTP id D47B214D01 for ; Fri, 16 Jul 1999 16:59:41 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Received: from localhost (vince@localhost) by venus.GAIANET.NET (8.9.3/8.9.3) with ESMTP id QAA09904; Fri, 16 Jul 1999 16:58:26 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Date: Fri, 16 Jul 1999 16:58:26 -0700 (PDT) From: Vincent Poy To: Matthew Dillon Cc: Bill Paul , crypt0genic , hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? In-Reply-To: <199907162355.QAA22402@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 16 Jul 1999, Matthew Dillon wrote: > : Good point but I think it's like how much of 100Mhz a 100BaseTX > :can push. If it pushes 100%, then it might be wise to have a little more > :room for overhead. Kinda like a car, better to have reserve power when > :you need it then pushing it to the max. In regards to 1000BaseT, I > :thought there was no standards for that yet, atleast all the Gigabit stuff > :is all fiber and not copper. Quality of cable does matter, atleast in > :high-end audio/video it does and I'm sure data would be more picky than > :human ears. > > The copper gigabit standard isn't out yet, but I was under the impression > that they were pretty close. > > In regards to audio/video verses ethernet, you have to remember that > audio and video are *analog*, not digital. The cable quality matters > for analog, but it only needs to be "good enough" for digital. If you > don't get any bit errors (and you shouldn't) then a better cable is not > going to make a difference. Actually, I was referring to *digital* Audio cables like those used for CD Transports to Digital/Analog convertors such as Kimber Kable would be higher grade compared to Monster Cable. You're correct about the bit errors though. Cheers, Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 17: 7:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 805C814F94 for ; Fri, 16 Jul 1999 17:07:16 -0700 (PDT) (envelope-from louie@whizzo.transsys.com) Received: from whizzo.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.9.3/8.9.1) with ESMTP id UAA75267; Fri, 16 Jul 1999 20:05:32 -0400 (EDT) (envelope-from louie@whizzo.transsys.com) Message-Id: <199907170005.UAA75267@whizzo.transsys.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Matthew Dillon Cc: Vincent Poy , Bill Paul , crypt0genic , hackers@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: poor ethernet performance? References: <199907162355.QAA22402@apollo.backplane.com> In-reply-to: Your message of "Fri, 16 Jul 1999 16:55:29 PDT." <199907162355.QAA22402@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 16 Jul 1999 20:05:32 -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > : Good point but I think it's like how much of 100Mhz a 100BaseTX > :can push. If it pushes 100%, then it might be wise to have a little more > :room for overhead. Kinda like a car, better to have reserve power when > :you need it then pushing it to the max. In regards to 1000BaseT, I > :thought there was no standards for that yet, atleast all the Gigabit stuff > :is all fiber and not copper. Quality of cable does matter, atleast in > :high-end audio/video it does and I'm sure data would be more picky than > :human ears. > : > : > :Cheers, > :Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ > :Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] > > The copper gigabit standard isn't out yet, but I was under the impression > that they were pretty close. > > In regards to audio/video verses ethernet, you have to remember that > audio and video are *analog*, not digital. The cable quality matters > for analog, but it only needs to be "good enough" for digital. If you > don't get any bit errors (and you shouldn't) then a better cable is not > going to make a difference. One of the big deals with the different grades of cable is the degree of crosstalk between the transmit and receive pairs in the cable sheath. When you're talking about Category-3 or Category-5 cable systems, this INCLUDES the connectors, patch panels, cross-connect blocks and cross-connect cables. For instance, you have to work pretty hard to do better than 10Base-T with a Category-3 wiring system if you have type 66 punch blocks because of the impedence bump and crosstalk issues. Same sort of things apply at 100base-T and Category-5 cable systems. Using gold-plated "Monster Cable" is just pissing away money of the other components are also up to the same level of "quality" (har, har). And, as Matt said, if you're not getting CRC errors then it's good enough, and there's no point spending money to get better wire. louie (who uses #12 ROMEX cable for speaker wire.) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 17:14: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from venus.GAIANET.NET (venus.GAIANET.NET [207.211.200.51]) by hub.freebsd.org (Postfix) with ESMTP id 4E7DE14C2B for ; Fri, 16 Jul 1999 17:13:59 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Received: from localhost (vince@localhost) by venus.GAIANET.NET (8.9.3/8.9.3) with ESMTP id RAA10001; Fri, 16 Jul 1999 17:13:30 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Date: Fri, 16 Jul 1999 17:13:30 -0700 (PDT) From: Vincent Poy To: "Louis A. Mamakos" Cc: Matthew Dillon , Bill Paul , crypt0genic , hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? In-Reply-To: <199907170005.UAA75267@whizzo.transsys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 16 Jul 1999, Louis A. Mamakos wrote: > > : Good point but I think it's like how much of 100Mhz a 100BaseTX > > :can push. If it pushes 100%, then it might be wise to have a little more > > :room for overhead. Kinda like a car, better to have reserve power when > > :you need it then pushing it to the max. In regards to 1000BaseT, I > > :thought there was no standards for that yet, atleast all the Gigabit stuff > > :is all fiber and not copper. Quality of cable does matter, atleast in > > :high-end audio/video it does and I'm sure data would be more picky than > > :human ears. > > > > The copper gigabit standard isn't out yet, but I was under the impression > > that they were pretty close. > > > > In regards to audio/video verses ethernet, you have to remember that > > audio and video are *analog*, not digital. The cable quality matters > > for analog, but it only needs to be "good enough" for digital. If you > > don't get any bit errors (and you shouldn't) then a better cable is not > > going to make a difference. > > One of the big deals with the different grades of cable is the degree of > crosstalk between the transmit and receive pairs in the cable sheath. > When you're talking about Category-3 or Category-5 cable systems, this > INCLUDES the connectors, patch panels, cross-connect blocks and cross-connect > cables. Yep, everything in the chain counts. > For instance, you have to work pretty hard to do better than 10Base-T > with a Category-3 wiring system if you have type 66 punch blocks > because of the impedence bump and crosstalk issues. Same sort of things > apply at 100base-T and Category-5 cable systems. Using gold-plated > "Monster Cable" is just pissing away money of the other components are > also up to the same level of "quality" (har, har). I wouldn't rate Monster Cable as really high quality since it seems like their stuff is more marketing then the true value. > And, as Matt said, if you're not getting CRC errors then it's good > enough, and there's no point spending money to get better wire. I know, I'm just wondering how did they get more frequency out of wire of the same size. I can understand it if the wire was a larger guage. > louie > (who uses #12 ROMEX cable for speaker wire.) Cheers, Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 18:46:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mycenae.ilion.eu.org (mycenae.ilion.eu.org [203.35.206.129]) by hub.freebsd.org (Postfix) with ESMTP id 4B12514F64 for ; Fri, 16 Jul 1999 18:46:40 -0700 (PDT) (envelope-from patrykz@mycenae.ilion.eu.org) Received: from mycenae.ilion.eu.org (patrykz@localhost [127.0.0.1]) by mycenae.ilion.eu.org (8.9.2/8.9.2) with ESMTP id LAA37200; Sat, 17 Jul 1999 11:46:33 +1000 (EST) (envelope-from patrykz@mycenae.ilion.eu.org) Message-Id: <199907170146.LAA37200@mycenae.ilion.eu.org> To: Garance A Drosihn Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Swap overcommit In-reply-to: Your message of "Fri, 16 Jul 1999 12:04:08 -0400." Date: Sat, 17 Jul 1999 11:46:33 +1000 From: Patryk Zadarnowski Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > At 9:52 PM -0700 7/15/99, Matthew Dillon wrote: > >:> ... How many programmers bother to even *clear* errno before > >:> making these calls (since some system calls do not set errno > >: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >:> if it already non-zero). Virtually nobody. > >: ^^^^^^^^^^^^^^^^^^^^^^^ > >: > >:Erm... WTF?!?! If so, why the HELL are we doing that?!? > > > > No, wait, I got that wrong I think. > > > > Oh yah, I remember now. Hmm. How odd. I came across a case > > where read() could return -1 and not set errno properly if > > errno was already set, but a perusal of the kernel code seems > > to indicate that this can't happen. Very weird. > > For what it's worth, I know I've run into situations where errno > had to be cleared before calling some system routine (but I don't > think it was read, and I am sure it wasn't on freebsd). Ahem, I'm not sure what that's got to do with swap overcommit, but anything to distract this thread is a good thing ;) The correct thing to do with errno is to clear it before a call IFF you are going to check its value on return from the call, simply because the calls NEVER don't clear errno on success, but set/change it on error. Every standard I've seen requires this behaviour quite explicitely, and I'm preaty sure it's documented someone in BSD man pages too. It's definitely correct if you look at the syscall stub code in libc. And yes, almost all the code I've seen does the right thing when it comes to handling errno, including checking its value on an error from system call (ususally by calling warn() or err()), so the ``Virtually nobody'' argument above is rather misguided. If something in libc READS errno without clearing it (other than err/warr functions that is ;), it's badly broken and should be fixed in the library, not in the user code. IMHO. patryk. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 19:15:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 5392214F43 for ; Fri, 16 Jul 1999 19:15:33 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA25916; Fri, 16 Jul 1999 19:15:31 -0700 (PDT) (envelope-from dillon) Date: Fri, 16 Jul 1999 19:15:31 -0700 (PDT) From: Matthew Dillon Message-Id: <199907170215.TAA25916@apollo.backplane.com> To: Vincent Poy Cc: Bill Paul , crypt0genic , hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : Actually, I was referring to *digital* Audio cables like those :used for CD Transports to Digital/Analog convertors such as Kimber Kable :would be higher grade compared to Monster Cable. You're correct about the :bit errors though. Digital is digital. Either it works or it doesn't. -Matt Matthew Dillon :Cheers, :Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 19:23:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 5C98E14F3F for ; Fri, 16 Jul 1999 19:23:18 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA25948; Fri, 16 Jul 1999 19:20:44 -0700 (PDT) (envelope-from dillon) Date: Fri, 16 Jul 1999 19:20:44 -0700 (PDT) From: Matthew Dillon Message-Id: <199907170220.TAA25948@apollo.backplane.com> To: Vincent Poy Cc: "Louis A. Mamakos" , Bill Paul , crypt0genic , hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : I know, I'm just wondering how did they get more frequency out of :wire of the same size. I can understand it if the wire was a larger :guage. For twisted pair, Less power == less crosstalk. Plus the higher bandwidth transceivers use better receivers and better pre-attenuation of the signal. I'm not sure what the gigabit copper ethernet people are doing, but there are other ways as well. Basic ethernet uses baseband which is quite noisy even with the preattenuation, so there was lots of room to go faster. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 20:11:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from venus.GAIANET.NET (venus.GAIANET.NET [207.211.200.51]) by hub.freebsd.org (Postfix) with ESMTP id E60CB14FD9 for ; Fri, 16 Jul 1999 20:11:03 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Received: from localhost (vince@localhost) by venus.GAIANET.NET (8.9.3/8.9.3) with ESMTP id UAA10774; Fri, 16 Jul 1999 20:08:38 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Date: Fri, 16 Jul 1999 20:08:38 -0700 (PDT) From: Vincent Poy To: Matthew Dillon Cc: "Louis A. Mamakos" , Bill Paul , crypt0genic , hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? In-Reply-To: <199907170220.TAA25948@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 16 Jul 1999, Matthew Dillon wrote: > : I know, I'm just wondering how did they get more frequency out of > :wire of the same size. I can understand it if the wire was a larger > :guage. > > For twisted pair, Less power == less crosstalk. Plus the higher > bandwidth transceivers use better receivers and better pre-attenuation > of the signal. Cross talk is only one of the variables I think... There is balancing and ACR and how well it can keep a true 100 Ohms to the cable. > I'm not sure what the gigabit copper ethernet people are doing, but there > are other ways as well. I wonder if any Gigabit ethernet cards exist that uses UTP because everything seems to be pointing to the fiber direction. > Basic ethernet uses baseband which is quite noisy even with the > preattenuation, so there was lots of room to go faster. Yep, it would have been nice if the original spec was shielded but anything shielded would have a degrade in signal... It's the insultaion whether it is PVC, Teflon or even the new air chambers introduced by Matthew Bond at Tara Labs using Regtangular Solid Core cable capable of handling 2.5Ghz. Cheers, Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jul 16 23:18:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from storm.digital-rain.com (storm.digital-rain.com [204.244.71.70]) by hub.freebsd.org (Postfix) with ESMTP id A949A14D1A for ; Fri, 16 Jul 1999 23:18:34 -0700 (PDT) (envelope-from tim@storm.digital-rain.com) Received: from agamemnon.melonville.net (dial-line60.digital-rain.com [204.244.94.60]) by storm.digital-rain.com (8.9.1/8.9.1) with SMTP id XAA07860 for ; Fri, 16 Jul 1999 23:16:25 -0700 (PDT) Message-Id: <3.0.2.32.19990716231622.007e2100@storm.digital-rain.com> X-Sender: tim@storm.digital-rain.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Fri, 16 Jul 1999 23:16:22 -0700 To: freebsd-hackers@freebsd.org From: Tim Baird Subject: Re: poor ethernet performance? In-Reply-To: References: <199907170220.TAA25948@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 08:08 PM 16/07/99 -0700, you wrote: >On Fri, 16 Jul 1999, Matthew Dillon wrote: > >> : I know, I'm just wondering how did they get more frequency out of >> :wire of the same size. I can understand it if the wire was a larger >> :guage. >> >> For twisted pair, Less power == less crosstalk. Plus the higher >> bandwidth transceivers use better receivers and better pre-attenuation >> of the signal. > > Cross talk is only one of the variables I think... There is >balancing and ACR and how well it can keep a true 100 Ohms to the cable. Now for a brief tutorial on transmission line / gigabit ethernet...... Ensuring that the entire transmission path maintains a consistant characteristic impedance is the most difficult task in cable manufacture. It has typically the most influence on the quality of the signal transmission. Crosstalk is always present in a multi pair cable system, it is a matter of degree i.e. how much cross talk (undesirable signal) is present as a percentage of desired signal. The level of crosstalk is proportional to dv/dt .... the rate of change in signal voltage with respect to time. This is different than "frequency". A 1 Hz signal that approaches a square wave (or rectangle) can have HUGE crosstalk at the edges because of the large dv/dt at those points. Care must be taken to optimize the dv/dt with respect to the desired baud rate. (baud == state changes per second) As a cable length increases, losses increase, (these can be compensated for by increasing drive level ... and thus dv/dt) but a potentially worse bogey man plays a role....propagation delay. Most of the physical problems previously indicated can be improved upon, but no one has found a way around the limits of the speed of light (most transmission line allows propagation at about 70 to 80% of c). The time is not far off where this will be by far the most significant limit on information exchange for everyday communication. STP is better to use over shorter lengths where high level of EMI compromise the common mode rejection of the reciving system. The downside is that STP typically has rotton characteristic impedance consistency....not because of the plastic jacketing etc, but because of the varying distance (radius) between the cable pairs and the sheild over the length of the cable. Going to coax is usually the choice here for standard ethernet. Gigabit ethernet obviously creates a new level of awarenes about all of these factors. From a great article at http://www.gigabit-ethernet.org/technology/whitepapers/gige_11.97/how.html.. ..... * Use existing 4-pair Category 5 cable. To ensure proper operation at full link lengths, the cable must conform to the requirements of ANSI/TIA/EIA-568-A (1995). * Use all four pairs in the cable to keep symbol rate at or below 125 Mbaud. * Use PAM-5 coding to increase the amount of information sent with each symbol. (similar concept to analog modem methods) * Use 4D 8-state Trellis Forward Error Correction coding to offset the impact of noise and crosstalk. (ie. reciever has the ability to correct the error without requesting retransmission) * Use pulse shaping techniques to condition the transmitted spectrum. (i.e. limit dv/dt etc) * Use state-of-the-art DSP signal equalization techniques to manage the problems of noise, echo and crosstalk interferences, and to ensure a bit error rate of 1 x 10 exp(-10). > >> I'm not sure what the gigabit copper ethernet people are doing, but there >> are other ways as well. > > I wonder if any Gigabit ethernet cards exist that uses UTP because >everything seems to be pointing to the fiber direction. > >> Basic ethernet uses baseband which is quite noisy even with the >> preattenuation, so there was lots of room to go faster. > > Yep, it would have been nice if the original spec was shielded but >anything shielded would have a degrade in signal... It's the insultaion >whether it is PVC, Teflon or even the new air chambers introduced by >Matthew Bond at Tara Labs using Regtangular Solid Core cable capable of >handling 2.5Ghz. > > >Cheers, >Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ >Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] >GaiaNet Corporation - M & C Estate / / / / | / | __] ] >Beverly Hills, California USA 90210 / / / / / |/ / | __] ] >HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-hackers" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 0:30: 8 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from venus.GAIANET.NET (venus.GAIANET.NET [207.211.200.51]) by hub.freebsd.org (Postfix) with ESMTP id EF73B14E28 for ; Sat, 17 Jul 1999 00:29:57 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Received: from localhost (vince@localhost) by venus.GAIANET.NET (8.9.3/8.9.3) with ESMTP id AAA11733; Sat, 17 Jul 1999 00:28:18 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Date: Sat, 17 Jul 1999 00:28:18 -0700 (PDT) From: Vincent Poy To: Tim Baird Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? In-Reply-To: <3.0.2.32.19990716231622.007e2100@storm.digital-rain.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 16 Jul 1999, Tim Baird wrote: > At 08:08 PM 16/07/99 -0700, you wrote: > >On Fri, 16 Jul 1999, Matthew Dillon wrote: > > > >> : I know, I'm just wondering how did they get more frequency out of > >> :wire of the same size. I can understand it if the wire was a larger > >> :guage. > >> > >> For twisted pair, Less power == less crosstalk. Plus the higher > >> bandwidth transceivers use better receivers and better pre-attenuation > >> of the signal. > > > > Cross talk is only one of the variables I think... There is > >balancing and ACR and how well it can keep a true 100 Ohms to the cable. > > Now for a brief tutorial on transmission line / gigabit ethernet...... > > > Ensuring that the entire transmission path maintains a consistant > characteristic impedance is the most difficult task in cable manufacture. > It has typically the most influence on the quality of the signal > transmission. Crosstalk is always present in a multi pair cable system, it > is a matter of degree i.e. how much cross talk (undesirable signal) is > present as a percentage of desired signal. The level of crosstalk is > proportional to dv/dt .... the rate of change in signal voltage with > respect to time. This is different than "frequency". A 1 Hz signal that > approaches a square wave (or rectangle) can have HUGE crosstalk at the > edges because of the large dv/dt at those points. Care must be taken to > optimize the dv/dt with respect to the desired baud rate. (baud == state > changes per second) > > As a cable length increases, losses increase, (these can be compensated for > by increasing drive level ... and thus dv/dt) but a potentially worse bogey > man plays a role....propagation delay. Most of the physical problems > previously indicated can be improved upon, but no one has found a way > around the limits of the speed of light (most transmission line allows > propagation at about 70 to 80% of c). The time is not far off where this > will be by far the most significant limit on information exchange for > everyday communication. > > STP is better to use over shorter lengths where high level of EMI > compromise the common mode rejection of the reciving system. The downside > is that STP typically has rotton characteristic impedance > consistency....not because of the plastic jacketing etc, but because of the > varying distance (radius) between the cable pairs and the sheild over the > length of the cable. Going to coax is usually the choice here for standard > ethernet. > > Gigabit ethernet obviously creates a new level of awarenes about all of > these factors. From a great article at > http://www.gigabit-ethernet.org/technology/whitepapers/gige_11.97/how.html.. > ..... > > * Use existing 4-pair Category 5 cable. To ensure proper operation at full > link lengths, the cable must conform to the requirements of > ANSI/TIA/EIA-568-A (1995). > > * Use all four pairs in the cable to keep symbol rate at or below 125 Mbaud. > > * Use PAM-5 coding to increase the amount of information sent with each > symbol. (similar concept to analog modem methods) > > * Use 4D 8-state Trellis Forward Error Correction coding to offset the > impact of noise and crosstalk. (ie. reciever has the ability to correct the > error without requesting retransmission) > > * Use pulse shaping techniques to condition the transmitted spectrum. (i.e. > limit dv/dt etc) > > * Use state-of-the-art DSP signal equalization techniques to manage the > problems of noise, echo and crosstalk interferences, and to ensure a bit > error rate of 1 x 10 exp(-10). Thanks for the article and for the brief. I just have a little comment on shielded versus unshielded for both analog and digital audio cables, not sure if this applies to data cable but digital audio is data: Cables are of the "nude" (unshielded) style, which has generally been perceived to sound "faster" and less "colored" than conventional fully shielded cables. As it turns out, there is good reason to think so since properly designed, un-shielded cables are much less reactive to the signal than their fully shielded counterparts. At audio frequencies and with reasonably short lengths of cable, a shield typically does more harm than good and is otherwise necessary only for Radio Frequency transmission and/or into extremely high gain inputs such as microphone and phono pre-amps. Instead, properly braided or twisted conductors effectively reduce susceptibility to induced noise, especially inductively coupled interference (EMI) while angular crossing weakens the field effects of opposite polarity conductors on each other. The mechanism for the self-shielding/field controlling design is to divide the signal into several separate runs in a continually changing orientation such that only a small fraction of either polarity is ever in the ideal orientation to the wave front. This has most relevance to electromagnetic fields either internal or external, which especially require an optimal angular component to induce the greatest opposing current flow. Cheers, Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 1:51:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from kozlik.carrier.kiev.ua (kozlik.carrier.kiev.ua [193.193.193.111]) by hub.freebsd.org (Postfix) with ESMTP id 3B9B214F88 for ; Sat, 17 Jul 1999 01:51:16 -0700 (PDT) (envelope-from nx@nn.kiev.ua) Received: from nn.UUCP (uucp@localhost) by kozlik.carrier.kiev.ua (8.The.Best/UUCP_FOREVER) with UUCP id LAA00243 for freebsd-hackers@freebsd.org; Sat, 17 Jul 1999 11:50:47 +0300 (EEST) (envelope-from nx@nn.kiev.ua) Received: from nn.UUCP (uucp@localhost) by kozlik.carrier.kiev.ua (rmail mypid=00242 childpid=00243) with UUCP; Sat, 17 Jul 1999 08:50:47 +0000 GMT Received: by nn.kiev.ua (UUPC/@ v7.00, 29Jul97) id AA06197; Sat, 17 Jul 1999 11:35:42 +0300 (EDT) To: freebsd-hackers@freebsd.org X-Comment-To: "Brian F. Feldman" References: Message-ID: From: "Valentin Nechayev" Date: Sat, 17 Jul 1999 11:35:41 +0300 (EDT) X-Mailer: dMail [Demos Mail for DOS v2.06] Subject: Re: Replacement for grep(1) (part 2) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 36 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian F. Feldman wrote: >> There are other ways. For example, even if a user account is resource >> limited, root processes (such as sendmail, popper, identd, and so forth) >> are not. Attacks against these servers generally result in very high >> loads and sometimes make it difficult to login to fix the problem, but do >> not result in running out of swap. It results sometimes in out of swap, too. > Inetd is rate-limited by default nowadays, so this really doesn't apply. It really does apply. Inetd limits incoming connections per minute, not per second. It is possible to use minute limit in a few seconds and cause a high load. Sendmail is worse than inetd; it cannot limit incoming rate on established connection. Butenko's (butenko@stalker.com) DoS attack to sendmail is to send thousands of letters to local user thru fast netork connection (i.e., Ethernet) thru one established TCP connection; the only barrier is testing of LA before sending '250 XXX message accepted to delivery' reply and fork-and-deliver-or-queue-and-exit decision, but attacker can send too many letters in few seconds; a hundreds of delivery processes locked on /usr/libexec/mail.local mailbox waiting. LA counts system state characteristics of last minute and thus is similar to average patients' temperature per hospital per last year. ;( I have seen a variant of this attack on my mail hosts, when host with 6000 letters in mail queue (mail2news server) sent all its mail to smarthost (uucp spool server); after ~500 letters, sendmail on smarthost closed port 25 on RefuseLA; it was saved from out-of-swap only because domain resolving spent some time. The only mechanism against such type of attack I can imagine is to sm_sleep(1) at "mail from:" smtp server code or before '250 Message accepted for delivery'. For inetd, we must limit connections per second, not per minute. -- Netch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 1:56:15 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from storm.digital-rain.com (storm.digital-rain.com [204.244.71.70]) by hub.freebsd.org (Postfix) with ESMTP id 6591D14BF5 for ; Sat, 17 Jul 1999 01:56:10 -0700 (PDT) (envelope-from tim@storm.digital-rain.com) Received: from agamemnon.melonville.net (dial-line60.digital-rain.com [204.244.94.60]) by storm.digital-rain.com (8.9.1/8.9.1) with SMTP id BAA08628 for ; Sat, 17 Jul 1999 01:54:07 -0700 (PDT) Message-Id: <3.0.2.32.19990717015406.0095f670@storm.digital-rain.com> X-Sender: tim@storm.digital-rain.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Sat, 17 Jul 1999 01:54:06 -0700 To: freebsd-hackers@freebsd.org From: Tim Baird Subject: Re: poor ethernet performance? In-Reply-To: References: <3.0.2.32.19990716231622.007e2100@storm.digital-rain.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> >> Now for a brief tutorial on transmission line / gigabit ethernet...... >> >> >> Ensuring that the entire transmission path maintains a consistant >> characteristic impedance is the most difficult task in cable manufacture. >> It has typically the most influence on the quality of the signal >> transmission. Crosstalk is always present in a multi pair cable system, it >> is a matter of degree i.e. how much cross talk (undesirable signal) is >> present as a percentage of desired signal. The level of crosstalk is >> proportional to dv/dt .... the rate of change in signal voltage with >> respect to time. This is different than "frequency". A 1 Hz signal that >> approaches a square wave (or rectangle) can have HUGE crosstalk at the >> edges because of the large dv/dt at those points. Care must be taken to >> optimize the dv/dt with respect to the desired baud rate. (baud == state >> changes per second) >> >> As a cable length increases, losses increase, (these can be compensated for >> by increasing drive level ... and thus dv/dt) but a potentially worse bogey >> man plays a role....propagation delay. Most of the physical problems >> previously indicated can be improved upon, but no one has found a way >> around the limits of the speed of light (most transmission line allows >> propagation at about 70 to 80% of c). The time is not far off where this >> will be by far the most significant limit on information exchange for >> everyday communication. >> >> STP is better to use over shorter lengths where high level of EMI >> compromise the common mode rejection of the reciving system. The downside >> is that STP typically has rotton characteristic impedance >> consistency....not because of the plastic jacketing etc, but because of the >> varying distance (radius) between the cable pairs and the sheild over the >> length of the cable. Going to coax is usually the choice here for standard >> ethernet. >> >> Gigabit ethernet obviously creates a new level of awarenes about all of >> these factors. From a great article at >> http://www.gigabit-ethernet.org/technology/whitepapers/gige_11.97/how.html.. >> ..... >> >> * Use existing 4-pair Category 5 cable. To ensure proper operation at full >> link lengths, the cable must conform to the requirements of >> ANSI/TIA/EIA-568-A (1995). >> >> * Use all four pairs in the cable to keep symbol rate at or below 125 Mbaud. >> >> * Use PAM-5 coding to increase the amount of information sent with each >> symbol. (similar concept to analog modem methods) >> >> * Use 4D 8-state Trellis Forward Error Correction coding to offset the >> impact of noise and crosstalk. (ie. reciever has the ability to correct the >> error without requesting retransmission) >> >> * Use pulse shaping techniques to condition the transmitted spectrum. (i.e. >> limit dv/dt etc) >> >> * Use state-of-the-art DSP signal equalization techniques to manage the >> problems of noise, echo and crosstalk interferences, and to ensure a bit >> error rate of 1 x 10 exp(-10). > > Thanks for the article and for the brief. I just have a little >comment on shielded versus unshielded for both analog and digital audio >cables, not sure if this applies to data cable but digital audio is data: > >Cables are of the "nude" (unshielded) style, which has generally been >perceived to sound "faster" and less "colored" than conventional fully >shielded cables. Ahem....I am not sure what this means......It sounds a little bit like those articles that you read in that audiophile magazine "The Absolute Sound" where people claim that they can hear the difference in the acoustics of their listening room depending on where they have situated their teacup......but I digress.....see below.... As it turns out, there is good reason to think so since >properly designed, un-shielded cables are much less reactive to the signal >than their fully shielded counterparts. At audio frequencies and with >reasonably short lengths of cable, a shield typically does more harm than >good and is otherwise necessary only for Radio Frequency transmission >and/or into extremely high gain inputs such as microphone and phono >pre-amps. Instead, properly braided or twisted conductors effectively >reduce susceptibility to induced noise, especially inductively coupled >interference (EMI) while angular crossing weakens the field effects of >opposite polarity conductors on each other. The mechanism for the >self-shielding/field controlling design is to divide the signal into >several separate runs in a continually changing orientation such that only >a small fraction of either polarity is ever in the ideal orientation to >the wave front. This has most relevance to electromagnetic fields either >internal or external, which especially require an optimal angular >component to induce the greatest opposing current flow. This is not a very accurate description of what is happening in a twisted pair situation....... There are two factors influencing the design of twisted pair transmission line. First there is the need to control the consistency of the characteristic impedance of the line. This happens by controlling the distance (radius) between the two conductors as well as the dielectric material that is present in their vicinity. For coax, this is a special compound between the braided outer conductor (shield) and the inner conductor. For twisted pair, this is usually air (the dielectric properties of the insulation are made to be virtually the same as air). The dielectric only affects the capacitive element by controlling permittivity, the inductive element is essentially controlled by the permeability of free space. The characteristic impedance has nothing at all to do with the DC resistance of the conductors used...it (CI) is a combination of the two reactive effects inherantly present along the line...namely capacitance (storage of electric charge) measured in Farads/meter and inductance (storage of magnetic energy) measured in Henries/meter. These two effects or "reactances" will always be equal and opposite at some frequency, the idea is to have an effective cancellation happening over as broad a range as possible so that they do not limit the bandwidth of the transmission line. The values of the two reactances are positive and negative imaginary numbers. When you take the square root of the ratio of the two values, you end up with a real number in the unit of "ohms".....ie the characteristic impedance......... BTW This is EXACTLY analogous to "index of refraction" with respect to light....... As the spectral components of your signal increase in frequency, there are some interesting effects which occur...one is "skin effect". This effect is the tendency for currents on the line to travel to the outside of the conductor as their self induced electromagnetic force creates a higher flux density at the center of the conductor...this changes the effective cross-sectional area of the conductor and thus the resistance. The result is a more "lossy" line....Other losses are found in the dielectric material, and of course the natural resistance of the copper.... Second, to minimize the effect of electromagnetic interference (EMI) which is both "crosstalk" and other stray emag signals incident on the transmission line, the twisted pair design is used on the assumption that common mode signals are effectively rejected by the reciever...ie any currents induced along the line that are EQUAL will be cancelled out by the differential reciever. If you twist the cable pair as it travels through space, you will have any incident signal affect BOTH conductors equally (hopefully)....thus the EMI induced currents will be effectively cancelled out by the commond mode rejection characteristics of the differential receiver....This is why you twist your antenna wire that comes from your TV antenna on your roof (if anyone still uses these)...otherwise your TV will have a ghosted image...one signal from the antenna, and another signal (shifted in time) coming in along the antenna wire. As for these issues in the audio realm, I can assure you that high frequency effects such as skin effect, characteristic impedance considerations, and the like have NO real influence on your sound quality...anyone who says so is shoveling cow cookies, or has a high bit error rate in the cerebral cortex For input stages like microphones etc, there is the need to block out EMI so that you don't record your guitar along with the 60 Hz hum from your electrical system, the brush noise from your neighbour's drill etc.....This is where using a combo of sheilded and twisted cable is preferred....... As for data transmission, you want to maximize the data rate, maximize the distance, minimize the error rate, simplify the installation procedure, minimize the cost etc....Therefore, you want to have all of these design considerations outlined above built in to the whole system. Also, you don't want to have to rip out the network cable every time you upgrade your data pumps...You want as good a cable as you can afford, that way the data pumps (ethernet cards) are able to operate at their full capacity without wasting time doing retrans....Most of the time though, a reasonably conscientous cable installation will not be found to be the weak link in your system. Usually it will work great or really badly, and the cause - if it is bad cable - is usually found easily by isolating different segments and testing.... I hope everyone is benefitting by these simple facts....I hate to see needless misunderstanding BTW, if this is too far off topic for this list, please feel free to express your concern (anyone) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 2:13:41 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from venus.GAIANET.NET (venus.GAIANET.NET [207.211.200.51]) by hub.freebsd.org (Postfix) with ESMTP id 39A9B14C34 for ; Sat, 17 Jul 1999 02:13:37 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Received: from localhost (vince@localhost) by venus.GAIANET.NET (8.9.3/8.9.3) with ESMTP id CAA12263; Sat, 17 Jul 1999 02:12:38 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Date: Sat, 17 Jul 1999 02:12:38 -0700 (PDT) From: Vincent Poy To: Tim Baird Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? In-Reply-To: <3.0.2.32.19990717015406.0095f670@storm.digital-rain.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 17 Jul 1999, Tim Baird wrote: > > Thanks for the article and for the brief. I just have a little > >comment on shielded versus unshielded for both analog and digital audio > >cables, not sure if this applies to data cable but digital audio is data: > > > >Cables are of the "nude" (unshielded) style, which has generally been > >perceived to sound "faster" and less "colored" than conventional fully > >shielded cables. > > Ahem....I am not sure what this means......It sounds a little bit like > those articles that you read in that audiophile magazine "The Absolute > Sound" where people claim that they can hear the difference in the > acoustics of their listening room depending on where they have situated > their teacup......but I digress.....see below.... It all depends on the equipment too since remember the wire is the weakest link in the chain and every cable sounds different. I'm sure no wire is 100% perfect. > As it turns out, there is good reason to think so since > >properly designed, un-shielded cables are much less reactive to the signal > >than their fully shielded counterparts. At audio frequencies and with > >reasonably short lengths of cable, a shield typically does more harm than > >good and is otherwise necessary only for Radio Frequency transmission > >and/or into extremely high gain inputs such as microphone and phono > >pre-amps. Instead, properly braided or twisted conductors effectively > >reduce susceptibility to induced noise, especially inductively coupled > >interference (EMI) while angular crossing weakens the field effects of > >opposite polarity conductors on each other. The mechanism for the > >self-shielding/field controlling design is to divide the signal into > >several separate runs in a continually changing orientation such that only > >a small fraction of either polarity is ever in the ideal orientation to > >the wave front. This has most relevance to electromagnetic fields either > >internal or external, which especially require an optimal angular > >component to induce the greatest opposing current flow. > > This is not a very accurate description of what is happening in a twisted > pair situation....... > > There are two factors influencing the design of twisted pair transmission > line. > > First there is the need to control the consistency of the characteristic > impedance of the line. This happens by controlling the distance (radius) > between the two conductors as well as the dielectric material that is > present in their vicinity. For coax, this is a special compound between > the braided outer conductor (shield) and the inner conductor. For twisted > pair, this is usually air (the dielectric properties of the insulation are > made to be virtually the same as air). The dielectric only affects the > capacitive element by controlling permittivity, the inductive element is > essentially controlled by the permeability of free space. The > characteristic impedance has nothing at all to do with the DC resistance of > the conductors used...it (CI) is a combination of the two reactive effects > inherantly present along the line...namely capacitance (storage of electric > charge) measured in Farads/meter and inductance (storage of magnetic > energy) measured in Henries/meter. These two effects or "reactances" will > always be equal and opposite at some frequency, the idea is to have an > effective cancellation happening over as broad a range as possible so that > they do not limit the bandwidth of the transmission line. The values of > the two reactances are positive and negative imaginary numbers. When you > take the square root of the ratio of the two values, you end up with a real > number in the unit of "ohms".....ie the characteristic impedance......... Yes, but how consistent the ohms rating is what is important. > BTW This is EXACTLY analogous to "index of refraction" with respect to > light....... > > As the spectral components of your signal increase in frequency, there are > some interesting effects which occur...one is "skin effect". This effect > is the tendency for currents on the line to travel to the outside of the > conductor as their self induced electromagnetic force creates a higher flux > density at the center of the conductor...this changes the effective > cross-sectional area of the conductor and thus the resistance. The result > is a more "lossy" line....Other losses are found in the dielectric > material, and of course the natural resistance of the copper.... > > > Second, to minimize the effect of electromagnetic interference (EMI) which > is both "crosstalk" and other stray emag signals incident on the > transmission line, the twisted pair design is used on the assumption that > common mode signals are effectively rejected by the reciever...ie any > currents induced along the line that are EQUAL will be cancelled out by the > differential reciever. If you twist the cable pair as it travels through > space, you will have any incident signal affect BOTH conductors equally > (hopefully)....thus the EMI induced currents will be effectively cancelled > out by the commond mode rejection characteristics of the differential > receiver....This is why you twist your antenna wire that comes from your TV > antenna on your roof (if anyone still uses these)...otherwise your TV will > have a ghosted image...one signal from the antenna, and another signal > (shifted in time) coming in along the antenna wire. You have a good point. > As for these issues in the audio realm, I can assure you that high > frequency effects such as skin effect, characteristic impedance > considerations, and the like have NO real influence on your sound > quality...anyone who says so is shoveling cow cookies, or has a high bit > error rate in the cerebral cortex It all depends again on the equipment on both ends of the chain. It's like garbage in/garbage out if the equipment is garbage in the first place. > For input stages like microphones etc, there is the need to block out EMI > so that you don't record your guitar along with the 60 Hz hum from your > electrical system, the brush noise from your neighbour's drill etc.....This > is where using a combo of sheilded and twisted cable is preferred....... Yep, that's true. > As for data transmission, you want to maximize the data rate, maximize the > distance, minimize the error rate, simplify the installation procedure, > minimize the cost etc....Therefore, you want to have all of these design > considerations outlined above built in to the whole system. Also, you > don't want to have to rip out the network cable every time you upgrade your > data pumps...You want as good a cable as you can afford, that way the data > pumps (ethernet cards) are able to operate at their full capacity without > wasting time doing retrans....Most of the time though, a reasonably > conscientous cable installation will not be found to be the weak link in > your system. Usually it will work great or really badly, and the cause - > if it is bad cable - is usually found easily by isolating different > segments and testing.... > > I hope everyone is benefitting by these simple facts....I hate to see > needless misunderstanding > > BTW, if this is too far off topic for this list, please feel free to > express your concern (anyone) I am benefiting from it for sure. I guess what I was asking originally was if the higher frequency rated cables will give it more headroom since the 100BaseTX ethernet does push CAT5 to the limit. Cheers, Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 2:51:34 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from kozlik.carrier.kiev.ua (kozlik.carrier.kiev.ua [193.193.193.111]) by hub.freebsd.org (Postfix) with ESMTP id 0B82314CC4 for ; Sat, 17 Jul 1999 02:51:13 -0700 (PDT) (envelope-from nx@nn.kiev.ua) Received: from nn.UUCP (uucp@localhost) by kozlik.carrier.kiev.ua (8.The.Best/UUCP_FOREVER) with UUCP id MAA07508 for freebsd-hackers@freebsd.org; Sat, 17 Jul 1999 12:50:43 +0300 (EEST) (envelope-from nx@nn.kiev.ua) Received: from nn.UUCP (uucp@localhost) by kozlik.carrier.kiev.ua (rmail mypid=07507 childpid=07508) with UUCP; Sat, 17 Jul 1999 09:50:43 +0000 GMT Received: by nn.kiev.ua (UUPC/@ v7.00, 29Jul97) id AA06197; Sat, 17 Jul 1999 12:49:28 +0300 (EDT) To: freebsd-hackers@freebsd.org X-Comment-To: Matthew Dillon References: <199907132229.PAA81360@apollo.backplane.com> Message-ID: From: "Valentin Nechayev" Date: Sat, 17 Jul 1999 12:49:28 +0300 (EDT) X-Mailer: dMail [Demos Mail for DOS v2.06] Subject: Re: Replacement for grep(1) (part 2) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 69 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > Give me a shell and I can crash any machine. Oh. ;| > A good example of this is sendmail. Before the MaxDaemonChildren and > MaxArticleSize options, it was possible for sendmail to overcommit a > machine. In this case the overcommit that can occur is with I/O, not > swap. As a general performance rule, you have to set MaxDaemonChildren > and MaxArticleSize to prevent the overcommit from occuring. This is a > function of sendmail, not a function of the kernel. Sigh. ((c)you) Sendmail can overcommit a machine with right set of MaxDaemonChildren, MaxArticleSize, QueueLA & RefuseLA options - I have seen such situations. MaxDaemonChildren limits only number of main processes for incoming connections (plus queue run processes). For each connection, after "main from:" and until accepting message, server process for incoming connection forks child which accepts recipient list and letter body. After message accepting, that child can fork delivery process. A queue run process with "O ForkEachJob=true" option, which is default, can create a delivery process for each queue job (in my practice, queue of more than 1000 jobs is ordinary event). All these forks depend only on one test - get current LA and compare it with QueueLA - which fail when high load appeared less than one minute ago. To prevent its overcommit, (I interfere in details with parallel message) the minimal (and possibly not enough) setup set is: 1) patch - insert sm_sleep(1) to server subprocess code before "accepted" reply - limit incoming mail rate; 2) Desrease QueueLA for listening daemon to sub-minimal value (i.e.2); 3) Increase QueueLA for queue running daemon to high values (i.e.50) and set them OForkEachJob=false. But most of these tunings are indirect. A direct tuning invented experimentally on my mail servers is specially hacked pstat program that returns 1 if either swap or file descriptors are used more than 2/3, 0 otherwise; on getting 1, sendmail stops delivering. But, it's pity, this check is unportable. (P.S. Don't tell me change MTA; this is fully another question.) > Another good example is a web server. A web server must have specific > limitations on the number of simultanious connections it is allowed > to handle at once and on the number of CGI's or other auxillary programs > that are allowed to be running at any given time. The overcommit issue > here has nothing to do with swap and everything to do with performance. > Specifically, these limitations exist to avoid cascade failures. As in sendmail case, you propose make some calculations (which are difficult and non-trivial to newbies) to make appreciations of nesessary resources. Another way, which is imho more acceptable, is to provide not hard barriers (SIGKILL on overcommitting), but soft barriers (i.e., stop memory allocating for non-wheel users when memory begins to exhaust). Extra 64M of memory or a disk for swap is commonly quite more cheaper than profitloss on critical service crash. > In the same manner any truely critical system server must handle the > resource management itself to deal with all sorts of problem situations, > including memory. You do not need to build any of this control into the > kernel. No, we need it. Not every server can be patched for such tests (due to loss of sources or another reason), not every admin can make nesessary patches. Kernel must help in it. -- Netch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 3: 3:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id A8D3614D68 for ; Sat, 17 Jul 1999 03:03:03 -0700 (PDT) (envelope-from sthaug@nethelp.no) Received: (qmail 51883 invoked by uid 1001); 17 Jul 1999 10:00:46 +0000 (GMT) To: vince@venus.GAIANET.NET Cc: tim@storm.digital-rain.com, freebsd-hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? From: sthaug@nethelp.no In-Reply-To: Your message of "Sat, 17 Jul 1999 02:12:38 -0700 (PDT)" References: X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sat, 17 Jul 1999 12:00:46 +0200 Message-ID: <51881.932205646@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I am benefiting from it for sure. I guess what I was asking > originally was if the higher frequency rated cables will give it more > headroom since the 100BaseTX ethernet does push CAT5 to the limit. 100BaseTX is specified to run on Cat5 cabling, and with proper Cat5 cabling you get a a BER of 10^-8 or better. As long as your cabling meets the Cat5 spec, you'll get 100 Mbps - there's no possibility of "more headroom" with cables rated to higher frequency. Note that 100BaseTX is different from 10BaseT (but similar to synchronous serial lines) in that there is always a signal present. Note also that FreeBSD can easily saturate 100 Mbps Ethernet. Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 4:30:27 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net [194.217.242.20]) by hub.freebsd.org (Postfix) with ESMTP id 3729B14D47 for ; Sat, 17 Jul 1999 04:30:23 -0700 (PDT) (envelope-from dmlb@ragnet.demon.co.uk) Received: from ragnet.demon.co.uk ([158.152.46.40]) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 115Sfd-0008pb-0K; Sat, 17 Jul 1999 11:30:22 +0000 Received: from dmlb by ragnet.demon.co.uk with local (Exim 2.12 #1) id 115RsV-000Lhy-00; Sat, 17 Jul 1999 11:39:35 +0100 Content-Length: 1098 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199907162355.QAA22402@apollo.backplane.com> Date: Sat, 17 Jul 1999 11:39:35 +0100 (BST) From: Duncan Barclay To: Matthew Dillon Subject: Re: poor ethernet performance? Cc: hackers@FreeBSD.ORG, crypt0genic , Bill Paul , Vincent Poy Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 16-Jul-99 Matthew Dillon wrote: > > In regards to audio/video verses ethernet, you have to remember that > audio and video are *analog*, not digital. The cable quality matters > for analog, but it only needs to be "good enough" for digital. If you > don't get any bit errors (and you shouldn't) then a better cable is not > going to make a difference. > > -Matt > Matthew Dillon And you seen the nice square waves of 100Mb or !Gb ether on a line then? The techniques used for transmitting 100Mb/s down copper are certainly not digital. Pulse shaping, line estimation, ISI removal are all analogue! The cable itself is less improtant than the impedance matching at connectors and bends in the cable. Duncan --- ________________________________________________________________________ Duncan Barclay | God smiles upon the little children, dmlb@ragnet.demon.co.uk | the alcoholics, and the permanently stoned. ________________________________________________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 5:42:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id DACBE14CE6 for ; Sat, 17 Jul 1999 05:42:45 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id OAA14709; Sat, 17 Jul 1999 14:42:43 +0200 (CEST) (envelope-from des) To: hackers@freebsd.org Subject: Determining the return address From: Dag-Erling Smorgrav Date: 17 Jul 1999 14:42:43 +0200 Message-ID: Lines: 51 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is there any (evidently non-portable) way of determining a function instance's return address? I have an idea or two that involves the return address and dladdr(). The code I currently use looks like this: int log_print(log_t *log, char *fmt, ...) { char date[32], str[MAX_LOG_LINE]; struct iovec iov[10]; Dl_info info; size_t len; va_list ap; int n; len = log_makedate(date, sizeof date); iov[n=0].iov_base = date; iov[n].iov_len = len; if (dladdr(*(((void**)&log)-1), &info) == 0) iov[++n].iov_base = "(unknown)"; else iov[++n].iov_base = (char *)info.dli_sname; iov[n].iov_len = strlen(iov[n].iov_base); iov[++n].iov_base = ": "; iov[n].iov_len = 2; va_start(ap, fmt); len = lvformat(str, sizeof str, fmt, ap); va_end(ap); while (len > 0 && isspace(str[len-1])) --len; iov[++n].iov_base = str; iov[n].iov_len = len; iov[++n].iov_base = "\n"; iov[n].iov_len = 1; return writev(log->fd, iov, ++n); } Is it correct? (empirical evidence suggests it is) Is there any better way to do it? Will it work on the Alpha? BTW, is dladdr() signal-safe? DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 5:56:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mailout1.nyroc.rr.com (mailout1-0.nyroc.rr.com [24.92.226.81]) by hub.freebsd.org (Postfix) with ESMTP id 1287D14CE6 for ; Sat, 17 Jul 1999 05:56:50 -0700 (PDT) (envelope-from assem@twcny.rr.com) Received: from mail1.twcny.rr.com ([24.92.226.139]) by mailout1.nyroc.rr.com (Post.Office MTA v3.5.3 release 223 ID# 0-59787U250000L250000S0V35) with ESMTP id com for ; Sat, 17 Jul 1999 08:55:57 -0400 Received: from twcny.rr.com ([24.92.245.150]) by mail1.twcny.rr.com (Post.Office MTA v3.5.2 release 221 ID# 0-53939U80000L80000S0V35) with ESMTP id com for ; Sat, 17 Jul 1999 08:55:56 -0400 Message-ID: <37907E69.90037620@twcny.rr.com> Date: Sat, 17 Jul 1999 09:00:25 -0400 From: Assem Salama X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: Devloper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am interested in helping in the development in FreeBSD. I'm not a hotshot programmer but I know how to program. Could someone please send me the available projects that I can work on and some info about them? Thanks, Assem Salama To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 8:30:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 3A2A214CE6 for ; Sat, 17 Jul 1999 08:30:06 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id IAA74679; Sat, 17 Jul 1999 08:29:34 -0700 (PDT) (envelope-from dillon) Date: Sat, 17 Jul 1999 08:29:34 -0700 (PDT) From: Matthew Dillon Message-Id: <199907171529.IAA74679@apollo.backplane.com> To: Duncan Barclay Cc: hackers@FreeBSD.ORG, crypt0genic , Bill Paul , Vincent Poy Subject: Re: poor ethernet performance? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :And you seen the nice square waves of 100Mb or !Gb ether on a line then? The :techniques used for transmitting 100Mb/s down copper are certainly not digital. :Pulse shaping, line estimation, ISI removal are all analogue! : :The cable itself is less improtant than the impedance matching at connectors :and bends in the cable. : :Duncan : :Duncan Barclay | God smiles upon the little children, :dmlb@ragnet.demon.co.uk | the alcoholics, and the permanently stoned. Obviously you don't get square waves going down the wire - But it is still a digital communications protocol. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 8:38:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id B317A14C07 for ; Sat, 17 Jul 1999 08:38:46 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id IAA74714; Sat, 17 Jul 1999 08:37:21 -0700 (PDT) (envelope-from dillon) Date: Sat, 17 Jul 1999 08:37:21 -0700 (PDT) From: Matthew Dillon Message-Id: <199907171537.IAA74714@apollo.backplane.com> To: "Valentin Nechayev" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) References: <199907132229.PAA81360@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> machine. In this case the overcommit that can occur is with I/O, not :> swap. As a general performance rule, you have to set MaxDaemonChildren :> and MaxArticleSize to prevent the overcommit from occuring. This is a :> function of sendmail, not a function of the kernel. : :Sigh. ((c)you) Sendmail can overcommit a machine with right set of :MaxDaemonChildren, MaxArticleSize, QueueLA & RefuseLA options - I have seen :such situations. MaxDaemonChildren limits only number of main processes for :incoming connections (plus queue run processes). For each connection, after :"main from:" and until accepting message, server process for incoming :connection forks child which accepts recipient list and letter body. After :message accepting, that child can fork delivery process. A queue run process :with "O ForkEachJob=true" option, which is default, can create a delivery :process for each queue job (in my practice, queue of more than 1000 jobs is :-- :Netch Actually this isn't true. QueueLA & RefuseLA tend to be useless options with sendmail. MaxDaemonChildren, on the otherhand, tends to be a very useful option. By running the daemon and the queue separately, and putting the daemon in queue-only mode, sendmail has virtually no chance of taking down the machine. Example (assuming a box w/256MB of ram): sendmail -bd -O MaxDaemonChildren=130 -O DeliveryMode=queue sendmail -q1m -O MaxDaemonChildren=40 -O MinQueueAge=30m sendmail -q1m -O MaxDaemonChildren=40 -O MinQueueAge=2h This is what we do at BEST. Once we began doing things this this way, our three (continuously loaded) frontend mail machines never bogged down ever again. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 8:49:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 1D0F714BD6 for ; Sat, 17 Jul 1999 08:49:26 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id IAA74789; Sat, 17 Jul 1999 08:47:38 -0700 (PDT) (envelope-from dillon) Date: Sat, 17 Jul 1999 08:47:38 -0700 (PDT) From: Matthew Dillon Message-Id: <199907171547.IAA74789@apollo.backplane.com> To: "Valentin Nechayev" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Replacement for grep(1) (part 2) References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :It results sometimes in out of swap, too. : :> Inetd is rate-limited by default nowadays, so this really doesn't apply. : :It really does apply. Inetd limits incoming connections per minute, not per :second. It is possible to use minute limit in a few seconds and cause a high :load. Sendmail is worse than inetd; it cannot limit incoming rate on : :Netch You can specify a maximum fork limit for inetd on a per-service basis. You are a year or two too late on these things. A great many improvements have been made to programs like sendmail and inetd explicitly to deal with overload situations. Web servers too. These were fairly simple changes as well. For sendmail it was as simple as making MaxDaemonChildren apply to queue runs - I submitted that one to Eric Allman two years ago and it's been a part of sendmail since then. For inetd it is the -c, -C, and -R options (which can be specified on a per-service basis as well). Dima and I added the -R option back in 1997 specifically to help with DOS attacks. Sendmail is not an issue when properly configured. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 9:40:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 04BC014C47 for ; Sat, 17 Jul 1999 09:40:55 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id BAA08839; Sun, 18 Jul 1999 01:39:29 +0900 (JST) Message-ID: <3790AD50.DC28CD62@newsguy.com> Date: Sun, 18 Jul 1999 01:20:32 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Mike Smith Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: System unique identifier..... References: <199906260011.RAA00865@dingo.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith wrote: > > The loader will, at some stage in the future, grow a persistent data > store in which items like this can be saved. Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent data storage? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Misguided Angel hanging over me Heart like Gabriel, pure and white as ivory Soul like Lucifer, black and cold like a piece of lead..." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 9:57:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 51E1A14BF8 for ; Sat, 17 Jul 1999 09:57:47 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id SAA20369; Sat, 17 Jul 1999 18:57:41 +0200 (CEST) (envelope-from des) To: Assem Salama Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Devloper References: <37907E69.90037620@twcny.rr.com> From: Dag-Erling Smorgrav Date: 17 Jul 1999 18:57:40 +0200 In-Reply-To: Assem Salama's message of "Sat, 17 Jul 1999 09:00:25 -0400" Message-ID: Lines: 10 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Assem Salama writes: > I am interested in helping in the development in FreeBSD. I'm not a > hotshot programmer but I know how to program. Could someone please send > me the available projects that I can work on and some info about them? DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 10:22:36 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id BC79414DEE for ; Sat, 17 Jul 1999 10:22:32 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id CAA12768; Sun, 18 Jul 1999 02:22:23 +0900 (JST) Message-ID: <3790BBAF.3556105C@newsguy.com> Date: Sun, 18 Jul 1999 02:21:51 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Dag-Erling Smorgrav Cc: Assem Salama , freebsd-hackers@FreeBSD.ORG Subject: Re: Devloper References: <37907E69.90037620@twcny.rr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > > Assem Salama writes: > > I am interested in helping in the development in FreeBSD. I'm not a > > hotshot programmer but I know how to program. Could someone please send > > me the available projects that I can work on and some info about them? > > A few additions: :-) * a sysctl to make the system non-overcommit * SIGDANGER in low-memory situations * Dividing processes into those that ought to be killed first and those that ought to be killed last in low-memory situations * Per-user swap space limit -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Misguided Angel hanging over me Heart like Gabriel, pure and white as ivory Soul like Lucifer, black and cold like a piece of lead..." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 10:38: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id D433C14E81 for ; Sat, 17 Jul 1999 10:38:06 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id TAA21313; Sat, 17 Jul 1999 19:36:51 +0200 (CEST) (envelope-from des) To: "Daniel C. Sobral" Cc: Dag-Erling Smorgrav , Assem Salama , freebsd-hackers@FreeBSD.ORG Subject: Re: Devloper References: <37907E69.90037620@twcny.rr.com> <3790BBAF.3556105C@newsguy.com> From: Dag-Erling Smorgrav Date: 17 Jul 1999 19:36:51 +0200 In-Reply-To: "Daniel C. Sobral"'s message of "Sun, 18 Jul 1999 02:21:51 +0900" Message-ID: Lines: 25 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel C. Sobral" writes: > * a sysctl to make the system non-overcommit So I see common sense lost in the end. > * SIGDANGER in low-memory situations Do we support more than 32 signals? ISTR AIX already does this. What signal numbers / names does AIX use for this? > * Dividing processes into those that ought to be killed first and > those that ought to be killed last in low-memory situations How does AIX solve that problem? > * Per-user swap space limit Is that a realistic goal? What do we do about shared text, count it once for every user that uses it? DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 11:52:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from asteroid.svib.ru (asteroid.svib.ru [195.151.166.145]) by hub.freebsd.org (Postfix) with ESMTP id A1DDC14E82; Sat, 17 Jul 1999 11:52:42 -0700 (PDT) (envelope-from tarkhil@asteroid.svib.ru) Received: from shuttle.svib.ru (shuttle.svib.ru [195.151.166.144]) by asteroid.svib.ru (8.9.3/8.9.3) with ESMTP id WAA21540; Sat, 17 Jul 1999 22:51:55 +0400 (MSD) (envelope-from tarkhil@asteroid.svib.ru) Received: from shuttle.svib.ru (minas-tirith.pol.ru [127.0.0.1]) by shuttle.svib.ru (8.9.3/8.8.8) with ESMTP id WAA25204; Sat, 17 Jul 1999 22:51:18 +0400 (MSD) (envelope-from tarkhil@shuttle.svib.ru) Message-Id: <199907171851.WAA25204@shuttle.svib.ru> X-Mailer: exmh version 2.0.2 2/24/98 To: stable@freebsd.org Cc: hackers@freebsd.org Reply-To: tarkhil@asteroid.svib.ru Subject: Booting from vinum? X-URL: http://freebsd.svib.ru Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 17 Jul 1999 22:51:17 +0400 From: Alex Povolotsky Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello! Is it possible to have a root partition on vinum'ed disk and benefit from mirroring? If yes, how do I do it? Alex. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 11:57:51 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 63E3414E82 for ; Sat, 17 Jul 1999 11:57:48 -0700 (PDT) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (monica.cs.rpi.edu [128.213.7.2]) by cs.rpi.edu (8.9.3/8.9.3) with ESMTP id OAA81681 for ; Sat, 17 Jul 1999 14:57:47 -0400 (EDT) Message-Id: <199907171857.OAA81681@cs.rpi.edu> To: freebsd-hackers@freebsd.org Subject: USFS (User Space File System) Date: Sat, 17 Jul 1999 14:57:45 -0400 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am looking at a project that will require a user based process to interact with the system as if it were a filesystem. The traditional way I have seen this done is as the system NFS mounting itself (ala AMD). I would really like a more clean approach to this. What I am interested in is a 'User Space File System' that would interact with a user process in a similiar manor to how nfsd's do. A process would issue a mount (ok, this is different than NFSDs), then it would make a special system call with a structure, that call would return whenever a request was pending with the structure filled in with the appropriate information. The user process would fulfill the request, pack the return data into the structure and call kernel again. I have a number of questions on more specific ideas (like caching, inode/vnode interaction, etc). But I am just feeling arround for what people think about this. Any ideas/comments? -- David Cross | email: crossd@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science | Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 12:32:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id A400914C27 for ; Sat, 17 Jul 1999 12:32:48 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id NAA36096 for ; Sat, 17 Jul 1999 13:32:02 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id NAA64473 for ; Sat, 17 Jul 1999 13:32:02 -0600 (MDT) Message-Id: <199907171932.NAA64473@harmony.village.org> To: hackers@freebsd.org Subject: telnetd Date: Sat, 17 Jul 1999 13:32:02 -0600 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG What purpose is served by the twisty maze of ifdefs in telnetd? I'd like to unifdef many of them. I'm trying to track down a bug and the twisty maze makes it very hard to follow. Comments? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 13: 8:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from jane.lfn.org (nocitycouncil.com [209.16.92.7]) by hub.freebsd.org (Postfix) with SMTP id CF80C14CE6 for ; Sat, 17 Jul 1999 13:08:54 -0700 (PDT) (envelope-from caj@lfn.org) Received: (qmail 5555 invoked by uid 100); 17 Jul 1999 20:07:12 -0000 Date: Sat, 17 Jul 1999 15:07:12 -0500 (CDT) From: Craig Johnston To: hackers@freebsd.org Subject: vinum is cool. anyone bitten recently? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, I'm looking into doing striping and mirroring on a new webserver I am bringing up (3.2-stable) and I have to say, vinum looks very cool. It took me like half an hour to get it going from first contact. Nice job Greg -- very straightforward. Now, the official status of vinum is still alpha, right? But then again I know that that was (is?) the official status of softupdates for quite some time and I have been using it with no problems. So my question is, has anyone actually been bitten by vinum recently? I'm willing to take my chances if I can at least be pretty sure that I won't suddenly lose everything on both plexes if I am mirroring. thanks, Craig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 13:34:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from trooper.velocet.ca (trooper.velocet.net [209.167.225.226]) by hub.freebsd.org (Postfix) with ESMTP id 08BDA14C18; Sat, 17 Jul 1999 13:34:13 -0700 (PDT) (envelope-from dgilbert@trooper.velocet.ca) Received: (from dgilbert@localhost) by trooper.velocet.ca (8.9.3/8.9.3) id QAA52875; Sat, 17 Jul 1999 16:32:46 -0400 (EDT) (envelope-from dgilbert) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14224.59502.513327.576979@trooper.velocet.ca> Date: Sat, 17 Jul 1999 16:32:46 -0400 (EDT) To: tarkhil@asteroid.svib.ru Cc: stable@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Booting from vinum? In-Reply-To: <199907171851.WAA25204@shuttle.svib.ru> References: <199907171851.WAA25204@shuttle.svib.ru> X-Mailer: VM 6.71 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> "Alex" == Alex Povolotsky writes: Alex> Hello! Is it possible to have a root partition on vinum'ed disk Alex> and benefit from mirroring? If yes, how do I do it? My current design for this type of situation is to have 64M boot partitions and 256M swap partitions on each disk. I then use some number of the swap partitions and one of the 64Mboot partitions. Since boot partitions don't change much, I just back up my changes to one of the other partitions every so often. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 13:54:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id C184F14C9D for ; Sat, 17 Jul 1999 13:54:55 -0700 (PDT) (envelope-from bright@rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.9.3/8.9.3) with SMTP id RAA27715; Sat, 17 Jul 1999 17:01:52 -0400 (EDT) Date: Sat, 17 Jul 1999 16:01:50 -0500 (EST) From: Alfred Perlstein To: Dag-Erling Smorgrav Cc: hackers@FreeBSD.ORG Subject: Re: Determining the return address In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 17 Jul 1999, Dag-Erling Smorgrav wrote: > Is there any (evidently non-portable) way of determining a function > instance's return address? I have an idea or two that involves the > return address and dladdr(). The code I currently use looks like this: > > int > log_print(log_t *log, char *fmt, ...) > { > char date[32], str[MAX_LOG_LINE]; > struct iovec iov[10]; > Dl_info info; > size_t len; > va_list ap; > int n; > > len = log_makedate(date, sizeof date); > iov[n=0].iov_base = date; > iov[n].iov_len = len; > > if (dladdr(*(((void**)&log)-1), &info) == 0) > iov[++n].iov_base = "(unknown)"; > else > iov[++n].iov_base = (char *)info.dli_sname; > iov[n].iov_len = strlen(iov[n].iov_base); ... > > > Is it correct? (empirical evidence suggests it is) Is there any better > way to do it? Will it work on the Alpha? This looks like what you are doing is trying to grab the data on the stack before "log" which is the return address. I doubt this is at all portable and may fail because of optimizations and ABI, such as archs that store the return address in a register... gdb and glibc have some functions to assist in runtime backtraces, perhaps a look there may help? > > BTW, is dladdr() signal-safe? not according to the sigaction man page. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 14:26:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from venus.GAIANET.NET (venus.GAIANET.NET [207.211.200.51]) by hub.freebsd.org (Postfix) with ESMTP id 6A3C314C57 for ; Sat, 17 Jul 1999 14:25:59 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Received: from localhost (vince@localhost) by venus.GAIANET.NET (8.9.3/8.9.3) with ESMTP id OAA18181; Sat, 17 Jul 1999 14:25:41 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Date: Sat, 17 Jul 1999 14:25:41 -0700 (PDT) From: Vincent Poy To: sthaug@nethelp.no Cc: tim@storm.digital-rain.com, freebsd-hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? In-Reply-To: <51881.932205646@verdi.nethelp.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 17 Jul 1999 sthaug@nethelp.no wrote: > > I am benefiting from it for sure. I guess what I was asking > > originally was if the higher frequency rated cables will give it more > > headroom since the 100BaseTX ethernet does push CAT5 to the limit. > > 100BaseTX is specified to run on Cat5 cabling, and with proper Cat5 > cabling you get a a BER of 10^-8 or better. Speaking about specifications, what's the spec to run 100BaseT4? > As long as your cabling meets the Cat5 spec, you'll get 100 Mbps - > there's no possibility of "more headroom" with cables rated to higher > frequency. Note that 100BaseTX is different from 10BaseT (but similar > to synchronous serial lines) in that there is always a signal present. > Note also that FreeBSD can easily saturate 100 Mbps Ethernet. It meets the spec when shipped but the bends, curves, temperature and other factors do affect the performance. I guess a good way to test the cable is with FreeBSD since it's the only real OS I've seen that can do like real world speeds. The only thing is that has anyone really saw 12 Megabytes/sec Full Duplex under FreeBSD? Cheers, Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 14:39:59 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from arnold.neland.dk (mail.neland.dk [194.255.12.232]) by hub.freebsd.org (Postfix) with ESMTP id 191B514C57 for ; Sat, 17 Jul 1999 14:39:36 -0700 (PDT) (envelope-from leifn@neland.dk) Received: from gina (gina.neland.dk [192.168.0.14]) by arnold.neland.dk (8.9.3/8.9.3) with SMTP id XAA41656 for ; Sat, 17 Jul 1999 23:39:28 +0200 (CEST) (envelope-from leifn@neland.dk) Message-ID: <007301bed09c$e50777a0$0e00a8c0@neland.dk> From: "Leif Neland" To: "FreeBSD Hackers" Subject: softupdates on root partition, no floppy Date: Sat, 17 Jul 1999 23:39:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a machine with two scsi disks, one with /, one with /usr, and no floppy. I have turned on softupdates on /usr while usr was unmounted, but I can't turn on softupdates on /, because it is always mounted. Normally the answer would be to boot on a floppy, but the machine doesn't have a floppydrive. Is there any way to force softupdate on on a mounted system, or do I have to either move the / to another machine, or move a floppydrive to this machine? Leif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 15: 8: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id E82B514C8C for ; Sat, 17 Jul 1999 15:08:00 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id PAA20593; Sat, 17 Jul 1999 15:07:51 -0700 Date: Sat, 17 Jul 1999 15:07:51 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Daniel C. Sobral" Cc: Mike Smith , freebsd-hackers@FreeBSD.ORG Subject: Re: System unique identifier..... In-Reply-To: <3790AD50.DC28CD62@newsguy.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Mike Smith wrote: > > > > The loader will, at some stage in the future, grow a persistent data > > store in which items like this can be saved. > > Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent > data storage? Not if the items stored there are needed prior to being able to read it. Probably not a problem because it really becomes more of a persistent boot property which is platform specific. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 15:14:33 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (Postfix) with ESMTP id 7667E14C18 for ; Sat, 17 Jul 1999 15:14:17 -0700 (PDT) (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca-tx.tdx.co.uk [195.188.177.242]) by caladan.tdx.co.uk (8.9.3/8.9.3/Kp) with ESMTP id XAA91738; Sat, 17 Jul 1999 23:13:56 +0100 (BST) Message-ID: <3790FFFC.D0AAB31C@tdx.co.uk> Date: Sat, 17 Jul 1999 23:13:16 +0100 From: Karl Pielorz Organization: TDX - The Digital eXchange X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Craig Johnston Cc: hackers@FreeBSD.ORG Subject: Re: vinum is cool. anyone bitten recently? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Craig Johnston wrote: > > Well, I'm looking into doing striping and mirroring on a new webserver > I am bringing up (3.2-stable) and I have to say, vinum looks very cool. > It took me like half an hour to get it going from first contact. > > Nice job Greg -- very straightforward. > > Now, the official status of vinum is still alpha, right? But then > again I know that that was (is?) the official status of softupdates > for quite some time and I have been using it with no problems. Hi, We've been running vinum for quite a while on a number of systems... It's not 'bitten' us for a while, but it is _extremly_ intolerant of bad drives/termination/hardware etc. In fact, I would go as far as saying, nothing stresses the system more than building the world with a high -j factor on Vinum drives :-) We have 2 x 4.0-Current boxes running Vinum, and 1 x 3.2-Release box running vinum - all are healthy so far (Though two of the systems did have a couple of problems from the outset, which have recently been cured through 'better' setups (i.e. SCSI bus configuration etc.)... Having said that - it is 'alpha' / new - and you should take appropriate precautions... i.e. Don't bet your life on it, and as _always_ have nice regular backups... :) -Karl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 15:18:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (Postfix) with ESMTP id 97DF914C18 for ; Sat, 17 Jul 1999 15:18:22 -0700 (PDT) (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca-tx.tdx.co.uk [195.188.177.242]) by caladan.tdx.co.uk (8.9.3/8.9.3/Kp) with ESMTP id XAA92249; Sat, 17 Jul 1999 23:17:59 +0100 (BST) Message-ID: <379100EF.CF14F1B4@tdx.co.uk> Date: Sat, 17 Jul 1999 23:17:19 +0100 From: Karl Pielorz Organization: TDX - The Digital eXchange X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Vincent Poy Cc: sthaug@nethelp.no, tim@storm.digital-rain.com, freebsd-hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Vincent Poy wrote: > > Note also that FreeBSD can easily saturate 100 Mbps Ethernet. > > It meets the spec when shipped but the bends, curves, temperature > and other factors do affect the performance. I guess a good way to test > the cable is with FreeBSD since it's the only real OS I've seen that can > do like real world speeds. The only thing is that has anyone really saw > 12 Megabytes/sec Full Duplex under FreeBSD? There again, any network installer worth their salt will test the cable when in-situ, after the 'dust' has settled... Fastest I've seen on my setup (doing anything useful) is around 9Mb/sec going from my WinNT box (with Intel Pro 100B) to my FreeBSD -current box (also with Pro 100B). So far, transfers from FreeBSD to WinNT are _always_ slower than transfers from WinNT to FreeBSD - which considering the hardware and write-overhead etc. - you would have though the opposite should be true... I guess NT ain't a great operating system after all... -Karl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 15:24:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from venus.GAIANET.NET (venus.GAIANET.NET [207.211.200.51]) by hub.freebsd.org (Postfix) with ESMTP id 42FBA14F59 for ; Sat, 17 Jul 1999 15:24:18 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Received: from localhost (vince@localhost) by venus.GAIANET.NET (8.9.3/8.9.3) with ESMTP id PAA18442; Sat, 17 Jul 1999 15:22:56 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Date: Sat, 17 Jul 1999 15:22:56 -0700 (PDT) From: Vincent Poy To: Karl Pielorz Cc: sthaug@nethelp.no, tim@storm.digital-rain.com, freebsd-hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? In-Reply-To: <379100EF.CF14F1B4@tdx.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 17 Jul 1999, Karl Pielorz wrote: > Vincent Poy wrote: > > > > Note also that FreeBSD can easily saturate 100 Mbps Ethernet. > > > > It meets the spec when shipped but the bends, curves, temperature > > and other factors do affect the performance. I guess a good way to test > > the cable is with FreeBSD since it's the only real OS I've seen that can > > do like real world speeds. The only thing is that has anyone really saw > > 12 Megabytes/sec Full Duplex under FreeBSD? > > There again, any network installer worth their salt will test the cable when > in-situ, after the 'dust' has settled... Testing after the dust has settled and while it is in use is different since conditions do change. The testers only tests for continuity, not the impedance or any other electrical properties of the cable. > Fastest I've seen on my setup (doing anything useful) is around 9Mb/sec going > from my WinNT box (with Intel Pro 100B) to my FreeBSD -current box (also with > Pro 100B). Hmmm, how large of a file do you have to transfer to see the max speed? > So far, transfers from FreeBSD to WinNT are _always_ slower than transfers > from WinNT to FreeBSD - which considering the hardware and write-overhead etc. > - you would have though the opposite should be true... I guess NT ain't a > great operating system after all... What about from FreeBSD to FreeBSD? =) Cheers, Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 15:38: 6 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id C83C614F6B for ; Sat, 17 Jul 1999 15:37:56 -0700 (PDT) (envelope-from sthaug@nethelp.no) Received: (qmail 60049 invoked by uid 1001); 17 Jul 1999 22:37:53 +0000 (GMT) To: vince@venus.GAIANET.NET Cc: tim@storm.digital-rain.com, freebsd-hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? From: sthaug@nethelp.no In-Reply-To: Your message of "Sat, 17 Jul 1999 14:25:41 -0700 (PDT)" References: X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sun, 18 Jul 1999 00:37:53 +0200 Message-ID: <60044.932251073@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > It meets the spec when shipped but the bends, curves, temperature > and other factors do affect the performance. I guess a good way to test > the cable is with FreeBSD since it's the only real OS I've seen that can > do like real world speeds. The only thing is that has anyone really saw > 12 Megabytes/sec Full Duplex under FreeBSD? If you mean mega = 1048576, it's impossible since this is faster than 100 Mbps whichever way you count it. If you mean mega = 1000000, it depends on which way you're counting. The "speed of light" for TCP, application to application, on 100 Mbps Ethernet is 100 * 1460/1538 = 94.93 Mbps. This assumes full duplex. I've measured 94.87 Mbps myself on full duplex 100BaseTX (back to back with a crossover cable or through a switch). This is close enough to the "speed of light" that I see no point in trying to improve on it... Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 15:43:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from venus.GAIANET.NET (venus.GAIANET.NET [207.211.200.51]) by hub.freebsd.org (Postfix) with ESMTP id C67A814D85 for ; Sat, 17 Jul 1999 15:43:33 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Received: from localhost (vince@localhost) by venus.GAIANET.NET (8.9.3/8.9.3) with ESMTP id PAA18532; Sat, 17 Jul 1999 15:43:22 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Date: Sat, 17 Jul 1999 15:43:22 -0700 (PDT) From: Vincent Poy To: sthaug@nethelp.no Cc: tim@storm.digital-rain.com, freebsd-hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? In-Reply-To: <60044.932251073@verdi.nethelp.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 18 Jul 1999 sthaug@nethelp.no wrote: > > It meets the spec when shipped but the bends, curves, temperature > > and other factors do affect the performance. I guess a good way to test > > the cable is with FreeBSD since it's the only real OS I've seen that can > > do like real world speeds. The only thing is that has anyone really saw > > 12 Megabytes/sec Full Duplex under FreeBSD? > > If you mean mega = 1048576, it's impossible since this is faster than 100 > Mbps whichever way you count it. > > If you mean mega = 1000000, it depends on which way you're counting. The > "speed of light" for TCP, application to application, on 100 Mbps Ethernet > is 100 * 1460/1538 = 94.93 Mbps. This assumes full duplex. I mean Mega as in 1000000. 100Mbps Ethernet should be equal to about 12500Kbytes/sec which is equal to 12.5Mbytes/sec. 94.93Megabits/sec doesn't equal to 100Megabits/sec. > I've measured 94.87 Mbps myself on full duplex 100BaseTX (back to back > with a crossover cable or through a switch). This is close enough to > the "speed of light" that I see no point in trying to improve on it... Yeah but what's the transfer rate you get? Cheers, Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 15:53: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id EFDB114BEC for ; Sat, 17 Jul 1999 15:53:00 -0700 (PDT) (envelope-from sthaug@nethelp.no) Received: (qmail 60229 invoked by uid 1001); 17 Jul 1999 22:51:31 +0000 (GMT) To: vince@venus.GAIANET.NET Cc: tim@storm.digital-rain.com, freebsd-hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? From: sthaug@nethelp.no In-Reply-To: Your message of "Sat, 17 Jul 1999 15:43:22 -0700 (PDT)" References: X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sun, 18 Jul 1999 00:51:31 +0200 Message-ID: <60227.932251891@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I mean Mega as in 1000000. 100Mbps Ethernet should be equal to > about 12500Kbytes/sec which is equal to 12.5Mbytes/sec. 94.93Megabits/sec > doesn't equal to 100Megabits/sec. 12.5 Mbytes/sec on the wire *is* 94.93 Megabits/sec application to application using TCP - that's what I'm trying to say. You'll never see 12.5 Mbytes/sec application to application - look up the Ethernet frame formats to see why (1460 bytes of TCP payload is 1538 bytes on the wire). > > I've measured 94.87 Mbps myself on full duplex 100BaseTX (back to back > > with a crossover cable or through a switch). This is close enough to > > the "speed of light" that I see no point in trying to improve on it... > > Yeah but what's the transfer rate you get? 94.87 Mbps, application to application, using ttcp. Using Mega = 1000000, that should be 11.86 MBytes/sec. Oh yeah, this was measured with FreeBSD, with a P-133 on the receving end, back in '96 :-) Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 16: 1:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from venus.GAIANET.NET (venus.GAIANET.NET [207.211.200.51]) by hub.freebsd.org (Postfix) with ESMTP id 7A3E514C27 for ; Sat, 17 Jul 1999 16:01:52 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Received: from localhost (vince@localhost) by venus.GAIANET.NET (8.9.3/8.9.3) with ESMTP id QAA18627; Sat, 17 Jul 1999 16:01:40 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Date: Sat, 17 Jul 1999 16:01:40 -0700 (PDT) From: Vincent Poy To: sthaug@nethelp.no Cc: tim@storm.digital-rain.com, freebsd-hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? In-Reply-To: <60227.932251891@verdi.nethelp.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 18 Jul 1999 sthaug@nethelp.no wrote: > > I mean Mega as in 1000000. 100Mbps Ethernet should be equal to > > about 12500Kbytes/sec which is equal to 12.5Mbytes/sec. 94.93Megabits/sec > > doesn't equal to 100Megabits/sec. > > 12.5 Mbytes/sec on the wire *is* 94.93 Megabits/sec application to > application using TCP - that's what I'm trying to say. You'll never see > 12.5 Mbytes/sec application to application - look up the Ethernet frame > formats to see why (1460 bytes of TCP payload is 1538 bytes on the wire). I guess I forgot about the overhead. I've tested between two FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco 2924XL Switch Full Duplex and never seen anything close to the speeds. > > > I've measured 94.87 Mbps myself on full duplex 100BaseTX (back to back > > > with a crossover cable or through a switch). This is close enough to > > > the "speed of light" that I see no point in trying to improve on it... > > > > Yeah but what's the transfer rate you get? > > 94.87 Mbps, application to application, using ttcp. Using Mega = 1000000, > that should be 11.86 MBytes/sec. > > Oh yeah, this was measured with FreeBSD, with a P-133 on the receving end, > back in '96 :-) Hmmm, how did you do the measurement and how big of a file does it need? With a 122MByte file, it only does 2644Kbytes/sec. This is between two Pentium II 450 machines with Intel Pro100+ NICs. Cheers, Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 16: 6:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 8BEDD14F46 for ; Sat, 17 Jul 1999 16:06:49 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA81618; Sat, 17 Jul 1999 16:06:38 -0700 (PDT) (envelope-from dillon) Date: Sat, 17 Jul 1999 16:06:38 -0700 (PDT) From: Matthew Dillon Message-Id: <199907172306.QAA81618@apollo.backplane.com> To: "Leif Neland" Cc: "FreeBSD Hackers" Subject: Re: softupdates on root partition, no floppy References: <007301bed09c$e50777a0$0e00a8c0@neland.dk> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I have a machine with two scsi disks, one with /, one with /usr, and no :floppy. :I have turned on softupdates on /usr while usr was unmounted, but I can't :turn on softupdates on /, because it is always mounted. : :Normally the answer would be to boot on a floppy, but the machine doesn't :have a floppydrive. : :Is there any way to force softupdate on on a mounted system, or do I have to :either move the / to another machine, or move a floppydrive to this machine? : :Leif If you boot single-user, root will be mounted read-only and you should be able to 'tunefs -n enable /dev/rda0a' and reboot. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 16:10:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id 4F18F14EBB for ; Sat, 17 Jul 1999 16:10:51 -0700 (PDT) (envelope-from sthaug@nethelp.no) Received: (qmail 60402 invoked by uid 1001); 17 Jul 1999 23:10:33 +0000 (GMT) To: vince@venus.GAIANET.NET Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? From: sthaug@nethelp.no In-Reply-To: Your message of "Sat, 17 Jul 1999 16:01:40 -0700 (PDT)" References: X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sun, 18 Jul 1999 01:10:33 +0200 Message-ID: <60400.932253033@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hmmm, how did you do the measurement and how big of a file does it > need? As I said, I used ttcp. ttcp is a "network only" test - it can source or sink traffic itself. This is nice because you avoid other sources of problems (disk bandwidth etc). I tended to run the tests for 30 seconds to one minute. Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 16:17:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from venus.GAIANET.NET (venus.GAIANET.NET [207.211.200.51]) by hub.freebsd.org (Postfix) with ESMTP id 4873314BFC for ; Sat, 17 Jul 1999 16:17:05 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Received: from localhost (vince@localhost) by venus.GAIANET.NET (8.9.3/8.9.3) with ESMTP id QAA18703; Sat, 17 Jul 1999 16:14:19 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Date: Sat, 17 Jul 1999 16:14:19 -0700 (PDT) From: Vincent Poy To: sthaug@nethelp.no Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? In-Reply-To: <60400.932253033@verdi.nethelp.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 18 Jul 1999 sthaug@nethelp.no wrote: > > Hmmm, how did you do the measurement and how big of a file does it > > need? > > As I said, I used ttcp. ttcp is a "network only" test - it can source > or sink traffic itself. This is nice because you avoid other sources of > problems (disk bandwidth etc). I tended to run the tests for 30 seconds > to one minute. Oops, must have missed that one. How do I do the ttcp test? Cheers, Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 16:17:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from arnold.neland.dk (mail.neland.dk [194.255.12.232]) by hub.freebsd.org (Postfix) with ESMTP id 4E25214F7F for ; Sat, 17 Jul 1999 16:17:34 -0700 (PDT) (envelope-from leifn@neland.dk) Received: from gina (gina.neland.dk [192.168.0.14]) by arnold.neland.dk (8.9.3/8.9.3) with SMTP id BAA62537; Sun, 18 Jul 1999 01:16:19 +0200 (CEST) (envelope-from leifn@neland.dk) Message-ID: <045e01bed0aa$6a4cfa40$0e00a8c0@neland.dk> From: "Leif Neland" To: "Vincent Poy" Cc: References: Subject: Sv: poor ethernet performance? Date: Sun, 18 Jul 1999 01:14:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ----- Original Message ----- From: Vincent Poy To: Karl Pielorz Cc: ; ; Sent: Sunday, July 18, 1999 12:22 AM Subject: Re: poor ethernet performance? > > There again, any network installer worth their salt will test the cable when > > in-situ, after the 'dust' has settled... > > Testing after the dust has settled and while it is in use is > different since conditions do change. The testers only tests for > continuity, not the impedance or any other electrical properties of the > cable. > Depends on the tester. Our electrician had a $1500 tester, which gave a printout of several electrical properties of each installed cable; this was included in the documentation of the network, which also included nice cad-drawings of the location of every outlet. Leif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 16:17:53 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id B37C815025 for ; Sat, 17 Jul 1999 16:17:47 -0700 (PDT) (envelope-from sthaug@nethelp.no) Received: (qmail 60467 invoked by uid 1001); 17 Jul 1999 23:17:30 +0000 (GMT) To: vince@venus.GAIANET.NET Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? From: sthaug@nethelp.no In-Reply-To: Your message of "Sat, 17 Jul 1999 16:14:19 -0700 (PDT)" References: X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sun, 18 Jul 1999 01:17:30 +0200 Message-ID: <60465.932253450@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > As I said, I used ttcp. ttcp is a "network only" test - it can source > > or sink traffic itself. This is nice because you avoid other sources of > > problems (disk bandwidth etc). I tended to run the tests for 30 seconds > > to one minute. > > Oops, must have missed that one. How do I do the ttcp test? By reading the man page? (This is no longer freebsd-hackers stuff, methinks...) ttcp -r on the receiver and ttcp -t on the sender is a good start. Proceed from there. Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 16:23:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 4674314F9C for ; Sat, 17 Jul 1999 16:23:24 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA81716; Sat, 17 Jul 1999 16:20:39 -0700 (PDT) (envelope-from dillon) Date: Sat, 17 Jul 1999 16:20:39 -0700 (PDT) From: Matthew Dillon Message-Id: <199907172320.QAA81716@apollo.backplane.com> To: Vincent Poy Cc: sthaug@nethelp.no, tim@storm.digital-rain.com, freebsd-hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : Hmmm, how did you do the measurement and how big of a file does it :need? : : With a 122MByte file, it only does 2644Kbytes/sec. This is :between two Pentium II 450 machines with Intel Pro100+ NICs. : : :Cheers, :Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ 2.6 MB/sec is what I would expect if you were running the test over an ssh link on a fast cpu - the encryption eats a lot of cpu. But a normal rcp or ftp or data transfer can easily do 9-10 MBytes/sec. test3:/root# /usr/bin/rsh apollo -n "dd if=/images/swap/swap.209.157.86.6 bs=16k" > /dev/null 8192+0 records in 8192+0 records out 134217728 bytes transferred in 13.558270 secs (9899326 bytes/sec) test3:/root# /usr/bin/rsh apollo -n "dd if=/images/swap/swap.209.157.86.6 bs=16k" > /dev/null 8192+0 records in 8192+0 records out 134217728 bytes transferred in 13.530817 secs (9919410 bytes/sec) This is over 100BaseTX, *HALF* duplex running through a hub. 9.9 MBytes/sec. (using 1 MByte = 1000 * 1000). But if I use ssh instead, which I do only so I remember to turn off the shell service in my inetd.conf that I just turned on a moment ago, I am limited by apollo's poor PPro-200 and get: test3:/root# ssh apollo -n "dd if=/images/swap/swap.209.157.86.6 bs=16k" > /dev/null 8192+0 records in 8192+0 records out 134217728 bytes transferred in 96.545217 secs (1390206 bytes/sec) test3:/root# -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 16:31:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net [194.217.242.41]) by hub.freebsd.org (Postfix) with ESMTP id 6523914C4E for ; Sat, 17 Jul 1999 16:31:41 -0700 (PDT) (envelope-from dmlb@ragnet.demon.co.uk) Received: from ragnet.demon.co.uk ([158.152.46.40]) by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1) id 115duY-000JjW-0C; Sat, 17 Jul 1999 23:30:31 +0000 Received: from dmlb by ragnet.demon.co.uk with local (Exim 2.12 #1) id 115ZHR-000PDd-00; Sat, 17 Jul 1999 19:33:49 +0100 Content-Length: 754 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199907171529.IAA74679@apollo.backplane.com> Date: Sat, 17 Jul 1999 19:33:49 +0100 (BST) From: Duncan Barclay To: Matthew Dillon Subject: Re: poor ethernet performance? Cc: hackers@FreeBSD.ORG, crypt0genic , Bill Paul , Vincent Poy Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 17-Jul-99 Matthew Dillon wrote: > > Obviously you don't get square waves going down the wire - But it is > still a digital communications protocol. > > -Matt However the physical layer, i.e. the cable, is analogue and the discussion was about cables. To carry your reasoning a bit further - a digital cellular phone system is not an RF/Wireless system because the data is digital. I hope we agree that it is! Duncan --- ________________________________________________________________________ Duncan Barclay | God smiles upon the little children, dmlb@ragnet.demon.co.uk | the alcoholics, and the permanently stoned. ________________________________________________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 16:33: 2 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from venus.GAIANET.NET (venus.GAIANET.NET [207.211.200.51]) by hub.freebsd.org (Postfix) with ESMTP id 04E2714C4E for ; Sat, 17 Jul 1999 16:32:59 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Received: from localhost (vince@localhost) by venus.GAIANET.NET (8.9.3/8.9.3) with ESMTP id QAA18789; Sat, 17 Jul 1999 16:31:23 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Date: Sat, 17 Jul 1999 16:31:23 -0700 (PDT) From: Vincent Poy To: Leif Neland Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Sv: poor ethernet performance? In-Reply-To: <045e01bed0aa$6a4cfa40$0e00a8c0@neland.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 18 Jul 1999, Leif Neland wrote: > > > There again, any network installer worth their salt will test the cable > when > > > in-situ, after the 'dust' has settled... > > > > Testing after the dust has settled and while it is in use is > > different since conditions do change. The testers only tests for > > continuity, not the impedance or any other electrical properties of the > > cable. > > > Depends on the tester. Our electrician had a $1500 tester, which gave a > printout of several electrical properties of each installed cable; this was > included in the documentation of the network, which also included nice > cad-drawings of the location of every outlet. I know that can be done... I'm just saying during the actual use of the cable, people don't constantly keep testing it. Cheers, Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 16:37:31 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from venus.GAIANET.NET (venus.GAIANET.NET [207.211.200.51]) by hub.freebsd.org (Postfix) with ESMTP id 0347214CE6 for ; Sat, 17 Jul 1999 16:37:28 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Received: from localhost (vince@localhost) by venus.GAIANET.NET (8.9.3/8.9.3) with ESMTP id QAA18818; Sat, 17 Jul 1999 16:35:54 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Date: Sat, 17 Jul 1999 16:35:54 -0700 (PDT) From: Vincent Poy To: sthaug@nethelp.no Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? In-Reply-To: <60465.932253450@verdi.nethelp.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 18 Jul 1999 sthaug@nethelp.no wrote: > > > As I said, I used ttcp. ttcp is a "network only" test - it can source > > > or sink traffic itself. This is nice because you avoid other sources of > > > problems (disk bandwidth etc). I tended to run the tests for 30 seconds > > > to one minute. > > > > Oops, must have missed that one. How do I do the ttcp test? > > By reading the man page? The manpage doesn't really say anything about how to use ttcp... > (This is no longer freebsd-hackers stuff, methinks...) > > ttcp -r on the receiver and ttcp -t on the sender is a good start. > Proceed from there. Cheers, Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 16:44:58 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from venus.GAIANET.NET (venus.GAIANET.NET [207.211.200.51]) by hub.freebsd.org (Postfix) with ESMTP id C41DF14CE6 for ; Sat, 17 Jul 1999 16:44:54 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Received: from localhost (vince@localhost) by venus.GAIANET.NET (8.9.3/8.9.3) with ESMTP id QAA18842; Sat, 17 Jul 1999 16:41:35 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Date: Sat, 17 Jul 1999 16:41:35 -0700 (PDT) From: Vincent Poy To: Matthew Dillon Cc: sthaug@nethelp.no, tim@storm.digital-rain.com, freebsd-hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? In-Reply-To: <199907172320.QAA81716@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 17 Jul 1999, Matthew Dillon wrote: > : Hmmm, how did you do the measurement and how big of a file does it > :need? > : > : With a 122MByte file, it only does 2644Kbytes/sec. This is > :between two Pentium II 450 machines with Intel Pro100+ NICs. > > 2.6 MB/sec is what I would expect if you were running the test > over an ssh link on a fast cpu - the encryption eats a lot of cpu. But > a normal rcp or ftp or data transfer can easily do 9-10 MBytes/sec. That was actually done with ftp between two machines connected Full Duplex to a Cisco Catalyst 2924XL switch. > This is over 100BaseTX, *HALF* duplex running through a hub. 9.9 > MBytes/sec. > (using 1 MByte = 1000 * 1000). > > But if I use ssh instead, which I do only so I remember to turn off > the shell service in my inetd.conf that I just turned on a moment ago, > I am limited by apollo's poor PPro-200 and get: > > test3:/root# ssh apollo -n "dd if=/images/swap/swap.209.157.86.6 bs=16k" > /dev/null > 8192+0 records in > 8192+0 records out > 134217728 bytes transferred in 96.545217 secs (1390206 bytes/sec) > test3:/root# Interesting... Cheers, Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 16:45:47 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from venus.GAIANET.NET (venus.GAIANET.NET [207.211.200.51]) by hub.freebsd.org (Postfix) with ESMTP id 6BEA214E88 for ; Sat, 17 Jul 1999 16:45:45 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Received: from localhost (vince@localhost) by venus.GAIANET.NET (8.9.3/8.9.3) with ESMTP id QAA18858; Sat, 17 Jul 1999 16:44:38 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Date: Sat, 17 Jul 1999 16:44:38 -0700 (PDT) From: Vincent Poy To: sthaug@nethelp.no Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 17 Jul 1999, Vincent Poy wrote: > > > > As I said, I used ttcp. ttcp is a "network only" test - it can source > > > > or sink traffic itself. This is nice because you avoid other sources of > > > > problems (disk bandwidth etc). I tended to run the tests for 30 seconds > > > > to one minute. > > > > > > Oops, must have missed that one. How do I do the ttcp test? > > > > By reading the man page? > > The manpage doesn't really say anything about how to use ttcp... > > > (This is no longer freebsd-hackers stuff, methinks...) > > > > ttcp -r on the receiver and ttcp -t on the sender is a good start. > > Proceed from there. There is no ttcp binary anywhere on either my -CURRENT, 3.2-RELEASE and 3.1-RELEASE systems. Cheers, Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 16:45:57 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from caladan.tdx.co.uk (caladan.tdx.co.uk [195.188.177.4]) by hub.freebsd.org (Postfix) with ESMTP id 6227415018 for ; Sat, 17 Jul 1999 16:45:53 -0700 (PDT) (envelope-from kpielorz@tdx.co.uk) Received: from tdx.co.uk (lorca-tx.tdx.co.uk [195.188.177.242]) by caladan.tdx.co.uk (8.9.3/8.9.3/Kp) with ESMTP id AAA00976; Sun, 18 Jul 1999 00:45:04 +0100 (BST) Message-ID: <37911557.8B0A5293@tdx.co.uk> Date: Sun, 18 Jul 1999 00:44:23 +0100 From: Karl Pielorz Organization: TDX - The Digital eXchange X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Vincent Poy Cc: sthaug@nethelp.no, tim@storm.digital-rain.com, freebsd-hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Vincent Poy wrote: > Testing after the dust has settled and while it is in use is > different since conditions do change. The testers only tests for > continuity, not the impedance or any other electrical properties of the > cable. The decent testers (such as a professional cable installing friend of mine uses) do a full range of tests, at both 10Mbs and 100Mbs speed, including cross talk, attenuation + a host of other things. The customers gets a certificate _per_ connection, listing all the details... The decent testers use proper TDR techniques to do a full range of testing, more than just "The wires conduct, and their in the right order at both ends" :-) > > Fastest I've seen on my setup (doing anything useful) is around 9Mb/sec going > > from my WinNT box (with Intel Pro 100B) to my FreeBSD -current box (also with > > Pro 100B). > > Hmmm, how large of a file do you have to transfer to see the max > speed? Typically around 2Gb's... I do a lot of DVR work, so I always have large files kicking around :-) > What about from FreeBSD to FreeBSD? =) Don't have two boxes to test from... I've toyed with replacing my current NT install with FreeBSD, I guess I just love Delphi too much :-) [hence need Win32 :)] + The company database runs only under Win32 so far... This is getting off-topic for -hackers - if you want to chat we should either move it somewhere more appropriate - or personal replies only :-) -Kp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 16:48: 9 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 4264114CE6 for ; Sat, 17 Jul 1999 16:48:05 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id TAA99317; Sat, 17 Jul 1999 19:47:24 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Sat, 17 Jul 1999 19:47:23 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: "David E. Cross" Cc: freebsd-hackers@FreeBSD.org Subject: Re: USFS (User Space File System) In-Reply-To: <199907171857.OAA81681@cs.rpi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Look into the portal filesystem. This is what you want :) Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 17:36: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id CB6D614C57; Sat, 17 Jul 1999 17:36:05 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA86259; Sat, 17 Jul 1999 17:33:40 -0700 (PDT) (envelope-from dillon) Date: Sat, 17 Jul 1999 17:33:40 -0700 (PDT) From: Matthew Dillon Message-Id: <199907180033.RAA86259@apollo.backplane.com> To: "Brian F. Feldman" Cc: "David E. Cross" , freebsd-hackers@FreeBSD.ORG Subject: Re: USFS (User Space File System) References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Look into the portal filesystem. This is what you want :) : : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ : green@FreeBSD.org _ __ ___ | _ ) __| \ Actually, it isn't quite. All the portal filesystem will allow you to do is pass back a descriptor. It does not allow you to simulate a filesystem. But something similar to what the portal filesystem does would be cool -- maybe a real protocol to pass the VOP requests down to a user process and get responses & data. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 17:47:21 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 0594B14C3C for ; Sat, 17 Jul 1999 17:47:18 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA86301; Sat, 17 Jul 1999 17:44:33 -0700 (PDT) (envelope-from dillon) Date: Sat, 17 Jul 1999 17:44:33 -0700 (PDT) From: Matthew Dillon Message-Id: <199907180044.RAA86301@apollo.backplane.com> To: Vincent Poy Cc: sthaug@nethelp.no, tim@storm.digital-rain.com, freebsd-hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> 2.6 MB/sec is what I would expect if you were running the test :> over an ssh link on a fast cpu - the encryption eats a lot of cpu. But :> a normal rcp or ftp or data transfer can easily do 9-10 MBytes/sec. : : That was actually done with ftp between two machines connected :Full Duplex to a Cisco Catalyst 2924XL switch. :Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ You've got breakage somewhere, I've run 9-10 MBytes/sec in both directions at once through a catalyst between two FreeBSD boxes at full-duplex. Check for interface errors or collisions - this kinda sounds like the duplex hasn't been matched up. You should have no errors and no collisions at all if you are running full-duplex. Make sure the duplex and port speed on the catalyst is hardwired -- we have had no end of troubles with the autodetect junk on catalysts. It also doesn't hurt to hardware the duplex and port speed on the UNIX boxes. If you still have problems there are a number of possibilities. If you are using discrete RJ45 ports try switching the cables as well as use a different catalyst port. If you are using telco cables - those big fat 50 or 100 pair cables that use centronics-like connectors on the catalyst side hat, you probably have an RJ45 punchdown block on the other end. These have to be Cat-5 punchdown blocks, not Cat-3 punchdown blocks. Try a different port on the punchdown block. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 17:52:50 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 5FABD14C3C for ; Sat, 17 Jul 1999 17:52:47 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA86335; Sat, 17 Jul 1999 17:50:36 -0700 (PDT) (envelope-from dillon) Date: Sat, 17 Jul 1999 17:50:36 -0700 (PDT) From: Matthew Dillon Message-Id: <199907180050.RAA86335@apollo.backplane.com> To: Duncan Barclay Cc: hackers@FreeBSD.ORG, crypt0genic , Bill Paul , Vincent Poy Subject: Re: poor ethernet performance? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :On 17-Jul-99 Matthew Dillon wrote: :> :> Obviously you don't get square waves going down the wire - But it is :> still a digital communications protocol. :> :> -Matt : :However the physical layer, i.e. the cable, is analogue and the discussion was :about cables. To carry your reasoning a bit further - a digital :cellular phone system is not an RF/Wireless system because the data is digital. :I hope we agree that it is! : :Duncan Duncan, the entire physical world is an analog medium. Well, not including quantum mechanical effects anyway. Even the photons running down *FIBER* are essentially analog signals - because the lasers cannot be turned on and off instantly. The difference between treating the medium as analog or digital is that when you treat it as digital you quantize it well above the noise floor and treat errors seriously - the idea is to recover the data exactly as it was sent. When you treat the medium as analog, you either do not quantize it at all, or you quantize it close to the noise floor and ignore the errors. The recovered data does not have to exactly match what was sent. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 18:28:11 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from search.sparks.net (search.sparks.net [208.5.188.60]) by hub.freebsd.org (Postfix) with ESMTP id 451AC14F6B for ; Sat, 17 Jul 1999 18:28:02 -0700 (PDT) (envelope-from dmiller@search.sparks.net) Received: by search.sparks.net (Postfix, from userid 100) id 57457258; Sat, 17 Jul 1999 21:28:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by search.sparks.net (Postfix) with SMTP id 459F6244; Sat, 17 Jul 1999 21:28:02 -0400 (EDT) Date: Sat, 17 Jul 1999 21:28:02 -0400 (EDT) From: David Miller To: Matthew Dillon Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: 650 MB MFS? In-Reply-To: <199907152006.NAA12783@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Jul 1999, Matthew Dillon wrote: > : > :Are there any design limits to mfs? I want to use cdrecord to write to a > :dozen or so CD's at once, and fear making lots of coasters if I run them > :all off a single on-disk file. However, a CD only holds 650 MB, so it > :seems like I could have the image on mfs and sleep well sans coasters. > : > :Would FreeBSD handle an mfs of this size? > > Well, if you have 650MB of ram available... I suppose. > Otherwise MFS is just going to shove the data into > swap. These days 650 isn't that hard:) > > The answer is, yes you can create an MFS partition that > large. You have to make sure that you have sufficient > swap available and that your datasize resource limit is > big enough. > > So, checklist: > > * You will need 650MB of swap, possibly even more. > (unless you have 650MB+ of ram in your system) > > * from csh, 'unlimit data' then type 'limit' to > see what your maximum datasize limit is. You > may have to reconfigure your kernel to increase > it: > > options "MAXDSIZ=(1024*1024*1024)" Thanks, this is an easy one to overlook:) > * Look into using the VN device instead of MFS. > VN allows you to create a 'disk file' and then > turn it into a partition that you can then > mount and use normally. I'm not sure what good that will do me. The point of the exercise is to ensure that cdrecord never has to wait on enough seeks to create coasters. Putting it all in ram before starting should do this, but a different interface to the same data on disk doesn't. Unless I'm missing something, which is usually the case:) Thanks for the answers Matt! --- David To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 18:48:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 5E1AF14D06 for ; Sat, 17 Jul 1999 18:48:26 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA88154; Sat, 17 Jul 1999 18:48:18 -0700 (PDT) (envelope-from dillon) Date: Sat, 17 Jul 1999 18:48:18 -0700 (PDT) From: Matthew Dillon Message-Id: <199907180148.SAA88154@apollo.backplane.com> To: David Miller Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: 650 MB MFS? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :I'm not sure what good that will do me. The point of the exercise is to :ensure that cdrecord never has to wait on enough seeks to create coasters. :Putting it all in ram before starting should do this, but a different :interface to the same data on disk doesn't. : :Unless I'm missing something, which is usually the case:) : :Thanks for the answers Matt! : :--- David MFS isn't very efficient - when you read the data it will be stored in memory twice. This is because MFS's 'disk' is a process's VM space, which happens to be memory which is *different* memory then the VM cache. So each page is stored in memory twice. If you have enough ram... say you have 1GB of ram, and you create a normal image file on disk, the system will be able to hold the entire contents of the file in the VM cache as a matter of course. This would be fairly easy to test. Create the image file, then do a read pass on it: dd if=imagefile of=/dev/null bs=32k Then do another read pass on it while running 'iostat 1'. xterm1> iostat 1 xterm2> dd if=imagefile of=/dev/null bs=32k If you don't get significant disk activity then the entire file has been cached in ram and you should be able to cdrecord it. You can test both mechanisms by running 'iostat 1' while trying each one. Then use whichever one is better. If you don't have a gig of ram, MFS isn't going to help you since the pages will be forced out to swap and cause disk I/O to occur when they are brought back in. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 19:23:54 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id DE40314FAB for ; Sat, 17 Jul 1999 19:23:51 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id WAA02002; Sat, 17 Jul 1999 22:23:50 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Sat, 17 Jul 1999 22:23:49 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Matthew Dillon Cc: "David E. Cross" , freebsd-hackers@FreeBSD.org Subject: Re: USFS (User Space File System) In-Reply-To: <199907180033.RAA86259@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 17 Jul 1999, Matthew Dillon wrote: > : > :Look into the portal filesystem. This is what you want :) > : > : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ > : green@FreeBSD.org _ __ ___ | _ ) __| \ > > Actually, it isn't quite. All the portal filesystem will allow you > to do is pass back a descriptor. It does not allow you to simulate > a filesystem. Maybe I didn't read the original e-mail that well. But with descriptors, can't you fork off individual handlers for each fd? Make a user-land FS that way? I never investigated it, except noticing the neat things it does with the portal daemon. > > But something similar to what the portal filesystem does would be > cool -- maybe a real protocol to pass the VOP requests down to a > user process and get responses & data. > > -Matt > Matthew Dillon > > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 19:36:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id E1C6A14C28; Sat, 17 Jul 1999 19:36:36 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA88346; Sat, 17 Jul 1999 19:36:36 -0700 (PDT) (envelope-from dillon) Date: Sat, 17 Jul 1999 19:36:36 -0700 (PDT) From: Matthew Dillon Message-Id: <199907180236.TAA88346@apollo.backplane.com> To: "Brian F. Feldman" Cc: "David E. Cross" , freebsd-hackers@FreeBSD.ORG Subject: Re: USFS (User Space File System) References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> : :> : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ :> : green@FreeBSD.org _ __ ___ | _ ) __| \ :> :> Actually, it isn't quite. All the portal filesystem will allow you :> to do is pass back a descriptor. It does not allow you to simulate :> a filesystem. : :Maybe I didn't read the original e-mail that well. But with descriptors, :can't you fork off individual handlers for each fd? Make a user-land FS :that way? I never investigated it, except noticing the neat things it does :with the portal daemon. :... : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ No, you can't. All you can do is return a file descriptor. It can be a pipe, of course, but that's still nowhere near what you need to simulate a filesystem. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 19:49:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lion.butya.kz (butya-gw.butya.kz [194.87.112.252]) by hub.freebsd.org (Postfix) with ESMTP id 6615314A0B for ; Sat, 17 Jul 1999 19:49:24 -0700 (PDT) (envelope-from bp@butya.kz) Received: from bp (helo=localhost) by lion.butya.kz with local-esmtp (Exim 2.12 #1) id 115gy0-0004DO-00; Sun, 18 Jul 1999 09:46:16 +0700 Date: Sun, 18 Jul 1999 09:46:16 +0700 (ALMST) From: Boris Popov To: "David E. Cross" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: USFS (User Space File System) In-Reply-To: <199907171857.OAA81681@cs.rpi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 17 Jul 1999, David E. Cross wrote: > I am looking at a project that will require a user based process to interact > with the system as if it were a filesystem. The traditional way I have seen [...] > I have a number of questions on more specific ideas (like caching, inode/vnode > interaction, etc). But I am just feeling arround for what people think > about this. Any ideas/comments? That type of file system is very useful for simple tasks. A while ago I'm experementing with 'IPX network browser' which shows NetWare servers as directories and allows to go down to see volumes, print queues etc. You probably should look at Coda file system. It have a kernel part which interacts with 'Venus' - a user-land daemon. Coda folks done a great job discovering many weird cases in such model. It would be nice if we're have something like 'userfs' (or 'daemonfs') with unified interface and mount command like this: # mount_user /mydaemon /mountpoint so, all that I need to create a new file system is to write 'mydaemon' program. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 20:25:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 8382F14C85 for ; Sat, 17 Jul 1999 20:25:41 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id MAA21098; Sun, 18 Jul 1999 12:25:33 +0900 (JST) Message-ID: <37914924.4B6FCB28@newsguy.com> Date: Sun, 18 Jul 1999 12:25:24 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Dag-Erling Smorgrav Cc: Assem Salama , freebsd-hackers@FreeBSD.ORG Subject: Re: Devloper References: <37907E69.90037620@twcny.rr.com> <3790BBAF.3556105C@newsguy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > > "Daniel C. Sobral" writes: > > * a sysctl to make the system non-overcommit > > So I see common sense lost in the end. I think nobody objects to the knob, just to people trying to convince us that it would do any good. > > * SIGDANGER in low-memory situations > > Do we support more than 32 signals? So it's a cascade project. :-) > ISTR AIX already does this. What signal numbers / names does AIX use > for this? It's AIX that I have in mind when I think of this. (AIX does have the knob, which can be set per process.) > > * Dividing processes into those that ought to be killed first and > > those that ought to be killed last in low-memory situations > > How does AIX solve that problem? AFAIK, it doesn't. Though maybe the processes which are not overcommitting are "immune", which makes some sense. > > * Per-user swap space limit > > Is that a realistic goal? What do we do about shared text, count it > once for every user that uses it? Shared TEXT is not swapped. :-) We are talking about *swap*. I don't think we could have any swap space shared between users except through some arcane uses of mmap(). Anyway, DG suggested, Dillon thought it a good idea, who am I to say anything? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Misguided Angel hanging over me Heart like Gabriel, pure and white as ivory Soul like Lucifer, black and cold like a piece of lead..." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 20:41: 3 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from rebel.net.au (rebel.rebel.net.au [203.20.69.66]) by hub.freebsd.org (Postfix) with ESMTP id CC90914C37 for ; Sat, 17 Jul 1999 20:40:57 -0700 (PDT) (envelope-from kkenn@rebel.net.au) Received: from 203.20.69.71 (dialup-1.rebel.net.au [203.20.69.71]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id NAA22038 for ; Sun, 18 Jul 1999 13:08:26 +0930 Received: (qmail 27079 invoked from network); 18 Jul 1999 03:37:47 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 18 Jul 1999 03:37:47 -0000 Date: Sun, 18 Jul 1999 13:07:47 +0930 (CST) From: Kris Kennaway Reply-To: kkenn@rebel.net.au To: "David E. Cross" Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: USFS (User Space File System) In-Reply-To: <199907171857.OAA81681@cs.rpi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 17 Jul 1999, David E. Cross wrote: > I have a number of questions on more specific ideas (like caching, inode/vnode > interaction, etc). But I am just feeling arround for what people think > about this. Any ideas/comments? John Heidemann's papers on file system stacking layers refer to implementations of this which allowed them to cheaply and easily prototype new stacking layers outside the kernel. Heidemann did at least some of his work for BSD (in fact I think that's where our implementation comes from), but I don't know if the user-space FS code was ported. http://www.isi.edu/~johnh/WORK/ucla.html#stackable_filing There is some heavily censored reference code provided on the page, but it's probably not useful (all the potentially Sun-proprietary code was removed, which means entire files). I think this would be a good way to go, although there's probably some work needed on FreeBSD's stacking code to make it fully functional. Kris > > -- > David Cross | email: crossd@cs.rpi.edu > Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd > Rensselaer Polytechnic Institute, | Ph: 518.276.2860 > Department of Computer Science | Fax: 518.276.4033 > I speak only for myself. | WinNT:Linux::Linux:FreeBSD ------------------------------------------------------------------------------ The Feynman Problem-Solving Algorithm: (1) Write down the problem (2) Think real hard (3) Write down the answer ------------------------------------------------------------------------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 21: 4:12 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 6A35314C37 for ; Sat, 17 Jul 1999 21:04:10 -0700 (PDT) (envelope-from green@FreeBSD.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id AAA03681; Sun, 18 Jul 1999 00:03:45 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Sun, 18 Jul 1999 00:03:45 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Matthew Dillon Cc: Vincent Poy , sthaug@nethelp.no, tim@storm.digital-rain.com, freebsd-hackers@FreeBSD.org Subject: Re: poor ethernet performance? In-Reply-To: <199907172320.QAA81716@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 17 Jul 1999, Matthew Dillon wrote: > : Hmmm, how did you do the measurement and how big of a file does it > :need? > : > : With a 122MByte file, it only does 2644Kbytes/sec. This is > :between two Pentium II 450 machines with Intel Pro100+ NICs. > : > : > :Cheers, > :Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ > > 2.6 MB/sec is what I would expect if you were running the test > over an ssh link on a fast cpu - the encryption eats a lot of cpu. But > a normal rcp or ftp or data transfer can easily do 9-10 MBytes/sec. Just to refute that... I get almost 2Mb/s over lo0 with ssh. This is with standard compression/decompression and idea encryption/decryption. Since this has to run both ends, my K6-2 350 is really doing 4Mb/s or higher (take into account lo0 overhead.) I'd expect a P6 (II, whatever) running at at 450 to beat that, by around 15%. > > > -Matt > Matthew Dillon > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ green@FreeBSD.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jul 17 22:41:28 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from venus.GAIANET.NET (venus.GAIANET.NET [207.211.200.51]) by hub.freebsd.org (Postfix) with ESMTP id C7C6F14DDE for ; Sat, 17 Jul 1999 22:41:26 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Received: from localhost (vince@localhost) by venus.GAIANET.NET (8.9.3/8.9.3) with ESMTP id WAA20219; Sat, 17 Jul 1999 22:38:30 -0700 (PDT) (envelope-from vince@venus.GAIANET.NET) Date: Sat, 17 Jul 1999 22:38:30 -0700 (PDT) From: Vincent Poy To: Matthew Dillon Cc: sthaug@nethelp.no, tim@storm.digital-rain.com, freebsd-hackers@FreeBSD.ORG Subject: Re: poor ethernet performance? In-Reply-To: <199907180044.RAA86301@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 17 Jul 1999, Matthew Dillon wrote: > :> 2.6 MB/sec is what I would expect if you were running the test > :> over an ssh link on a fast cpu - the encryption eats a lot of cpu. But > :> a normal rcp or ftp or data transfer can easily do 9-10 MBytes/sec. > : > : That was actually done with ftp between two machines connected > :Full Duplex to a Cisco Catalyst 2924XL switch. > > You've got breakage somewhere, I've run 9-10 MBytes/sec in both > directions at once through a catalyst between two FreeBSD boxes at > full-duplex. Not sure about the breakage but it does sound like something is wrong. We replaced all the cables with pre-made ones and it's still the same. Maybe the 100Meg file isn't large enough since it seems it starts slow then builds up in speed. > Check for interface errors or collisions - this kinda sounds like the > duplex hasn't been matched up. You should have no errors and no > collisions at all if you are running full-duplex. Make sure the duplex > and port speed on the catalyst is hardwired -- we have had no end of > troubles with the autodetect junk on catalysts. It also doesn't hurt to > hardware the duplex and port speed on the UNIX boxes. Ah, you have a point there. The problem is we have so many wires, we don't know which port goes to what on the Catalyst so we had it on autodetect and FreeBSD does boot up with fxp0 showing 100Mbps Full Duplex. > If you still have problems there are a number of possibilities. If you > are using discrete RJ45 ports try switching the cables as well as use > a different catalyst port. If you are using telco cables - those big > fat 50 or 100 pair cables that use centronics-like connectors on the > catalyst side hat, you probably have an RJ45 punchdown block on the other > end. These have to be Cat-5 punchdown blocks, not Cat-3 punchdown blocks. > Try a different port on the punchdown block. Hmmm, we're not using punchdown blocks since the cables from the switches go directly to the workstation and other hubs/switches. Cheers, Vince - vince@MCESTATE.COM - vince@GAIANET.NET ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message