From owner-freebsd-current Sun Jul 11 0:12:47 1999 Delivered-To: freebsd-current@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 8979014C20 for ; Sun, 11 Jul 1999 00:12:43 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id IAA09652; Sun, 11 Jul 1999 08:12:52 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 11 Jul 1999 08:12:52 +0100 (BST) From: Doug Rabson To: Matthew Dillon Cc: Alan Cox , Stephen McKay , Andrew Gallatin , freebsd-current@freebsd.org Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") In-Reply-To: <199907102141.OAA58697@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 10 Jul 1999, Matthew Dillon wrote: > > The supposedly atomic functions in i386/include/atomic.h are not > as atomic as was previously thought :-): > > #define atomic_add_short(P, V) (*(u_short*)(P) += (V)) > > I looked at that kinda funny. But C doesn't guarentee a RMW opcode > for a "+=" !!!. Alan found an example showing a load, add, and > separate store by disassembling the kernel. An interrupt occuring in > the middle of that sequence would lead to the reported problems. > > I'm pretty sure this is the problem causing the "objtrm" lockups. I've > submitted a patch to Alan to make those atomic_*() functions inline > assembly. > > There also appear to be a number of mistakes in some of the inline > assembly already laying around -- some of it appears to specify output > arguments for RMW instructions without also indicating to the compiler > that those are input arguments as well, leading to bogus optimizations > by the C compiler. The 'setbits' function is the one Alan found > inadvertantly while we were trying to figure out why my first iteration > didn't work. heh heh. Alan will fix the setbits inline. > > It wouldn't hurt if someone with more assembly experience could audit > all of the inline assembly present in the source base. > > I am re-running the 16MB/make -j5 buildworld test to see if this has > really fixed the problem. What a nightmare. This must be due to egcs compiling things differently from gcc 2.7.1. I should have guessed when people started talking about objtrm (I spent many unhappy hours looking for objtrm bugs on the alpha) but my attention was elsewhere. Before I fixed this stuff for the alpha, the += expressions were scattered all over the source tree. At least you get to fix the macro :-). -- 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-current" in the body of the message From owner-freebsd-current Sun Jul 11 0:42:35 1999 Delivered-To: freebsd-current@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 1B73B14C20 for ; Sun, 11 Jul 1999 00:42:31 -0700 (PDT) (envelope-from alc@cs.rice.edu) Received: (from alc@localhost) by cs.rice.edu (8.9.0/8.9.0) id CAA10422; Sun, 11 Jul 1999 02:42:17 -0500 (CDT) Date: Sun, 11 Jul 1999 02:42:17 -0500 From: Alan Cox To: Doug Rabson Cc: Matthew Dillon , Stephen McKay , Andrew Gallatin , freebsd-current@freebsd.org Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") Message-ID: <19990711024217.B6401@cs.rice.edu> References: <199907102141.OAA58697@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5us In-Reply-To: ; from Doug Rabson on Sun, Jul 11, 1999 at 08:12:52AM +0100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jul 11, 1999 at 08:12:52AM +0100, Doug Rabson wrote: > > What a nightmare. This must be due to egcs compiling things differently > from gcc 2.7.1. ... Yes, at least for the one case in vm_pageout_flush. (I checked the analogous code on a 3.x-STABLE system and it appears to be fine for this case.) I haven't looked for others. Alan P.S. I plan to move the fix to 3.X-stable even if it appears that the compiler is generating safe code. There's really no point in taking chances. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 11 0:56:41 1999 Delivered-To: freebsd-current@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 9FC8F14BD4 for ; Sun, 11 Jul 1999 00:56:38 -0700 (PDT) (envelope-from alc@cs.rice.edu) Received: (from alc@localhost) by cs.rice.edu (8.9.0/8.9.0) id CAA10518; Sun, 11 Jul 1999 02:56:24 -0500 (CDT) Date: Sun, 11 Jul 1999 02:56:23 -0500 From: Alan Cox To: Doug Rabson Cc: Matthew Dillon , Stephen McKay , Andrew Gallatin , freebsd-current@freebsd.org Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") Message-ID: <19990711025623.C6401@cs.rice.edu> References: <199907102141.OAA58697@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5us In-Reply-To: ; from Doug Rabson on Sun, Jul 11, 1999 at 08:12:52AM +0100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Actually, I should have said swap_pager_getpages and not vm_pageout_flush. Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 11 1:39: 9 1999 Delivered-To: freebsd-current@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id B9C8314D3D for ; Sun, 11 Jul 1999 01:39:03 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA03758; Sun, 11 Jul 1999 09:39:22 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 11 Jul 1999 09:39:22 +0100 (BST) From: Doug Rabson To: Alan Cox Cc: Matthew Dillon , Stephen McKay , Andrew Gallatin , freebsd-current@freebsd.org Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") In-Reply-To: <19990711024217.B6401@cs.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Jul 1999, Alan Cox wrote: > On Sun, Jul 11, 1999 at 08:12:52AM +0100, Doug Rabson wrote: > > > > What a nightmare. This must be due to egcs compiling things differently > > from gcc 2.7.1. ... > > Yes, at least for the one case in vm_pageout_flush. (I checked > the analogous code on a 3.x-STABLE system and it appears to be fine > for this case.) I haven't looked for others. > > Alan > > P.S. I plan to move the fix to 3.X-stable even if it appears > that the compiler is generating safe code. There's really > no point in taking chances. Agreed. -- 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-current" in the body of the message From owner-freebsd-current Sun Jul 11 4:22:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id B2D5614C0C for ; Sun, 11 Jul 1999 04:22:30 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id UAA26761; Sun, 11 Jul 1999 20:22:26 +0900 (JST) Message-ID: <37887C61.2F462FD@newsguy.com> Date: Sun, 11 Jul 1999 20:13: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: Nicolas Blais Cc: freebsd-current@FreeBSD.ORG Subject: Re: HELP!!! -CURRENT libtool problem. References: <37810FDD.C1321FE7@videotron.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nicolas Blais wrote: > > Hi. I've finally installed FreeBSD 4.0 and to tell you the truth, I'm > not > very impressed. I was expecting some bugs but not like that... Well, maybe this FAQ entry candidate will help clarify things for you: "Q: Why shouldn't I just go ahead and run -current? That's got all the latest stuff, right? A:4.0 is the next major release of FreeBSD. For now, and for a while, all -stable releases of FreeBSD will be in the 3.x line. These are minor releases, which do not introduce big changes and we try our best to avoid breaking compatibility backward compatibility (binary, file formats, etc). Meanwhile, our fearless developers are cooking the 4.0 version. This branch is known as 4.0-current, or just -current (since when 4.0 becomes stable, the current branch will become 5.0-current). Our developers are fearless because a -current system is something in development, and, thus, subject to all sort of bugs, which can wipe out your disks, burn your monitor, erase your BIOS, overheat your CPU(s), spit out your PCI cards, send the fans flying (sometimes throwing stuff at them first), make international phone calls to phone sex services, print pornography until your printer runs out of paper/toner (sorry, no such luck... it's just the Stark report), send insulting faxes to your boss, cheat on the mob and blame you for it, attract attention for the gentle I.R.S. personel, blow your house fuses, open the gas and then set your house on fire, make your girlfriend break up with you (or your wife cheat on you), and bomb Yugoslavia. This last one we are trying to debug, though [NOTE: at the time of this writing, we have reports that this bug has been fixed]. Because of the above, we advise against using -current. If you so insist, the following rules must be obeyed: 1) Read cvs-all. No, I'm not kidding. I mean it. 2) Read freebsd-current. Yeah, that one too. 3) If something fails, it's probably because you missed a message on cvs-all or freebsd-current. 4) If that's not the case, it's probably a temporary bug. Cvsup again after the appropriate time (minimum of one hour, though one full day is not unreasonable). 5) If it still crashes *at the same location*, then it's probably your fault. Junk your customized settings, and try to reproduce it with a vanilla system. 6) If you can reproduce it even with a vanilla system, then you might actually have stumbled on a bug. Congratulations! Find out what the bug is, and send us the patches. 7) If you are not capable of the above, you might just keep quiet and wait until someone fixes it. See steps 1 and 2 for how do you know someone fixed it. 8) OTOH, you might help tracking the bug. See the handbook on getting crash dumps, kernel traces, and such stuff. 9) If you loose all data on your hard disks because of a bug, that's one of the risks of running -current. Either you can deal with that, or you shouldn't be running -current. These rules, though written tongue-in-cheek, are for real. FreeBSD 4.0-current is *not* supposed to work all the time. It is being *developed*. And saying "Hey! I have a bug!" does *NOT* help developers. Furthermore, sometimes it breaks *on purpose*, while things are being changed, and the fixes are *not* immediate. If you can live with that, and think you have any compelling reason to run -current, read the handbook for further instructions. Sorry if this seems too harsh, but many people are just not used to the concept of a development tree available publicly, and think of it as the "latest version". It is *not* the latest version. When it is *ready*, it will be the latest version. Until then... read the above." Any other question? -- 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-current" in the body of the message From owner-freebsd-current Sun Jul 11 8: 5:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from aurora.sol.net (aurora.sol.net [206.55.65.76]) by hub.freebsd.org (Postfix) with ESMTP id 2A57B14F04 for ; Sun, 11 Jul 1999 08:05:28 -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 KAA77032; Sun, 11 Jul 1999 10:05:23 -0500 (CDT) From: Joe Greco Message-Id: <199907111505.KAA77032@aurora.sol.net> Subject: Re: utmp & last In-Reply-To: <199907100928.FAA79011_kiwi.datasys.net@ns.sol.net> from Ayan George at "Jul 10, 1999 9:28:44 am" To: ayan@kiwi.datasys.net (Ayan George) Date: Sun, 11 Jul 1999 10:05:22 -0500 (CDT) Cc: current@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-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Why do we store the utmp/wtmp and last logs in different data > structures? > > What seems strange is that they use the different data types to > store the same information (the time): > > struct lastlog { > time_t ll_time; > char ll_line[UT_LINESIZE]; > char ll_host[UT_HOSTSIZE]; > }; > > struct utmp { > char ut_line[UT_LINESIZE]; > char ut_name[UT_NAMESIZE]; > char ut_host[UT_HOSTSIZE]; > long ut_time; > }; > > Not that there is any _real_ difference between long and time_t, > but it would imagine we'd want to be as consistant as possable. > > Anyhow, IMHO the umtp filestructure should be used to store the > last log. At the same time, I'm sure there is a reason for > the way things are. Could someone clue me in? Good programmers don't waste space. In particular, since the lastlog format uses the uid as the index into the file, when the format was designed, the maximum file size would have been 28 * 65536 ~= 1.8MB. By comparison, your suggestion bloats it up to 36 * 65536 ~= 2.4MB - to add a completely useless field. Now, that may not seem like a lot, but there was a time and day when we were installing on 40MB hard drives and were in complete awe at how much space we had. I remember my first serious FreeBSD box on a pair of 30MB RLL's. This, of course, assumes the 8-character name that was in use at the time this format was devised. Now that we have 32-bit UID's, and 16-character names, it is a bit more significant... although it is possible to argue that the lastlog format itself is broken. Defining one really big uid (oh, let's say 2^32-1) results in a 114GB-sized file, although it is likely to be sparse. :-) This is still a problem for sparse-unaware utilities. Your approach would yield a 180GB-sized file. I'm not sure what advantage this extra 66GB waste (that's 37% waste!) would provide. Your point about time storage is correct, however, I believe. Using long instead of time_t is just asking for problems. There's probably some hysterical raison for it. ... 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-current" in the body of the message From owner-freebsd-current Sun Jul 11 13:36:39 1999 Delivered-To: freebsd-current@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-current@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-current" in the body of the message From owner-freebsd-current Sun Jul 11 15:45:32 1999 Delivered-To: freebsd-current@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 F18FE14F53 for ; Sun, 11 Jul 1999 15:45:28 -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 WAA32337; Sun, 11 Jul 1999 22:00:50 +0100 (BST) (envelope-from nik) Date: Sun, 11 Jul 1999 22:00:50 +0100 From: Nik Clayton To: "Daniel C. Sobral" Cc: Nicolas Blais , freebsd-current@FreeBSD.ORG Subject: Re: HELP!!! -CURRENT libtool problem. Message-ID: <19990711220050.A31542@catkin.nothing-going-on.org> References: <37810FDD.C1321FE7@videotron.ca> <37887C61.2F462FD@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <37887C61.2F462FD@newsguy.com>; from Daniel C. Sobral on Sun, Jul 11, 1999 at 08:13:37PM +0900 Organization: Nik at home, where there's nothing going on Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jul 11, 1999 at 08:13:37PM +0900, Daniel C. Sobral wrote: [snip] > "Q: Why shouldn't I just go ahead and run -current? That's got > all the latest stuff, right? [snip] > If you can live with that, and think you have any compelling reason > to run -current, read the handbook for further instructions. > > Sorry if this seems too harsh, but many people are just not used to > the concept of a development tree available publicly, and think of > it as the "latest version". It is *not* the latest version. When it > is *ready*, it will be the latest version. Until then... read the > above." > > Any other question? Q: I want to use this cool piece of software that's in the FreeBSD ports system. But I can't build it on my 3.x-stable system. Why not? A: Ah, sorry. The ports system only targets -current, trying to get it to work with -stable is too much work. If you want to be sure of using the ports system successfully you need to be running -current. Or was this policy reversed recently and I didn't notice (always a likely possibility). [ And yes, I *know* the ports system relies on volunteers, and that if people can't be bothered to test their ports on a -stable system then there's not a lot we can do about it. But this does lead to the amusing situation (for various values of "amusing") where on one hand we're telling people not to use -current unless they really know what they're doing, but on the other hand we're (in some cases) preventing them from using a major piece of FreeBSD infrastructure which is expressly designed to make life easier for exactly the sort of people who should be running -stable. ] 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-current" in the body of the message From owner-freebsd-current Sun Jul 11 15:50:51 1999 Delivered-To: freebsd-current@freebsd.org Received: from ducky.net (gate.ducky.net [199.2.211.252]) by hub.freebsd.org (Postfix) with ESMTP id E6D9314EE9 for ; Sun, 11 Jul 1999 15:50:47 -0700 (PDT) (envelope-from mike@ducky.net) Received: from ducky.net (localhost.ducky.net [127.0.0.1]) by ducky.net (8.9.1/8.8.5) with ESMTP id PAA16398; Sun, 11 Jul 1999 15:49:16 -0700 (PDT) Message-Id: <199907112249.PAA16398@ducky.net> To: Doug Rabson Cc: Matthew Dillon , Alan Cox , Stephen McKay , Andrew Gallatin , freebsd-current@freebsd.org, mike@ducky.net Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") In-reply-to: Your message of "Sun, 11 Jul 1999 08:12:52 BST." Date: Sun, 11 Jul 1999 15:49:15 -0700 From: Mike Haertel Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >On Sat, 10 Jul 1999, Matthew Dillon wrote: >> >> The supposedly atomic functions in i386/include/atomic.h are not >> as atomic as was previously thought :-): >> >> #define atomic_add_short(P, V) (*(u_short*)(P) += (V)) >[...] > >Before I fixed this stuff for the alpha, the += expressions were >scattered all over the source tree. At least you get to fix the macro :-). Um. FYI on x86, even if the compiler generates the RMW form "addl $1, foo", it's not atomic. If you want it to be atomic you have to precede the opcode with a LOCK prefix 0xF0. I guess I should clarify what I mean by atomic: "addl $1, foo" is atomic with respect to interrupts. However, it is not atomic with respect to other processors, i.e is not SMP safe. "lock addl $1, foo" is both atomic with respect to interrupts, and also with respect to activity by the other processor. Mike (one of those pesky x86 architects at Intel) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 11 15:55:51 1999 Delivered-To: freebsd-current@freebsd.org Received: from norn.ca.eu.org (cr965240-b.abtsfd1.bc.wave.home.com [24.113.19.137]) by hub.freebsd.org (Postfix) with ESMTP id 4F2E214EE9 for ; Sun, 11 Jul 1999 15:55:48 -0700 (PDT) (envelope-from cpiazza@norn.ca.eu.org) Received: by norn.ca.eu.org (Postfix, from userid 1002) id AEC78760; Mon, 12 Jul 1999 15:54:40 -0700 (PDT) Date: Mon, 12 Jul 1999 15:54:40 -0700 From: Chris Piazza To: Nik Clayton Cc: "Daniel C. Sobral" , Nicolas Blais , freebsd-current@FreeBSD.ORG Subject: Re: HELP!!! -CURRENT libtool problem. Message-ID: <19990712155440.B494@norn.ca.eu.org> References: <37810FDD.C1321FE7@videotron.ca> <37887C61.2F462FD@newsguy.com> <19990711220050.A31542@catkin.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <19990711220050.A31542@catkin.nothing-going-on.org>; from Nik Clayton on Sun, Jul 11, 1999 at 10:00:50PM +0100 X-Operating-System: FreeBSD 4.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jul 11, 1999 at 10:00:50PM +0100, Nik Clayton wrote: > hmm... > > > > Any other question? > > Q: I want to use this cool piece of software that's in the FreeBSD > ports system. But I can't build it on my 3.x-stable system. > > Why not? > > A: Ah, sorry. The ports system only targets -current, trying to get > it to work with -stable is too much work. If you want to be sure > of using the ports system successfully you need to be running > -current. > > > Or was this policy reversed recently and I didn't notice (always a > likely possibility). Um..er... I hope you were really just being sarcastic. All ports should work on -stable as well as -current. In fact, more build on -stable than -current according to http://bento.freebsd.org/. If any ports work on one but not the other it is a bug and should be fixed. So I ask, what policy? > > [ And yes, I *know* the ports system relies on volunteers, and that if > people can't be bothered to test their ports on a -stable system then > there's not a lot we can do about it. But this does lead to the > amusing situation (for various values of "amusing") where on one hand > we're telling people not to use -current unless they really know what > they're doing, but on the other hand we're (in some cases) preventing > them from using a major piece of FreeBSD infrastructure which is > expressly designed to make life easier for exactly the sort of people > who should be running -stable. ] -Chris -- cpiazza@home.net cpiazza@FreeBSD.org "A great many people think they are thinking when they are merely rearranging their prejudices" -William James To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 11 16: 8:37 1999 Delivered-To: freebsd-current@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id E01E914EE9 for ; Sun, 11 Jul 1999 16:08:34 -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 QAA22527; Sun, 11 Jul 1999 16:08:29 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Nik Clayton Cc: "Daniel C. Sobral" , Nicolas Blais , freebsd-current@FreeBSD.ORG Subject: Re: HELP!!! -CURRENT libtool problem. In-reply-to: Your message of "Sun, 11 Jul 1999 22:00:50 BST." <19990711220050.A31542@catkin.nothing-going-on.org> Date: Sun, 11 Jul 1999 16:08:28 -0700 Message-ID: <22523.931734508@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Q: I want to use this cool piece of software that's in the FreeBSD > ports system. But I can't build it on my 3.x-stable system. > > Why not? A. Likely because someone running only on a -current box last committed a change to the port which broke it with 3.x. Please submit a bug report on this with send-pr since the -current ports collection is supposed to work with both the -current and -stable branches. If you're running a release version that lags significantly behind -current or -stable, you will require a ports upgrade kit from http://www.freebsd.org/ports - Jordan > > A: Ah, sorry. The ports system only targets -current, trying to get > it to work with -stable is too much work. If you want to be sure > of using the ports system successfully you need to be running > -current. > > > Or was this policy reversed recently and I didn't notice (always a > likely possibility). > > [ And yes, I *know* the ports system relies on volunteers, and that if > people can't be bothered to test their ports on a -stable system then > there's not a lot we can do about it. But this does lead to the > amusing situation (for various values of "amusing") where on one hand > we're telling people not to use -current unless they really know what > they're doing, but on the other hand we're (in some cases) preventing > them from using a major piece of FreeBSD infrastructure which is > expressly designed to make life easier for exactly the sort of people > who should be running -stable. ] > > 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-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 11 16:10:14 1999 Delivered-To: freebsd-current@freebsd.org Received: from megadodo.segNET.COM (megadodo.segNET.COM [206.34.181.3]) by hub.freebsd.org (Postfix) with ESMTP id 5361D14EE9 for ; Sun, 11 Jul 1999 16:10:06 -0700 (PDT) (envelope-from adams@digitalspark.net) Received: from arc0a23.bf.sover.net (adams@arc0a23.bf.sover.net [209.198.85.23]) by megadodo.segNET.COM (8.9.1a/8.8.5) with ESMTP id TAA29236; Sun, 11 Jul 1999 19:09:58 -0400 (EDT) Date: Sun, 11 Jul 1999 19:12:27 +0000 (GMT) From: Adam Strohl To: Nik Clayton Cc: "Daniel C. Sobral" , Nicolas Blais , freebsd-current@FreeBSD.ORG Subject: Re: HELP!!! -CURRENT libtool problem. In-Reply-To: <19990711220050.A31542@catkin.nothing-going-on.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Jul 1999, Nik Clayton wrote: > Q: I want to use this cool piece of software that's in the FreeBSD > ports system. But I can't build it on my 3.x-stable system. > > Why not? > > A: Ah, sorry. The ports system only targets -current, trying to get > it to work with -stable is too much work. If you want to be sure > of using the ports system successfully you need to be running > -current. > A: E-mail the port maintainer. You'll find that's a lot easier. And if the port maintainer doesn't respond/and or you want it fixed ASAP, instead of going through the hassel of (for new people) learning how to cvsup make build world, etc, fix the problem yourself. Also: Last I checked the port system didn't "target" -current. Infact I bet more stuff compiles under -stable than -current, esspecially when things are getting shaken up. I think the real issue is that people see/hear that something works under -current and without thinking of the other tradeoffs (ie; they can't just type 'make' and it all works without them knowing what is going on), leap off and go to -current because at the time it was the easiest way to get something working. You're basically restating something we already know. -current has the latest. Sometimes this means that it has more because its all working pretty well, sometimes it doesn't. We know this. That's the point. - ----( Adam Strohl )------------------------------------------------ - - UNIX Operations/Systems http://www.digitalspark.net - - adams (at) digitalspark.net xxx.xxx.xxxx xxxxx - - ----------------------------------------( DigitalSpark.NET )------- - To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 11 16:14:36 1999 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id BD97714FC1 for ; Sun, 11 Jul 1999 16:14:32 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40350>; Mon, 12 Jul 1999 08:56:24 +1000 Date: Mon, 12 Jul 1999 09:14:17 +1000 From: Peter Jeremy Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") In-reply-to: <199907112249.PAA16398@ducky.net> To: mike@ducky.net Cc: freebsd-current@FreeBSD.ORG Message-Id: <99Jul12.085624est.40350@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Haertel wrote: >Um. FYI on x86, even if the compiler generates the RMW >form "addl $1, foo", it's not atomic. If you want it to >be atomic you have to precede the opcode with a LOCK >prefix 0xF0. I'd noticed that point as well. The top of sys/i386/include/atomic.h _does_ make is clear that they aren't SMP safe: /* * Various simple arithmetic on memory which is atomic in the presence * of interrupts. * * Note: these versions are not SMP safe. */ That said, it should be fairly simple to change Matt's new in-line assembler versions to insert LOCK prefixes when building an SMP kernel. (Although I don't know that this is necessary yet, given the `Big Giant Lock'). There remains the problem of locating all the operations in the kernel that _should_ be atomic but aren't marked as such. Doug Rabson and the rest of the Alpha porting crew will have found a lot of these, but locating race conditions by waiting for them to occur is not the best solution. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 11 16:37:35 1999 Delivered-To: freebsd-current@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id DDE8D150BC for ; Sun, 11 Jul 1999 16:37:32 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (iras-3-43.ucdavis.edu [169.237.17.43]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id QAA27204; Sun, 11 Jul 1999 16:37:30 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id XAA53048; Sun, 11 Jul 1999 23:37:28 GMT (envelope-from obrien) Date: Sun, 11 Jul 1999 16:37:27 -0700 From: "David O'Brien" To: Nik Clayton Cc: Nicolas Blais , freebsd-current@FreeBSD.ORG Subject: Re: HELP!!! -CURRENT libtool problem. Message-ID: <19990711163727.A52930@dragon.nuxi.com> Reply-To: obrien@NUXI.com References: <37810FDD.C1321FE7@videotron.ca> <37887C61.2F462FD@newsguy.com> <19990711220050.A31542@catkin.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <19990711220050.A31542@catkin.nothing-going-on.org>; from Nik Clayton on Sun, Jul 11, 1999 at 10:00:50PM +0100 X-Operating-System: FreeBSD 4.0-CURRENT 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-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Q: I want to use this cool piece of software that's in the FreeBSD > ports system. But I can't build it on my 3.x-stable system. Why not? > > A: Ah, sorry. The ports system only targets -current, trying to get it to > work with -stable is too much work. If you want to be sure of using the > ports system successfully you need to be running -current. > > > Or was this policy reversed recently and I didn't notice (always a > likely possibility). That policy was reversed back in August 1997 (2.2.6 or so). Ever since then Ports track -STABLE and until recently, Satoshi was only building packages on -STABLE machines. -- -- David (obrien@NUXI.com -or- obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 11 16:47: 6 1999 Delivered-To: freebsd-current@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 0A15314C4B for ; Sun, 11 Jul 1999 16:47:01 -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 AAA53158; Mon, 12 Jul 1999 00:46:12 +0100 (BST) (envelope-from nik) Date: Mon, 12 Jul 1999 00:46:12 +0100 From: Nik Clayton To: Chris Piazza Cc: Nik Clayton , "Daniel C. Sobral" , Nicolas Blais , freebsd-current@FreeBSD.ORG Subject: Re: HELP!!! -CURRENT libtool problem. Message-ID: <19990712004612.A51439@catkin.nothing-going-on.org> References: <37810FDD.C1321FE7@videotron.ca> <37887C61.2F462FD@newsguy.com> <19990711220050.A31542@catkin.nothing-going-on.org> <19990712155440.B494@norn.ca.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <19990712155440.B494@norn.ca.eu.org>; from Chris Piazza on Mon, Jul 12, 1999 at 03:54:40PM -0700 Organization: Nik at home, where there's nothing going on Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 12, 1999 at 03:54:40PM -0700, Chris Piazza wrote: > Um..er... I hope you were really just being sarcastic. All ports > should work on -stable as well as -current. In fact, more build > on -stable than -current according to http://bento.freebsd.org/. > If any ports work on one but not the other it is a bug and should > be fixed. So I ask, what policy? I was under the impression that if you were CVSup'ing the ports tree then any changes to the ports subsystem (for example, new command line parameters to fetch(1)) would be utilised by the ports system *before* they had been merged in to -stable. The rationale being that if you were tracking the ports tree in that way then you should be tracking -current instead. There have certainly been periods where my -stable system has been unable to build new versions of ports where my the ports tree is perhaps a week newer than the built source tree on my machine. Checking the mail archives when this has happened has shown me the problem, and it's been relatively simple to either build the thing by hand, or do a local merge of the change from -current to my tree. I'm hand-waving here slightly, as it's been a few months since I last needed to do this, and specific cases are fuzzy in my memory at the moment, as it just became an automatic process ("Oh, this port doesn't build, what hasn't been merged in now? Right, fixed.") that I didn't take particular note of the ports where it's been an issue. But my point is that if we're warning people away from -current (and I'm in complete agreement that this is a good idea) then we should also be aware that as well as not being able to run the latest and greatest FreeBSD code, we are occasionally giving them advice that means that (apparently) unrelated systems (the ports tree) don't build properly. It's not a big deal, but I see a lot of sweeping generalisations about things like this (more so on Usenet, obviously), whether it's things like "Run -stable for an easier life", or "FreeBSD is a better server than Linux", or "OpenBSD is the most secure of the *BSDs", and it always bugs me slightly. :-) 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-current" in the body of the message From owner-freebsd-current Sun Jul 11 17: 3: 9 1999 Delivered-To: freebsd-current@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 73C5B14C4B for ; Sun, 11 Jul 1999 17:03:04 -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 JAA19471; Mon, 12 Jul 1999 09:33:02 +0930 (CST) Received: from localhost by mercury; (5.65v3.2/1.1.8.2/27Nov97-0404PM) id AA08887; Mon, 12 Jul 1999 09:33:02 +0930 Date: Mon, 12 Jul 1999 09:33:02 +0930 (CST) From: Kris Kennaway To: "Jordan K. Hubbard" Cc: Nik Clayton , "Daniel C. Sobral" , Nicolas Blais , freebsd-current@freebsd.org Subject: Re: HELP!!! -CURRENT libtool problem. In-Reply-To: <22523.931734508@zippy.cdrom.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Jul 1999, Jordan K. Hubbard wrote: > > Q: I want to use this cool piece of software that's in the FreeBSD > > ports system. But I can't build it on my 3.x-stable system. > > > > Why not? > > A. Likely because someone running only on a -current box last committed > a change to the port which broke it with 3.x. Please submit a bug > report on this with send-pr since the -current ports collection is supposed > to work with both the -current and -stable branches. If you're running a > release version that lags significantly behind -current or -stable, you > will require a ports upgrade kit from http://www.freebsd.org/ports Does someone plan to add this question and the other one about the dangers of -current to the FAQ? I think they are both well-answered. 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-current" in the body of the message From owner-freebsd-current Sun Jul 11 17:35:50 1999 Delivered-To: freebsd-current@freebsd.org Received: from smtp11.bellglobal.com (smtp11.bellglobal.com [204.101.251.53]) by hub.freebsd.org (Postfix) with ESMTP id 3CFEE151FA for ; Sun, 11 Jul 1999 17:35:43 -0700 (PDT) (envelope-from hoek@FreeBSD.org) Received: from localhost.nowhere (ppp18332.on.bellglobal.com [206.172.130.12]) by smtp11.bellglobal.com (8.8.5/8.8.5) with ESMTP id UAA05202; Sun, 11 Jul 1999 20:37:52 -0400 (EDT) Received: (from tim@localhost) by localhost.nowhere (8.9.3/8.9.1) id UAA96136; Sun, 11 Jul 1999 20:34:50 -0400 (EDT) (envelope-from tim) Date: Sun, 11 Jul 1999 20:34:50 -0400 From: Tim Vanderhoek To: Nik Clayton Cc: Chris Piazza , "Daniel C. Sobral" , Nicolas Blais , freebsd-current@FreeBSD.org Subject: Re: HELP!!! -CURRENT libtool problem. Message-ID: <19990711203450.A96070@mad> References: <37810FDD.C1321FE7@videotron.ca> <37887C61.2F462FD@newsguy.com> <19990711220050.A31542@catkin.nothing-going-on.org> <19990712155440.B494@norn.ca.eu.org> <19990712004612.A51439@catkin.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <19990712004612.A51439@catkin.nothing-going-on.org>; from Nik Clayton on Mon, Jul 12, 1999 at 12:46:12AM +0100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 12, 1999 at 12:46:12AM +0100, Nik Clayton wrote: > > I was under the impression that if you were CVSup'ing the ports tree then > any changes to the ports subsystem (for example, new command line > parameters to fetch(1)) would be utilised by the ports system *before* > they had been merged in to -stable. The rationale being that if you Well, ya, sometimes that happens, especially if you CVSup only the ports tree. The upgrade kits found on http://www.FreeBSD.org/ports/ are useful here. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 11 20:55:50 1999 Delivered-To: freebsd-current@freebsd.org Received: from resnet.uoregon.edu (resnet.uoregon.edu [128.223.144.32]) by hub.freebsd.org (Postfix) with ESMTP id BD8C114CFC for ; Sun, 11 Jul 1999 20:55:48 -0700 (PDT) (envelope-from dwhite@resnet.uoregon.edu) Received: from localhost (dwhite@localhost) by resnet.uoregon.edu (8.9.3/8.9.3) with ESMTP id UAA37405; Sun, 11 Jul 1999 20:53:04 -0700 (PDT) (envelope-from dwhite@resnet.uoregon.edu) Date: Sun, 11 Jul 1999 20:53:04 -0700 (PDT) From: Doug White To: Kris Kennaway Cc: freebsd-current@FreeBSD.ORG Subject: Re: HELP!!! -CURRENT libtool problem. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 12 Jul 1999, Kris Kennaway wrote: > On Sun, 11 Jul 1999, Jordan K. Hubbard wrote: > > > > Q: I want to use this cool piece of software that's in the FreeBSD > > > ports system. But I can't build it on my 3.x-stable system. > > > > > > Why not? > > > > A. Likely because someone running only on a -current box last committed > > a change to the port which broke it with 3.x. Please submit a bug > > report on this with send-pr since the -current ports collection is supposed > > to work with both the -current and -stable branches. If you're running a > > release version that lags significantly behind -current or -stable, you > > will require a ports upgrade kit from http://www.freebsd.org/ports > > Does someone plan to add this question and the other one about the dangers > of -current to the FAQ? I think they are both well-answered. Does the letter someone sent to faq@freebsd.org have all this info, or do I need to rewrite it? I'll commit it once I have the correct info. :) Doug White Internet: dwhite@resnet.uoregon.edu | FreeBSD: The Power to Serve http://gladstone.uoregon.edu/~dwhite | www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 11 20:58: 4 1999 Delivered-To: freebsd-current@freebsd.org Received: from smtp4.erols.com (smtp4.erols.com [207.172.3.237]) by hub.freebsd.org (Postfix) with ESMTP id BC72114D4A for ; Sun, 11 Jul 1999 20:58:01 -0700 (PDT) (envelope-from jobaldwi@vt.edu) Received: from john.baldwin.cx (207-172-143-112.s49.as1.hgt.md.dialup.rcn.com [207.172.143.112]) by smtp4.erols.com (8.8.8/smtp-v1) with ESMTP id XAA16367; Sun, 11 Jul 1999 23:57:53 -0400 (EDT) Message-Id: <199907120357.XAA16367@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: Date: Sun, 11 Jul 1999 23:58:01 -0400 (EDT) From: John Baldwin To: Kris Kennaway Subject: Re: HELP!!! -CURRENT libtool problem. Cc: freebsd-current@freebsd.org, Nicolas Blais , "Daniel C. Sobral" , Nik Clayton , "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 12-Jul-99 Kris Kennaway wrote: > On Sun, 11 Jul 1999, Jordan K. Hubbard wrote: > >> > Q: I want to use this cool piece of software that's in the FreeBSD >> > ports system. But I can't build it on my 3.x-stable system. >> > >> > Why not? >> >> A. Likely because someone running only on a -current box last committed >> a change to the port which broke it with 3.x. Please submit a bug >> report on this with send-pr since the -current ports collection is >> supposed >> to work with both the -current and -stable branches. If you're running a >> release version that lags significantly behind -current or -stable, you >> will require a ports upgrade kit from http://www.freebsd.org/ports > > Does someone plan to add this question and the other one about the dangers > of -current to the FAQ? I think they are both well-answered. PR/12595 PR/12599 > Kris --- 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-current" in the body of the message From owner-freebsd-current Sun Jul 11 21:16:20 1999 Delivered-To: freebsd-current@freebsd.org Received: from ren.detir.qld.gov.au (ns.detir.qld.gov.au [203.46.81.66]) by hub.freebsd.org (Postfix) with ESMTP id C4DE914FA1 for ; Sun, 11 Jul 1999 21:16:15 -0700 (PDT) (envelope-from syssgm@detir.qld.gov.au) Received: by ren.detir.qld.gov.au; id OAA02022; Mon, 12 Jul 1999 14:15:06 +1000 (EST) Received: from ogre.detir.qld.gov.au(167.123.8.3) by ren.detir.qld.gov.au via smap (3.2) id xma002014; Mon, 12 Jul 99 14:15:04 +1000 Received: from atlas.detir.qld.gov.au (atlas.detir.qld.gov.au [167.123.8.9]) by ogre.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id OAA15778; Mon, 12 Jul 1999 14:13:25 +1000 (EST) Received: from nymph.detir.qld.gov.au (nymph.detir.qld.gov.au [167.123.10.10]) by atlas.detir.qld.gov.au (8.8.5/8.8.5) with ESMTP id OAA06962; Mon, 12 Jul 1999 14:13:25 +1000 (EST) Received: from nymph.detir.qld.gov.au (localhost.detir.qld.gov.au [127.0.0.1]) by nymph.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id OAA13966; Mon, 12 Jul 1999 14:13:24 +1000 (EST) (envelope-from syssgm@nymph.detir.qld.gov.au) Message-Id: <199907120413.OAA13966@nymph.detir.qld.gov.au> To: Matthew Dillon Cc: Stephen McKay , freebsd-current@FreeBSD.ORG Subject: Re: Stuck in "objtrm" - live kernel test to run References: <199907081828.LAA41802@apollo.backplane.com> <199907091033.UAA03176@nymph.detir.qld.gov.au> <199907100711.AAA53510@apollo.backplane.com> In-Reply-To: <199907100711.AAA53510@apollo.backplane.com> from Matthew Dillon at "Sat, 10 Jul 1999 00:11:43 -0700" Date: Mon, 12 Jul 1999 14:13:24 +1000 From: Stephen McKay Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Saturday, 10th July 1999, Matthew Dillon wrote: > I'm trying to simulate your 486 setup. You must love pain! A make -j5 > buildworld on a 16MB-limited machine pages like hell (200-400 pageins/sec > AND 200-400 pageouts/sec simultaniously, almost continuously). Maximal pain, maximal gain! :-) The only reason I'm using a big, powerful 486 is that my 386 here died and there were none left to replace it. With NFS src and obj, make world was taking over a week. No joking. > Are you > using any special sysctls or special kernel config options? I have been using "sysctl -w vm.swap_async_max=2" for a while. It seems to help throughput on this machine, and definitely helps interactive performance. I suspect that a few extra I/O limiters, or some sort of I/O rate quota system would help enforce fairness even on faster machines. For example, we have a performance anomaly with squid on 3.2 that could be over-eager pagedaemon behaviour flooding the I/O system. > Also, try the latest -CURRENT and see if you can still get it stuck in > objtrm. I haven't had any luck so far in my simulation. If you still > get stuck in objtrm then try Alan's patch and see if that has an effect. Maybe you should send me your latest patch, the atomic_* fixer and I'll give it a whirl. It hasn't turned up in the cvs-cur CTM patches yet. Stephen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sun Jul 11 21:55: 1 1999 Delivered-To: freebsd-current@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id A34C614BCE; Sun, 11 Jul 1999 21:54:55 -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 OAA04220; Mon, 12 Jul 1999 14:24:53 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id OAA29216; Mon, 12 Jul 1999 14:24:52 +0930 (CST) Date: Mon, 12 Jul 1999 14:24:52 +0930 From: Greg Lehey To: FreeBSD mobile Mailing List , FreeBSD current users Subject: When will -CURRENT support PCMCIA modems again? Message-ID: <19990712142452.F21403@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i 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-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've just updated my laptop from 3.2-RELEASE to 4.0-CURRENT, and I find that PCMCIA modems (sio) are no longer supported. I'm playing around with it to get it to work, but so far I've just managed to get panics out of sioprobe. Before I continue with this: is anybody else working on it? If so, I'll get out of your way. 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-current" in the body of the message From owner-freebsd-current Sun Jul 11 23:31: 7 1999 Delivered-To: freebsd-current@freebsd.org Received: from holonet.net (zen.holonet.net [198.207.169.5]) by hub.freebsd.org (Postfix) with ESMTP id D1704150D5 for ; Sun, 11 Jul 1999 23:31:05 -0700 (PDT) (envelope-from adamw@holonet.net) Received: from DialupEudora (adamw@localhost) by holonet.net (Adam Wight) with SMTP id XAA05748; Sun, 11 Jul 1999 23:26:46 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 11 Jul 1999 22:27:04 -0800 To: freebsd-current@freebsd.org From: adamw@holonet.net (Adam Wight) Subject: ftp passive mode Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Why was the FTP_PASS_MODE logic changed? This forces everyone who uses active connections to alter their environment... -Adam Wight To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 0: 4: 7 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 8D7A315002 for ; Mon, 12 Jul 1999 00:04:02 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id XAA66214; Sun, 11 Jul 1999 23:58:52 -0700 (PDT) (envelope-from dillon) Date: Sun, 11 Jul 1999 23:58:52 -0700 (PDT) From: Matthew Dillon Message-Id: <199907120658.XAA66214@apollo.backplane.com> To: Peter Jeremy Cc: mike@ducky.net, freebsd-current@FreeBSD.ORG Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") References: <99Jul12.085624est.40350@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :That said, it should be fairly simple to change Matt's new in-line :assembler versions to insert LOCK prefixes when building an SMP :kernel. (Although I don't know that this is necessary yet, given :the `Big Giant Lock'). : :There remains the problem of locating all the operations in the kernel :that _should_ be atomic but aren't marked as such. Doug Rabson and :the rest of the Alpha porting crew will have found a lot of these, but :locating race conditions by waiting for them to occur is not the best :solution. : :Peter Here's the patch. Alan should be committing it (or something close to it) soon. I did add the lock prefix, because I expect the SMP stuff will eventually depend on the atomic macros actually being SMP-atomic. It took a few iterations to get the __asm statement right :-) This patch appears to fix the objtrm problem and may also fix other potential VM races. -Matt Index: i386/include/atomic.h =================================================================== RCS file: /home/ncvs/src/sys/i386/include/atomic.h,v retrieving revision 1.1 diff -u -r1.1 atomic.h --- atomic.h 1998/08/24 08:39:36 1.1 +++ atomic.h 1999/07/11 08:03:50 @@ -30,29 +30,131 @@ /* * Various simple arithmetic on memory which is atomic in the presence - * of interrupts. + * of interrupts. This code is now SMP safe as well. * - * Note: these versions are not SMP safe. + * The assembly is volatilized to demark potential before-and-after side + * effects if an interrupt or SMP collision were to occurs. */ -#define atomic_set_char(P, V) (*(u_char*)(P) |= (V)) -#define atomic_clear_char(P, V) (*(u_char*)(P) &= ~(V)) -#define atomic_add_char(P, V) (*(u_char*)(P) += (V)) -#define atomic_subtract_char(P, V) (*(u_char*)(P) -= (V)) - -#define atomic_set_short(P, V) (*(u_short*)(P) |= (V)) -#define atomic_clear_short(P, V) (*(u_short*)(P) &= ~(V)) -#define atomic_add_short(P, V) (*(u_short*)(P) += (V)) -#define atomic_subtract_short(P, V) (*(u_short*)(P) -= (V)) - -#define atomic_set_int(P, V) (*(u_int*)(P) |= (V)) -#define atomic_clear_int(P, V) (*(u_int*)(P) &= ~(V)) -#define atomic_add_int(P, V) (*(u_int*)(P) += (V)) -#define atomic_subtract_int(P, V) (*(u_int*)(P) -= (V)) - -#define atomic_set_long(P, V) (*(u_long*)(P) |= (V)) -#define atomic_clear_long(P, V) (*(u_long*)(P) &= ~(V)) -#define atomic_add_long(P, V) (*(u_long*)(P) += (V)) -#define atomic_subtract_long(P, V) (*(u_long*)(P) -= (V)) +#define ATOMIC_ASM(type,op) \ + __asm __volatile ("lock; " op : "=m" (*(type *)p) : "ir" (v), "0" (*(type *)p)) + +static __inline void +atomic_set_char(void *p, u_char v) +{ + ATOMIC_ASM(u_char, "orb %1,%0"); +} + +static __inline void +atomic_clear_char(void *p, u_char v) +{ + v = ~v; + ATOMIC_ASM(u_char, "andb %1,%0"); +} + +static __inline void +atomic_add_char(void *p, u_char v) +{ + ATOMIC_ASM(u_char, "addb %1,%0"); +} + +static __inline void +atomic_subtract_char(void *p, u_char v) +{ + ATOMIC_ASM(u_char, "subb %1,%0"); +} + +static __inline void +atomic_set_short(void *p, u_short v) +{ + ATOMIC_ASM(u_short, "orw %1,%0"); +} + +static __inline void +atomic_clear_short(void *p, u_short v) +{ + v = ~v; + ATOMIC_ASM(u_short, "andw %1,%0"); +} + +static __inline void +atomic_add_short(void *p, u_short v) +{ + ATOMIC_ASM(u_short, "addw %1,%0"); +} + +static __inline void +atomic_subtract_short(void *p, u_short v) +{ + ATOMIC_ASM(u_short, "subw %1,%0"); +} + + +static __inline void +atomic_set_int(void *p, u_int v) +{ + ATOMIC_ASM(u_int, "orl %1,%0"); +} + +static __inline void +atomic_clear_int(void *p, u_int v) +{ + v = ~v; + ATOMIC_ASM(u_int, "andl %1,%0"); +} + +static __inline void +atomic_add_int(void *p, u_int v) +{ + ATOMIC_ASM(u_int, "addl %1,%0"); +} + +static __inline void +atomic_subtract_int(void *p, u_int v) +{ + ATOMIC_ASM(u_int, "subl %1,%0"); +} + + +static __inline void +atomic_set_long(void *p, u_long v) +{ + ATOMIC_ASM(u_long, "orl %1,%0"); +} + +static __inline void +atomic_clear_long(void *p, u_long v) +{ + v = ~v; + ATOMIC_ASM(u_long, "andl %1,%0"); +} + +static __inline void +atomic_add_long(void *p, u_long v) +{ + ATOMIC_ASM(u_long, "addl %1,%0"); +} + +static __inline void +atomic_subtract_long(void *p, u_long v) +{ + ATOMIC_ASM(u_long, "subl %1,%0"); +} + +#undef ATOMIC_ASM + +#ifndef I386_CPU + +static __inline int +atomic_cmpex(volatile int *pint, int oldv, int newv) +{ + __asm __volatile ("/* %0 %1 */; lock; cmpxchgl %2,(%3)" + : "=a" (oldv) + : "a" (oldv), "r" (newv), "r" (pint) + ); + return(oldv); +} + +#endif #endif /* ! _MACHINE_ATOMIC_H_ */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 0:32:52 1999 Delivered-To: freebsd-current@freebsd.org Received: from dfw-ix15.ix.netcom.com (dfw-ix15.ix.netcom.com [206.214.98.15]) by hub.freebsd.org (Postfix) with ESMTP id 67802151D8 for ; Mon, 12 Jul 1999 00:32:50 -0700 (PDT) (envelope-from asami@cs.berkeley.edu) Received: (from smap@localhost) by dfw-ix15.ix.netcom.com (8.8.4/8.8.4) id CAA05614; Mon, 12 Jul 1999 02:32:14 -0500 (CDT) Received: from sji-ca4-70.ix.netcom.com(205.186.212.198) by dfw-ix15.ix.netcom.com via smap (V1.3) id rma005543; Mon Jul 12 02:31:59 1999 Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.9.3/8.6.9) id AAA67992; Mon, 12 Jul 1999 00:31:52 -0700 (PDT) Date: Mon, 12 Jul 1999 00:31:52 -0700 (PDT) Message-Id: <199907120731.AAA67992@silvia.hip.berkeley.edu> X-Authentication-Warning: silvia.hip.berkeley.edu: asami set sender to asami@cs.berkeley.edu using -f To: nik@nothing-going-on.demon.co.uk Cc: cpiazza@home.net, nik@nothing-going-on.demon.co.uk, dcs@newsguy.com, nicblais@videotron.ca, freebsd-current@FreeBSD.ORG In-reply-to: <19990712004612.A51439@catkin.nothing-going-on.org> (message from Nik Clayton on Mon, 12 Jul 1999 00:46:12 +0100) Subject: Re: HELP!!! -CURRENT libtool problem. From: asami@FreeBSD.ORG (Satoshi - Ports Wraith - Asami) References: <37810FDD.C1321FE7@videotron.ca> <37887C61.2F462FD@newsguy.com> <19990711220050.A31542@catkin.nothing-going-on.org> <19990712155440.B494@norn.ca.eu.org> <19990712004612.A51439@catkin.nothing-going-on.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * From: Nik Clayton I really wish you would stop spreading FUD. Don't open your mouth if you don't know what you are talking about. * I was under the impression that if you were CVSup'ing the ports tree then * any changes to the ports subsystem (for example, new command line * parameters to fetch(1)) would be utilised by the ports system *before* * they had been merged in to -stable. The rationale being that if you * were tracking the ports tree in that way then you should be tracking * -current instead. The ports tree tracks *both* -current and -stable. This is the official policy. It has been this way for quite some time (and definitely from before you joined). I have never started using a new feature on -current before it was merged back to -stable (or a new feature before it was officially committed). If it happened to you, that is because you tried to use a new ports tree on an old system. The upgrade kits are your friend. Satoshi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 0:55:46 1999 Delivered-To: freebsd-current@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id CE05114C98 for ; Mon, 12 Jul 1999 00:55:39 -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 113asb-000DkE-00; Mon, 12 Jul 1999 09:52:01 +0200 From: Sheldon Hearn To: adamw@holonet.net (Adam Wight) Cc: freebsd-current@FreeBSD.ORG Subject: Re: ftp passive mode In-reply-to: Your message of "Sun, 11 Jul 1999 22:27:04 PST." Date: Mon, 12 Jul 1999 09:52:01 +0200 Message-ID: <52837.931765921@axl.noc.iafrica.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Jul 1999 22:27:04 PST, Adam Wight wrote: > Why was the FTP_PASS_MODE logic changed? This forces everyone who > uses active connections to alter their environment... Please let's not get into this again. This was discussed to death on the hackers mailing list last week and the week before. The change is not going to be reverted. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 0:56: 5 1999 Delivered-To: freebsd-current@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 5A76B1521C for ; Mon, 12 Jul 1999 00:55:56 -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 IAA06688; Mon, 12 Jul 1999 08:52:56 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Mon, 12 Jul 1999 08:52:56 +0100 (BST) From: Doug Rabson To: Mike Haertel Cc: Matthew Dillon , Alan Cox , Stephen McKay , Andrew Gallatin , freebsd-current@freebsd.org Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") In-Reply-To: <199907112249.PAA16398@ducky.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 11 Jul 1999, Mike Haertel wrote: > >On Sat, 10 Jul 1999, Matthew Dillon wrote: > >> > >> The supposedly atomic functions in i386/include/atomic.h are not > >> as atomic as was previously thought :-): > >> > >> #define atomic_add_short(P, V) (*(u_short*)(P) += (V)) > >[...] > > > >Before I fixed this stuff for the alpha, the += expressions were > >scattered all over the source tree. At least you get to fix the macro :-). > > Um. FYI on x86, even if the compiler generates the RMW > form "addl $1, foo", it's not atomic. If you want it to > be atomic you have to precede the opcode with a LOCK > prefix 0xF0. > > I guess I should clarify what I mean by atomic: > > "addl $1, foo" is atomic with respect to interrupts. > However, it is not atomic with respect to other processors, > i.e is not SMP safe. > > "lock addl $1, foo" is both atomic with respect to > interrupts, and also with respect to activity by > the other processor. I know about this. We (currently) only need it to be atomic wrt interrupts and the i386 header file states this explicitly. The alpha versions of this are SMP safe simply because the code sequence which was interrupt safe was the same. -- 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-current" in the body of the message From owner-freebsd-current Mon Jul 12 1: 2:23 1999 Delivered-To: freebsd-current@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 37DE71520F for ; Mon, 12 Jul 1999 01:02:19 -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 JAA14597; Mon, 12 Jul 1999 09:00:59 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Mon, 12 Jul 1999 09:00:59 +0100 (BST) From: Doug Rabson To: Peter Jeremy Cc: mike@ducky.net, freebsd-current@freebsd.org Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") In-Reply-To: <99Jul12.085624est.40350@border.alcanet.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 12 Jul 1999, Peter Jeremy wrote: > Mike Haertel wrote: > >Um. FYI on x86, even if the compiler generates the RMW > >form "addl $1, foo", it's not atomic. If you want it to > >be atomic you have to precede the opcode with a LOCK > >prefix 0xF0. > > I'd noticed that point as well. The top of sys/i386/include/atomic.h > _does_ make is clear that they aren't SMP safe: > > /* > * Various simple arithmetic on memory which is atomic in the presence > * of interrupts. > * > * Note: these versions are not SMP safe. > */ > > That said, it should be fairly simple to change Matt's new in-line > assembler versions to insert LOCK prefixes when building an SMP > kernel. (Although I don't know that this is necessary yet, given > the `Big Giant Lock'). We don't need the lock prefix for the current SMP implementation. A lock prefix would be needed in a multithreaded implementation but should not be added unless the kernel is an SMP kernel otherwise UP performance would suffer. -- 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-current" in the body of the message From owner-freebsd-current Mon Jul 12 1:51:36 1999 Delivered-To: freebsd-current@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 C409914CD0 for ; Mon, 12 Jul 1999 01:51:20 -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 KAA21696 for freebsd-current@FreeBSD.ORG; Mon, 12 Jul 1999 10:50:45 +0200 (CEST) (envelope-from olli) Date: Mon, 12 Jul 1999 10:50:45 +0200 (CEST) From: Oliver Fromme Message-Id: <199907120850.KAA21696@dorifer.heim3.tu-clausthal.de> To: freebsd-current@FreeBSD.ORG Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") Organization: Administration Heim 3 Reply-To: freebsd-current@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-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug Rabson wrote in list.freebsd-current: > On Mon, 12 Jul 1999, Peter Jeremy wrote: > > That said, it should be fairly simple to change Matt's new in-line > > assembler versions to insert LOCK prefixes when building an SMP > > kernel. (Although I don't know that this is necessary yet, given > > the `Big Giant Lock'). > > We don't need the lock prefix for the current SMP implementation. A lock > prefix would be needed in a multithreaded implementation but should not be > added unless the kernel is an SMP kernel otherwise UP performance would > suffer. In my list of i386 clock cycles, the lock prefix is listed with 0 (zero) cycles. That would mean that it does not affect performance on UP systems (except that it bloats the kernel by 1 byte for each such macro, which _might_ have negative effect on the caches in the worst case, but this is not very likely). 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-current" in the body of the message From owner-freebsd-current Mon Jul 12 2:14:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 8B07214D47 for ; Mon, 12 Jul 1999 02:14:26 -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 0837981; Mon, 12 Jul 1999 17:11:49 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Doug Rabson Cc: Peter Jeremy , mike@ducky.net, freebsd-current@freebsd.org Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") In-reply-to: Your message of "Mon, 12 Jul 1999 09:00:59 +0100." Date: Mon, 12 Jul 1999 17:11:48 +0800 From: Peter Wemm Message-Id: <19990712091149.0837981@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug Rabson wrote: > On Mon, 12 Jul 1999, Peter Jeremy wrote: > > > Mike Haertel wrote: > > >Um. FYI on x86, even if the compiler generates the RMW > > >form "addl $1, foo", it's not atomic. If you want it to > > >be atomic you have to precede the opcode with a LOCK > > >prefix 0xF0. > > > > I'd noticed that point as well. The top of sys/i386/include/atomic.h > > _does_ make is clear that they aren't SMP safe: > > > > /* > > * Various simple arithmetic on memory which is atomic in the presence > > * of interrupts. > > * > > * Note: these versions are not SMP safe. > > */ > > > > That said, it should be fairly simple to change Matt's new in-line > > assembler versions to insert LOCK prefixes when building an SMP > > kernel. (Although I don't know that this is necessary yet, given > > the `Big Giant Lock'). > > We don't need the lock prefix for the current SMP implementation. A lock > prefix would be needed in a multithreaded implementation but should not be > added unless the kernel is an SMP kernel otherwise UP performance would > suffer. I was under the impression that a locked instruction was essentially free at runtime, with the sole exception of being one byte larger. If there is any chance of this stuff getting exported to modules via inlines, it should support both as we don't need any more differences between SMP and non-SMP modules than we've already got. :-( Also, with the posted example, atomic_cmpex() is #ifndef I386_CPU - that means it won't be available on any of the default kernels, either at install time or for 99% of post-install systems built from a release. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 2:28:17 1999 Delivered-To: freebsd-current@freebsd.org Received: from cons.org (knight.cons.org [194.233.237.195]) by hub.freebsd.org (Postfix) with ESMTP id 598D814D47 for ; Mon, 12 Jul 1999 02:28:07 -0700 (PDT) (envelope-from cracauer@cons.org) Received: (from cracauer@localhost) by cons.org (8.8.8/8.7.3) id LAA06133 for freebsd-current@freebsd.org; Mon, 12 Jul 1999 11:28:05 +0200 (CEST) Date: Mon, 12 Jul 1999 11:28:04 +0200 From: Martin Cracauer To: freebsd-current@freebsd.org Subject: Using float emulator on a system with FPU? Message-ID: <19990712112802.A4800@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Moin, I'm going to work on FreeBSD's floating point support, but I need to test my changes on systems using the FPU emulators (non-GPL and GPL). Is there any way to use these emulators on a system that has a hardware FPU? Guessing from LINT's comments, you had to leave out npx and include one of the emulators, but -current's config refuses to config a kernel file without npx support. I also tried to add "disable" to npx's config line, which compiles and runs ok, but still uses the hardware FPU (timing and exception test). Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 3:34:35 1999 Delivered-To: freebsd-current@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id 7438D14D4E for ; Mon, 12 Jul 1999 03:34:31 -0700 (PDT) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id GAA14268; Mon, 12 Jul 1999 06:32:58 -0400 (EDT) (envelope-from luoqi) Date: Mon, 12 Jul 1999 06:32:58 -0400 (EDT) From: Luoqi Chen Message-Id: <199907121032.GAA14268@lor.watermarkgroup.com> To: dfr@nlsystems.com, jeremyp@gsmx07.alcatel.com.au Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") Cc: freebsd-current@FreeBSD.ORG, mike@ducky.net Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > We don't need the lock prefix for the current SMP implementation. A lock > prefix would be needed in a multithreaded implementation but should not be > added unless the kernel is an SMP kernel otherwise UP performance would > suffer. > > -- > Doug Rabson Mail: dfr@nlsystems.com > Nonlinear Systems Ltd. Phone: +44 181 442 9037 > Lock prefix should be added to kernel modules if we want a single set for both SMP and UP. -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 4:24:27 1999 Delivered-To: freebsd-current@freebsd.org Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (Postfix) with ESMTP id E07E114C8E for ; Mon, 12 Jul 1999 04:24:23 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id VAA05708; Mon, 12 Jul 1999 21:21:41 +1000 Date: Mon, 12 Jul 1999 21:21:41 +1000 From: Bruce Evans Message-Id: <199907121121.VAA05708@godzilla.zeta.org.au> To: dfr@nlsystems.com, peter@netplex.com.au Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") Cc: freebsd-current@FreeBSD.ORG, jeremyp@gsmx07.alcatel.com.au, mike@ducky.net Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >I was under the impression that a locked instruction was essentially free >at runtime, with the sole exception of being one byte larger. No, they are very expensive, at least when done in a minimal loop (8 cycles on my P5/133 UP and 16 cycles on my Celeron/450). ISTR Steve Passe saying that they took 30 cycles on an early SMP system. >Also, with the posted example, atomic_cmpex() is #ifndef I386_CPU - that >means it won't be available on any of the default kernels, either at >install time or for 99% of post-install systems built from a release. No one seems to have noticed dropping of support for coprocessorless/ working-FPU-emulatorless systems in cc (the default for -ffancy-math-387 changed from off to on with egcs). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 4:46:44 1999 Delivered-To: freebsd-current@freebsd.org Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9]) by hub.freebsd.org (Postfix) with ESMTP id 1FCA114C14 for ; Mon, 12 Jul 1999 04:46:37 -0700 (PDT) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id VAA07535; Mon, 12 Jul 1999 21:44:59 +1000 Date: Mon, 12 Jul 1999 21:44:59 +1000 From: Bruce Evans Message-Id: <199907121144.VAA07535@godzilla.zeta.org.au> To: cracauer@cons.org, freebsd-current@FreeBSD.ORG Subject: Re: Using float emulator on a system with FPU? Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >I'm going to work on FreeBSD's floating point support, but I need to >test my changes on systems using the FPU emulators (non-GPL and GPL). > >Is there any way to use these emulators on a system that has a >hardware FPU? Toggling `npx_exists' using ddb used to work. Now, toggling it off on i586 systems causes a panic in the i586-optimised copy routines. >Guessing from LINT's comments, you had to leave out npx and include >one of the emulators, but -current's config refuses to config a kernel >file without npx support. This was broken by adding "mandatory" to the npx line in file.i386. >I also tried to add "disable" to npx's config line, which compiles and >runs ok, but still uses the hardware FPU (timing and exception test). This may be because npx0 now attaches to nexus, but "disable" only works for isa devices. It's annoying that userconfig doesn't support displaying or changing npx0. BTW, PCI devices are no longer displayed by userconfig. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 7:15:45 1999 Delivered-To: freebsd-current@freebsd.org Received: from lamb.sas.com (lamb.sas.com [192.35.83.8]) by hub.freebsd.org (Postfix) with ESMTP id 7A45B1507E for ; Mon, 12 Jul 1999 07:15:05 -0700 (PDT) (envelope-from dagill@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 KAA16934 for ; Mon, 12 Jul 1999 10:15:04 -0400 (EDT) Received: from frink.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA14459; Mon, 12 Jul 1999 10:14:34 -0400 Received: (from dagill@localhost) by frink.unx.sas.com (8.9.3/8.9.3) id KAA36811 for freebsd-current@freebsd.org; Mon, 12 Jul 1999 10:14:34 -0400 (EDT) (envelope-from dagill) From: Dave Gillham Message-Id: <199907121414.KAA36811@frink.unx.sas.com> Subject: patch: PAM hooks for rshd & rlogind To: freebsd-current@freebsd.org Date: Mon, 12 Jul 1999 10:14:34 -0400 (EDT) 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-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Attached are patches for rshd and rlogind to add a hook to use PAM modules to handle user authentication. Currently we have restricted compute servers that we want to keep most users from directly logging into, but that must retain the .rhosts functionality for the few users that are allowed to login. For this reason we couldn't just use the -l flag with rshd. Additionally, because our users must be able to place processes on the servers (via a custom inetd interface), we could not just remove their password entries. While we could have set their shell to /sbin/nologin this would have been inconvenient as we use a shared password file on our network. The following code (which originally came from login) gives us the ability to use PAM to deny the user access before attempting to access their .rhosts file. Without these changes, rsh and rlogin authenticate the user by their .rhosts file without giving PAM a chance to validate them. With these changes, we provide the oportunity to callout to PAM before any .rhost checking and thus deny user login based on the policy coded into the PAM module. Please consider these changes for review and integration into the base system. Thanks, Dave Gillham dagill@unx.sas.com Index: rlogind/Makefile =================================================================== RCS file: /usr/mirror/ncvs/src/libexec/rlogind/Makefile,v retrieving revision 1.10 diff -r1.10 Makefile 23a24,30 > .if defined(NOPAM) > CFLAGS+= -DNO_PAM > .else > DPADD+= ${LIBPAM} > LDADD+= ${MINUSLPAM} > .endif > Index: rlogind/rlogind.c =================================================================== RCS file: /usr/mirror/ncvs/src/libexec/rlogind/rlogind.c,v retrieving revision 1.23 diff -r1.23 rlogind.c 82a83,87 > #ifndef NO_PAM > #include > #include > #endif > 125a131,134 > #ifndef NO_PAM > static int auth_pam __P((char *)); > #endif > 198a208,313 > #ifndef NO_PAM > /* > * Attempt to authenticate the user using PAM. Returns 0 if the user is > * authenticated, or 1 if not authenticated. If some sort of PAM system > * error occurs (e.g., the "/etc/pam.conf" file is missing) then this > * function returns -1. This can be used as an indication that we should > * fall back to a different authentication mechanism. > */ > static int > auth_pam(char *username) > { > struct passwd *pawd; > pam_handle_t *pamh = NULL; > const char *tmpl_user; > const void *item; > int rval; > char *tty, *ttyn; > char hostname[MAXHOSTNAMELEN]; > char tname[sizeof(_PATH_TTY) + 10]; > int e; > > static struct pam_conv conv = { misc_conv, NULL }; > > ttyn = ttyname(STDIN_FILENO); > > if (ttyn == NULL || *ttyn == '\0') { > (void)snprintf(tname, sizeof(tname), "%s??", _PATH_TTY); > ttyn = tname; > } > if ((tty = strrchr(ttyn, '/')) != NULL) > ++tty; > else > tty = ttyn; > > rval = gethostname(hostname, sizeof(hostname)); > > if (rval < 0) { > syslog(LOG_ERR, "auth_pam: Failed to resolve local hostname"); > return -1; > } > if ((e = pam_start("rshd", username, &conv, &pamh)) != PAM_SUCCESS) { > syslog(LOG_ERR, "pam_start: %s", pam_strerror(pamh, e)); > return -1; > } > if ((e = pam_set_item(pamh, PAM_TTY, tty)) != PAM_SUCCESS) { > syslog(LOG_ERR, "pam_set_item(PAM_TTY): %s", > pam_strerror(pamh, e)); > return -1; > } > if (hostname != NULL && > (e = pam_set_item(pamh, PAM_RHOST, hostname)) != PAM_SUCCESS) { > syslog(LOG_ERR, "pam_set_item(PAM_RHOST): %s", > pam_strerror(pamh, e)); > return -1; > } > > e = pam_authenticate(pamh, 0); > > switch (e) { > case PAM_SUCCESS: > /* > * With PAM we support the concept of a "template" > * user. The user enters a login name which is > * authenticated by PAM, usually via a remote service > * such as RADIUS or TACACS+. If authentication > * succeeds, a different but related "template" name > * is used for setting the credentials, shell, and > * home directory. The name the user enters need only > * exist on the remote authentication server, but the > * template name must be present in the local password > * database. > * > * This is supported by two various mechanisms in the > * individual modules. However, from the application's > * point of view, the template user is always passed > * back as a changed value of the PAM_USER item. > */ > if ((e = pam_get_item(pamh, PAM_USER, &item)) == > PAM_SUCCESS) { > tmpl_user = (const char *) item; > if (strcmp(username, tmpl_user) != 0) > pawd = getpwnam(tmpl_user); > } else > syslog(LOG_ERR, "Couldn't get PAM_USER: %s", pam_strerror(pamh, e)); > rval = 0; > break; > > case PAM_AUTH_ERR: > case PAM_USER_UNKNOWN: > case PAM_MAXTRIES: > rval = 1; > break; > > default: > syslog(LOG_ERR, "auth_pam: %s", pam_strerror(pamh, e)); > rval = -1; > break; > } > if ((e = pam_end(pamh, e)) != PAM_SUCCESS) { > syslog(LOG_ERR, "pam_end: %s", pam_strerror(pamh, e)); > rval = -1; > } > return rval; > } > #endif > 278a394,395 > > 588a706 > int retval; 596a715,727 > > #ifndef NO_PAM > retval = auth_pam(lusername); > > if (retval < 0) { > syslog(LOG_ERR,"PAM authentication failed"); > } > else if (retval == 1) { > syslog(LOG_ERR,"User %s failed PAM authentication",lusername); > exit(1); > } > #endif > Index: rshd/Makefile =================================================================== RCS file: /usr/mirror/ncvs/src/libexec/rshd/Makefile,v retrieving revision 1.10 diff -r1.10 Makefile 19a20,26 > .if defined(NOPAM) > CFLAGS+= -DNO_PAM > .else > DPADD+= ${LIBPAM} > LDADD+= ${MINUSLPAM} > .endif > Index: rshd/rshd.c =================================================================== RCS file: /usr/mirror/ncvs/src/libexec/rshd/rshd.c,v retrieving revision 1.25 diff -r1.25 rshd.c 82a83,87 > #ifndef NO_PAM > #include > #include > #endif > 94a100,103 > #ifndef NO_PAM > static int auth_pam __P((char *)); > #endif > 197a207,314 > #ifndef NO_PAM > /* > * Attempt to authenticate the user using PAM. Returns 0 if the user is > * authenticated, or 1 if not authenticated. If some sort of PAM system > * error occurs (e.g., the "/etc/pam.conf" file is missing) then this > * function returns -1. This can be used as an indication that we should > * fall back to a different authentication mechanism. > */ > static int > auth_pam(char *username) > { > struct passwd *pawd; > pam_handle_t *pamh = NULL; > const char *tmpl_user; > const void *item; > int rval; > char *tty, *ttyn; > char hostname[MAXHOSTNAMELEN]; > char tname[sizeof(_PATH_TTY) + 10]; > int e; > > static struct pam_conv conv = { misc_conv, NULL }; > > ttyn = ttyname(STDIN_FILENO); > > if (ttyn == NULL || *ttyn == '\0') { > (void)snprintf(tname, sizeof(tname), "%s??", _PATH_TTY); > ttyn = tname; > } > if ((tty = strrchr(ttyn, '/')) != NULL) > ++tty; > else > tty = ttyn; > > rval = gethostname(hostname, sizeof(hostname)); > > if (rval < 0) { > syslog(LOG_ERR, "auth_pam: Failed to resolve local hostname"); > return -1; > } > if ((e = pam_start("rshd", username, &conv, &pamh)) != PAM_SUCCESS) { > syslog(LOG_ERR, "pam_start: %s", pam_strerror(pamh, e)); > return -1; > } > if ((e = pam_set_item(pamh, PAM_TTY, tty)) != PAM_SUCCESS) { > syslog(LOG_ERR, "pam_set_item(PAM_TTY): %s", > pam_strerror(pamh, e)); > return -1; > } > if (hostname != NULL && > (e = pam_set_item(pamh, PAM_RHOST, hostname)) != PAM_SUCCESS) { > syslog(LOG_ERR, "pam_set_item(PAM_RHOST): %s", > pam_strerror(pamh, e)); > return -1; > } > > e = pam_authenticate(pamh, 0); > > > switch (e) { > > case PAM_SUCCESS: > /* > * With PAM we support the concept of a "template" > * user. The user enters a login name which is > * authenticated by PAM, usually via a remote service > * such as RADIUS or TACACS+. If authentication > * succeeds, a different but related "template" name > * is used for setting the credentials, shell, and > * home directory. The name the user enters need only > * exist on the remote authentication server, but the > * template name must be present in the local password > * database. > * > * This is supported by two various mechanisms in the > * individual modules. However, from the application's > * point of view, the template user is always passed > * back as a changed value of the PAM_USER item. > */ > if ((e = pam_get_item(pamh, PAM_USER, &item)) == > PAM_SUCCESS) { > tmpl_user = (const char *) item; > if (strcmp(username, tmpl_user) != 0) > pawd = getpwnam(tmpl_user); > } else > syslog(LOG_ERR, "Couldn't get PAM_USER: %s", pam_strerror(pamh, e)); > rval = 0; > break; > > case PAM_AUTH_ERR: > case PAM_USER_UNKNOWN: > case PAM_MAXTRIES: > rval = 1; > break; > > default: > syslog(LOG_ERR, "auth_pam: %s", pam_strerror(pamh, e)); > rval = -1; > break; > } > if ((e = pam_end(pamh, e)) != PAM_SUCCESS) { > syslog(LOG_ERR, "pam_end: %s", pam_strerror(pamh, e)); > rval = -1; > } > return rval; > } > #endif > 215a333 > int retval; 428a547,558 > > #ifndef NO_PAM > retval = auth_pam(locuser); > > if (retval < 0) { > syslog(LOG_ERR,"PAM authentication failed"); > } > else if (retval == 1) { > syslog(LOG_ERR,"User %s failed PAM authentication",locuser); > exit(1); > } > #endif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 9:49:17 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 91D0114FD2 for ; Mon, 12 Jul 1999 09:49:03 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA70249; Mon, 12 Jul 1999 09:47:11 -0700 (PDT) (envelope-from dillon) Date: Mon, 12 Jul 1999 09:47:11 -0700 (PDT) From: Matthew Dillon Message-Id: <199907121647.JAA70249@apollo.backplane.com> To: Luoqi Chen Cc: dfr@nlsystems.com, jeremyp@gsmx07.alcatel.com.au, freebsd-current@FreeBSD.ORG, mike@ducky.net Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") References: <199907121032.GAA14268@lor.watermarkgroup.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> We don't need the lock prefix for the current SMP implementation. A lock :> prefix would be needed in a multithreaded implementation but should not be :> added unless the kernel is an SMP kernel otherwise UP performance would :> suffer. :> :> -- :> Doug Rabson Mail: dfr@nlsystems.com :> Nonlinear Systems Ltd. Phone: +44 181 442 9037 :> :Lock prefix should be added to kernel modules if we want a single set for :both SMP and UP. : :-lq Yah, definitely for simple things like this, it will save us a lot of work in the future. And so I have. p.s. I'm pretty sure that the lock prefix costs nothing on a UP system, and probably wouldn't be noticed on an SMP system either because the write-allocation overhead is already pretty bad. But I haven't tested it. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 9:55:47 1999 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id A43D415059 for ; Mon, 12 Jul 1999 09:55:28 -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 SAA20138; Mon, 12 Jul 1999 18:52:02 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: Luoqi Chen , dfr@nlsystems.com, jeremyp@gsmx07.alcatel.com.au, freebsd-current@FreeBSD.ORG, mike@ducky.net Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") In-reply-to: Your message of "Mon, 12 Jul 1999 09:47:11 PDT." <199907121647.JAA70249@apollo.backplane.com> Date: Mon, 12 Jul 1999 18:52:02 +0200 Message-ID: <20136.931798322@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > p.s. I'm pretty sure that the lock prefix costs nothing on a UP system, > and probably wouldn't be noticed on an SMP system either because the > write-allocation overhead is already pretty bad. But I haven't tested > it. it's actually quite expensive in terms of bus bandwidth because a lot of things have to be synchronized and stalled... -- 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-current" in the body of the message From owner-freebsd-current Mon Jul 12 10: 8:30 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 741F71513B for ; Mon, 12 Jul 1999 10:08:22 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA70338; Mon, 12 Jul 1999 10:06:14 -0700 (PDT) (envelope-from dillon) Date: Mon, 12 Jul 1999 10:06:14 -0700 (PDT) From: Matthew Dillon Message-Id: <199907121706.KAA70338@apollo.backplane.com> To: Poul-Henning Kamp Cc: Luoqi Chen , dfr@nlsystems.com, jeremyp@gsmx07.alcatel.com.au, freebsd-current@FreeBSD.ORG, mike@ducky.net Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") References: <20136.931798322@critter.freebsd.dk> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> p.s. I'm pretty sure that the lock prefix costs nothing on a UP system, :> and probably wouldn't be noticed on an SMP system either because the :> write-allocation overhead is already pretty bad. But I haven't tested :> it. : :it's actually quite expensive in terms of bus bandwidth because a lot of :things have to be synchronized and stalled... : :-- :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! It depends on which L1/L2 cache model Intel is using. I wouldn't expect it to be much more expensive then a standard read-modify-write, but I will run some tests on an SMP box between two user processes to get some hard numbers. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 10:40:56 1999 Delivered-To: freebsd-current@freebsd.org Received: from metriclient-2.uoregon.edu (metriclient-2.uoregon.edu [128.223.172.2]) by hub.freebsd.org (Postfix) with ESMTP id 71F6114DC3 for ; Mon, 12 Jul 1999 10:40:28 -0700 (PDT) (envelope-from gurney_j@efn.org) Received: (from jmg@localhost) by metriclient-2.uoregon.edu (8.9.1/8.8.7) id KAA00800; Mon, 12 Jul 1999 10:38:45 -0700 (PDT) Message-ID: <19990712103845.39296@hydrogen.fircrest.net> Date: Mon, 12 Jul 1999 10:38:45 -0700 From: John-Mark Gurney To: Matthew Dillon Cc: Luoqi Chen , dfr@nlsystems.com, jeremyp@gsmx07.alcatel.com.au, freebsd-current@FreeBSD.ORG, mike@ducky.net Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") References: <199907121032.GAA14268@lor.watermarkgroup.com> <199907121647.JAA70249@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199907121647.JAA70249@apollo.backplane.com>; from Matthew Dillon on Mon, Jul 12, 1999 at 09:47:11AM -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-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon scribbled this message on Jul 12: > p.s. I'm pretty sure that the lock prefix costs nothing on a UP system, > and probably wouldn't be noticed on an SMP system either because the > write-allocation overhead is already pretty bad. But I haven't tested > it. actually, I'm not so sure, it guarantees that NO other bus operation will succeed while this is happening... what happens if a pci bus mastering card makes a modification to this value? sure, it normally won't happen, but it can... and w/o the lock prefix, this CAN happen from what I understand of the architecture... so, it does have to lock even the memory bus, simply the cache isn't enough for the lock to do what it needs... -- 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-current" in the body of the message From owner-freebsd-current Mon Jul 12 10:41:57 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 8568315135 for ; Mon, 12 Jul 1999 10:41:49 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA70496; Mon, 12 Jul 1999 10:41:10 -0700 (PDT) (envelope-from dillon) Date: Mon, 12 Jul 1999 10:41:10 -0700 (PDT) From: Matthew Dillon Message-Id: <199907121741.KAA70496@apollo.backplane.com> To: Matthew Dillon Cc: Poul-Henning Kamp , Luoqi Chen , dfr@nlsystems.com, jeremyp@gsmx07.alcatel.com.au, freebsd-current@FreeBSD.ORG, mike@ducky.net Subject: lock prefix overhead in SMP system - results Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ok, here we are. The lock instruction overhead is significant relative the execution time of the instruction, though on a 450 MHz P-III it is still not a huge problem. Basically 12 vs 89 ns for the non competitive case, and 26 vs 161 ns for the competitive case. empty loop 9.33 ns/loop mode 0 1proc no locks 12.86 ns/loop mode 9 2proc no locks 26.16 ns/loop mode 10 1proc w/ locks 89.87 ns/loop mode 1 2proc w/ locks 161.09 ns/loop mode 2 If you modify the source code and add three nop() calls inside the loop for case 9 and 1 (which also covers 10 and 2), which avoids some of the synchronization overhead, you get numbers closer to what I expect in the real world. ( recompile the code -DREAL_WORLD ) empty loop 9.33 ns/loop mode 0 1proc no locks 55.89 ns/loop 2proc no locks 129.96 ns/loop 1proc w/ locks 98.35 ns/loop 2proc w/ locks 160.96 ns/loop /* * Compile -O2 */ #include #include #include #include #include #include #include #include #define LOOPS 10000000 #define ATOMIC_ASM(type,op) \ __asm __volatile ("lock; " op : "=m" (*(type *)p) : "ir" (v), "0" (*(type *)p)) #define ATOMIC_ASM_NOLOCK(type,op) \ __asm __volatile (op : "=m" (*(type *)p) : "ir" (v), "0" (*(type *)p)) static __inline void atomic_add_int(void *p, u_int v) { ATOMIC_ASM(int, "addl %1,%0"); } static __inline void atomic_add_int_nolock(void *p, u_int v) { ATOMIC_ASM_NOLOCK(int, "addl %1,%0"); } void nop(void) { } int main(int ac, char **av) { int fd; char *ptr; char *wlocks; int pgsize = getpagesize(); volatile int i; int m; int usec; pid_t pid = -1; struct timeval tv1; struct timeval tv2; if (ac == 1) { printf("%s {0,1,2}\n", av[0]); printf(" 0 - empty loop\n"); printf(" 1 - one process\n"); printf(" 2 - two processes\n"); printf(" 8 - empty loop - no lock\n"); printf(" 9 - one process - no lock\n"); printf(" 10- two processes - no lock\n"); exit(1); } m = strtol(av[1], NULL, 0); fd = open("test.dat", O_RDWR|O_CREAT|O_TRUNC, 0666); ftruncate(fd, pgsize); ptr = mmap(NULL, pgsize, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); if (m & 8) wlocks = ""; else wlocks = " w/locks"; gettimeofday(&tv1, NULL); switch(m) { case 10: pid = fork(); /* fall through */ case 9: for (i = 0; i < LOOPS; ++i) { atomic_add_int_nolock(ptr, 1); #ifdef REAL_WORLD nop(); nop(); nop(); #endif } break; case 8: for (i = 0; i < LOOPS; ++i) { ; } break; case 2: pid = fork(); /* fall through */ case 1: for (i = 0; i < LOOPS; ++i) { atomic_add_int(ptr, 1); #ifdef REAL_WORLD nop(); nop(); nop(); #endif } break; case 0: for (i = 0; i < LOOPS; ++i) { ; } break; default: printf("huh?\n"); exit(1); } if (pid == 0) _exit(0); while (wait(NULL) > 0) ; gettimeofday(&tv2, NULL); usec = tv2.tv_usec + 1000000 - tv1.tv_usec + (tv2.tv_sec - tv1.tv_sec - 1) * 1000000; switch(m) { case 0: case 8: printf("empty%s %4.2f ns/loop\n", wlocks, (double)usec * 1000.0 / (double)LOOPS); break; case 1: case 9: printf("1proc%s %4.2f ns/loop\n", wlocks, (double)usec * 1000.0 / (double)LOOPS); break; case 2: case 10: printf("2proc%s %4.2f ns/loop\n", wlocks, (double)usec * 1000.0 / (double)LOOPS / 2.0); break; } return(0); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 10:43: 3 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 23527150E1 for ; Mon, 12 Jul 1999 10:42:56 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA70526; Mon, 12 Jul 1999 10:42:38 -0700 (PDT) (envelope-from dillon) Date: Mon, 12 Jul 1999 10:42:38 -0700 (PDT) From: Matthew Dillon Message-Id: <199907121742.KAA70526@apollo.backplane.com> To: John-Mark Gurney Cc: Luoqi Chen , dfr@nlsystems.com, jeremyp@gsmx07.alcatel.com.au, freebsd-current@FreeBSD.ORG, mike@ducky.net Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") References: <199907121032.GAA14268@lor.watermarkgroup.com> <199907121647.JAA70249@apollo.backplane.com> <19990712103845.39296@hydrogen.fircrest.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :actually, I'm not so sure, it guarantees that NO other bus operation :will succeed while this is happening... what happens if a pci bus :mastering card makes a modification to this value? sure, it normally :won't happen, but it can... and w/o the lock prefix, this CAN happen :from what I understand of the architecture... : :so, it does have to lock even the memory bus, simply the cache isn't :enough for the lock to do what it needs... : :-- : John-Mark Gurney Voice: +1 541 684 8449 : Cu Networking P.O. Box 5693, 97405 As I said, it depends what L1/L2 cache model intel is using. If they are being smart it does *NOT* prevent other bus operations from occuring, it simply locks the cache line containing the item for the duration of the instruction. The worst case should be an extra snoop on the bus. Hold on, I have some numbers. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 10:43:48 1999 Delivered-To: freebsd-current@freebsd.org Received: from ducky.net (gate.ducky.net [199.2.211.252]) by hub.freebsd.org (Postfix) with ESMTP id 2B009150BE for ; Mon, 12 Jul 1999 10:43:30 -0700 (PDT) (envelope-from mike@ducky.net) Received: from ducky.net (localhost.ducky.net [127.0.0.1]) by ducky.net (8.9.1/8.8.5) with ESMTP id KAA17837; Mon, 12 Jul 1999 10:41:26 -0700 (PDT) Message-Id: <199907121741.KAA17837@ducky.net> To: Matthew Dillon Cc: Luoqi Chen , dfr@nlsystems.com, jeremyp@gsmx07.alcatel.com.au, freebsd-current@FreeBSD.ORG, mike@ducky.net, mike@ducky.net Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") In-reply-to: Your message of "Mon, 12 Jul 1999 09:47:11 PDT." <199907121647.JAA70249@apollo.backplane.com> Date: Mon, 12 Jul 1999 10:41:26 -0700 From: Mike Haertel Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You might think that, due to MESI state bits in the cache and bus coherency protocols, that locks are "free". Unfortunately, the lock prefix has a measurable cost on a UP system, at least on P6 and later processors. The reason is that the locked memory operation is an "at-retirement" operation, which means that it waits for the out-of-order execution of all instructions logically older than it to complete before it even starts to operate. (Suppose locks were not at-retirement--then locks on cache lines could be obtained out-of-order, and this would lead to a possibility of global deadlocks even if the original code was deadlock-free.) Locks may in fact have further serializing effects, like draining the store queues prior to obtaining the lock, I have forgotten. Hmm, I am almost sure the lock needs to drain the store queues. Let's assume it does. This all adds up to "locks are painful". Some data: Loop: addl $1, foo subl $1, %ecx jne Loop requires about 30 seconds to 10M iterations, and with "lock; addl $1, foo" requires about 4 minutes and 30 seconds on my 333 MHz P-II. (This loop has other problems and someone else just posted a much better lock benchmark than this. Anyway...) As future processors become more deeply out-of-order, locks will become even more painful (although one could imagine at some point that they might cross the pain threshold that would justify heroic hardware solutions allowing OOO locks). Anyway, taking all that into account, I still agree with Dillon that it is a better software solution to allow the same loadable drivers to work for both UP and MP systems whenever possible. One way to do this while not feeling the full pain of locks would be to make the atomic operations actual function calls through function pointers. They could point to the locked or non-locked versions depending on whether the kernel was SMP. Although function calls are more expensive than inline code, they aren't necessarily a lot more so, and function calls to non-locked RMW operations are certainly much cheaper than inline locked RMW operations. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 10:47:44 1999 Delivered-To: freebsd-current@freebsd.org Received: from mailman.cs.ucla.edu (Mailman.CS.UCLA.EDU [131.179.128.30]) by hub.freebsd.org (Postfix) with ESMTP id ACE441514D for ; Mon, 12 Jul 1999 10:47:36 -0700 (PDT) (envelope-from scottm@mordred.cs.ucla.edu) Received: from mordred.cs.ucla.edu (mordred.cs.ucla.edu [131.179.192.128]) by mailman.cs.ucla.edu (8.9.1/UCLACS-5.0) with ESMTP id KAA25038 for ; Mon, 12 Jul 1999 10:47:31 -0700 (PDT) Received: (from scottm@localhost) by mordred.cs.ucla.edu (8.9.3/8.9.3) id KAA02111 for freebsd-current@freebsd.org; Mon, 12 Jul 1999 10:47:33 -0700 (PDT) (envelope-from scottm) Date: Mon, 12 Jul 1999 10:47:33 -0700 (PDT) From: Scott Michel Message-Id: <199907121747.KAA02111@mordred.cs.ucla.edu> To: freebsd-current@freebsd.org Subject: Just the kind of news we needed... Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG If you haven't /.'d today, there's a news article purporting that FreeBSD can be exploited via kernel modules: http://thc.pimmel.com/ -scooter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 10:49:13 1999 Delivered-To: freebsd-current@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id B1384150BE; Mon, 12 Jul 1999 10:48:49 -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 TAA63538; Mon, 12 Jul 1999 19:47:46 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199907121747.TAA63538@gratis.grondar.za> To: Greg Lehey Cc: FreeBSD mobile Mailing List , FreeBSD current users Subject: Re: When will -CURRENT support PCMCIA modems again? Date: Mon, 12 Jul 1999 19:47:44 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I've just updated my laptop from 3.2-RELEASE to 4.0-CURRENT, and I > find that PCMCIA modems (sio) are no longer supported. I'm playing > around with it to get it to work, but so far I've just managed to get > panics out of sioprobe. Before I continue with this: is anybody else > working on it? If so, I'll get out of your way. Warner Losh is working on this, but he has the bad taste to let his day job take priority, so this will take a bit of time ;-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 10:52:53 1999 Delivered-To: freebsd-current@freebsd.org Received: from gratis.grondar.za (gratis.grondar.za [196.7.18.65]) by hub.freebsd.org (Postfix) with ESMTP id 7F31015092 for ; Mon, 12 Jul 1999 10:52:45 -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 TAA63578; Mon, 12 Jul 1999 19:50:12 +0200 (SAST) (envelope-from mark@grondar.za) Message-Id: <199907121750.TAA63578@gratis.grondar.za> To: Dave Gillham Cc: freebsd-current@FreeBSD.ORG Subject: Re: patch: PAM hooks for rshd & rlogind Date: Mon, 12 Jul 1999 19:50:12 +0200 From: Mark Murray Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Attached are patches for rshd and rlogind to add a hook to use > PAM modules to handle user authentication. Thank you! Saves me (and JDP?) some work! M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 11: 5:47 1999 Delivered-To: freebsd-current@freebsd.org Received: from thelab.hub.org (nat206.255.mpoweredpc.net [142.177.206.255]) by hub.freebsd.org (Postfix) with ESMTP id 92C3015168 for ; Mon, 12 Jul 1999 11:05:36 -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 PAA16370; Mon, 12 Jul 1999 15:06:03 -0300 (ADT) (envelope-from scrappy@hub.org) X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs Date: Mon, 12 Jul 1999 15:06:03 -0300 (ADT) From: The Hermit Hacker To: Scott Michel Cc: freebsd-current@FreeBSD.ORG Subject: Re: Just the kind of news we needed... In-Reply-To: <199907121747.KAA02111@mordred.cs.ucla.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Yup, and if you read freebsd-security@freebsd.org, its old news *shrug* On Mon, 12 Jul 1999, Scott Michel wrote: > If you haven't /.'d today, there's a news article purporting that > FreeBSD can be exploited via kernel modules: > > > http://thc.pimmel.com/ > > > > -scooter > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" 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-current" in the body of the message From owner-freebsd-current Mon Jul 12 11: 7:10 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 471F5150BE for ; Mon, 12 Jul 1999 11:07:01 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA70634; Mon, 12 Jul 1999 11:06:42 -0700 (PDT) (envelope-from dillon) Date: Mon, 12 Jul 1999 11:06:42 -0700 (PDT) From: Matthew Dillon Message-Id: <199907121806.LAA70634@apollo.backplane.com> To: Poul-Henning Kamp Cc: Luoqi Chen , dfr@nlsystems.com, jeremyp@gsmx07.alcatel.com.au, freebsd-current@FreeBSD.ORG, mike@ducky.net Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") References: <20136.931798322@critter.freebsd.dk> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Here we are: Empty loop mode 0 9.21 ns/loop nproc=1 lcks=EMPTY Tight loop, 1 and 2 processes, with and without lock prefix mode 1 16.48 ns/loop nproc=1 lcks=no mode 2 23.65 ns/loop nproc=2 lcks=no mode 3 93.02 ns/loop nproc=1 lcks=yes mode 4 160.82 ns/loop nproc=2 lcks=yes Spread loop, 1 and 2 processes, with and without lock prefix. Other memory operations included in loop to mimic more typical situations. mode 5 37.64 ns/loop nproc=1 lcks=no mode 6 89.28 ns/loop nproc=2 lcks=no mode 7 88.32 ns/loop nproc=1 lcks=yes mode 8 161.08 ns/loop nproc=2 lcks=yes As you can see, the lock prefix creates a stall condition on the locked memory, but does *NOT* stall other memory. The overhead is the same with and without the other assembly ops when the lock prefix is used. Therefore I believe the impact will be unnoticeable. On a duel 450MHz P-III we are talking 37 ns vs 88 ns - an overhead of 50 ns for the one processor case, and an overhead of 72 ns for the two processor case. Still, I suppose if we wanted to optimize the UP case we could do away with the lock prefix on non-SMP machines. I don't know if the SMP variable is accessible from within the i386/include/atomic.h header file, though. -Matt /* * Compile -O2. Appropriate variables have been volatilized to avoid * inappropriate optimizations. */ #include #include #include #include #include #include #include #include #define LOOPS 10000000 #define ATOMIC_ASM(type,op) \ __asm __volatile ("lock; " op : "=m" (*(type *)p) : "ir" (v), "0" (*(type *)p)) #define ATOMIC_ASM_NOLOCK(type,op) \ __asm __volatile (op : "=m" (*(type *)p) : "ir" (v), "0" (*(type *)p)) static __inline void atomic_add_int(void *p, u_int v) { ATOMIC_ASM(int, "addl %1,%0"); } static __inline void atomic_add_int_nolock(void *p, u_int v) { ATOMIC_ASM_NOLOCK(int, "addl %1,%0"); } volatile int GX[8]; /* note: not shared between processes */ int main(int ac, char **av) { int fd; int *ptr; char *wlocks; int pgsize = getpagesize(); volatile int i; int m; int usec; struct timeval tv1; struct timeval tv2; fd = open("test.dat", O_RDWR|O_CREAT|O_TRUNC, 0666); ftruncate(fd, pgsize); ptr = mmap(NULL, pgsize, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); for (m = 0; m <= 8; ++m) { pid_t pid = -1; int nproc = 1; const char *lcks = "EMPTY"; gettimeofday(&tv1, NULL); switch(m) { case 8: pid = fork(); nproc = 2; /* fall through */ case 7: for (i = 0; i < LOOPS; ++i) { atomic_add_int(ptr, 1); GX[0] = 1; GX[1] = 1; GX[2] = 1; GX[3] = 1; GX[4] = 1; GX[5] = 1; GX[6] = 1; GX[7] = 1; } lcks = "yes"; break; case 6: pid = fork(); nproc = 2; /* fall through */ case 5: for (i = 0; i < LOOPS; ++i) { atomic_add_int_nolock(ptr, 1); GX[0] = 1; GX[1] = 1; GX[2] = 1; GX[3] = 1; GX[4] = 1; GX[5] = 1; GX[6] = 1; GX[7] = 1; } lcks = "no"; break; case 4: pid = fork(); nproc = 2; /* fall through */ case 3: for (i = 0; i < LOOPS; ++i) { atomic_add_int(ptr, 1); } lcks = "yes"; break; case 2: pid = fork(); nproc = 2; /* fall through */ case 1: for (i = 0; i < LOOPS; ++i) { atomic_add_int_nolock(ptr, 1); } lcks = "no"; break; case 0: for (i = 0; i < LOOPS; ++i) { ; } break; default: printf("huh?\n"); exit(1); } if (pid == 0) _exit(0); while (wait(NULL) > 0) ; gettimeofday(&tv2, NULL); usec = tv2.tv_usec + 1000000 - tv1.tv_usec + (tv2.tv_sec - tv1.tv_sec - 1) * 1000000; printf("mode %d\t%6.2f ns/loop nproc=%d lcks=%s\n", m, (double)usec * 1000.0 / (double)LOOPS / (double)nproc, nproc, lcks); } return(0); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 11:12:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 662B21522A for ; Mon, 12 Jul 1999 11:12:24 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA70732; Mon, 12 Jul 1999 11:12:08 -0700 (PDT) (envelope-from dillon) Date: Mon, 12 Jul 1999 11:12:08 -0700 (PDT) From: Matthew Dillon Message-Id: <199907121812.LAA70732@apollo.backplane.com> To: Poul-Henning Kamp , Luoqi Chen , dfr@nlsystems.com, jeremyp@gsmx07.alcatel.com.au, freebsd-current@FreeBSD.ORG, mike@ducky.net Subject: Ack! Wrong results. Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG How did that happen?!!! Argg.. I didn't save the email. Here are better results: Empty loop: mode 0 9.21 ns/loop nproc=1 lcks=EMPTY With and without lock prefix, one and two processes mode 1 16.48 ns/loop nproc=1 lcks=no mode 2 23.65 ns/loop nproc=2 lcks=no mode 3 93.02 ns/loop nproc=1 lcks=yes mode 4 160.82 ns/loop nproc=2 lcks=yes With and without lock prefix, one and two processes, with other global memory operations (note that the lock prefix instructions have absorbed the other memory ops) mode 5 37.64 ns/loop nproc=1 lcks=no mode 6 89.28 ns/loop nproc=2 lcks=no mode 7 88.32 ns/loop nproc=1 lcks=yes mode 8 161.08 ns/loop nproc=2 lcks=yes My conclusion from this is that the lock protocols have a general case overhead of 50 to 80 nS on a duel P-III/450 system. I don't think it would be noticeable. -Matt /* * Compile -O2 */ #include #include #include #include #include #include #include #include #define LOOPS 10000000 #define ATOMIC_ASM(type,op) \ __asm __volatile ("lock; " op : "=m" (*(type *)p) : "ir" (v), "0" (*(type *)p)) #define ATOMIC_ASM_NOLOCK(type,op) \ __asm __volatile (op : "=m" (*(type *)p) : "ir" (v), "0" (*(type *)p)) static __inline void atomic_add_int(void *p, u_int v) { ATOMIC_ASM(int, "addl %1,%0"); } static __inline void atomic_add_int_nolock(void *p, u_int v) { ATOMIC_ASM_NOLOCK(int, "addl %1,%0"); } volatile int GX[8]; /* note: not shared between processes */ int main(int ac, char **av) { int fd; int *ptr; char *wlocks; int pgsize = getpagesize(); volatile int i; int m; int usec; struct timeval tv1; struct timeval tv2; fd = open("test.dat", O_RDWR|O_CREAT|O_TRUNC, 0666); ftruncate(fd, pgsize); ptr = mmap(NULL, pgsize, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); for (m = 0; m <= 8; ++m) { pid_t pid = -1; int nproc = 1; const char *lcks = "EMPTY"; gettimeofday(&tv1, NULL); switch(m) { case 8: pid = fork(); nproc = 2; /* fall through */ case 7: for (i = 0; i < LOOPS; ++i) { atomic_add_int(ptr, 1); GX[0] = 1; GX[1] = 1; GX[2] = 1; GX[3] = 1; GX[4] = 1; GX[5] = 1; GX[6] = 1; GX[7] = 1; } lcks = "yes"; break; case 6: pid = fork(); nproc = 2; /* fall through */ case 5: for (i = 0; i < LOOPS; ++i) { atomic_add_int_nolock(ptr, 1); GX[0] = 1; GX[1] = 1; GX[2] = 1; GX[3] = 1; GX[4] = 1; GX[5] = 1; GX[6] = 1; GX[7] = 1; } lcks = "no"; break; case 4: pid = fork(); nproc = 2; /* fall through */ case 3: for (i = 0; i < LOOPS; ++i) { atomic_add_int(ptr, 1); } lcks = "yes"; break; case 2: pid = fork(); nproc = 2; /* fall through */ case 1: for (i = 0; i < LOOPS; ++i) { atomic_add_int_nolock(ptr, 1); } lcks = "no"; break; case 0: for (i = 0; i < LOOPS; ++i) { ; } break; default: printf("huh?\n"); exit(1); } if (pid == 0) _exit(0); while (wait(NULL) > 0) ; gettimeofday(&tv2, NULL); usec = tv2.tv_usec + 1000000 - tv1.tv_usec + (tv2.tv_sec - tv1.tv_sec - 1) * 1000000; printf("mode %d\t%6.2f ns/loop nproc=%d lcks=%s\n", m, (double)usec * 1000.0 / (double)LOOPS / (double)nproc, nproc, lcks); } return(0); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 11:12:56 1999 Delivered-To: freebsd-current@freebsd.org Received: from misha.cisco.com (misha.cisco.com [171.69.206.50]) by hub.freebsd.org (Postfix) with ESMTP id 524B7151A6 for ; Mon, 12 Jul 1999 11:12:40 -0700 (PDT) (envelope-from mi@misha.cisco.com) Received: (from mi@localhost) by misha.cisco.com (8.9.3/8.9.1) id OAA79735 for current@freebsd.org; Mon, 12 Jul 1999 14:12:34 -0400 (EDT) (envelope-from mi) Message-Id: <199907121812.OAA79735@misha.cisco.com> Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") In-Reply-To: <199907121741.KAA17837@ducky.net> from Mike Haertel at "Jul 12, 1999 10:41:26 am" To: current@freebsd.org Date: Mon, 12 Jul 1999 14:12:34 -0400 (EDT) Reply-To: mi@aldan.algebra.com From: Mikhail Teterin X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Haertel once wrote: > Anyway, taking all that into account, I still agree with Dillon that > it is a better software solution to allow the same loadable drivers to > work for both UP and MP systems whenever possible. What's wrong, again with /modules and /modules.smp? If some third party only wants to provide ONE module, they can provide the smp one, right? The open-source ones, should be compileable one way or the other. The new hardware is so much faster for the benefit of applications, not the kernel :) -mi (without plans to retire his 486 and P90 anytime soon) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 11:14:15 1999 Delivered-To: freebsd-current@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id CE1251536C for ; Mon, 12 Jul 1999 11:14:04 -0700 (PDT) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id OAA19519; Mon, 12 Jul 1999 14:13:17 -0400 (EDT) (envelope-from luoqi) Date: Mon, 12 Jul 1999 14:13:17 -0400 (EDT) From: Luoqi Chen Message-Id: <199907121813.OAA19519@lor.watermarkgroup.com> To: dillon@apollo.backplane.com Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") Cc: freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > do away with the lock prefix on non-SMP machines. I don't know if the > SMP variable is accessible from within the i386/include/atomic.h header > file, though. > SMP is globally defined (in opt_global.h). -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 11:14:35 1999 Delivered-To: freebsd-current@freebsd.org Received: from btw.plaintalk.bellevue.wa.us (btw.aa.net [206.125.75.16]) by hub.freebsd.org (Postfix) with ESMTP id 6800E15281 for ; Mon, 12 Jul 1999 11:14:20 -0700 (PDT) (envelope-from dennis.glatting@software-munitions.com) Received: from localhost (dennisg@localhost) by btw.plaintalk.bellevue.wa.us (8.9.3/8.9.3) with ESMTP id LAA60198 for ; Mon, 12 Jul 1999 11:14:16 -0700 (PDT) Date: Mon, 12 Jul 1999 11:14:15 -0700 (PDT) From: Dennis Glatting To: freebsd-current@freebsd.org Subject: Re: Just the kind of news we needed... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I don't understand. If you have to be root to load a kernel module then don't you have complete control over the box anyway? If so, you can replace the kernel and all the MD5 checksums and check code isn't going to do you a bit of good. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 11:25:42 1999 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id A457A15147 for ; Mon, 12 Jul 1999 11:25:20 -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 UAA20503; Mon, 12 Jul 1999 20:23:26 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: John-Mark Gurney Cc: Matthew Dillon , Luoqi Chen , dfr@nlsystems.com, jeremyp@gsmx07.alcatel.com.au, freebsd-current@FreeBSD.ORG, mike@ducky.net Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") In-reply-to: Your message of "Mon, 12 Jul 1999 10:38:45 PDT." <19990712103845.39296@hydrogen.fircrest.net> Date: Mon, 12 Jul 1999 20:23:26 +0200 Message-ID: <20501.931803806@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19990712103845.39296@hydrogen.fircrest.net>, John-Mark Gurney writes: >Matthew Dillon scribbled this message on Jul 12: >> p.s. I'm pretty sure that the lock prefix costs nothing on a UP system, >> and probably wouldn't be noticed on an SMP system either because the >> write-allocation overhead is already pretty bad. But I haven't tested >> it. > >actually, I'm not so sure, it guarantees that NO other bus operation >will succeed while this is happening... what happens if a pci bus >mastering card makes a modification to this value? sure, it normally >won't happen, but it can... and w/o the lock prefix, this CAN happen >from what I understand of the architecture... it locks EVERYTHING. -- 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-current" in the body of the message From owner-freebsd-current Mon Jul 12 11:31:39 1999 Delivered-To: freebsd-current@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id 13812151A2 for ; Mon, 12 Jul 1999 11:31:28 -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 OAA86475; Mon, 12 Jul 1999 14:29:55 -0400 (EDT) Message-Id: <199907121829.OAA86475@cs.rpi.edu> To: Scott Michel Cc: freebsd-current@FreeBSD.ORG, crossd@cs.rpi.edu Subject: Re: Just the kind of news we needed... In-Reply-To: Message from Scott Michel of "Mon, 12 Jul 1999 10:47:33 PDT." <199907121747.KAA02111@mordred.cs.ucla.edu> Date: Mon, 12 Jul 1999 14:29:51 -0400 From: "David E. Cross" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > If you haven't /.'d today, there's a news article purporting that > FreeBSD can be exploited via kernel modules: > > > http://thc.pimmel.com/ I did a quick read of that, I don't see how the system is being exploited at all. All of their tricks need to be able to load a kernel module in order for them to work. And you need to be root to load a kernel module (unless I missed something). That's sort of like saying it is an exploit for root to be able to edit the password file or 'su - userj'. -- 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-current" in the body of the message From owner-freebsd-current Mon Jul 12 11:37:45 1999 Delivered-To: freebsd-current@freebsd.org Received: from mail-out.visi.com (tele.visi.com [209.98.98.17]) by hub.freebsd.org (Postfix) with ESMTP id D012515025 for ; Mon, 12 Jul 1999 11:37:40 -0700 (PDT) (envelope-from mestery@visi.com) Received: from isis.visi.com (isis.visi.com [209.98.98.8]) by mail-out.visi.com (Postfix) with ESMTP id 190AB1F821; Mon, 12 Jul 1999 13:37:32 -0500 (CDT) Received: from localhost (mestery@localhost) by isis.visi.com (8.8.8/8.8.8) with ESMTP id NAA16368; Mon, 12 Jul 1999 13:37:31 -0500 (CDT) X-Authentication-Warning: isis.visi.com: mestery owned process doing -bs Date: Mon, 12 Jul 1999 13:37:31 -0500 (CDT) From: To: Scott Michel Cc: freebsd-current@FreeBSD.ORG Subject: Re: Just the kind of news we needed... In-Reply-To: <199907121747.KAA02111@mordred.cs.ucla.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, On Mon, 12 Jul 1999, Scott Michel wrote: > If you haven't /.'d today, there's a news article purporting that > FreeBSD can be exploited via kernel modules: > > > http://thc.pimmel.com/ > I actually found the article a very good source of documentation on programming loadable modules for FreeBSD. Granted, I'm not sure of it's accuracy, but it was a worthwhile read for someone like myself who has only coded LKMs for Linux. Very interesting. -- Kyle Mestery | StorageTek's Storage Networking Group mestery@visi.com | http://www.freebsd.org/ mestery@netwinder.org | http://www.netwinder.org/ Protect your right to privacy: www.freecrypto.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 11:42:50 1999 Delivered-To: freebsd-current@freebsd.org Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (Postfix) with ESMTP id D086815025 for ; Mon, 12 Jul 1999 11:42:46 -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 OAA86709; Mon, 12 Jul 1999 14:41:36 -0400 (EDT) Message-Id: <199907121841.OAA86709@cs.rpi.edu> To: mestery@visi.com Cc: Scott Michel , freebsd-current@FreeBSD.ORG, crossd@cs.rpi.edu Subject: Re: Just the kind of news we needed... In-Reply-To: Message from of "Mon, 12 Jul 1999 13:37:31 CDT." Date: Mon, 12 Jul 1999 14:41:32 -0400 From: "David E. Cross" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > http://thc.pimmel.com/ > > > I actually found the article a very good source of documentation on > programming loadable modules for FreeBSD. Granted, I'm not sure of it's > accuracy, but it was a worthwhile read for someone like myself who has > only coded LKMs for Linux. Very interesting. Agreed. Perhaps we could (with the author's permission) import this a bit into the documentation project? -- 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-current" in the body of the message From owner-freebsd-current Mon Jul 12 11:54:56 1999 Delivered-To: freebsd-current@freebsd.org Received: from arc.hq.cti.ru (arc.hq.cti.ru [195.34.40.3]) by hub.freebsd.org (Postfix) with ESMTP id 2BDB014DCC; Mon, 12 Jul 1999 11:54:51 -0700 (PDT) (envelope-from tejblum@arc.hq.cti.ru) Received: from arc.hq.cti.ru (localhost [127.0.0.1]) by arc.hq.cti.ru (8.9.3/8.9.3) with ESMTP id WAA27876; Mon, 12 Jul 1999 22:53:49 +0400 (MSD) (envelope-from tejblum@arc.hq.cti.ru) Message-Id: <199907121853.WAA27876@arc.hq.cti.ru> X-Mailer: exmh version 2.0zeta 7/24/97 To: Jason Evans Cc: current@FreeBSD.org, alc@FreeBSD.org Subject: Re: Thread stack allocation (was Re: cvs commit: src/lib/libc_r Makefile src/lib/libc_r/uthread pthread_private.h uthread_create.c uthread_gc.c uthread_init.c) In-reply-to: Your message of "Mon, 12 Jul 1999 11:28:58 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jul 1999 22:53:49 +0400 From: Dmitrij Tejblum Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, 12 Jul 1999, Dmitrij Tejblum wrote: > > Alan Cox wrote: > > > When you create a stack or grow an existing stack, the minimum chunk size > > > is 128K. > > > > This make use of "growable" stacks in libc_r particulary useful, given that > > libc_r make "growable" only 64K stacks. > > That is a problem, to be sure. In order to make effective use of growable > stacks, each stack really needs to be at least 256KB. However, Alan also > pointed out that growable stacks are a bit of a non-feature, since the VM > is lazy about backing mapped regions. In light of this, I'm leaning > toward using MAP_ANON instead of MAP_STACK. I don't see how MAP_ANON is better than MAP_STACK. > > These changes create other troubles. For example, they limit the size of the > > initial thread to 1M, and this is too little and not tunable. > > Making the initial stack size tunable at runtime would require a > non-standard interface. How big is big enough? I picked 1MB rather > randomly; increasing the value is quite easy. One possible solution would > be to pay at least some heed to the value of getrlimit(RLIMIT_STACK, ..). Well, why you map stacks on fixed address, and in the process stack? I think, you could map it at random address. (And mprotect the red zone). > Another problem with the changes I made was also pointed out by Alan. > Each stack is a separate region, and with the red zones, there end up > being two regions for every stack. This apparently has a direct impact on > page table lookups. Somehow, the stack allocation code needs to be more > economical in this regard, but I haven't thought of a slick method yet. Anyway, what are the advantages of mmap over malloc? Especially if you change MAP_STACK to MAP_ANON? Dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 12:18:18 1999 Delivered-To: freebsd-current@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 9D99314F5A for ; Mon, 12 Jul 1999 12:18:05 -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 UAA01510; Mon, 12 Jul 1999 20:17:33 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Mon, 12 Jul 1999 20:17:33 +0100 (BST) From: Doug Rabson To: Martin Cracauer Cc: freebsd-current@freebsd.org Subject: Re: Using float emulator on a system with FPU? In-Reply-To: <19990712112802.A4800@cons.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 12 Jul 1999, Martin Cracauer wrote: > Moin, > > I'm going to work on FreeBSD's floating point support, but I need to > test my changes on systems using the FPU emulators (non-GPL and GPL). > > Is there any way to use these emulators on a system that has a > hardware FPU? > > Guessing from LINT's comments, you had to leave out npx and include > one of the emulators, but -current's config refuses to config a kernel > file without npx support. > > I also tried to add "disable" to npx's config line, which compiles and > runs ok, but still uses the hardware FPU (timing and exception test). You might consider looking at the fp emulator which I wrote for the alpha. It should be accurate (I tested against the fpu on an x86) and contains test harness code which can be used to play with it on both x86 and alpha. -- 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-current" in the body of the message From owner-freebsd-current Mon Jul 12 12:27: 6 1999 Delivered-To: freebsd-current@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 2476B1514D for ; Mon, 12 Jul 1999 12:27:01 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.1/8.9.1) id PAA02307; Mon, 12 Jul 1999 15:26:41 -0400 (EDT) (envelope-from wollman) Date: Mon, 12 Jul 1999 15:26:41 -0400 (EDT) From: Garrett Wollman Message-Id: <199907121926.PAA02307@khavrinen.lcs.mit.edu> To: Martin Cracauer Cc: freebsd-current@FreeBSD.ORG Subject: Using float emulator on a system with FPU? In-Reply-To: <19990712112802.A4800@cons.org> References: <19990712112802.A4800@cons.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > I'm going to work on FreeBSD's floating point support, but I need to > test my changes on systems using the FPU emulators (non-GPL and GPL). I suggested about half a year ago that we should officially desupport non-FPU configurations in 4.0. Unfortunately, my resolution was soundly defeated. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 12:27:22 1999 Delivered-To: freebsd-current@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id E62A01523C for ; Mon, 12 Jul 1999 12:27:18 -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 UAA01563; Mon, 12 Jul 1999 20:27:35 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Mon, 12 Jul 1999 20:27:35 +0100 (BST) From: Doug Rabson To: mestery@visi.com Cc: Scott Michel , freebsd-current@freebsd.org Subject: Re: Just the kind of news we needed... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 12 Jul 1999 mestery@visi.com wrote: > Hi, > > On Mon, 12 Jul 1999, Scott Michel wrote: > > > If you haven't /.'d today, there's a news article purporting that > > FreeBSD can be exploited via kernel modules: > > > > > > http://thc.pimmel.com/ > > > I actually found the article a very good source of documentation on > programming loadable modules for FreeBSD. Granted, I'm not sure of it's > accuracy, but it was a worthwhile read for someone like myself who has > only coded LKMs for Linux. Very interesting. I just read through it and it is a nice tutorial on how the module system works. I can't see it as an exploit though - you have to be root first to load any code. -- 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-current" in the body of the message From owner-freebsd-current Mon Jul 12 13:26:57 1999 Delivered-To: freebsd-current@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id DD45814F79 for ; Mon, 12 Jul 1999 13:26: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 QAA52065; Mon, 12 Jul 1999 16:26:06 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Mon, 12 Jul 1999 16:26:06 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Garrett Wollman Cc: Martin Cracauer , freebsd-current@FreeBSD.org Subject: Re: Using float emulator on a system with FPU? In-Reply-To: <199907121926.PAA02307@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 12 Jul 1999, Garrett Wollman wrote: > < said: > > > I'm going to work on FreeBSD's floating point support, but I need to > > test my changes on systems using the FPU emulators (non-GPL and GPL). > > I suggested about half a year ago that we should officially desupport > non-FPU configurations in 4.0. Unfortunately, my resolution was > soundly defeated. Why shouldn't we? Noone uses machines without FPUs anymore. What non-ancient CPU doesn't have an FPU? And we're talking about the i386 family here... > > -GAWollman > > -- > Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same > wollman@lcs.mit.edu | O Siem / The fires of freedom > Opinions not those of| Dance in the burning flame > MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" 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-current" in the body of the message From owner-freebsd-current Mon Jul 12 13:35: 5 1999 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 116F614BED; Mon, 12 Jul 1999 13:35:01 -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 WAA21272; Mon, 12 Jul 1999 22:33:01 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: "Brian F. Feldman" Cc: Garrett Wollman , Martin Cracauer , freebsd-current@FreeBSD.ORG Subject: Re: Using float emulator on a system with FPU? In-reply-to: Your message of "Mon, 12 Jul 1999 16:26:06 EDT." Date: Mon, 12 Jul 1999 22:33:01 +0200 Message-ID: <21270.931811581@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , "Bria >> I suggested about half a year ago that we should officially desupport >> non-FPU configurations in 4.0. Unfortunately, my resolution was >> soundly defeated. > >Why shouldn't we? Noone uses machines without FPUs anymore. What non-ancient >CPU doesn't have an FPU? And we're talking about the i386 family here... A lot of 386 machines are being built into places where people will never know they are. We should not kill that market. -- 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-current" in the body of the message From owner-freebsd-current Mon Jul 12 13:36:48 1999 Delivered-To: freebsd-current@freebsd.org Received: from pawn.primelocation.net (pawn.primelocation.net [205.161.238.235]) by hub.freebsd.org (Postfix) with ESMTP id CF25714BED; Mon, 12 Jul 1999 13:36:40 -0700 (PDT) (envelope-from jedgar@fxp.org) Received: by pawn.primelocation.net (Postfix, from userid 1003) id 879D1F818; Mon, 12 Jul 1999 16:35:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by pawn.primelocation.net (Postfix) with ESMTP id 7A17F9B15; Mon, 12 Jul 1999 16:35:38 -0400 (EDT) Date: Mon, 12 Jul 1999 16:35:38 -0400 (EDT) From: "Chris D. Faulhaber" X-Sender: jedgar@pawn.primelocation.net To: "Brian F. Feldman" Cc: freebsd-current@FreeBSD.org Subject: Re: Using float emulator on a system with FPU? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 12 Jul 1999, Brian F. Feldman wrote: > On Mon, 12 Jul 1999, Garrett Wollman wrote: > > > < said: > > > > > I'm going to work on FreeBSD's floating point support, but I need to > > > test my changes on systems using the FPU emulators (non-GPL and GPL). > > > > I suggested about half a year ago that we should officially desupport > > non-FPU configurations in 4.0. Unfortunately, my resolution was > > soundly defeated. > > Why shouldn't we? Noone uses machines without FPUs anymore. What non-ancient > CPU doesn't have an FPU? And we're talking about the i386 family here... > Embedded systems, anyone? ----- 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-current" in the body of the message From owner-freebsd-current Mon Jul 12 13:37:25 1999 Delivered-To: freebsd-current@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 0953A14C57 for ; Mon, 12 Jul 1999 13:37:23 -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 NAA33358; Mon, 12 Jul 1999 13:36:55 -0700 (PDT) Date: Mon, 12 Jul 1999 13:36:54 -0700 (PDT) From: Julian Elischer To: Garrett Wollman Cc: Martin Cracauer , freebsd-current@FreeBSD.ORG Subject: Re: Using float emulator on a system with FPU? In-Reply-To: <199907121926.PAA02307@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 12 Jul 1999, Garrett Wollman wrote: > < said: > > > I'm going to work on FreeBSD's floating point support, but I need to > > test my changes on systems using the FPU emulators (non-GPL and GPL). > > I suggested about half a year ago that we should officially desupport > non-FPU configurations in 4.0. Unfortunately, my resolution was > soundly defeated. there are a lot of 486sx and 386 machines out there doing real work. > > -GAWollman > > -- > Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same > wollman@lcs.mit.edu | O Siem / The fires of freedom > Opinions not those of| Dance in the burning flame > MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 13:39:30 1999 Delivered-To: freebsd-current@freebsd.org Received: from shell.webmaster.com (mail.webmaster.com [209.133.28.73]) by hub.freebsd.org (Postfix) with ESMTP id 00C6414C57; Mon, 12 Jul 1999 13:39:27 -0700 (PDT) (envelope-from davids@webmaster.com) Received: from whenever ([209.133.29.2]) by shell.webmaster.com (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S10000V35) with SMTP id com; Mon, 12 Jul 1999 13:38:58 -0700 From: "David Schwartz" To: "Chris D. Faulhaber" , "Brian F. Feldman" Cc: Subject: RE: Using float emulator on a system with FPU? Date: Mon, 12 Jul 1999 13:38:57 -0700 Message-ID: <000001becca6$90be9880$021d85d1@youwant.to> 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.2377.0 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Why shouldn't we? Noone uses machines without FPUs anymore. > What non-ancient > > CPU doesn't have an FPU? And we're talking about the i386 family here... > > > > Embedded systems, anyone? True, but how late a version do you really want to run on them? I've left even my P60's at FreeBSD-2.x and have no intention of ever upgrading them. DS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 13:41:11 1999 Delivered-To: freebsd-current@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 0EC8B1521E; Mon, 12 Jul 1999 13:41:09 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id QAA12633; Mon, 12 Jul 1999 16:38:55 -0400 (EDT) Date: Mon, 12 Jul 1999 16:38:55 -0400 (EDT) From: Daniel Eischen Message-Id: <199907122038.QAA12633@pcnet1.pcnet.com> To: green@FreeBSD.ORG, wollman@khavrinen.lcs.mit.edu Subject: Re: Using float emulator on a system with FPU? Cc: cracauer@cons.org, freebsd-current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Why shouldn't we? Noone uses machines without FPUs anymore. What non-ancient > CPU doesn't have an FPU? And we're talking about the i386 family here... IIRC, there were a few folks running FreeBSD in an embedded environment. Perhaps with 80386 FPU coprocessor-less systems? Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 13:52:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from freesbee.t.dk (freesbee.t.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with SMTP id 933AA1511B for ; Mon, 12 Jul 1999 13:52:29 -0700 (PDT) (envelope-from jesper@freesbee.t.dk) Received: (qmail 18376 invoked by uid 1001); 12 Jul 1999 20:51:32 -0000 Date: Mon, 12 Jul 1999 22:51:32 +0200 From: Jesper Skriver To: David Schwartz Cc: "Chris D. Faulhaber" , "Brian F. Feldman" , freebsd-current@FreeBSD.org Subject: Re: Using float emulator on a system with FPU? Message-ID: <19990712225132.A18351@skriver.dk> References: <000001becca6$90be9880$021d85d1@youwant.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.2i In-Reply-To: <000001becca6$90be9880$021d85d1@youwant.to>; from David Schwartz on Mon, Jul 12, 1999 at 01:38:57PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 12, 1999 at 01:38:57PM -0700, David Schwartz wrote: > > > > Why shouldn't we? Noone uses machines without FPUs anymore. > > What non-ancient > > > CPU doesn't have an FPU? And we're talking about the i386 family here... > > > > > > > Embedded systems, anyone? > > True, but how late a version do you really want to run on them? I've left > even my P60's at FreeBSD-2.x and have no intention of ever upgrading them. Lots of new embedded systems are slow pentiums, and quite a few are 486, probably sx some of them ... /Jesper -- Jesper Skriver (JS4261-RIPE), Network manager Tele Danmark DataNet, IP section (AS3292) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 13:55:31 1999 Delivered-To: freebsd-current@freebsd.org Received: from misha.cisco.com (misha.cisco.com [171.69.206.50]) by hub.freebsd.org (Postfix) with ESMTP id E220C1511B; Mon, 12 Jul 1999 13:55:27 -0700 (PDT) (envelope-from mi@misha.cisco.com) Received: (from mi@localhost) by misha.cisco.com (8.9.3/8.9.1) id QAA80307; Mon, 12 Jul 1999 16:55:22 -0400 (EDT) (envelope-from mi) Message-Id: <199907122055.QAA80307@misha.cisco.com> Subject: Re: Using float emulator on a system with FPU? In-Reply-To: from "Brian F. Feldman" at "Jul 12, 1999 04:26:06 pm" To: "Brian F. Feldman" Date: Mon, 12 Jul 1999 16:55:22 -0400 (EDT) Cc: current@FreeBSD.ORG Reply-To: mi@aldan.algebra.com From: Mikhail Teterin X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian F. Feldman once wrote: > > I suggested about half a year ago that we should officially > > desupport non-FPU configurations in 4.0. Unfortunately, my > > resolution was soundly defeated. > > Why shouldn't we? Noone uses machines without FPUs anymore. What > non-ancient CPU doesn't have an FPU? And we're talking about the i386 > family here... "One should NEVER, EVER generalize". My laptop, for example, is a 386SX25 with 8Mb of RAM. Minicom, fetchmail, sendmail, and elm work just peachy on it. To answer someone else's question about the OS version on it -- it is 3.2-BETA as of beginning of May, pretty recent... Made by Digital (may they RIP) it is quite reliable, although the on-board battery is no more, and I have to re-set the time on it after the external battery runs out. I'd rather see the FPU emulation remains available, although, by the time 4.0 becomes -stable (when?), I _may_ retire the poor thing. -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 14: 6:37 1999 Delivered-To: freebsd-current@freebsd.org Received: from hooked.net (pm3-12.ppp.wenet.net [206.15.85.12]) by hub.freebsd.org (Postfix) with ESMTP id 499B21511A; Mon, 12 Jul 1999 14:06:29 -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 NAA41664; Mon, 12 Jul 1999 13:44:18 -0700 (PDT) (envelope-from garbanzo@hooked.net) X-Authentication-Warning: zippy.dyn.ml.org: garbanzo owned process doing -bs Date: Mon, 12 Jul 1999 13:44:18 -0700 (PDT) From: Alex Zepeda To: "Brian F. Feldman" Cc: Garrett Wollman , Martin Cracauer , freebsd-current@FreeBSD.ORG Subject: Re: Using float emulator on a system with FPU? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 12 Jul 1999, Brian F. Feldman wrote: > Why shouldn't we? Noone uses machines without FPUs anymore. What > non-ancient CPU doesn't have an FPU? And we're talking about the i386 > family here... I've noticed recently, more and more, Linux is moving into the embedded market quite nicely, and being used on smaller and smaller systems. FreeBSD OTOH has been focusing (albeit not too successfully) on the higher end market. With my recent addition of an 040 powered Mac that I plan to put NetBSD on, this really irks me. I'd love to put some (read: a significant) amount of time getting FreeBSD up and running on this, but there seems to be a lot of resistance to using FreeBSD on smaller/older machines. It almost seems like the requirement is Pentium III, Alpha or bust. And yes, this machine does have an FPU, but there are plenty of *newer* systems without FPUs For instance, doesn't the StrongArm lack an FPU? What about embedded systems? A 486SX would draw a whole lot less power than a Pentium. And it's certainly not like emulating an FPU is an impossible task like say on some LC040s... - alex To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 14:56: 2 1999 Delivered-To: freebsd-current@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id CD29B14E48 for ; Mon, 12 Jul 1999 14:56:00 -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 RAA53791; Mon, 12 Jul 1999 17:55:37 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Mon, 12 Jul 1999 17:55:37 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Alex Zepeda Cc: Garrett Wollman , Martin Cracauer , freebsd-current@FreeBSD.org Subject: Re: Using float emulator on a system with FPU? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 12 Jul 1999, Alex Zepeda wrote: > On Mon, 12 Jul 1999, Brian F. Feldman wrote: > > > Why shouldn't we? Noone uses machines without FPUs anymore. What > > non-ancient CPU doesn't have an FPU? And we're talking about the i386 > > family here... > > I've noticed recently, more and more, Linux is moving into the embedded > market quite nicely, and being used on smaller and smaller systems. > FreeBSD OTOH has been focusing (albeit not too successfully) on the higher > end market. > > With my recent addition of an 040 powered Mac that I plan to put NetBSD > on, this really irks me. I'd love to put some (read: a significant) > amount of time getting FreeBSD up and running on this, but there seems to > be a lot of resistance to using FreeBSD on smaller/older machines. It > almost seems like the requirement is Pentium III, Alpha or bust. > > And yes, this machine does have an FPU, but there are plenty of *newer* > systems without FPUs For instance, doesn't the StrongArm lack an FPU? What > about embedded systems? A 486SX would draw a whole lot less power than a > Pentium. And it's certainly not like emulating an FPU is an impossible > task like say on some LC040s... Compare the 486SX to a 486DX, not a pentium. > > - alex > > 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-current" in the body of the message From owner-freebsd-current Mon Jul 12 14:59:55 1999 Delivered-To: freebsd-current@freebsd.org Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (Postfix) with ESMTP id 728BD1524C; Mon, 12 Jul 1999 14:59:44 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.9.3/8.9.1) id IAA70195; Tue, 13 Jul 1999 08:03:32 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199907122203.IAA70195@cimlogic.com.au> Subject: Re: Using float emulator on a system with FPU? In-Reply-To: from Alex Zepeda at "Jul 12, 1999 01:44:18 pm" To: garbanzo@hooked.net (Alex Zepeda) Date: Tue, 13 Jul 1999 08:03:32 +1000 (EST) Cc: green@FreeBSD.ORG (Brian F. Feldman), wollman@khavrinen.lcs.mit.edu (Garrett Wollman), cracauer@cons.org (Martin Cracauer), freebsd-current@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-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alex Zepeda wrote: > On Mon, 12 Jul 1999, Brian F. Feldman wrote: > > > Why shouldn't we? Noone uses machines without FPUs anymore. What > > non-ancient CPU doesn't have an FPU? And we're talking about the i386 > > family here... Nonsense. Read this: > I've noticed recently, more and more, Linux is moving into the embedded > market quite nicely, and being used on smaller and smaller systems. > FreeBSD OTOH has been focusing (albeit not too successfully) on the higher > end market. That's a matter of perspective. Remember that people can base a product on FreeBSD without being forced to give away their value-added sources. I have a solar powered i386 board here that consumes just 2W. It runs FreeBSD. There is a tiny bit of custom code to initialise the board and boot the kernel out of flash, but the kernel is standard FreeBSD. > With my recent addition of an 040 powered Mac that I plan to put NetBSD > on, this really irks me. I'd love to put some (read: a significant) > amount of time getting FreeBSD up and running on this, but there seems to > be a lot of resistance to using FreeBSD on smaller/older machines. It > almost seems like the requirement is Pentium III, Alpha or bust. I don't think that is true. You are commenting on what other people have chosen to put their time into. The only resistance I see is people actually doing the work. To get in-principle approval before doing a substantial amount of work, ask core@FreeBSD.org. My bet is they won't object. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 15: 1: 9 1999 Delivered-To: freebsd-current@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 1FE731527D for ; Mon, 12 Jul 1999 15:01:03 -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 XAA02529; Mon, 12 Jul 1999 23:01:38 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Mon, 12 Jul 1999 23:01:38 +0100 (BST) From: Doug Rabson To: Matthew Dillon Cc: Poul-Henning Kamp , Luoqi Chen , jeremyp@gsmx07.alcatel.com.au, freebsd-current@FreeBSD.ORG, mike@ducky.net Subject: Re: Ack! Wrong results. In-Reply-To: <199907121812.LAA70732@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 12 Jul 1999, Matthew Dillon wrote: > How did that happen?!!! Argg.. I didn't save the email. > > Here are better results: > > Empty loop: > > mode 0 9.21 ns/loop nproc=1 lcks=EMPTY > > With and without lock prefix, one and two processes > > mode 1 16.48 ns/loop nproc=1 lcks=no > mode 2 23.65 ns/loop nproc=2 lcks=no > mode 3 93.02 ns/loop nproc=1 lcks=yes > mode 4 160.82 ns/loop nproc=2 lcks=yes > > With and without lock prefix, one and two processes, with > other global memory operations (note that the lock prefix instructions > have absorbed the other memory ops) > > mode 5 37.64 ns/loop nproc=1 lcks=no > mode 6 89.28 ns/loop nproc=2 lcks=no > mode 7 88.32 ns/loop nproc=1 lcks=yes > mode 8 161.08 ns/loop nproc=2 lcks=yes > > My conclusion from this is that the lock protocols have a general case > overhead of 50 to 80 nS on a duel P-III/450 system. I don't think it > would be noticeable. Just as another data point, it would be interesting to see the overhead for non-inline versions (i.e. functions in the kernel which are using lock or not called by code in loaded modules). The alpha versions of these operations are already non-inline since it takes quite a few instructions to implement them. -- 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-current" in the body of the message From owner-freebsd-current Mon Jul 12 15: 6:19 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id C201015271 for ; Mon, 12 Jul 1999 15:06:17 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA72489; Mon, 12 Jul 1999 15:05:29 -0700 (PDT) (envelope-from dillon) Date: Mon, 12 Jul 1999 15:05:29 -0700 (PDT) From: Matthew Dillon Message-Id: <199907122205.PAA72489@apollo.backplane.com> To: Doug Rabson Cc: Poul-Henning Kamp , Luoqi Chen , jeremyp@gsmx07.alcatel.com.au, freebsd-current@FreeBSD.ORG, mike@ducky.net Subject: Re: Ack! Wrong results. References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Just as another data point, it would be interesting to see the overhead :for non-inline versions (i.e. functions in the kernel which are using lock :or not called by code in loaded modules). : :The alpha versions of these operations are already non-inline since it :takes quite a few instructions to implement them. : :-- :Doug Rabson Mail: dfr@nlsystems.com :Nonlinear Systems Ltd. Phone: +44 181 442 9037 Well, you can change those inline's to real functions and run the program. But I'll tell you what you will see... procedure calls are very cheap on intel cpu's, so it will probably have an effect similar to the global assignments I added in the second half of the test. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 15:29:40 1999 Delivered-To: freebsd-current@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 7FA6614CE1 for ; Mon, 12 Jul 1999 15:29:36 -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 XAA20247; Mon, 12 Jul 1999 23:23:43 +0100 (BST) (envelope-from nik) Date: Mon, 12 Jul 1999 23:23:42 +0100 From: Nik Clayton To: "David E. Cross" Cc: mestery@visi.com, Scott Michel , freebsd-current@FreeBSD.ORG Subject: Re: Just the kind of news we needed... Message-ID: <19990712232342.B19068@catkin.nothing-going-on.org> References: <199907121841.OAA86709@cs.rpi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199907121841.OAA86709@cs.rpi.edu>; from David E. Cross on Mon, Jul 12, 1999 at 02:41:32PM -0400 Organization: Nik at home, where there's nothing going on Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 12, 1999 at 02:41:32PM -0400, David E. Cross wrote: > > > http://thc.pimmel.com/ > > > > > I actually found the article a very good source of documentation on > > programming loadable modules for FreeBSD. Granted, I'm not sure of it's > > accuracy, but it was a worthwhile read for someone like myself who has > > only coded LKMs for Linux. Very interesting. > > Agreed. Perhaps we could (with the author's permission) import this a bit > into the documentation project? He he. I'll contact them tomorrow, and see what I can work out. 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-current" in the body of the message From owner-freebsd-current Mon Jul 12 15:29:59 1999 Delivered-To: freebsd-current@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 3997D152B1; Mon, 12 Jul 1999 15:29:36 -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 XAA19741; Mon, 12 Jul 1999 23:19:43 +0100 (BST) (envelope-from nik) Date: Mon, 12 Jul 1999 23:19:41 +0100 From: Nik Clayton To: Satoshi - Ports Wraith - Asami Cc: nik@nothing-going-on.demon.co.uk, cpiazza@home.net, dcs@newsguy.com, nicblais@videotron.ca, freebsd-current@FreeBSD.ORG Subject: Re: HELP!!! -CURRENT libtool problem. Message-ID: <19990712231941.A19068@catkin.nothing-going-on.org> References: <37810FDD.C1321FE7@videotron.ca> <37887C61.2F462FD@newsguy.com> <19990711220050.A31542@catkin.nothing-going-on.org> <19990712155440.B494@norn.ca.eu.org> <19990712004612.A51439@catkin.nothing-going-on.org> <199907120731.AAA67992@silvia.hip.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199907120731.AAA67992@silvia.hip.berkeley.edu>; from Satoshi - Ports Wraith - Asami on Mon, Jul 12, 1999 at 12:31:52AM -0700 Organization: Nik at home, where there's nothing going on Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Satoshi. On Mon, Jul 12, 1999 at 12:31:52AM -0700, Satoshi - Ports Wraith - Asami wrote: > * From: Nik Clayton > > I really wish you would stop spreading FUD. Don't open your mouth if > you don't know what you are talking about. I do know what I'm talking about -- specifically; > * I was under the impression that if you were CVSup'ing the ports tree then > * any changes to the ports subsystem (for example, new command line > * parameters to fetch(1)) would be utilised by the ports system *before* > * they had been merged in to -stable. The rationale being that if you > * were tracking the ports tree in that way then you should be tracking > * -current instead. I'm careful to state that it's my impression. Not that it's the gospel truth, but that's the 'vibe' I've picked up from the times when the ports and src trees have been out of sync, and I've gone scouring for answers as to what's happened. You're correct in that better awareness is almost definitely the key. Would you consider posting the -stable and -current port build results to -announce (and comp.unix.bsd.freebsd.announce) fortnightly, in the same way that the "New ports committed in the past two weeks" message is sent out? 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-current" in the body of the message From owner-freebsd-current Mon Jul 12 15:40:23 1999 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 887EE15034 for ; Mon, 12 Jul 1999 15:40:18 -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 PAA15869; Mon, 12 Jul 1999 15:39:26 -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 PAA35065; Mon, 12 Jul 1999 15:39:25 -0700 (PDT) (envelope-from jdp@polstra.com) Date: Mon, 12 Jul 1999 15:39:25 -0700 (PDT) Message-Id: <199907122239.PAA35065@vashon.polstra.com> To: ayan@kiwi.datasys.net Subject: Re: utmp & last In-Reply-To: <199907100928.FAA79011@kiwi.datasys.net> Organization: Polstra & Co., Seattle, WA Cc: current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <199907100928.FAA79011@kiwi.datasys.net>, Ayan George wrote: > > What seems strange is that they use the different data types to > store the same information (the time): > > struct lastlog { > time_t ll_time; > char ll_line[UT_LINESIZE]; > char ll_host[UT_HOSTSIZE]; > }; > > struct utmp { > char ut_line[UT_LINESIZE]; > char ut_name[UT_NAMESIZE]; > char ut_host[UT_HOSTSIZE]; > long ut_time; > }; > > Not that there is any _real_ difference between long and time_t, On the Alpha, a long is 64 bits but a time_t is 32 bits. 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-current" in the body of the message From owner-freebsd-current Mon Jul 12 16: 7: 2 1999 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id E2E9F14E73 for ; Mon, 12 Jul 1999 16:06:29 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40574>; Tue, 13 Jul 1999 08:46:57 +1000 Date: Tue, 13 Jul 1999 09:04:57 +1000 From: Peter Jeremy Subject: Re: "objtrm" problem probably found To: dfr@nlsystems.com, dillon@apollo.backplane.com, freebsd-current@FreeBSD.ORG, luoqi@watermarkgroup.com, mike@ducky.net Message-Id: <99Jul13.084657est.40574@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug Rabson wrote: >We don't need the lock prefix for the current SMP implementation. A lock >prefix would be needed in a multithreaded implementation but should not be >added unless the kernel is an SMP kernel otherwise UP performance would >suffer. Modulo the issue of UP vs SMP modules, the code would seem to be simply: #ifdef SMP #define ATOMIC_ASM(type,op) \ __asm __volatile ("lock; " op : "=m" (*(type *)p) : "ir" (v), "0" (*(type *)p)) #else #define ATOMIC_ASM(type,op) \ __asm __volatile (op : "=m" (*(type *)p) : "ir" (v), "0" (*(type *)p)) #endif Or (maybe more clearly): #ifdef SMP #define SMP_LOCK "lock; " #else #define SMP_LOCK #endif #define ATOMIC_ASM(type,op) \ __asm __volatile (SMP_LOCK op : "=m" (*(type *)p) : "ir" (v), "0" (*(type *)p)) John-Mark Gurney wrote: >actually, I'm not so sure, it guarantees that NO other bus operation >will succeed while this is happening... what happens if a pci bus >mastering card makes a modification to this value? This is a valid point, but I don't think it's directly related to this thread. I think it's up the the various PCI device driver writers to ensure that objects shared between a PCI device and driver are correctly locked. The mechanism to do this is likely to be device- specific: Lock prefixes only protect objects no larger than 32 or 64 bits (depending on the processor), cards may require locked accesses to much larger structures. I believe the API to the PCI-locking routines should be distinct from the API for SMP locks - even though the underlying implementation may be common. Oliver Fromme wrote: >In my list of i386 clock cycles, the lock prefix is listed with >0 (zero) cycles. My i486 book states 1 cycle, although that cycle can be overlapped with several other combinations that add a cycle to the basic instruction execution time. I don't know about the Pentium and beyond timings. In any case, we have real-world timings, which are more useful. Mike Haertel wrote: >Although function calls are more expensive than inline code, >they aren't necessarily a lot more so, and function calls to >non-locked RMW operations are certainly much cheaper than >inline locked RMW operations. Based on my timings below, this is correct, though counter-intuitive. Given the substantial cost of indirect function calls, I don't this this would be acceptable, though. I think compiling modules separately for UP/SMP is a better choice. In Message-id: <19990 121806.LAA70634@apollo.backplane.com>, Matthew Dillon provided some hard figures for a dual PIII-450. Expanding those figures for a range of machines (all are UP except the PIII-450, which are Matt's SMP figures), and adding the cost of using indirect function calls (patches to Matt's code at the end): i386SX-25 P-133 PII-266 PIII-450 nproc locks mode 0 1950.23 39.65 26.31 9.21 EMPTY mode 1 3340.59 71.74 24.45 16.48 1 no tight mode 2 3237.57 71.18 25.27 23.65 2 no tight mode 3 3367.65 282.31 153.29 93.02 1 yes tight mode 4 3263.64 285.58 152.94 160.82 2 yes tight mode 5 9439.15 446.16 60.40 37.64 1 no spread mode 6 10231.96 467.39 60.16 89.28 2 no spread mode 7 10660.05 725.80 153.18 88.32 1 yes spread mode 8 9990.18 755.87 155.18 161.08 2 yes spread mode 9 5544.82 131.31 49.96 ? EMPTY mode 10 7234.97 174.20 64.81 ? 1 no tight mode 11 7212.14 178.72 64.87 ? 2 no tight mode 12 7355.46 304.74 182.75 ? 1 yes tight mode 13 6956.54 327.11 180.21 ? 2 yes tight mode 14 13603.72 582.02 100.10 ? 1 no spread mode 15 13443.54 543.97 101.13 ? 2 no spread mode 16 13731.94 717.31 207.12 ? 1 yes spread mode 17 13379.62 800.31 207.70 ? 2 yes spread Modes 9 through 17 are equivalent to modes 0-8 except that the operation is performed via a call thru a pointer-to-function. (Mode 9 is a pointer to a nop). Apart from the noticable improvement in overall speed from left to right, this shows that the lock prefix is _very_ expensive on Pentium and above, even in a UP configuration. It makes no difference on a 386. (I can produce the 486 figures tonight after I get home). It also suggests that moving to an indirect function call (to allow run-time UP/SMP selection) will be quite painful. > As you can see, the lock prefix creates a stall condition on the locked > memory, but does *NOT* stall other memory. This is at least CPU dependent (and may also depend on the motherboard chipset). The i486 states that `all memory is locked'. > Therefore I believe the impact will be unnoticeable. On a duel > 450MHz P-III we are talking 37 ns vs 88 ns - an overhead of 50 ns > for the one processor case, and an overhead of 72 ns for the two > processor case. Whilst that's true for a P-III, it's definitely not true for most lesser machines (which are probably more common - and are likely to remain so for a while). Based on the impact above, I believe the lock prefixes should not be inserted until they are necessary - even if it does mean we wind up with /modules and /modules.smp. I don't believe that moving to indirect function pointers is a reasonable work-around. Finally, my patches to Matt's last code: --- lock2.c~ Tue Jul 13 07:43:10 1999 +++ lock2.c Tue Jul 13 08:38:35 1999 @@ -32,6 +32,13 @@ ATOMIC_ASM_NOLOCK(int, "addl %1,%0"); } +static void nop(void *p, u_int v) {} + +static void (*add_lockp)(void *p, u_int v) = atomic_add_int; +static void (*add_nolockp)(void *p, u_int v) = atomic_add_int_nolock; +static void (*nopp)(void *p, u_int v) = nop; + + volatile int GX[8]; /* note: not shared between processes */ int @@ -51,7 +58,7 @@ ftruncate(fd, pgsize); ptr = mmap(NULL, pgsize, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); - for (m = 0; m <= 8; ++m) { + for (m = 0; m <= 17; ++m) { pid_t pid = -1; int nproc = 1; const char *lcks = "EMPTY"; @@ -119,6 +126,67 @@ ; } break; + case 8+9: + pid = fork(); + nproc = 2; + /* fall through */ + case 7+9: + for (i = 0; i < LOOPS; ++i) { + (*add_lockp)(ptr, 1); + GX[0] = 1; + GX[1] = 1; + GX[2] = 1; + GX[3] = 1; + GX[4] = 1; + GX[5] = 1; + GX[6] = 1; + GX[7] = 1; + } + lcks = "yes"; + break; + case 6+9: + pid = fork(); + nproc = 2; + /* fall through */ + case 5+9: + for (i = 0; i < LOOPS; ++i) { + (*add_nolockp)(ptr, 1); + GX[0] = 1; + GX[1] = 1; + GX[2] = 1; + GX[3] = 1; + GX[4] = 1; + GX[5] = 1; + GX[6] = 1; + GX[7] = 1; + } + lcks = "no"; + break; + case 4+9: + pid = fork(); + nproc = 2; + /* fall through */ + case 3+9: + for (i = 0; i < LOOPS; ++i) { + (*add_lockp)(ptr, 1); + } + lcks = "yes"; + break; + case 2+9: + pid = fork(); + nproc = 2; + /* fall through */ + case 1+9: + for (i = 0; i < LOOPS; ++i) { + (*add_nolockp)(ptr, 1); + } + lcks = "no"; + break; + case 0+9: + for (i = 0; i < LOOPS; ++i) { + (*nopp)(ptr, 1); + } + break; default: printf("huh?\n"); exit(1); @@ -131,7 +199,7 @@ usec = tv2.tv_usec + 1000000 - tv1.tv_usec + (tv2.tv_sec - tv1.tv_sec - 1) * 1000000; - printf("mode %d\t%6.2f ns/loop nproc=%d lcks=%s\n", m, (double)usec * 1000.0 / (double)LOOPS / (double)nproc, nproc, lcks); + printf("mode %2d\t%6.2f ns/loop nproc=%d lcks=%s\n", m, (double)usec * 1000.0 / (double)LOOPS / (double)nproc, nproc, lcks); } return(0); } Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 17: 1: 5 1999 Delivered-To: freebsd-current@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id 2DD0D14FD2; Mon, 12 Jul 1999 17:01: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 QAA02518; Mon, 12 Jul 1999 16:56:24 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907122356.QAA02518@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Stephen Hocking-Senior Programmer PGS Tensor Perth Cc: "Brian F. Feldman" , current@freebsd.org Subject: Re: MTRR stuff In-reply-to: Your message of "Sat, 10 Jul 1999 13:00:18 +0800." <199907100500.NAA05937@ariadne.tensor.pgs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jul 1999 16:56:24 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > What exactly are the ranges? You haven't given me enough info yet. I wrote the > > K6-* MTRR driver, so I'd like to help. > > > OK, the Linux 3dfx driver attempts to set up a write combining range starting > at the card's base address and 0x400000 bytes long. After doing this it then > sets up a range marked as uncacheable starting at the card's base address of > length 0x1000. The current i686 MTRR driver doesn't allow overlapping ranges at all; this is a defect in its implementation that will be rectified when I get to work on it next (hopefully in the next week or so). -- \\ 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-current" in the body of the message From owner-freebsd-current Mon Jul 12 18:21:47 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 3EA8F15230 for ; Mon, 12 Jul 1999 18:21:41 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA73158; Mon, 12 Jul 1999 18:21:26 -0700 (PDT) (envelope-from dillon) Date: Mon, 12 Jul 1999 18:21:26 -0700 (PDT) From: Matthew Dillon Message-Id: <199907130121.SAA73158@apollo.backplane.com> To: Peter Jeremy Cc: dfr@nlsystems.com, dillon@apollo.backplane.com, freebsd-current@FreeBSD.ORG, luoqi@watermarkgroup.com, mike@ducky.net Subject: Re: "objtrm" problem probably found References: <99Jul13.084657est.40574@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Or (maybe more clearly): : :#ifdef SMP :#define SMP_LOCK "lock; " :#else :#define SMP_LOCK :#endif : :#define ATOMIC_ASM(type,op) \ : __asm __volatile (SMP_LOCK op : "=m" (*(type *)p) : "ir" (v), "0" (*(type *)p)) Yes, precisely. :I believe the API to the PCI-locking routines should be distinct from :the API for SMP locks - even though the underlying implementation may :be common. This is more a driver issue then anything else. :Based on the impact above, I believe the lock prefixes should not :be inserted until they are necessary - even if it does mean we wind :up with /modules and /modules.smp. I don't believe that moving :to indirect function pointers is a reasonable work-around. : :Peter We can certainly remove it for the UP case, but it needs to stay in for the SMP case because there is a 100% chance that these routines are going to have to be SMP safe when the big giant lock hits up against the VM system. It will become even more important after interrupts are moved into their own threads if we want to be able to run interrupts in parallel with other supervisor code (e.g. network interrupt and network stack ). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 19:18: 4 1999 Delivered-To: freebsd-current@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id 2AC6114F42 for ; Mon, 12 Jul 1999 19:18: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 TAA03301; Mon, 12 Jul 1999 19:09:58 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907130209.TAA03301@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Mike Haertel Cc: Matthew Dillon , Luoqi Chen , dfr@nlsystems.com, jeremyp@gsmx07.alcatel.com.au, freebsd-current@FreeBSD.ORG Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") In-reply-to: Your message of "Mon, 12 Jul 1999 10:41:26 PDT." <199907121741.KAA17837@ducky.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jul 1999 19:09:58 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Although function calls are more expensive than inline code, > they aren't necessarily a lot more so, and function calls to > non-locked RMW operations are certainly much cheaper than > inline locked RMW operations. This is a fairly key statement in context, and an opinion here would count for a lot; are function calls likely to become more or less expensive in time? -- \\ 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-current" in the body of the message From owner-freebsd-current Mon Jul 12 19:31:56 1999 Delivered-To: freebsd-current@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id 5A6971506C; Mon, 12 Jul 1999 19:31:54 -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 TAA03396; Mon, 12 Jul 1999 19:25:27 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907130225.TAA03396@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Brian F. Feldman" Cc: Garrett Wollman , Martin Cracauer , freebsd-current@FreeBSD.org Subject: Re: Using float emulator on a system with FPU? In-reply-to: Your message of "Mon, 12 Jul 1999 16:26:06 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jul 1999 19:25:26 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I suggested about half a year ago that we should officially desupport > > non-FPU configurations in 4.0. Unfortunately, my resolution was > > soundly defeated. > > Why shouldn't we? Noone uses machines without FPUs anymore. What non-ancient > CPU doesn't have an FPU? And we're talking about the i386 family here... Lots (and I mean _lots_) of embedded systems use fpu-less 386 and 486 cores. Alienating users of these systems would be a dumb idea. -- \\ 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-current" in the body of the message From owner-freebsd-current Mon Jul 12 19:39:21 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 62A2F14E37 for ; Mon, 12 Jul 1999 19:39:16 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA73524; Mon, 12 Jul 1999 19:38:43 -0700 (PDT) (envelope-from dillon) Date: Mon, 12 Jul 1999 19:38:43 -0700 (PDT) From: Matthew Dillon Message-Id: <199907130238.TAA73524@apollo.backplane.com> To: Mike Smith Cc: Mike Haertel , Luoqi Chen , dfr@nlsystems.com, jeremyp@gsmx07.alcatel.com.au, freebsd-current@FreeBSD.ORG Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") References: <199907130209.TAA03301@dingo.cdrom.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :> Although function calls are more expensive than inline code, :> they aren't necessarily a lot more so, and function calls to :> non-locked RMW operations are certainly much cheaper than :> inline locked RMW operations. : :This is a fairly key statement in context, and an opinion here would :count for a lot; are function calls likely to become more or less :expensive in time? In terms of cycles, either less or the same. Certainly not more. If you think about it, a function call is nothing more then a save, a jump, and a retrieval and jump later on. On intel the save is a push, on other cpu's the save may be to a register (which is pushed later if necessary). The change in code flow used to be the expensive piece, but not any more. You typically either see a branch prediction cache (Intel) offering a best-case of 0-cycle latency, or a single-cycle latency that is slot-fillable (MIPS). Since the jump portion of a subroutine call to a direct label is nothing more then a deterministic branch, the branch prediction cache actually operates in this case. You do not quite get 0-cycle latency due to the push/pop, and potential arguments, but it is very fast. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 19:56:37 1999 Delivered-To: freebsd-current@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id C6C63150CF for ; Mon, 12 Jul 1999 19:56:34 -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 TAA03519; Mon, 12 Jul 1999 19:46:17 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907130246.TAA03519@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Matthew Dillon Cc: Mike Smith , Mike Haertel , Luoqi Chen , dfr@nlsystems.com, jeremyp@gsmx07.alcatel.com.au, freebsd-current@FreeBSD.ORG Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") In-reply-to: Your message of "Mon, 12 Jul 1999 19:38:43 PDT." <199907130238.TAA73524@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jul 1999 19:46:17 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > : > :> Although function calls are more expensive than inline code, > :> they aren't necessarily a lot more so, and function calls to > :> non-locked RMW operations are certainly much cheaper than > :> inline locked RMW operations. > : > :This is a fairly key statement in context, and an opinion here would > :count for a lot; are function calls likely to become more or less > :expensive in time? ... > The change in code flow used to be the expensive piece, but not any > more. You typically either see a branch prediction cache (Intel) > offering a best-case of 0-cycle latency, or a single-cycle latency > that is slot-fillable (MIPS). I assumed too much in asking the question; I was specifically interested in indirect function calls, since this has a direct impact on method-style implementations. -- \\ 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-current" in the body of the message From owner-freebsd-current Mon Jul 12 20:21:38 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id E0A2414C2F for ; Mon, 12 Jul 1999 20:21:30 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA73713; Mon, 12 Jul 1999 20:21:23 -0700 (PDT) (envelope-from dillon) Date: Mon, 12 Jul 1999 20:21:23 -0700 (PDT) From: Matthew Dillon Message-Id: <199907130321.UAA73713@apollo.backplane.com> To: Mike Smith Cc: Mike Smith , Mike Haertel , Luoqi Chen , dfr@nlsystems.com, jeremyp@gsmx07.alcatel.com.au, freebsd-current@FreeBSD.ORG Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") References: <199907130246.TAA03519@dingo.cdrom.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I assumed too much in asking the question; I was specifically :interested in indirect function calls, since this has a direct impact :on method-style implementations. Branch prediction caches are typically PC-sensitive. An indirect method call will never be as fast as a direct call, but if the indirect address is the same the branch prediction cache will work. If the indirect address changes at the PC where the call is being made, the branch cache may create a penalty. Try this core in one of the cases to that test program, and add two nop subroutines void nop1(void) { } and void nop2(void) { }. Compile this code without any optimizations! *no* optimizations or the test will not demonstrate the problem :-) In this case the branch prediction succeeds because the indirect address does not change at the PC where func() is called. I get 34 ns per loop. { void (*func)(void) = nop1; for (i = 0; i < LOOPS; ++i) { func(); if (i & 1) func = nop1; else func = nop1; } } In this case the branch prediction fails because the indirect address is different at the PC each time func() is called. I get 61ns. { void (*func)(void) = nop1; for (i = 0; i < LOOPS; ++i) { func(); if (i & 1) func = nop1; else func = nop2; } } In this case we simulate a mix. (i & 1) -> (i & 7). I get 47 ns. { void (*func)(void) = nop1; for (i = 0; i < LOOPS; ++i) { func(); if (i & 7) func = nop1; else func = nop2; } } Ok, so what does this mean for method calls? If the method call is INLINED, then the branch prediction cache will tend to work because the method call will tend to call the same address at any given PC. If the method call is doubly-indirect, where a routine is called which calculates the method address and then calls it, the branch prediction cache will tend to fail because a different address will tend to be called at the PC of the call. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 20:27:29 1999 Delivered-To: freebsd-current@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 3224014C2F for ; Mon, 12 Jul 1999 20:27: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 XAA59570; Mon, 12 Jul 1999 23:24:53 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Mon, 12 Jul 1999 23:24:53 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Mike Smith Cc: Stephen Hocking-Senior Programmer PGS Tensor Perth , current@FreeBSD.org Subject: Re: MTRR stuff In-Reply-To: <199907122356.QAA02518@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 12 Jul 1999, Mike Smith wrote: > > > > > What exactly are the ranges? You haven't given me enough info yet. I wrote the > > > K6-* MTRR driver, so I'd like to help. > > > > > OK, the Linux 3dfx driver attempts to set up a write combining range starting > > at the card's base address and 0x400000 bytes long. After doing this it then > > sets up a range marked as uncacheable starting at the card's base address of > > length 0x1000. > > The current i686 MTRR driver doesn't allow overlapping ranges at all; > this is a defect in its implementation that will be rectified when I > get to work on it next (hopefully in the next week or so). The current K6 MTRR driver does, but I need more information on exactly what's wrong. If it's returning EINVAL, what EXACTLY did he pass it? Stephen, you're not giving enough information. > > -- > \\ 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-current" 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-current" in the body of the message From owner-freebsd-current Mon Jul 12 20:59:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id BDCDE14F06 for ; Mon, 12 Jul 1999 20:59:23 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40360>; Tue, 13 Jul 1999 13:40:51 +1000 Date: Tue, 13 Jul 1999 13:37:15 +1000 From: Peter Jeremy Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") In-reply-to: <199907130209.TAA03301@dingo.cdrom.com> To: mike@smith.net.au Cc: freebsd-current@FreeBSD.ORG Message-Id: <99Jul13.134051est.40360@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith wrote: >> Although function calls are more expensive than inline code, >> they aren't necessarily a lot more so, and function calls to >> non-locked RMW operations are certainly much cheaper than >> inline locked RMW operations. > >This is a fairly key statement in context, and an opinion here would >count for a lot; are function calls likely to become more or less >expensive in time? Based on general computer architecture principles, I'd say that a lock prefix is likely to become more expensive[1], whilst a function call will become cheaper[2] over time. I'm not sure that this is an important issue here. The sole advantage of moving to indirect function calls would be that the same object code could be used on both UP and SMP configurations, without incurring the overhead of the lock prefix in the UP configuration. (At the expense of an additional function call in all configurations). We can't avoid the lock prefix overhead in the SMP case. Based on the timings I did this morning, function calls are (unacceptably, IMHO) expensive on all the CPU's I have to hand (i386, Pentium and P-II) - the latter two presumably comprising the bulk of current FreeBSD use. Currently the UP/SMP decision is made at compile time (and has significant and widespread impact) - therefore there seems little (if any) benefit in using function calls within the main kernel. I believe that Matt's patched i386/include/atomic.h, with the addition of code to only include the lock prefix when SMP is defined, is currently the optimal approach for the kernel - and I can't see any way a future IA-32 implementation could change that. The only benefit could be for kernel modules - a module could possibly be compiled so the same LKM would run on either UP or SMP. Note that function calls for atomic operations may not be sufficient (by themselves) to achieve this: One of the SMP gurus may be able to confirm whether anything else prevents an SMP-compiled LKM running with a UP kernel. If the lock prefix overhead becomes an issue for LKMs, then we could define a variant of i386/include/atomic.h (eg by using a #define which is only true for compiling LKMs) which does use indirect function calls (and add the appropriate initialisation code). This is a trivial exercise (which I'll demonstrate on request). [1] A locked instruction implies a synchronous RMW cycle. In order to meet write-ordering guarantees (without which, a locked RMW cycle would be useless as a semaphore primitive), it implies a complete write serialization, and probably some level of instruction serialisation. Since write-back pipelines will get longer and parallel execution units more numerous, the cost of a serialisation operation will get relatively higher. Also, lock instructions are relatively infrequent, therefore there is little incentive to expend valuable silicon on trying to make them more efficient (at least as seen by the executing CPU). [2] Function calls _are_ fairly common, therefore it probably is worthwhile expending some effort in optimising them - and the stack updates associated with a leaf subroutine are fairly easy to totally hide in an on-chip write pipeline/cache. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 21:37: 1 1999 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 8E12414F47 for ; Mon, 12 Jul 1999 21:36:54 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40326>; Tue, 13 Jul 1999 14:18:32 +1000 Date: Tue, 13 Jul 1999 14:36:20 +1000 From: Peter Jeremy Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") In-reply-to: <199907130238.TAA73524@apollo.backplane.com> To: dillon@apollo.backplane.com, mike@smith.net.au Cc: freebsd-current@FreeBSD.ORG Message-Id: <99Jul13.141832est.40326@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > The change in code flow used to be the expensive piece, but not any > more. You typically either see a branch prediction cache (Intel) > offering a best-case of 0-cycle latency, or a single-cycle latency > that is slot-fillable (MIPS). In the case of an indirect branch, you also need to fetch the destination address from memory. This is presumably 1 cycle (if it's cached). It may be possible to pre-fetch the address, but this requires a substantial amount of silicon for the interlocks. > Since the jump portion of a subroutine call to a direct label is nothing > more then a deterministic branch, the branch prediction cache actually > operates in this case. You do not quite get 0-cycle latency due to > the push/pop, and potential arguments, but it is very fast. I'm not sure there's any reason why you shouldn't. If you changed the semantics of a stack segment so that memory addresses below the stack pointer were irrelevant, you could implement a small, 0-cycle, on-chip stack (that overflowed into memory). I don't know whether this semantic change would be allowable (and whether the associated silicon could be justified) for the IA-32. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 22: 1:48 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 2F03C1517D for ; Mon, 12 Jul 1999 22:01:45 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id WAA74171; Mon, 12 Jul 1999 22:01:39 -0700 (PDT) (envelope-from dillon) Date: Mon, 12 Jul 1999 22:01:39 -0700 (PDT) From: Matthew Dillon Message-Id: <199907130501.WAA74171@apollo.backplane.com> To: Peter Jeremy Cc: mike@smith.net.au, freebsd-current@FreeBSD.ORG Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") References: <99Jul13.141832est.40326@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :I'm not sure there's any reason why you shouldn't. If you changed the :semantics of a stack segment so that memory addresses below the stack :pointer were irrelevant, you could implement a small, 0-cycle, on-chip :stack (that overflowed into memory). I don't know whether this :semantic change would be allowable (and whether the associated silicon :could be justified) for the IA-32. : :Peter This would be relatively complex and also results in cache coherency problems. A solution already exists: It's called branch-and-link, but Intel cpu's do not use it because Intel cpu's do not have enough registers (makes you just want to throw up -- all that MMX junk and they couldn't add a branch and link register! ). The key with branch-and-link is that the lowest subroutine level does not have to save/restore the register, making entry and return two or three times faster then subroutine calls that make other subroutine calls. The big problem with implementing complex caches is that it takes up a serious amount of die space and power. Most modern cpu's revolve almost entirely around their L1 cache and their register file. The remaining caches tend to be ad-hoc. Intel's branch prediction cache is like this. In order for a memory-prediction cache to be useful, it really needs to be cache-coherent, which basically kills the idea of having a separate little special case for the stack. Only the L1 cache is coherent. If you wanted you could implement multiple L1 data caches on-chip - that might be of some benefit, but otherwise branch-and-link is the better way to do it. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 22:29:14 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 52DB614F66 for ; Mon, 12 Jul 1999 22:29:11 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id WAA74299; Mon, 12 Jul 1999 22:28:02 -0700 (PDT) (envelope-from dillon) Date: Mon, 12 Jul 1999 22:28:02 -0700 (PDT) From: Matthew Dillon Message-Id: <199907130528.WAA74299@apollo.backplane.com> To: Peter Jeremy Cc: mike@smith.net.au, freebsd-current@FreeBSD.ORG Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") References: <99Jul13.134051est.40360@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Based on general computer architecture principles, I'd say that a lock :prefix is likely to become more expensive[1], whilst a function call :will become cheaper[2] over time. :... : :[1] A locked instruction implies a synchronous RMW cycle. In order : to meet write-ordering guarantees (without which, a locked RMW : cycle would be useless as a semaphore primitive), it implies a : complete write serialization, and probably some level of : instruction serialisation. Since write-back pipelines will get A locked instruction only implies cache coherency across the instruction. It does not imply serialization. Intel blows it big time, but that's intel for you. : longer and parallel execution units more numerous, the cost of : a serialisation operation will get relatively higher. Also, :Peter It is not a large number of execution units that implies a higher cost of serialization but instead data interdependancies. A locked instruction doe snot have to imply serialization. Modern cache coherency protocols do not have a problem with a large number of caches in a parallel processing subsystem. This is how a typical two-level cache coherency protocol works with an L1 and L2 cache: * The L2 cache is usually a superset of the L1 cache. That is, all cache lines in the L1 cache also exist in the L2 cache. * Both the L1 and L2 caches implement a shared and an exclusive bit, usually on a per-cache-line basis. * When a processor, A, issues a memory op that is not in its cache, it can request the cache line from main memory either shared (unlocked) or exclusive (locked). * All other processors snoop the main memory access. * If another processor's L2 cache contains the cache line being requested by processor A, it can provide the cache line to processor A and no main memory op actually occurs. In this case, the shared and exclusive bits in processor B's L1 and L2 caches are updated appropriately. - if A is requesting shared (unlocked) access, both A and B will set the shared bit and B will clear the exclusive bit. (B will cause A to stall if it is in the middle of operating on the locked cache line). - if A is requesting exclusive (locked) access, B will invalidate its cache line and clear both the shared and exclusive bits, and A will set its exclusive bit. A now owns that cache line. - If no other processor owns the cache line, A obtains the data from main memory and other processors have the option to snoop the access in their L2 caches. So, using the above rules as an example, a locked instruction can cost as little as 0 extra cycles no matter how many cpu's you have running in parallel. There is no need to serialize or synchronize anything. The worst case is actually not even as bad as a complete cache-miss case. The cost of snooping another cpu's L2 cache is much less then the cost of going to main memory. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 22:40:36 1999 Delivered-To: freebsd-current@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 79C0714F66 for ; Mon, 12 Jul 1999 22:40: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 PAA26898 for ; Tue, 13 Jul 1999 15:37:28 +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 PAA20358 for ; Tue, 13 Jul 1999 15:37:22 +1000 (EST) Received: (qmail 94535 invoked by uid 1000); 13 Jul 1999 05:37:16 -0000 From: "Andrew Reilly" Date: Tue, 13 Jul 1999 15:37:16 +1000 To: Mike Smith Cc: Mike Haertel , Matthew Dillon , Luoqi Chen , dfr@nlsystems.com, jeremyp@gsmx07.alcatel.com.au, freebsd-current@FreeBSD.ORG Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") Message-ID: <19990713153716.A94421@gurney.reilly.home> References: <199907121741.KAA17837@ducky.net> <199907130209.TAA03301@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199907130209.TAA03301@dingo.cdrom.com>; from Mike Smith on Mon, Jul 12, 1999 at 07:09:58PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 12, 1999 at 07:09:58PM -0700, Mike Smith wrote: > > Although function calls are more expensive than inline code, > > they aren't necessarily a lot more so, and function calls to > > non-locked RMW operations are certainly much cheaper than > > inline locked RMW operations. > > This is a fairly key statement in context, and an opinion here would > count for a lot; are function calls likely to become more or less > expensive in time? Others have answered this question, but I thought I'd point out that there is another alternative that is likely to be faster than indirect function calls on some architectures: inline branched code. So you still have a global variable selecting locked/non-locked, but it's a boolean, rather than a pointer. Your atomic macros are then { if (atomic_lock) asm("lock;foo"); else asm ("foo"); } You might be interested in the paper: "Efficient Dynamic Dispatch without Virtual Function Tables. The SmallEiffel Compiler." Olivier ZENDRA, Dominique COLNET, Suzanne COLLIN. 12th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA'97), Volume 32, Issue 10 - Atlanta, GA, USA, October 1997, pages 125-141. http://SmallEiffel.loria.fr/papers/papers.html#OOPSLA97 as a justification for that approach. -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 22:47: 8 1999 Delivered-To: freebsd-current@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id EC8CD14CA1 for ; Mon, 12 Jul 1999 22:47:06 -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 WAA04527; Mon, 12 Jul 1999 22:38:03 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907130538.WAA04527@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Andrew Reilly" Cc: Mike Smith , Mike Haertel , Matthew Dillon , Luoqi Chen , dfr@nlsystems.com, jeremyp@gsmx07.alcatel.com.au, freebsd-current@FreeBSD.ORG Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") In-reply-to: Your message of "Tue, 13 Jul 1999 15:37:16 +1000." <19990713153716.A94421@gurney.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jul 1999 22:38:03 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, Jul 12, 1999 at 07:09:58PM -0700, Mike Smith wrote: > > > Although function calls are more expensive than inline code, > > > they aren't necessarily a lot more so, and function calls to > > > non-locked RMW operations are certainly much cheaper than > > > inline locked RMW operations. > > > > This is a fairly key statement in context, and an opinion here would > > count for a lot; are function calls likely to become more or less > > expensive in time? > > Others have answered this question, but I thought I'd point out > that there is another alternative that is likely to be faster > than indirect function calls on some architectures: inline > branched code. So you still have a global variable selecting > locked/non-locked, but it's a boolean, rather than a pointer. > Your atomic macros are then { if (atomic_lock) asm("lock;foo"); > else asm ("foo"); } This requires you to have all the methods present at compile time, which defeats the entire purpose of dynamic method loading. -- \\ 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-current" in the body of the message From owner-freebsd-current Mon Jul 12 23: 2:46 1999 Delivered-To: freebsd-current@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 87F3E14BD0 for ; Mon, 12 Jul 1999 23:02:40 -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 QAA03028 for ; Tue, 13 Jul 1999 16:00: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 QAA01623 for ; Tue, 13 Jul 1999 16:00:05 +1000 (EST) Received: (qmail 94686 invoked by uid 1000); 13 Jul 1999 06:00:05 -0000 From: "Andrew Reilly" Date: Tue, 13 Jul 1999 16:00:05 +1000 To: Mike Smith Cc: Andrew Reilly , Mike Haertel , Matthew Dillon , Luoqi Chen , dfr@nlsystems.com, jeremyp@gsmx07.alcatel.com.au, freebsd-current@FreeBSD.ORG Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") Message-ID: <19990713160005.B94421@gurney.reilly.home> References: <19990713153716.A94421@gurney.reilly.home> <199907130538.WAA04527@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199907130538.WAA04527@dingo.cdrom.com>; from Mike Smith on Mon, Jul 12, 1999 at 10:38:03PM -0700 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 12, 1999 at 10:38:03PM -0700, Mike Smith wrote: > I said: > > than indirect function calls on some architectures: inline > > branched code. So you still have a global variable selecting > > locked/non-locked, but it's a boolean, rather than a pointer. > > Your atomic macros are then { if (atomic_lock) asm("lock;foo"); > > else asm ("foo"); } > > This requires you to have all the methods present at compile time, > which defeats the entire purpose of dynamic method loading. Pardon? I didn't see a discussion of dynamic loading anywhere here. We were referring to tiny inlined assembly language routines. The existing implementation is #defines in a C header file. (No, SmallEiffel doesn't do dynamic loading, and that's a perfectly fair and reasonable choice for a large number of applications.) -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 23:15:17 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id D705614E2A for ; Mon, 12 Jul 1999 23:15:15 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id XAA74538; Mon, 12 Jul 1999 23:13:58 -0700 (PDT) (envelope-from dillon) Date: Mon, 12 Jul 1999 23:13:58 -0700 (PDT) From: Matthew Dillon Message-Id: <199907130613.XAA74538@apollo.backplane.com> To: Matthew Dillon Cc: Peter Jeremy , mike@smith.net.au, freebsd-current@FreeBSD.ORG Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") References: <99Jul13.134051est.40360@border.alcanet.com.au> <199907130528.WAA74299@apollo.backplane.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :... I would also like to add a few more notes in regards to write pipelines. Write pipelines are not used any more, at least not long ones. The reason is simply the cache coherency issue again. Until the data is actually written into the L1 cache, it is acoherent. Acoherency is no longer allowed :-). That kind creates a problem for the old write pipeline. Thus, modern cpu's have begun removing their write pipelines in favor of a synchronous write to the L1 cache. This typically occurs in the "write-back" phase of the instruction pipeline. It does not cause a processor to stall. There are several advantages to this: * First, since the write is going directly into the L1 cache, it can partake of the cache coherency protocols. * Second, since the L1 cache is large compared to the older write-pipeline schema, this effectively gives us a (for all intents and purposes other then a memory copy) infinitely-sized write pipeline. * Third, we can throw away all the write pipeline address snooping junk on the chip, making the chip smaller. The cache coherency protocol may cause side effects when a memory write is issued. Typically the write is issued into the L1 cache and requires what is known as a write-through operation into the L2 cache in order to guarentee cache coherency. This is necessary because it is the L2 cache which is performing the bulk of the bus protocol to implement the cache coherency, and it needs to know when you've modified something. "write through" *used* to mean writing through to main memory, but with the advent of modern cache coherency protocols, the L2 cache *IS* main memory for all intents and purposes. Dirty data contained in the L2 cache inherently invalidates the associated memory address in main memory simply by being present in the L2 cache. Another processor attempting to access that location in main memory will instead obtain the data directly from our processor's L2 cache. One of the interesting benefits from this is that dirty data in the L2 cache can be flushed to main memory completely asynchronously without screwing up cache coherency, serialization, or anything else. Final note: memory mapped I/O spaces do not apply here. These are usually marked uncacheable and have nothing to do with the cache. But DMA is different. DMA works just like any other memory access in that it can be made to run through the L2 cache coherency protocols. So you can often safely initiate DMA without having to flush your caches. This is not true of all processors. I'm not sure about the Pentium's. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 23:19: 2 1999 Delivered-To: freebsd-current@freebsd.org Received: from sasami.jurai.net (sasami.jurai.net [63.67.141.99]) by hub.freebsd.org (Postfix) with ESMTP id 2D01214BD0; Mon, 12 Jul 1999 23:18:56 -0700 (PDT) (envelope-from winter@jurai.net) Received: from localhost (winter@localhost) by sasami.jurai.net (8.8.8/8.8.7) with ESMTP id CAA26724; Tue, 13 Jul 1999 02:18:12 -0400 (EDT) Date: Tue, 13 Jul 1999 02:18:12 -0400 (EDT) From: "Matthew N. Dodd" To: "Brian F. Feldman" Cc: freebsd-current@FreeBSD.ORG Subject: Re: Using float emulator on a system with FPU? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 12 Jul 1999, Brian F. Feldman wrote: > Why shouldn't we? Noone uses machines without FPUs anymore. What > non-ancient CPU doesn't have an FPU? And we're talking about the i386 > family here... I've got a few. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | winter@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 23:21:50 1999 Delivered-To: freebsd-current@freebsd.org Received: from ducky.net (gate.ducky.net [199.2.211.252]) by hub.freebsd.org (Postfix) with ESMTP id 7256D14BD0 for ; Mon, 12 Jul 1999 23:21:44 -0700 (PDT) (envelope-from mike@ducky.net) Received: from ducky.net (localhost.ducky.net [127.0.0.1]) by ducky.net (8.9.1/8.8.5) with ESMTP id XAA18700; Mon, 12 Jul 1999 23:11:54 -0700 (PDT) Message-Id: <199907130611.XAA18700@ducky.net> To: Mike Haertel Cc: Mike Smith , Matthew Dillon , Luoqi Chen , dfr@nlsystems.com, jeremyp@gsmx07.alcatel.com.au, freebsd-current@FreeBSD.ORG, mike@ducky.net Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") In-reply-to: Your message of "Mon, 12 Jul 1999 23:09:19 PDT." <199907130609.XAA18672@ducky.net> Date: Mon, 12 Jul 1999 23:11:54 -0700 From: Mike Haertel Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Second answer: in the real world, we're nearly always hitting the >cache on stack operations associated with calls and argument passing, >but not less often on operations in the procedure body. So, in ^^^ typo Urk. I meant to say "less often", delete the "not". To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 23:27:11 1999 Delivered-To: freebsd-current@freebsd.org Received: from ducky.net (gate.ducky.net [199.2.211.252]) by hub.freebsd.org (Postfix) with ESMTP id 5CF4114BD0 for ; Mon, 12 Jul 1999 23:27:07 -0700 (PDT) (envelope-from mike@ducky.net) Received: from ducky.net (localhost.ducky.net [127.0.0.1]) by ducky.net (8.9.1/8.8.5) with ESMTP id XAA18672; Mon, 12 Jul 1999 23:09:20 -0700 (PDT) Message-Id: <199907130609.XAA18672@ducky.net> To: Mike Smith Cc: Mike Haertel , Matthew Dillon , Luoqi Chen , dfr@nlsystems.com, jeremyp@gsmx07.alcatel.com.au, freebsd-current@FreeBSD.ORG, mike@ducky.net Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") In-reply-to: Your message of "Mon, 12 Jul 1999 19:09:58 PDT." <199907130209.TAA03301@dingo.cdrom.com> Date: Mon, 12 Jul 1999 23:09:19 -0700 From: Mike Haertel Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >This is a fairly key statement in context, and an opinion here would >count for a lot; are function calls likely to become more or less >expensive in time? Ambiguous question. First answer: Assume we're hitting the cache, taking no branch mispredicts, and everything is generally going at "the speed of light". The cost of a call, relative to the cost of "basic operations" like loads and adds, will stay about the same in Intel's next-generation x86 processors as it is now. We made some tradeoffs, some things go a little faster and others a little slower, but in the end the function call overhead averages out to about the same. Second answer: in the real world, we're nearly always hitting the cache on stack operations associated with calls and argument passing, but not less often on operations in the procedure body. So, in the real world, as memory latencies get worse and worse relative to processor frequency, the overhead for procedure calling represents an increasingly smaller percentage of the total execution time. Summary: So, correctly predicted calls are staying the same or getting cheaper. Certainly calls are not getting worse, unless perhaps you have lots of mispredicted calls. As pipelines get deeper, mispredicts get worse. But that's not a problem just for calls, it's branches in general. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Mon Jul 12 23:33:35 1999 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id A898615214 for ; Mon, 12 Jul 1999 23:33:30 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40326>; Tue, 13 Jul 1999 16:15:25 +1000 Date: Tue, 13 Jul 1999 16:33:11 +1000 From: Peter Jeremy Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") In-reply-to: <199907130528.WAA74299@apollo.backplane.com> To: dillon@apollo.backplane.com Cc: freebsd-current@FreeBSD.ORG Message-Id: <99Jul13.161525est.40326@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: >:[1] A locked instruction implies a synchronous RMW cycle. In order >: to meet write-ordering guarantees (without which, a locked RMW >: cycle would be useless as a semaphore primitive), it implies a >: complete write serialization, and probably some level of >: instruction serialisation. Since write-back pipelines will get > > A locked instruction only implies cache coherency across the > instruction. It does not imply serialization. Intel blows it > big time, but that's intel for you. Ooops, looks like foot-in-mouth time for me :-(. Maybe I should have said that "without any other cache coherency protocol, you need serialisation" :-). Given this correction, the lock degradation is much less than I suggested. I suspect there _will_ be gradual degradation though. >: longer and parallel execution units more numerous, the cost of >: a serialisation operation will get relatively higher. Also, > > It is not a large number of execution units that implies a higher > cost of serialization but instead data interdependancies. I was thinking more that a locked instruction is inconsistent with parallel execution, but that's probably not true either. > Modern cache coherency protocols do not have a problem with > a large number of caches in a parallel processing subsystem. I thought we were talking about Intel :-). > So, using the above rules as an example, a locked instruction can cost > as little as 0 extra cycles no matter how many cpu's you have running > in parallel. There is no need to serialize or synchronize anything. Assuming a non-contested access. If you've got two CPU's fighting over a lock, then you'll have a bus cycle - and CPU core speeds are increasing faster than bus speeds. (486's were normally 1 or 2 times the bus speed, a PIII-450 is 4.5 times bus speed). And as you pointed out elsewhere, call/return sequences can't get too much faster - which suggests that the relative costs should stay fairly similar. At least for a well-designed architecture... Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 13 0:22:35 1999 Delivered-To: freebsd-current@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 7E308152A2 for ; Tue, 13 Jul 1999 00:22:33 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (iras-1-16.ucdavis.edu [169.237.16.16]) by relay.nuxi.com (8.9.3/8.9.3) with ESMTP id AAA48047; Tue, 13 Jul 1999 00:22:30 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.9.3/8.9.1) id HAA06473; Tue, 13 Jul 1999 07:22:28 GMT (envelope-from obrien) Date: Tue, 13 Jul 1999 00:22:27 -0700 From: "David O'Brien" To: Nik Clayton Cc: freebsd-current@FreeBSD.ORG Subject: Re: HELP!!! -CURRENT libtool problem. Message-ID: <19990713002227.C6161@dragon.nuxi.com> Reply-To: obrien@NUXI.com References: <37810FDD.C1321FE7@videotron.ca> <37887C61.2F462FD@newsguy.com> <19990711220050.A31542@catkin.nothing-going-on.org> <19990712155440.B494@norn.ca.eu.org> <19990712004612.A51439@catkin.nothing-going-on.org> <199907120731.AAA67992@silvia.hip.berkeley.edu> <19990712231941.A19068@catkin.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <19990712231941.A19068@catkin.nothing-going-on.org>; from Nik Clayton on Mon, Jul 12, 1999 at 11:19:41PM +0100 X-Operating-System: FreeBSD 4.0-CURRENT 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-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > You're correct in that better awareness is almost definitely the key. > Would you consider posting the -stable and -current port build results You can find the realtime results from http://bento.freebsd.org/ -- -- David (obrien@NUXI.com -or- obrien@FreeBSD.org) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 13 0:32:18 1999 Delivered-To: freebsd-current@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id B348614EFF for ; Tue, 13 Jul 1999 00:32:15 -0700 (PDT) (envelope-from alc@cs.rice.edu) Received: (from alc@localhost) by cs.rice.edu (8.9.0/8.9.0) id CAA17885; Tue, 13 Jul 1999 02:30:12 -0500 (CDT) Date: Tue, 13 Jul 1999 02:30:12 -0500 From: Alan Cox To: Dmitrij Tejblum Cc: Jason Evans , current@freebsd.org Subject: Re: Thread stack allocation (was Re: cvs commit: src/lib/libc_r Makefile src/lib/libc_r/uthread pthread_private.h uthread_create.c uthread_gc.c uthread_init.c) Message-ID: <19990713023012.K6401@cs.rice.edu> References: <199907121853.WAA27876@arc.hq.cti.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5us In-Reply-To: <199907121853.WAA27876@arc.hq.cti.ru>; from Dmitrij Tejblum on Mon, Jul 12, 1999 at 10:53:49PM +0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Jul 12, 1999 at 10:53:49PM +0400, Dmitrij Tejblum wrote: > > I don't see how MAP_ANON is better than MAP_STACK. > It consumes fewer resources. Each time you grow the stack, it adds another vm_map_entry to the vm_map and (eventually) allocates another vm_object. Using MAP_ANON, there is at most one vm_object and one vm_map_entry (until an mprotect chops it up). > ... > > Anyway, what are the advantages of mmap over malloc? Especially if you change > MAP_STACK to MAP_ANON? > None really. But, the real point (as I've explained on the -committers list) is that there's no reason to use MAP_STACK in a FreeBSD-native program. Alan P.S. As an aside, just once, everyone should look at the /proc/"pid"/map of a running cvsup. Each line you see is a vm_map_entry. (What you see is a result of Modula-3's garbage collector.) Roughly speaking, on a page fault, if we're not faulting on the same range of addresses as the last page fault, a linear cost search is performed to find the correct entry. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 13 1:28: 0 1999 Delivered-To: freebsd-current@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 2C4A814BF4 for ; Tue, 13 Jul 1999 01:27:58 -0700 (PDT) (envelope-from alc@cs.rice.edu) Received: (from alc@localhost) by cs.rice.edu (8.9.0/8.9.0) id DAA18337 for current@freebsd.org; Tue, 13 Jul 1999 03:26:24 -0500 (CDT) Date: Tue, 13 Jul 1999 03:26:24 -0500 From: Alan Cox To: current@freebsd.org Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") Message-ID: <19990713032624.M6401@cs.rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5us Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Before this thread on "cache coherence" and "memory consistency" goes any further, I'd like to suggest a time-out to read something like http://www-ece.rice.edu/~sarita/Publications/models_tutorial.ps. A lot of what I'm reading has a grain of truth but isn't quite right. This paper appeared as a tutorial in IEEE Computer a couple years ago, and is fairly accessible to a general audience. Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 13 1:34:40 1999 Delivered-To: freebsd-current@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id 49FE614BF4 for ; Tue, 13 Jul 1999 01:34:35 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id LAA09881; Tue, 13 Jul 1999 11:29:05 +0300 (EEST) (envelope-from will) To: Alan Cox Cc: current@freebsd.org Subject: Re: Thread stack allocation (was Re: cvs commit: src/lib/libc_r Makefile src/lib/libc_r/uthread pthread_private.h uthread_create.c uthread_gc.c uthread_init.c) References: <199907121853.WAA27876@arc.hq.cti.ru> <19990713023012.K6401@cs.rice.edu.newsgate.clinet.fi> From: Ville-Pertti Keinonen Date: 13 Jul 1999 11:29:03 +0300 In-Reply-To: Alan Cox's message of "13 Jul 1999 10:32:41 +0300" Message-ID: <86673p7y28.fsf@not.demophon.com> Lines: 22 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alan Cox writes: > P.S. As an aside, just once, everyone should look at the /proc/"pid"/map > of a running cvsup. Each line you see is a vm_map_entry. (What you > see is a result of Modula-3's garbage collector.) Roughly speaking, Modula-3 really appears to be doing something weird, making half of the entries read-only. A garbage collected language should actually be capable of doing a better job than a non-gc one. > on a page fault, if we're not faulting on the same range of addresses > as the last page fault, a linear cost search is performed > to find the correct entry. Are you suggesting that vm_map_entries should be in, say, a red-black tree (not a bad idea, I've done this), or that programs should just keep their memory contiguous ((s)brk rather than mmap)? The latter is becoming increasingly difficult with the large numbers of shared libraries and growing use of dynamically loaded internal modules (XFree86 4.0?). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 13 2: 2:43 1999 Delivered-To: freebsd-current@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 310251501E for ; Tue, 13 Jul 1999 02:02:29 -0700 (PDT) (envelope-from alc@cs.rice.edu) Received: (from alc@localhost) by cs.rice.edu (8.9.0/8.9.0) id EAA19079; Tue, 13 Jul 1999 04:01:56 -0500 (CDT) Date: Tue, 13 Jul 1999 04:01:56 -0500 From: Alan Cox To: Ville-Pertti Keinonen Cc: current@freebsd.org Subject: Re: Thread stack allocation (was Re: cvs commit: src/lib/libc_r Makefile src/lib/libc_r/uthread pthread_private.h uthread_create.c uthread_gc.c uthread_init.c) Message-ID: <19990713040156.N6401@cs.rice.edu> References: <199907121853.WAA27876@arc.hq.cti.ru> <19990713023012.K6401@cs.rice.edu.newsgate.clinet.fi> <86673p7y28.fsf@not.demophon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5us In-Reply-To: <86673p7y28.fsf@not.demophon.com>; from Ville-Pertti Keinonen on Tue, Jul 13, 1999 at 11:29:03AM +0300 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 13, 1999 at 11:29:03AM +0300, Ville-Pertti Keinonen wrote: > > Alan Cox writes: > > > P.S. As an aside, just once, everyone should look at the /proc/"pid"/map > > of a running cvsup. Each line you see is a vm_map_entry. (What you > > see is a result of Modula-3's garbage collector.) Roughly speaking, > > Modula-3 really appears to be doing something weird, making half of > the entries read-only. A garbage collected language should actually > be capable of doing a better job than a non-gc one. > There's nothing weird going on. :-) It's fairly typical of a garbage collector that leverages the VM system to detect (write) accesses to data. (There was a DEC SRC or WRL techical report documenting Modula-3's garbage collector. A search engine would certainly turn it up.) Before long, you'll see some Java implementations doing the same thing. > > on a page fault, if we're not faulting on the same range of addresses > > as the last page fault, a linear cost search is performed > > to find the correct entry. > > Are you suggesting that vm_map_entries should be in, say, a red-black > tree (not a bad idea, I've done this), or that programs should just > keep their memory contiguous ((s)brk rather than mmap)? > That's one possibility. You'd have the same number of vm_map_entry's but finding the one you want is faster. (Btw, Linux has used an AVL tree for this purpose.) The other possibility is... Almost all of these vm_map_entry's started out as a single entry that got fragmented as mprotects were performed by the garbage collector. Instead of maintaining the page protections as part of the vm_map_entry, you could separate them into a smaller, specialized data structure that is attached to the original vm_map_entry. (SVR4, Solaris and Digital Unix use some variation of an array with an entry per page.) This way you address the problem by limiting the growth of the vm_map's list of vm_map_entry's. In the end, you may want to combine both approaches. I can't say for sure. Alan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 13 2:30:50 1999 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id AE4D215308 for ; Tue, 13 Jul 1999 02:30:40 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40336>; Tue, 13 Jul 1999 19:11:20 +1000 Date: Tue, 13 Jul 1999 19:29:10 +1000 From: Peter Jeremy Subject: Re: Using float emulator on a system with FPU? In-reply-to: To: cracauer@cons.org, dfr@nlsystems.com Cc: freebsd-current@FreeBSD.ORG Message-Id: <99Jul13.191120est.40336@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug Rabson wrote: >You might consider looking at the fp emulator which I wrote for the alpha. >It should be accurate (I tested against the fpu on an x86) and contains >test harness code which can be used to play with it on both x86 and alpha. Anyone interested in working on FP emulation (or checking the shortcuts DEC made when then designed the Alpha) might like to check out : UCBTEST is a suite of programs for testing certain difficult cases of IEEE 754 floating-point arithmetic. Some of the difficult test cases are obtained from number-theoretic algorithms developed by Turing Award winner Prof. W. Kahan, Department of Electrical Engineering and Computer Science, University of California, Berkeley, as part of ongoing research into test methods for computer arithmetic. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 13 3: 5:21 1999 Delivered-To: freebsd-current@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 42BB5151EA; Tue, 13 Jul 1999 03:05:11 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id TAA24789; Tue, 13 Jul 1999 19:04:59 +0900 (JST) Message-ID: <378B077B.DBA3C534@newsguy.com> Date: Tue, 13 Jul 1999 18:31:39 +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: Garrett Wollman , Martin Cracauer , freebsd-current@FreeBSD.ORG Subject: Re: Using float emulator on a system with FPU? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Brian F. Feldman" wrote: > > Why shouldn't we? Noone uses machines without FPUs anymore. What non-ancient > CPU doesn't have an FPU? And we're talking about the i386 family here... And 486SX. Anyway, I still hear of people with such machines. As a matter of fact, I caught some flak when I made the loader require fpu for a while. So, it *will* affect some people. I see no cost in continuing support, so why remove 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-current" in the body of the message From owner-freebsd-current Tue Jul 13 3: 8:22 1999 Delivered-To: freebsd-current@freebsd.org Received: from cons.org (knight.cons.org [194.233.237.195]) by hub.freebsd.org (Postfix) with ESMTP id 6700015269 for ; Tue, 13 Jul 1999 03:07:37 -0700 (PDT) (envelope-from cracauer@cons.org) Received: (from cracauer@localhost) by cons.org (8.8.8/8.7.3) id MAA12000; Tue, 13 Jul 1999 12:07:03 +0200 (CEST) Date: Tue, 13 Jul 1999 12:07:02 +0200 From: Martin Cracauer To: Garrett Wollman Cc: Martin Cracauer , freebsd-current@FreeBSD.ORG Subject: Re: Using float emulator on a system with FPU? Message-ID: <19990713120702.A11909@cons.org> References: <19990712112802.A4800@cons.org> <199907121926.PAA02307@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199907121926.PAA02307@khavrinen.lcs.mit.edu>; from Garrett Wollman on Mon, Jul 12, 1999 at 03:26:41PM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In <199907121926.PAA02307@khavrinen.lcs.mit.edu>, Garrett Wollman wrote: > < said: > > > I'm going to work on FreeBSD's floating point support, but I need to > > test my changes on systems using the FPU emulators (non-GPL and GPL). > > I suggested about half a year ago that we should officially desupport > non-FPU configurations in 4.0. Unfortunately, my resolution was > soundly defeated. Is the discussion you mentioned archived somewhere / was it on a public list? I'd like to read about the technical complications that arise from non-FPU support. Another class of machines I'd like to support are 486sx laptops, which make a nice system to run around-the-clock in a home environment. Also, there are many old (donated) PCs in the third world, eastern europe and Hamburg-Altona, a market that may become important, given the number of capable programmers who live there. I don't expect the work I'm going to do (FP exceptions) to be difficult to support on non-FPU machines, so I'm going to get a non-FPU machine to test it. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 13 3:15:35 1999 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 9F11614D70 for ; Tue, 13 Jul 1999 03:15:21 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40353>; Tue, 13 Jul 1999 19:55:41 +1000 Date: Tue, 13 Jul 1999 20:13:31 +1000 From: Peter Jeremy Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") In-reply-to: <199907130501.WAA74171@apollo.backplane.com> To: dillon@apollo.backplane.com Cc: freebsd-current@FreeBSD.ORG Message-Id: <99Jul13.195541est.40353@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: >:I'm not sure there's any reason why you shouldn't. If you changed the >:semantics of a stack segment so that memory addresses below the stack >:pointer were irrelevant, you could implement a small, 0-cycle, on-chip >:stack (that overflowed into memory). > > This would be relatively complex and also results in cache coherency > problems. I agree that there would be additional complexity. I believe that the `on-chip stack cache' part has been implemented on some Forth chips (where stack performance is rather critical), though I don't know whether any of them were MP-capable. My reason for suggesting the change to stack semantics was also to allow cache line allocation without a memory fetch (ie if SP=1000, a push would result in ff0..fff (or fe0..fff) being allocated as a cache line without bothering to fetch ff0..ffb). I'm not sure whether this change would actually provide a measurable improvement though (I suspect that it wouldn't). In this case, I believe cache coherency can be bypassed. The stack segment is only needed on one processor at a time. If there's an interrupt on that CPU, the on-chip stack would flush to memory so that the memory image was consistent. At the minimal end, another way of looking at it would be as an `invisible' branch-and-link register - capable of saving a single return address as long as nothing else was pushed onto the stack. > A solution already exists: It's called branch-and-link, One case where the IBM/360 accidently got it right :-). > but Intel cpu's do not use it because Intel cpu's do not have enough > registers (makes you just want to throw up -- all that MMX junk and they > couldn't add a branch and link register! ). But all that MMX junk makes Doom (or whatever) look much better and that's far more critical :-). > The key with branch-and-link > is that the lowest subroutine level does not have to save/restore the > register, making entry and return two or three times faster then > subroutine calls that make other subroutine calls. I seem to recall reading somewhere that leaf subroutine performance is also fairly important for overall performance (though that may have been before C-compilers learnt how to in-line functions). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 13 3:28:32 1999 Delivered-To: freebsd-current@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id A949614D70 for ; Tue, 13 Jul 1999 03:28:27 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id NAA10088; Tue, 13 Jul 1999 13:23:22 +0300 (EEST) (envelope-from will) To: Alan Cox Cc: current@freebsd.org Subject: Re: Thread stack allocation (was Re: cvs commit: src/lib/libc_r Makefile src/lib/libc_r/uthread pthread_private.h uthread_create.c uthread_gc.c uthread_init.c) References: <199907121853.WAA27876@arc.hq.cti.ru> <19990713023012.K6401@cs.rice.edu.newsgate.clinet.fi> <86673p7y28.fsf@not.demophon.com> <19990713040156.N6401@cs.rice.edu.newsgate.clinet.fi> From: Ville-Pertti Keinonen Date: 13 Jul 1999 13:23:21 +0300 In-Reply-To: Alan Cox's message of "13 Jul 1999 12:04:49 +0300" Message-ID: <863dys97c6.fsf@not.demophon.com> Lines: 30 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alan Cox writes: > Almost all of these vm_map_entry's started out as a single entry that got > fragmented as mprotects were performed by the garbage collector. > Instead of maintaining the page protections as part of the vm_map_entry, > you could separate them into a smaller, specialized data structure that is > attached to the original vm_map_entry. (SVR4, Solaris and Digital > Unix use some variation of an array with an entry per page.) > This way you address the problem by limiting the growth of the vm_map's > list of vm_map_entry's. That might be useful, and in FreeBSD it wouldn't be too hard to avoid breaking APIs (like in in Digital UNIX, where vm_region no longer returns accurate info). But arrays may be costly, VM regions can be large (look at e.g. anonymous mapping arrays in NetBSD's UVM), and you need to keep track of the protection of both mapped and unmapped pages. And this is a special case involving a small class of programs that use the virtual memory system for internal memory management. I'm pretty sure that moderately large numbers of distinct mmapped objects are more common. > In the end, you may want to combine both approaches. I can't say > for sure. I suspect that trees are going to be necessary at some point. Of course it isn't up to me, but common programs may start to require something to be done. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 13 3:39:15 1999 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id B365114D70 for ; Tue, 13 Jul 1999 03:39:11 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40341>; Tue, 13 Jul 1999 20:20:11 +1000 Date: Tue, 13 Jul 1999 20:38:01 +1000 From: Peter Jeremy Subject: LOCK overheads (was Re: "objtrm" problem probably found) To: dillon@apollo.backplane.com, freebsd-current@FreeBSD.ORG Message-Id: <99Jul13.202011est.40341@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG To expand on this morning's table: i386SX-25 486DX2-50 P-133 PII-266 PIII-450 nproc locks mode 0 1950.23 161.17 39.65 26.31 9.21 EMPTY mode 1 3340.59 221.74 71.74 24.45 16.48 1 no tight mode 2 3237.57 222.96 71.18 25.27 23.65 2 no tight mode 3 3367.65 626.28 282.31 153.29 93.02 1 yes tight mode 4 3263.64 627.83 285.58 152.94 160.82 2 yes tight mode 5 9439.15 2168.12 446.16 60.40 37.64 1 no spread mode 6 10231.96 2170.48 467.39 60.16 89.28 2 no spread mode 7 10660.05 3271.40 725.80 153.18 88.32 1 yes spread mode 8 9990.18 2243.56 755.87 155.18 161.08 2 yes spread mode 9 5544.82 623.13 131.31 49.96 ? EMPTY mode 10 7234.97 705.60 174.20 64.81 ? 1 no tight mode 11 7212.14 707.13 178.72 64.87 ? 2 no tight mode 12 7355.46 1075.49 304.74 182.75 ? 1 yes tight mode 13 6956.54 1076.95 327.11 180.21 ? 2 yes tight mode 14 13603.72 2486.87 582.02 100.10 ? 1 no spread mode 15 13443.54 1808.75 543.97 101.13 ? 2 no spread mode 16 13731.94 1587.16 717.31 207.12 ? 1 yes spread mode 17 13379.62 2547.45 800.31 207.70 ? 2 yes spread This suggests that adding a lock prefix to anything more recent than a 386 is fairly expensive. Since the 486 book states `1 clock', but a real example takes more like 20 clocks, it seems that external factors outweigh the stated execution timings. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 13 4:36:49 1999 Delivered-To: freebsd-current@freebsd.org Received: from blues.jpj.net (blues.jpj.net [204.97.17.146]) by hub.freebsd.org (Postfix) with ESMTP id 3FA7214BCF for ; Tue, 13 Jul 1999 04:36:46 -0700 (PDT) (envelope-from trevor@jpj.net) Received: from localhost (trevor@localhost) by blues.jpj.net (right/backatcha) with SMTP id HAA03808; Tue, 13 Jul 1999 07:36:00 -0400 (EDT) Date: Tue, 13 Jul 1999 07:35:55 -0400 (EDT) From: Trevor Johnson To: Alex Zepeda Cc: freebsd-current@FreeBSD.ORG Subject: Re: Using float emulator on a system with FPU? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alex Zepeda wrote: > I've noticed recently, more and more, Linux is moving into the embedded > market quite nicely, and being used on smaller and smaller systems. > FreeBSD OTOH has been focusing (albeit not too successfully) on the higher > end market. OTOOH: http://www.freebsd.org/~picobsd/ __ Trevor Johnson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 13 4:44:50 1999 Delivered-To: freebsd-current@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id B1CFF14C90 for ; Tue, 13 Jul 1999 04:44:48 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id UAA10235; Tue, 13 Jul 1999 20:44:08 +0900 (JST) Message-ID: <378B137C.80DC1E1B@newsguy.com> Date: Tue, 13 Jul 1999 19:22:52 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.6 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Ville-Pertti Keinonen Cc: Alan Cox , current@FreeBSD.ORG Subject: Re: Thread stack allocation (was Re: cvs commit: src/lib/libc_r Makefile src/lib/libc_r/uthread pthread_private.h uthread_create.c uthread_gc.c uthread_init.c) References: <199907121853.WAA27876@arc.hq.cti.ru> <19990713023012.K6401@cs.rice.edu.newsgate.clinet.fi> <86673p7y28.fsf@not.demophon.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ville-Pertti Keinonen wrote: > > Modula-3 really appears to be doing something weird, making half of > the entries read-only. A garbage collected language should actually > be capable of doing a better job than a non-gc one. Seems like pretty standard GC technique to me. Mark pages read-only to reduce the search space for unreferenced data. -- 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-current" in the body of the message From owner-freebsd-current Tue Jul 13 5:40:47 1999 Delivered-To: freebsd-current@freebsd.org Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (Postfix) with ESMTP id F1F8814FD6 for ; Tue, 13 Jul 1999 05:40:39 -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 OAA08327 for ; Tue, 13 Jul 1999 14:40:35 +0200 (MET DST) Date: Tue, 13 Jul 1999 14:40:32 +0200 (MET DST) From: Nick Hibma X-Sender: n_hibma@elect8 Reply-To: Nick Hibma To: FreeBSD current mailing list Subject: PR with patch, any takers? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [PATCH] mountd(8) can apply flags to wrong filesystem [Includes a patch, patch looks like it applies to mountd.c from current] Description When mountd(8) receives a HUP signal, it stops all NFS exporting of filesystems, and then passes the export rules from /etc/exports via a number of mount(2) invocations. In order to handle cases where the path listed in /etc/exports is not the real mount point, mountd repeatedly removes the last path component until the mount call succeeds. Due to insuffient error checking, mountd can miss the real mount point, and apply the flags from a mounted filesystem to the underlying one. In the case we have seen, a forgotten entry in /etc/exports resulted in mountd setting the nodev flag on / every time mountd was sent a HUP signal. Any takers for it? http://www.freebsd.org/cgi/query-pr.cgi?pr=7872 Cheers, Nick -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 13 5:51:27 1999 Delivered-To: freebsd-current@freebsd.org Received: from trinity.radio-do.de (trinity.Radio-do.de [193.101.164.3]) by hub.freebsd.org (Postfix) with ESMTP id DA1E914FD6 for ; Tue, 13 Jul 1999 05:51:18 -0700 (PDT) (envelope-from fn@trinity.radio-do.de) Received: (from fn@localhost) by trinity.radio-do.de (8.9.3/8.9.1) id OAA63058; Tue, 13 Jul 1999 14:49:51 +0200 (CEST) (envelope-from fn) To: Doug Rabson Cc: freebsd-current@FreeBSD.ORG Subject: Re: Just the kind of news we needed... References: From: Frank Nobis Date: 13 Jul 1999 14:49:50 +0200 In-Reply-To: Doug Rabson's message of "Mon, 12 Jul 1999 20:27:35 +0100 (BST)" Message-ID: Lines: 41 User-Agent: Gnus/5.070093 (Pterodactyl Gnus v0.93) XEmacs/21.1 (20 Minutes to Nikko) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug Rabson writes: > On Mon, 12 Jul 1999 mestery@visi.com wrote: > > > Hi, > > > > On Mon, 12 Jul 1999, Scott Michel wrote: > > > > > If you haven't /.'d today, there's a news article purporting that > > > FreeBSD can be exploited via kernel modules: > > > > > > > > > http://thc.pimmel.com/ > > > > > I actually found the article a very good source of documentation on > > programming loadable modules for FreeBSD. Granted, I'm not sure of it's > > accuracy, but it was a worthwhile read for someone like myself who has > > only coded LKMs for Linux. Very interesting. > > I just read through it and it is a nice tutorial on how the module system > works. I can't see it as an exploit though - you have to be root first to > load any code. That is correct. First you have to be root at all, to get some modules loaded. Afterwards you can prepare a system in a way that no one will see, that ther are no backdors installed deep in the kernel. A malicious system adminstrator can himself open every door for later user, when the time comes when he is no more sysadm. Image what one can do with that kind of backdoors. Otherwise the technics described in the article can be used to avoid that kind of insult. At least make it no so easy as it is just now. Just my 2p. Regards, Frank -- Frank Nobis Email: PGP AVAILABLE Landgrafenstr. 130 dg3dcn http://www.radio-do.de/~fn/ 44139 Dortmund Powered by SMP FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 13 5:52:38 1999 Delivered-To: freebsd-current@freebsd.org Received: from kaly.iqm.unicamp.br (d2p67.mpcnet.com.br [200.246.29.195]) by hub.freebsd.org (Postfix) with ESMTP id 22C3014FD6 for ; Tue, 13 Jul 1999 05:52:07 -0700 (PDT) (envelope-from vazquez@iqm.unicamp.br) Received: by kaly.iqm.unicamp.br (Postfix, from userid 105) id 77B9C1DD; Tue, 13 Jul 1999 00:51:58 -0300 (EST) Date: Tue, 13 Jul 1999 00:51:58 -0300 From: Pedro A M Vazquez To: Nik Clayton Cc: "David E. Cross" , mestery@visi.com, Scott Michel , freebsd-current@FreeBSD.ORG Subject: Re: Just the kind of news we needed... Message-ID: <19990713005157.A26497@kaly.iqm.unicamp.br> References: <199907121841.OAA86709@cs.rpi.edu> <19990712232342.B19068@catkin.nothing-going-on.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <19990712232342.B19068@catkin.nothing-going-on.org>; from Nik Clayton on Mon, Jul 12, 1999 at 11:23:42PM +0100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mon, Jul 12, 1999 at 11:23:42PM +0100, Nik Clayton wrote: > On Mon, Jul 12, 1999 at 02:41:32PM -0400, David E. Cross wrote: > > > > http://thc.pimmel.com/ > > > > > > > I actually found the article a very good source of documentation on > > > programming loadable modules for FreeBSD. Granted, I'm not sure of it's > > > accuracy, but it was a worthwhile read for someone like myself who has > > > only coded LKMs for Linux. Very interesting. > > > > Agreed. Perhaps we could (with the author's permission) import this a bit > > into the documentation project? > > He he. > > I'll contact them tomorrow, and see what I can work out. > yep the tutorial about kld is very good, the kewl topics about backdoors are as harmfull as building a trojaned kernel or tcpd wrapper. This article is like one of the sekure.org "teaching" how to "break" ssh after you got root on a given machine using ktrace. Not he's wrong but even Mitnick had beter ideas on VMS macines about trojaning PGP 5 years ago. Anyway while the article is very-very good it seems the markting was more slashdot oriented than security itself, I can see that "unknow user" at kernel@tdnet.com.br removing freebsd from his servers due freebsd being unsecure. I think articles like this one should be part of FBSD documentation not only as a digest but also with an url to the original paper, we had other good papers on *BSD internals in phrack and other uground publications that never got to www.freebsd.org > 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-current" in the body of the message > -- Whenever you find that you are on the side of the majority, it is time to reform. -- Mark Twain To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 13 6: 2:35 1999 Delivered-To: freebsd-current@freebsd.org Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (Postfix) with ESMTP id 069D914CA8 for ; Tue, 13 Jul 1999 06:02:30 -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 PAA09824 for ; Tue, 13 Jul 1999 15:02:01 +0200 (MET DST) Date: Tue, 13 Jul 1999 15:02:00 +0200 (MET DST) From: Nick Hibma X-Sender: n_hibma@elect8 Reply-To: Nick Hibma To: FreeBSD current mailing list Subject: PR with patch, any takers? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [PATCH] tempnam.c security problems [Includes a patch, patch applies to tempnam.c from current] Description The tempnam function has the security problem of trusting an environment variable, even when running setuid. While it might seem that using this function in a setuid/setgid program is insecure in and of itself due to the potential race condition between finding a file name and creating the file, open with the CREAT _and_ EXCL flags set solves this problem, at least for local filesystems. (Yes, the mkstemp function should be used instead, but software ported in from other OSes may not use this function.) The difficulty with trusting a user-set directory when this method (setting CREAT and EXCL) is used is that the directory in question could have permissions allowing the user to replace the file - a problem if the program closes the file then reopens it at a later point (perhaps to conserve file descriptors). It also poses the confidentiality hazard that the directory may be set to be in a msdos filesystem, so that the user can then examine the contents of the file. Any takers? The PR has already been marked suspended by phk, but never worked on. http://www.freebsd.org/cgi/query-pr.cgi?pr=6773 Nick -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 13 7:25:25 1999 Delivered-To: freebsd-current@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 59C2115030 for ; Tue, 13 Jul 1999 07:25:23 -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 KAA77332; Tue, 13 Jul 1999 10:21:52 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 13 Jul 1999 10:21:52 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Peter Jeremy Cc: cracauer@cons.org, dfr@nlsystems.com, freebsd-current@FreeBSD.org Subject: Re: Using float emulator on a system with FPU? In-Reply-To: <99Jul13.191120est.40336@border.alcanet.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, Peter Jeremy wrote: > Doug Rabson wrote: > >You might consider looking at the fp emulator which I wrote for the alpha. > >It should be accurate (I tested against the fpu on an x86) and contains > >test harness code which can be used to play with it on both x86 and alpha. > > Anyone interested in working on FP emulation (or checking the > shortcuts DEC made when then designed the Alpha) might like to > check out : fetch: ucbtest.tar.gz: www.netlib.org: HTTP server returned error code 404 Where's it really at? > > UCBTEST is a suite of programs for testing certain difficult cases of > IEEE 754 floating-point arithmetic. Some of the difficult test cases are > obtained from number-theoretic algorithms developed by Turing Award winner > Prof. W. Kahan, Department of Electrical Engineering and Computer Science, > University of California, Berkeley, as part of ongoing research into test > methods for computer arithmetic. > > Peter > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" 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-current" in the body of the message From owner-freebsd-current Tue Jul 13 7:30:55 1999 Delivered-To: freebsd-current@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 831771516B for ; Tue, 13 Jul 1999 07:30: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 KAA77435; Tue, 13 Jul 1999 10:28:05 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 13 Jul 1999 10:28:05 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Peter Jeremy Cc: dillon@apollo.backplane.com, freebsd-current@FreeBSD.org Subject: Re: LOCK overheads (was Re: "objtrm" problem probably found) In-Reply-To: <99Jul13.202011est.40341@border.alcanet.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Here's another data point: {"/home/green"}$ cc -O2 locktests.c -o locktests {"/home/green"}$ ./locktests mode 0 10.92 ns/loop nproc=1 lcks=EMPTY mode 1 17.99 ns/loop nproc=1 lcks=no mode 2 17.97 ns/loop nproc=2 lcks=no mode 3 166.33 ns/loop nproc=1 lcks=yes mode 4 167.91 ns/loop nproc=2 lcks=yes mode 5 42.16 ns/loop nproc=1 lcks=no mode 6 41.60 ns/loop nproc=2 lcks=no mode 7 188.86 ns/loop nproc=1 lcks=yes mode 8 191.56 ns/loop nproc=2 lcks=yes This is a K6-2 350. Locks are pretty expensive on them. 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-current" in the body of the message From owner-freebsd-current Tue Jul 13 8: 8:54 1999 Delivered-To: freebsd-current@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 0AF0315317 for ; Tue, 13 Jul 1999 08:08:33 -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 RAA07925 for freebsd-current@FreeBSD.ORG; Tue, 13 Jul 1999 17:08:29 +0200 (CEST) (envelope-from olli) Date: Tue, 13 Jul 1999 17:08:29 +0200 (CEST) From: Oliver Fromme Message-Id: <199907131508.RAA07925@dorifer.heim3.tu-clausthal.de> To: freebsd-current@FreeBSD.ORG Subject: Permissions on current.freebsd.org Organization: Administration Heim 3 Reply-To: freebsd-current@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-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Something broke with the -current snapshots generation on current.freebsd.org, probably a few days ago. The permissions aren't set appropriately: [...] drwxr-xr-x 19 root 0 1024 Jul 5 12:12 4.0-19990705-CURRENT drwxr-xr-x 19 root 0 1024 Jul 8 12:38 4.0-19990708-CURRENT drwxr-xr-x 19 root 0 1024 Jul 9 12:37 4.0-19990709-CURRENT drwx------ 19 root 0 1024 Jul 11 12:33 4.0-19990711-CURRENT drwx------ 19 root 0 1024 Jul 12 12:42 4.0-19990712-CURRENT drwx------ 19 root 0 1024 Jul 13 12:38 4.0-19990713-CURRENT 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-current" in the body of the message From owner-freebsd-current Tue Jul 13 8:55:31 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 157311531E; Tue, 13 Jul 1999 08:55:28 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id IAA78738; Tue, 13 Jul 1999 08:55:28 -0700 (PDT) (envelope-from dillon) Date: Tue, 13 Jul 1999 08:55:28 -0700 (PDT) From: Matthew Dillon Message-Id: <199907131555.IAA78738@apollo.backplane.com> To: "Brian F. Feldman" Cc: Peter Jeremy , freebsd-current@FreeBSD.org Subject: Re: LOCK overheads (was Re: "objtrm" problem probably found) References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Here's another data point: :{"/home/green"}$ cc -O2 locktests.c -o locktests :{"/home/green"}$ ./locktests :mode 0 10.92 ns/loop nproc=1 lcks=EMPTY :mode 1 17.99 ns/loop nproc=1 lcks=no :mode 2 17.97 ns/loop nproc=2 lcks=no :mode 3 166.33 ns/loop nproc=1 lcks=yes :mode 4 167.91 ns/loop nproc=2 lcks=yes :mode 5 42.16 ns/loop nproc=1 lcks=no :mode 6 41.60 ns/loop nproc=2 lcks=no :mode 7 188.86 ns/loop nproc=1 lcks=yes :mode 8 191.56 ns/loop nproc=2 lcks=yes : :This is a K6-2 350. Locks are pretty expensive on them. : : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ Wow, now that *is* expensive! The K6 must be implementing it in microcode for it to be that bad. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 13 10:41: 6 1999 Delivered-To: freebsd-current@freebsd.org Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (Postfix) with ESMTP id 0D1F814E0B; Tue, 13 Jul 1999 10:40: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 TAA14611; Tue, 13 Jul 1999 19:27:11 +0200 (MET DST) Received: (from wilko@localhost) by yedi.iaf.nl (8.9.3/8.9.3) id AAA04241; Tue, 13 Jul 1999 00:18:06 +0200 (CEST) (envelope-from wilko) From: Wilko Bulte Message-Id: <199907122218.AAA04241@yedi.iaf.nl> Subject: Re: Using float emulator on a system with FPU? In-Reply-To: <21270.931811581@critter.freebsd.dk> from Poul-Henning Kamp at "Jul 12, 1999 10:33: 1 pm" To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Tue, 13 Jul 1999 00:18:06 +0200 (CEST) Cc: green@FreeBSD.ORG, wollman@khavrinen.lcs.mit.edu, cracauer@cons.org, freebsd-current@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-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Poul-Henning Kamp wrote ... > In message , "Bria > > >> I suggested about half a year ago that we should officially desupport > >> non-FPU configurations in 4.0. Unfortunately, my resolution was > >> soundly defeated. > > > >Why shouldn't we? Noone uses machines without FPUs anymore. What non-ancient > >CPU doesn't have an FPU? And we're talking about the i386 family here... > > A lot of 386 machines are being built into places where people will > never know they are. We should not kill that market. www.tcja.nl was an ancient 386/40 until a couple of months ago. Low traffic Web servers don't (generally) need an FPU. No/low budget outfits run hardware most people on this list would give away for free (or thrash altogether). It is a M$-ism to discard a complete line of machines with each next release... Just my Dfl 0.02 -- | / 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-current" in the body of the message From owner-freebsd-current Tue Jul 13 10:57: 5 1999 Delivered-To: freebsd-current@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 BB0E215158 for ; Tue, 13 Jul 1999 10:57:00 -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 TAA12578 for freebsd-current@FreeBSD.ORG; Tue, 13 Jul 1999 19:56:50 +0200 (CEST) (envelope-from olli) Date: Tue, 13 Jul 1999 19:56:50 +0200 (CEST) From: Oliver Fromme Message-Id: <199907131756.TAA12578@dorifer.heim3.tu-clausthal.de> To: freebsd-current@FreeBSD.ORG Subject: Re: Using float emulator on a system with FPU? Organization: Administration Heim 3 Reply-To: freebsd-current@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-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wilko Bulte wrote in list.freebsd-current: > As Poul-Henning Kamp wrote ... > > In message , "Bria > > > > >> I suggested about half a year ago that we should officially desupport > > >> non-FPU configurations in 4.0. Unfortunately, my resolution was > > >> soundly defeated. > > > > > >Why shouldn't we? Noone uses machines without FPUs anymore. What non-ancient > > >CPU doesn't have an FPU? And we're talking about the i386 family here... > > > > A lot of 386 machines are being built into places where people will > > never know they are. We should not kill that market. > > www.tcja.nl was an ancient 386/40 until a couple of months ago. Low > traffic Web servers don't (generally) need an FPU. > No/low budget outfits run hardware most > people on this list would give away for free (or thrash altogether). > > It is a M$-ism to discard a complete line of machines with each next > release... I agree 100%. My "mobile emergency terminal" is an old 486SX notebook with 3.5 Mbyte RAM and 120 Mbyte HD. It works perfectly well for what I use it for. And I'd hate to have to keep an "old" release around for it while upgrading all other boxes. (Remember, 486SX processors don't have FPUs either.) Regards Oliver PS: No, I'm not doing "make world" on it. (In fact, I removed the compiler toolchain to save HD space.) -- 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-current" in the body of the message From owner-freebsd-current Tue Jul 13 11:11:19 1999 Delivered-To: freebsd-current@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id D326915034 for ; Tue, 13 Jul 1999 11:11: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 OAA86254; Tue, 13 Jul 1999 14:10:45 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Tue, 13 Jul 1999 14:10:45 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Matthew Dillon Cc: Peter Jeremy , freebsd-current@FreeBSD.org Subject: Re: LOCK overheads (was Re: "objtrm" problem probably found) In-Reply-To: <199907131555.IAA78738@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jul 1999, Matthew Dillon wrote: > > :Here's another data point: > :{"/home/green"}$ cc -O2 locktests.c -o locktests > :{"/home/green"}$ ./locktests > :mode 0 10.92 ns/loop nproc=1 lcks=EMPTY > :mode 1 17.99 ns/loop nproc=1 lcks=no > :mode 2 17.97 ns/loop nproc=2 lcks=no > :mode 3 166.33 ns/loop nproc=1 lcks=yes > :mode 4 167.91 ns/loop nproc=2 lcks=yes > :mode 5 42.16 ns/loop nproc=1 lcks=no > :mode 6 41.60 ns/loop nproc=2 lcks=no > :mode 7 188.86 ns/loop nproc=1 lcks=yes > :mode 8 191.56 ns/loop nproc=2 lcks=yes > : > :This is a K6-2 350. Locks are pretty expensive on them. > : > : Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ > > Wow, now that *is* expensive! The K6 must be implementing it in > microcode for it to be that bad. Sometimes you wonder what they're doing with that RISC86 translation. I have a feeling it's overhead for the OpenPIC implementation, really. > > -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-current" in the body of the message From owner-freebsd-current Tue Jul 13 13:33:31 1999 Delivered-To: freebsd-current@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 2662814E4B for ; Tue, 13 Jul 1999 13:33:29 -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 NAA62848 for ; Tue, 13 Jul 1999 13:31:28 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: freebsd-current@FreeBSD.ORG Subject: Re: Permissions on current.freebsd.org In-reply-to: Your message of "Tue, 13 Jul 1999 17:08:29 +0200." <199907131508.RAA07925@dorifer.heim3.tu-clausthal.de> Date: Tue, 13 Jul 1999 13:31:28 -0700 Message-ID: <62845.931897888@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is most odd - I will go investigate this. Absolutely nothing has changed with the build scripts recently which is what makes this so weird.. - Jordan > Something broke with the -current snapshots generation on > current.freebsd.org, probably a few days ago. The permissions > aren't set appropriately: > > [...] > drwxr-xr-x 19 root 0 1024 Jul 5 12:12 4.0-19990705-CURRENT > drwxr-xr-x 19 root 0 1024 Jul 8 12:38 4.0-19990708-CURRENT > drwxr-xr-x 19 root 0 1024 Jul 9 12:37 4.0-19990709-CURRENT > drwx------ 19 root 0 1024 Jul 11 12:33 4.0-19990711-CURRENT > drwx------ 19 root 0 1024 Jul 12 12:42 4.0-19990712-CURRENT > drwx------ 19 root 0 1024 Jul 13 12:38 4.0-19990713-CURRENT > > 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-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 13 13:34:43 1999 Delivered-To: freebsd-current@freebsd.org Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (Postfix) with ESMTP id F0EA414E4B for ; Tue, 13 Jul 1999 13:34:41 -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 XAA04654; Mon, 12 Jul 1999 23:01:15 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199907130601.XAA04654@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Andrew Reilly" Cc: freebsd-current@FreeBSD.ORG Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") In-reply-to: Your message of "Tue, 13 Jul 1999 16:00:05 +1000." <19990713160005.B94421@gurney.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 12 Jul 1999 23:01:15 -0700 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, Jul 12, 1999 at 10:38:03PM -0700, Mike Smith wrote: > > I said: > > > than indirect function calls on some architectures: inline > > > branched code. So you still have a global variable selecting > > > locked/non-locked, but it's a boolean, rather than a pointer. > > > Your atomic macros are then { if (atomic_lock) asm("lock;foo"); > > > else asm ("foo"); } > > > > This requires you to have all the methods present at compile time, > > which defeats the entire purpose of dynamic method loading. > > Pardon? I didn't see a discussion of dynamic loading anywhere > here. We were referring to tiny inlined assembly language routines. > The existing implementation is #defines in a C header file. Uh, no, I was asking about the overhead involved in indirect function calls specifically because there are instances where fast indirect methods would allow us to greatly improve the generality of parts of the FreeBSD kernel and modules. This includes code where we are currently using compile-time defines that require us to trade performance for generality. -- \\ 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-current" in the body of the message From owner-freebsd-current Tue Jul 13 13:45:54 1999 Delivered-To: freebsd-current@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id 8337C14BE4 for ; Tue, 13 Jul 1999 13:45:47 -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 WAA10365 for freebsd-current@FreeBSD.org; Tue, 13 Jul 1999 22:45:03 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id CBB8187AE; Tue, 13 Jul 1999 22:01:25 +0200 (CEST) (envelope-from roberto) Date: Tue, 13 Jul 1999 22:01:25 +0200 From: Ollivier Robert To: freebsd-current@FreeBSD.org Subject: Re: LOCK overheads (was Re: "objtrm" problem probably found) Message-ID: <19990713220125.A18250@keltia.freenix.fr> Mail-Followup-To: freebsd-current@FreeBSD.org References: <199907131555.IAA78738@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.95.5i In-Reply-To: <199907131555.IAA78738@apollo.backplane.com>; from Matthew Dillon on Tue, Jul 13, 1999 at 08:55:28AM -0700 X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5468 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Matthew Dillon: > Wow, now that *is* expensive! The K6 must be implementing it in > microcode for it to be that bad. K6-200: 244 [21:57] roberto@keltia:src/C> ./locktest 0 ... empty 26.84 ns/loop 1proc 22.62 ns/loop 2proc 22.64 ns/loop empty w/locks 17.58 ns/loop 1proc w/locks 288.28 ns/loop 2proc w/locks 288.16 ns/loop It hurts :( -- 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-current" in the body of the message From owner-freebsd-current Tue Jul 13 13:58:25 1999 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 77DBE14DD2; Tue, 13 Jul 1999 13:58:19 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40325>; Wed, 14 Jul 1999 06:40:04 +1000 Date: Wed, 14 Jul 1999 06:57:53 +1000 From: Peter Jeremy Subject: Re: Using float emulator on a system with FPU? In-reply-to: To: green@FreeBSD.ORG Cc: cracauer@cons.org, dfr@nlsystems.com, freebsd-current@FreeBSD.ORG Message-Id: <99Jul14.064004est.40325@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Brian F. Feldman" wrote: >On Tue, 13 Jul 1999, Peter Jeremy wrote: >> Anyone interested in working on FP emulation (or checking the >> shortcuts DEC made when then designed the Alpha) might like to >> check out : > >fetch: ucbtest.tar.gz: www.netlib.org: HTTP server returned error code 404 >Where's it really at? It looks like it's moved sometime in the last year-and-a-bit. Some rummaging around www.netlib.org produces . It should also be fetchable via FTP, but I don't know the URL. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 13 14:48:18 1999 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id D0EBA14DD2; Tue, 13 Jul 1999 14:48:10 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40325>; Wed, 14 Jul 1999 07:28:23 +1000 Date: Wed, 14 Jul 1999 07:46:13 +1000 From: Peter Jeremy Subject: Re: LOCK overheads (was Re: "objtrm" problem probably found) In-reply-to: <199907131555.IAA78738@apollo.backplane.com> To: dillon@apollo.backplane.com Cc: freebsd-current@FreeBSD.ORG, green@FreeBSD.ORG Message-Id: <99Jul14.072823est.40325@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: >:mode 1 17.99 ns/loop nproc=1 lcks=no >:mode 3 166.33 ns/loop nproc=1 lcks=yes ... >:This is a K6-2 350. Locks are pretty expensive on them. > Wow, now that *is* expensive! The K6 must be implementing it in > microcode for it to be that bad. I wouldn't be surprised if lock prefixes did result in microcode execution. As I stated yesterday, I don't believe locked instructions are implemented frequently enough to warrant special handling, and are therefore likely to be implemented in whichever way need the least chip area. Since you need to be able to track and mark the memory references associated with the instruction, the cheapest implementation (in terms of dedicated chip area) is likely to be something like: wait until all currently executing instructions are complete, wait until all pending memory writes are complete (at least to L1 cache), assert the lock pin and execute RMW instuction without allowing any other instructions to commence, deassert lock pin. This is (of course) probably the worst case as far as execution time as seen by that CPU - though it's not far off optimal as seen by other CPUs. (`Assert lock pin' should also be mapped into a `begin locked memory reference' using whatever cache coherency protocol is being used). I'm not saying that you can't implement a locked RMW sequence a lot better, but until the chip architects decide that the performance is an issue, they aren't likely to spend any silicon on it. The big IA-32 market is UP systems running games - and locked RMW instructions don't affect this market. Intel see the high-end of the market (where SMP and hence locked RMW is more of an issue) moving to Merced. This suggests that it's unlikely that the IA-32 will ever acquire a decent lock capability (though at least the PIII is no worse than the PII). That said, the above timings make a lock prefix cost over 50 core clocks (or 15 bus clocks) - even microcode couldn't be that bad. My other timings (core/bus cycles) were: 486DX2: 20/10, Pentium: 28/7, P-II: 34/8.5, P-III 34/7.5. I suspect that these timings are a combination of inefficient on-chip implementation of the lock prefix (see above for my reasoning behind this), together with poor off-chip handling of locked cycles. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 13 15:16:53 1999 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id DCFC1152F7; Tue, 13 Jul 1999 15:16: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 QAA21557; Tue, 13 Jul 1999 16:15:43 -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 QAA50028; Tue, 13 Jul 1999 16:14:33 -0600 (MDT) Message-Id: <199907132214.QAA50028@harmony.village.org> To: Greg Lehey Subject: Re: When will -CURRENT support PCMCIA modems again? Cc: FreeBSD mobile Mailing List , FreeBSD current users In-reply-to: Your message of "Mon, 12 Jul 1999 14:24:52 +0930." <19990712142452.F21403@freebie.lemis.com> References: <19990712142452.F21403@freebie.lemis.com> Date: Tue, 13 Jul 1999 16:14:33 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <19990712142452.F21403@freebie.lemis.com> Greg Lehey writes: : I've just updated my laptop from 3.2-RELEASE to 4.0-CURRENT, and I : find that PCMCIA modems (sio) are no longer supported. I'm playing : around with it to get it to work, but so far I've just managed to get : panics out of sioprobe. Before I continue with this: is anybody else : working on it? If so, I'll get out of your way. I think I have an idea on how to make this work, but have not had the time to make it work. I've taken the day off (mostly because my brother was in town through today) and am trying to get my system working again with the current pccard code.... Once that happens, it should be a couple hours to maybe having an interesting kludge to make new-bus drivers have pccard attachments.... if I'm lucky... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 13 15:23:56 1999 Delivered-To: freebsd-current@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 1734315073 for ; Tue, 13 Jul 1999 15:23:52 -0700 (PDT) (envelope-from jmz@FreeBSD.org) Received: (from jmz@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id PAA42483; Tue, 13 Jul 1999 15:23:03 -0700 (PDT) (envelope-from jmz@FreeBSD.org) Date: Tue, 13 Jul 1999 15:23:03 -0700 (PDT) Message-Id: <199907132223.PAA42483@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: jmz set sender to jmz@freefall.freebsd.org using -f From: Jean-Marc Zucconi To: freebsd-current@FreeBSD.ORG Subject: panic in -current (trap 12) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is with a current kernel - a kernel built 2 days ago runs ok. The system crashes at boot, just after the disk checks. I don't have a core dump, only the message printed on screen: fault code: supervisor read , page not present instruction pointer: 0xc0175396 from my kernel: c0175234 t vfs_setdirty c0175360 T getblk c01756f8 T geteblk c017573c T allocbuf This is on a SMP/softupdates system. Jean-Marc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Tue Jul 13 23:56: 5 1999 Delivered-To: freebsd-current@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-current@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-current" in the body of the message From owner-freebsd-current Wed Jul 14 0: 4:13 1999 Delivered-To: freebsd-current@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-current@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-current" in the body of the message From owner-freebsd-current Wed Jul 14 9:49:48 1999 Delivered-To: freebsd-current@freebsd.org Received: from mail.palmerharvey.co.uk (mail.palmerharvey.co.uk [62.172.109.58]) by hub.freebsd.org (Postfix) with ESMTP id E49F814C97 for ; Wed, 14 Jul 1999 09:49:36 -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 ; Wed, 14 Jul 1999 17:47:16 +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 3WRWCZJD; Wed, 14 Jul 1999 17:48:05 +0100 Received: from dom by voodoo.pandhm.co.uk with local (Exim 2.10 #1) id 114SC3-00006I-00 for current@freebsd.org; Wed, 14 Jul 1999 17:47:39 +0100 Date: Wed, 14 Jul 1999 17:47:39 +0100 To: current@freebsd.org Subject: panic: zone: entry in free Message-Id: <19990714174739.A324@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-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've been getting this panic when I've installed new kernels the last couple of times. The panic is occuring when I have freshly booted the system with a new kernel and logged on for the first time. It appears to occur at the point at which I start fetchmail in my profile, FWIW. BTW: My home directory is mounted over nfsv3,udp from a Solaris2.6 server with amd. I've tried getting rid of amd and it makes no difference. At the moment, I'm having to use a kernel from June 8th, to be able to login... Here's the traceback from ddb: Debugger(0xc01d545b) at Debugger+0x37 panic(0xc01e5339, 0xc6aa6df4, 0xc0152af8, 0x1, 0) at panic+0x74 zerror(0x1, 0, 0xc6aa6f80, 0xffffffff, 0xc0f3b300) at zerror+0x3f namei(0xc6aa6eec, 0, 0xc6aa6f80, 0xffffffff, 0xc6aa6e30) at namei+0xac vn_open(0xc6aa6eec, 0x3, 0, 0xc6558680, 0xc01f572c) at vn_open+0x1eb open(0xc6558680, 0xc6aa6f80, 0xffffffff, 0, 0xffffffff) at open+0xbb syscall(0x2f, 0x2f, 0x2f, 0xffffffff, 0) at syscall+0x182 Xint0x80_syscall() at Xint0x80_syscall+0x26 Does this lot mean anything to anybody? Unfortunately, I can't seem to get a crash dump out of the thing. I've tried doing both "panic" and "continue" from within ddb, and it looks as though the dump is being written to disk, but when it comes back up, nothing. Here's the config file for the kernel that's crashing on me: ------------------------------------------------------------------------ # # VOODOO --- Dom's workstation. A HP Vectra VL. # # $Id: VOODOO,v 1.22 1999/07/13 06:23:14 dom Exp $ # machine "i386" cpu "I686_CPU" ident VOODOO maxusers 32 # Build a debug kernel. makeoptions DEBUG="-g" options DDB # Kernel debugger. options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options "NO_F00F_HACK" options FFS #Berkeley Fast Filesystem options FFS_ROOT options INET #InterNETworking options INVARIANTS options INVARIANT_SUPPORT options KTRACE #kernel tracing options SOFTUPDATES options SYSVMSG options SYSVSEM options SYSVSHM options UCONSOLE #Allow users to grab the console options USER_LDT #Wine. controller isa0 at nexus? controller pci0 at nexus? 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 ## disk wd0 at wdc0 drive 0 flags 0xa0ff ## controller wdc1 at isa? port "IO_WD2" irq 15 ## device wcd0 #IDE CD-ROM # Soren's new atapi stuff... controller ata0 device atadisk0 device atapicd0 # syscons is the default console driver, resembling an SCO console 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? # Mandatory, don't remove device npx0 at nexus? port IO_NPX irq 13 device apm0 at nexus? disable flags 0x31 device sio0 at isa? port "IO_COM1" flags 0x10 irq 4 device sio1 at isa? port "IO_COM2" irq 3 device xl0 # Parallel port bus. controller ppbus0 device lpt0 at ppbus? device plip0 at ppbus? device ppc0 at isa? port? irq 7 pseudo-device loop pseudo-device ether pseudo-device pty 32 pseudo-device bpf 2 pseudo-device snp 2 #Snoop on ttys pseudo-device splash ------------------------------------------------------------------------ And here's the dmesg for the successful kernel that I'm running which is pretty much the same but with a couple more filesystems compiled into it instead of modules. Please let me know if there's any more information I can provide to help with tracking this down... ------------------------------------------------------------------------ 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 #18: Tue Jun 8 05:00:06 BST 1999 root@voodoo.pandhm.co.uk:/usr/src/sys/compile/VOODOO Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II (299.61-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x634 Stepping=4 Features=0x80f9ff real memory = 67108864 (65536K bytes) avail memory = 62611456 (61144K bytes) Preloaded elf kernel "kernel.goodnfs" at 0xc028c000. Preloaded elf module "if_tun.ko" at 0xc028c0a4. Pentium Pro MTRR support enabled, default memory type is uncacheable npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard pci0: on pcib0 Correcting Natoma config for non-SMP Correcting Natoma config for non-SMP chip0: at device 0.0 on pci0 isab0: at device 4.0 on pci0 ata-pci0: at device 4.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x01f0 irq 14 on ata-pci0 ata1 at 0x0170 irq 15 on ata-pci0 xl0: <3Com 3c905-TX Fast Etherlink XL> irq 11 at device 7.0 on pci0 xl0: Ethernet address: 00:60:08:76:7d:56 xl0: autoneg complete, link status good (full-duplex, 100Mbps) vga-pci0: at device 13.0 on pci0 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 ata-isa1: already registered as ata0 ata-isa2: already registered as ata0 atkbdc0: at port 0x60-0x6f on isa0 atkbd0: irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model MouseMan+, device ID 0 vga0: on isa0 sc0: on isa0 sc0: VGA color <16 virtual consoles, flags=0x0> 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 on isa0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold plip0: on ppbus 0 lpt0: on ppbus 0 lpt0: Interrupt-driven port ata1: unwanted interrupt 1 status = ff ata0: master: setting up WDMA2 mode on PIIX3/4 chip OK ad0: ATA-3 disk at ata0 as master ad0: 4104MB (8405775 sectors), 8895 cyls, 15 heads, 63 S/T, 512 B/S ad0: piomode=4, dmamode=2, udmamode=2 ad0: 16 secs/int, 0 depth queue, DMA mode acd0: CDROM drive at ata1 as master acd0: drive speed 1779 - 4134KB/sec, 128KB cache acd0: supported read types: CD-R, CD-RW, CD-DA, packet track acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked changing root device to wd0s2a WARNING: / was not properly dismounted ------------------------------------------------------------------------ -- 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-current" in the body of the message From owner-freebsd-current Wed Jul 14 19:14:25 1999 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 5C002154FF for ; Wed, 14 Jul 1999 19:14: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 UAA26395; Wed, 14 Jul 1999 20:14: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 UAA60347; Wed, 14 Jul 1999 20:14:19 -0600 (MDT) Message-Id: <199907150214.UAA60347@harmony.village.org> To: Mike Smith Subject: Re: Using float emulator on a system with FPU? Cc: freebsd-current@FreeBSD.org In-reply-to: Your message of "Mon, 12 Jul 1999 19:25:26 PDT." <199907130225.TAA03396@dingo.cdrom.com> References: <199907130225.TAA03396@dingo.cdrom.com> Date: Wed, 14 Jul 1999 20:14:19 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199907130225.TAA03396@dingo.cdrom.com> Mike Smith writes: : Lots (and I mean _lots_) of embedded systems use fpu-less 386 and 486 : cores. Alienating users of these systems would be a dumb idea. Without commenting on the need to have an emulator in the kernel, doesn't -msoft-float work faster? Or is that a MIPS only thing... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 14 19:50: 3 1999 Delivered-To: freebsd-current@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id C1F271548F for ; Wed, 14 Jul 1999 19:49:45 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40355>; Thu, 15 Jul 1999 12:29:42 +1000 Date: Thu, 15 Jul 1999 12:47:36 +1000 From: Peter Jeremy Subject: Re: Using float emulator on a system with FPU? In-reply-to: <199907150214.UAA60347@harmony.village.org> To: imp@village.org Cc: freebsd-current@FreeBSD.ORG Message-Id: <99Jul15.122942est.40355@border.alcanet.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Warner, >Without commenting on the need to have an emulator in the kernel, >doesn't -msoft-float work faster? Yes it does. The kernel has to emulate an 80x87, giving you the following sequence: a) trap to kernel b) decode FP instruction c) fetch operands - possibly including copyin() d) perform operation [this is the only bit the soft-FP code does] e) store result - possibly including copyout() f) return from trap The trap/decode/copyin()/copyout()/rtt are all non-trivial. > Or is that a MIPS only thing... It's documented under i386 as well. There is a note that gcc can still emit some hardware FP instructions (to return FP values on the 80x87 stack), but this can be prevented with -mno-fp-ret-in-387 The disadvantage of soft-FP is that you wind up with lots of different libc's - one for h/w FP, one for soft FP and maybe a few more for different FP formats (eg FFP on M68K, or a `cut-a-few-corners-but- give-almost-the-correct-answer-much-faster' IEEE, or single-precision only IEEE). This is less of a problem in an embedded system, where the FP requirements (if needed at all) are well defined. (The problem is that using the wrong library generally doesn't show up until run-time - when the results aren't what you expected). Note that the GNU newlib defines `iprintf()' (and family) as an integer-only printf() to avoid pulling in all the FP overhead when it's not really needed. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Wed Jul 14 21: 9:36 1999 Delivered-To: freebsd-current@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id 42E78154C6 for ; Wed, 14 Jul 1999 21:09:33 -0700 (PDT) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id AAA25885; Thu, 15 Jul 1999 00:08:07 -0400 (EDT) (envelope-from luoqi) Date: Thu, 15 Jul 1999 00:08:07 -0400 (EDT) From: Luoqi Chen Message-Id: <199907150408.AAA25885@lor.watermarkgroup.com> To: Dom.Mitchell@palmerharvey.co.uk, current@FreeBSD.ORG Subject: Re: panic: zone: entry in free Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I've been getting this panic when I've installed new kernels the last > couple of times. The panic is occuring when I have freshly booted the > system with a new kernel and logged on for the first time. It appears > to occur at the point at which I start fetchmail in my profile, FWIW. > Get rid of INVARIANTS in your config file. -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 15 0:51:21 1999 Delivered-To: freebsd-current@freebsd.org Received: from mail.palmerharvey.co.uk (mail.palmerharvey.co.uk [62.172.109.58]) by hub.freebsd.org (Postfix) with ESMTP id B0693152BC for ; Thu, 15 Jul 1999 00:51:17 -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 08:50:40 +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 3WRWCZSF; Thu, 15 Jul 1999 08:51:28 +0100 Received: from dom by voodoo.pandhm.co.uk with local (Exim 2.10 #1) id 114gIK-000CVC-00; Thu, 15 Jul 1999 08:51:04 +0100 Date: Thu, 15 Jul 1999 08:51:03 +0100 To: Luoqi Chen Cc: Dom.Mitchell@palmerharvey.co.uk, current@FreeBSD.ORG Subject: Re: panic: zone: entry in free Message-Id: <19990715085103.A48036@palmerharvey.co.uk> References: <199907150408.AAA25885@lor.watermarkgroup.com> MIME-Version: 1.0 X-Mailer: Mutt 0.95.6i In-Reply-To: <199907150408.AAA25885@lor.watermarkgroup.com>; from Luoqi Chen on Thu, Jul 15, 1999 at 12:08:07AM -0400 From: Dominic Mitchell Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 15, 1999 at 12:08:07AM -0400, Luoqi Chen wrote: > > I've been getting this panic when I've installed new kernels the last > > couple of times. The panic is occuring when I have freshly booted the > > system with a new kernel and logged on for the first time. It appears > > to occur at the point at which I start fetchmail in my profile, FWIW. > > > Get rid of INVARIANTS in your config file. I realise that will stop the panic from looking at the source code, but surely it's just covering up the problem and waiting for it to happen later? -- 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-current" in the body of the message From owner-freebsd-current Thu Jul 15 9:19:15 1999 Delivered-To: freebsd-current@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id AC0DE1559F for ; Thu, 15 Jul 1999 09:19:09 -0700 (PDT) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id MAA03390; Thu, 15 Jul 1999 12:18:42 -0400 (EDT) (envelope-from luoqi) Date: Thu, 15 Jul 1999 12:18:42 -0400 (EDT) From: Luoqi Chen Message-Id: <199907151618.MAA03390@lor.watermarkgroup.com> To: Dom.Mitchell@palmerharvey.co.uk Subject: Re: panic: zone: entry in free Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I realise that will stop the panic from looking at the source code, but > surely it's just covering up the problem and waiting for it to happen > later? > I'm pretty it's caused by the INVARIANTS option, similar incidents have been reported many times before. The problem with INVARIANTS is that 1. it alters data structures, 2. kernel modules don't know about this option, so you have inconsistent kernel and modules. There're three solutions, 1, make INVARIANTS less intrusive. So far only vm_zone code is causing problems, I suggest we rename the option to INVARIANTS_ZONE in this part of code (the code should be pretty much bug free by now). 2, compile modules with the option. The easiest way is probably add -DINVARIANTS in your /etc/make.conf, you have to remember to take it out when you remove the option from your config file. 3, do not use INVARIANTS if you don't need it. :) -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 15 10: 2:40 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 501591561E for ; Thu, 15 Jul 1999 10:02:32 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA11286; Thu, 15 Jul 1999 10:01:18 -0700 (PDT) (envelope-from dillon) Date: Thu, 15 Jul 1999 10:01:18 -0700 (PDT) From: Matthew Dillon Message-Id: <199907151701.KAA11286@apollo.backplane.com> To: Luoqi Chen Cc: Dom.Mitchell@palmerharvey.co.uk, current@FreeBSD.ORG Subject: Re: panic: zone: entry in free References: <199907151618.MAA03390@lor.watermarkgroup.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> I realise that will stop the panic from looking at the source code, but :> surely it's just covering up the problem and waiting for it to happen :> later? :> :I'm pretty it's caused by the INVARIANTS option, similar incidents have been :reported many times before. The problem with INVARIANTS is that 1. it alters :data structures, 2. kernel modules don't know about this option, so you :have inconsistent kernel and modules. There're three solutions, : :1, make INVARIANTS less intrusive. So far only vm_zone code is causing :problems, I suggest we rename the option to INVARIANTS_ZONE in this part :of code (the code should be pretty much bug free by now). : :2, compile modules with the option. The easiest way is probably add :-DINVARIANTS in your /etc/make.conf, you have to remember to take it :out when you remove the option from your config file. : :3, do not use INVARIANTS if you don't need it. :) : :-lq This sounds very similar to the DIAGNOSTIC story... I would much prefer to see INVARIANTS be entirely passive and not fall down the same well as DIAGNOSTIC did. People may remember how utterly useless DIAGNOSTIC became due to being overly intrusive. INVARIANTS should simply assert conditions that it expects to be true and panic if they aren't. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 15 10:33:53 1999 Delivered-To: freebsd-current@freebsd.org Received: from lamb.sas.com (lamb.sas.com [192.35.83.8]) by hub.freebsd.org (Postfix) with ESMTP id 666A614DB9 for ; Thu, 15 Jul 1999 10:33:42 -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 NAA16692 for ; Thu, 15 Jul 1999 13:33:21 -0400 (EDT) Received: from bb01f39.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA03147; Thu, 15 Jul 1999 13:32:51 -0400 Received: (from jwd@localhost) by bb01f39.unx.sas.com (8.9.1/8.9.1) id NAA79230 for freebsd-current@freebsd.org; Thu, 15 Jul 1999 13:32:50 -0400 (EDT) (envelope-from jwd) From: "John W. DeBoskey" Message-Id: <199907151732.NAA79230@bb01f39.unx.sas.com> Subject: /etc/fstab vs. /sbin/mount -p To: freebsd-current@freebsd.org Date: Thu, 15 Jul 1999 13:32:50 -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-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I just noticed the following while tracing my config to make sure everything was correct: From /etc/fstab, I am forcing a v2 mount: netapp01:/vol/sas /sas nfs rw,nfsv2 0 2 /sbin/mount -p should create an fstab format output: netapp01:/vol/sas /sas nfs rw 0 2 It seems to have dropped the v2 flag... Comments? Thanks, John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 15 11:24:51 1999 Delivered-To: freebsd-current@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 5A68E150EE for ; Thu, 15 Jul 1999 11:24:46 -0700 (PDT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 15 Jul 1999 19:24:16 +0100 (BST) Date: Thu, 15 Jul 1999 19:24:16 +0100 From: David Malone To: "John W. DeBoskey" Cc: freebsd-current@freebsd.org Subject: Re: /etc/fstab vs. /sbin/mount -p Message-ID: <19990715192416.A1772@walton.maths.tcd.ie> References: <199907151732.NAA79230@bb01f39.unx.sas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199907151732.NAA79230@bb01f39.unx.sas.com>; from John W. DeBoskey on Thu, Jul 15, 1999 at 01:32:50PM -0400 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 15, 1999 at 01:32:50PM -0400, John W. DeBoskey wrote: > It seems to have dropped the v2 flag... Mount can only get generic options back again - I went looking for a way to get the other options back again when I was adding the fstab and cur options to mount, but couldn't find any. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 15 11:27:38 1999 Delivered-To: freebsd-current@freebsd.org Received: from mailer.syr.edu (mailer.syr.edu [128.230.18.29]) by hub.freebsd.org (Postfix) with ESMTP id BAAB615054 for ; Thu, 15 Jul 1999 11:27:36 -0700 (PDT) (envelope-from cmsedore@mailbox.syr.edu) Received: from rodan.syr.edu by mailer.syr.edu (LSMTP for Windows NT v1.1a) with SMTP id <0.2F8E6AC0@mailer.syr.edu>; Thu, 15 Jul 1999 14:27:36 -0400 Received: from localhost (cmsedore@localhost) by rodan.syr.edu (8.8.7/8.8.7) with ESMTP id OAA15465 for ; Thu, 15 Jul 1999 14:27:31 -0400 (EDT) X-Authentication-Warning: rodan.syr.edu: cmsedore owned process doing -bs Date: Thu, 15 Jul 1999 14:27:31 -0400 (EDT) From: Christopher Sedore X-Sender: cmsedore@rodan.syr.edu To: freebsd-current@freebsd.org Subject: aio and fd patches Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm interested in finding someone to help me get the aio patches I've written committed into -current. These fixes make the aio routines much more useful for io on sockets than they are now (each io op on a socket blocks an aiod). This is a bit of a work in progress, but I've been running these patches here for over a month with good performance and no new detriment to stability. There should be no stability impact on code which doesn't utilize aio routines. I'm also interested in whether anyone is working to get the patches from Ville-Pertti Keinonen for file descriptor referencing committed. These are important for aio and other more critical subsystems. You can see my report of issues in kern/12053. I somehow managed to include a mangled and outdated version of the patch with that report, so that patch shouldn't be integrated. An updated patch is available at http://tfeed.maxwell.syr.edu/aio-diff -Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 15 11:33:27 1999 Delivered-To: freebsd-current@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 19A4A14D61 for ; Thu, 15 Jul 1999 11:33:24 -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 OAA38946; Thu, 15 Jul 1999 14:33:22 -0400 (EDT) X-Authentication-Warning: janus.syracuse.net: green owned process doing -bs Date: Thu, 15 Jul 1999 14:33:21 -0400 (EDT) From: "Brian F. Feldman" X-Sender: green@janus.syracuse.net To: Luoqi Chen Cc: Dom.Mitchell@palmerharvey.co.uk, current@FreeBSD.org Subject: Re: panic: zone: entry in free In-Reply-To: <199907151618.MAA03390@lor.watermarkgroup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Jul 1999, Luoqi Chen wrote: > > I realise that will stop the panic from looking at the source code, but > > surely it's just covering up the problem and waiting for it to happen > > later? > > > I'm pretty it's caused by the INVARIANTS option, similar incidents have been > reported many times before. The problem with INVARIANTS is that 1. it alters > data structures, 2. kernel modules don't know about this option, so you > have inconsistent kernel and modules. There're three solutions, > > 1, make INVARIANTS less intrusive. So far only vm_zone code is causing > problems, I suggest we rename the option to INVARIANTS_ZONE in this part > of code (the code should be pretty much bug free by now). > > 2, compile modules with the option. The easiest way is probably add > -DINVARIANTS in your /etc/make.conf, you have to remember to take it > out when you remove the option from your config file. I apply the following to freshly checked-out sources: --- src/sys/modules/Makefile.inc.orig Fri Oct 16 00:31:35 1998 +++ src/sys/modules/Makefile.inc Sun Mar 14 23:03:02 1999 @@ -1,3 +1,8 @@ # $Id: Makefile.inc,v 1.1 1998/10/16 04:31:35 peter Exp $ KLDMOD= true +CFLAGS+= -DINVARIANTS +NTUN=4 +PPP_FILTER=1 +VM86=1 +CFLAGS+= -g > > 3, do not use INVARIANTS if you don't need it. :) > > -lq > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" 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-current" in the body of the message From owner-freebsd-current Thu Jul 15 13:18:11 1999 Delivered-To: freebsd-current@freebsd.org Received: from mail.palmerharvey.co.uk (mail.palmerharvey.co.uk [62.172.109.58]) by hub.freebsd.org (Postfix) with ESMTP id 52D1114D09 for ; Thu, 15 Jul 1999 13:18:07 -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:17:39 +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 3WRWC5CS; Thu, 15 Jul 1999 21:18:27 +0100 Received: from dom by voodoo.pandhm.co.uk with local (Exim 2.10 #1) id 114rxD-0000SB-00; Thu, 15 Jul 1999 21:18:03 +0100 Date: Thu, 15 Jul 1999 21:18:03 +0100 To: Luoqi Chen Cc: Dom.Mitchell@palmerharvey.co.uk, current@FreeBSD.ORG Subject: Re: panic: zone: entry in free Message-Id: <19990715211803.A1728@palmerharvey.co.uk> References: <199907151618.MAA03390@lor.watermarkgroup.com> MIME-Version: 1.0 X-Mailer: Mutt 0.95.6i In-Reply-To: <199907151618.MAA03390@lor.watermarkgroup.com>; from Luoqi Chen on Thu, Jul 15, 1999 at 12:18:42PM -0400 From: Dominic Mitchell Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 15, 1999 at 12:18:42PM -0400, Luoqi Chen wrote: > > I realise that will stop the panic from looking at the source code, but > > surely it's just covering up the problem and waiting for it to happen > > later? > > > I'm pretty it's caused by the INVARIANTS option, similar incidents have been > reported many times before. The problem with INVARIANTS is that 1. it alters > data structures, 2. kernel modules don't know about this option, so you > have inconsistent kernel and modules. There're three solutions, > > 1, make INVARIANTS less intrusive. So far only vm_zone code is causing > problems, I suggest we rename the option to INVARIANTS_ZONE in this part > of code (the code should be pretty much bug free by now). > > 2, compile modules with the option. The easiest way is probably add > -DINVARIANTS in your /etc/make.conf, you have to remember to take it > out when you remove the option from your config file. > > 3, do not use INVARIANTS if you don't need it. :) Well, for the moment, I guess I'll take the 3rd option. My current kernel seems to be up and alive a lot longer... Given that I'm not the programmer, I'll keep INVARIANTS off for the moment. This of course begs the question, under what circumstances *should* one use INVARIANTS? -- 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-current" in the body of the message From owner-freebsd-current Thu Jul 15 13:23:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from mail.palmerharvey.co.uk (mail.palmerharvey.co.uk [62.172.109.58]) by hub.freebsd.org (Postfix) with ESMTP id 3093F14DDA for ; Thu, 15 Jul 1999 13:23:26 -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:21:57 +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 3WRWC5CV; Thu, 15 Jul 1999 21:22:45 +0100 Received: from dom by voodoo.pandhm.co.uk with local (Exim 2.10 #1) id 114s1N-0000Sb-00; Thu, 15 Jul 1999 21:22:21 +0100 Date: Thu, 15 Jul 1999 21:22:21 +0100 To: Matthew Dillon Cc: Luoqi Chen , Dom.Mitchell@palmerharvey.co.uk, current@FreeBSD.ORG Subject: Re: panic: zone: entry in free Message-Id: <19990715212220.B1728@palmerharvey.co.uk> References: <199907151618.MAA03390@lor.watermarkgroup.com> <199907151701.KAA11286@apollo.backplane.com> MIME-Version: 1.0 X-Mailer: Mutt 0.95.6i In-Reply-To: <199907151701.KAA11286@apollo.backplane.com>; from Matthew Dillon on Thu, Jul 15, 1999 at 10:01:18AM -0700 From: Dominic Mitchell Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Jul 15, 1999 at 10:01:18AM -0700, Matthew Dillon wrote: > :> I realise that will stop the panic from looking at the source code, but > :> surely it's just covering up the problem and waiting for it to happen > :> later? > :> > :I'm pretty it's caused by the INVARIANTS option, similar incidents have been > :reported many times before. The problem with INVARIANTS is that 1. it alters > :data structures, 2. kernel modules don't know about this option, so you > :have inconsistent kernel and modules. There're three solutions, > : > :1, make INVARIANTS less intrusive. So far only vm_zone code is causing > :problems, I suggest we rename the option to INVARIANTS_ZONE in this part > :of code (the code should be pretty much bug free by now). > : > :2, compile modules with the option. The easiest way is probably add > :-DINVARIANTS in your /etc/make.conf, you have to remember to take it > :out when you remove the option from your config file. > : > :3, do not use INVARIANTS if you don't need it. :) > > This sounds very similar to the DIAGNOSTIC story... I would much > prefer to see INVARIANTS be entirely passive and not fall down > the same well as DIAGNOSTIC did. People may remember how utterly > useless DIAGNOSTIC became due to being overly intrusive. > > INVARIANTS should simply assert conditions that it expects to be > true and panic if they aren't. In this case, it appears to have done that. I just don't know enough to work out what is causing the assertion to fail... -- 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-current" in the body of the message From owner-freebsd-current Thu Jul 15 15:21: 2 1999 Delivered-To: freebsd-current@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 934D315614 for ; Thu, 15 Jul 1999 15:20:52 -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 114tqJ-000KhR-00; Fri, 16 Jul 1999 00:19:03 +0200 From: Sheldon Hearn To: Dominic Mitchell Cc: Luoqi Chen , current@FreeBSD.ORG Subject: Re: panic: zone: entry in free In-reply-to: Your message of "Thu, 15 Jul 1999 21:18:03 +0100." <19990715211803.A1728@palmerharvey.co.uk> Date: Fri, 16 Jul 1999 00:19:03 +0200 Message-ID: <79572.932077143@axl.noc.iafrica.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 15 Jul 1999 21:18:03 +0100, Dominic Mitchell wrote: > This of course begs the question, under what circumstances *should* one > use INVARIANTS? This has been explained to me before as "when you have the time and inclination to look into any problems that this might cause or highlight." Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Thu Jul 15 17:31:10 1999 Delivered-To: freebsd-current@freebsd.org Received: from darwin.ntu.edu.au (darwin.ntu.edu.au [138.80.128.3]) by hub.freebsd.org (Postfix) with ESMTP id 2D7CC1577D for ; Thu, 15 Jul 1999 17:31:06 -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 JAA21637; Fri, 16 Jul 1999 09:58:42 +0930 (CST) Received: (grog@localhost) by mojave.lemis.com (8.9.3/8.6.12) id XAA00596; Thu, 15 Jul 1999 23:30:48 +0930 (CST) Message-ID: <19990715233048.63844@mojave.lemis.com> Date: Thu, 15 Jul 1999 23:30:48 +0930 From: Greg Lehey To: Luoqi Chen , Dom.Mitchell@palmerharvey.co.uk, current@FreeBSD.ORG Subject: Re: panic: zone: entry in free References: <199907150408.AAA25885@lor.watermarkgroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: <199907150408.AAA25885@lor.watermarkgroup.com>; from Luoqi Chen on Thu, Jul 15, 1999 at 12:08:07AM -0400 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-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thursday, 15 July 1999 at 0:08:07 -0400, Luoqi Chen wrote: >> I've been getting this panic when I've installed new kernels the last >> couple of times. The panic is occuring when I have freshly booted the >> system with a new kernel and logged on for the first time. It appears >> to occur at the point at which I start fetchmail in my profile, FWIW. > > Get rid of INVARIANTS in your config file. That removes the symptom, not the cause. 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-current" in the body of the message From owner-freebsd-current Fri Jul 16 0:12:11 1999 Delivered-To: freebsd-current@freebsd.org Received: from mfo01.iij.ad.jp (mfo01.iij.ad.jp [202.232.2.118]) by hub.freebsd.org (Postfix) with ESMTP id 1EDFF1558C; Fri, 16 Jul 1999 00:12:00 -0700 (PDT) (envelope-from a-aiwai@hh.iij4u.or.jp) Received: from hh.iij4u.or.jp (root@hh.iij4u.or.jp [210.130.0.22]) by mfo01.iij.ad.jp (8.8.8/MFO1.3) with ESMTP id QAA03455; Fri, 16 Jul 1999 16:11:32 +0900 (JST) Received: from ns1 ([210.164.233.184]) by hh.iij4u.or.jp (8.8.8+2.2IIJ/4U1.1) with SMTP id QAA19881; Fri, 16 Jul 1999 16:07:04 +0900 (JST) Message-ID: <009d01becf5a$5a0a8e00$b8e9a4d2@ns1.grove.co.jp> From: "yonebayashi" To: Subject: =?iso-2022-jp?B?GyRCJCo8ajtmPXEkLSReJDckPxsoQg==?= Date: Fri, 16 Jul 1999 15:49:26 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0099_01BECFA5.C9F23600" 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-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0099_01BECFA5.C9F23600 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit $B$O$8$a$^$7$F!"$j$+$G!<$9!#(B $BFMA3$G$9$,!":G6a!"$I!<$b!VF|>H$j!W$,B3$$$F$k$N$h$M!#(B $B$"!<$C!"$I$C$+$K$$$$CK!"$$$J$$$+$J!<$C!"$J!<$s$F(B $B;W$C$?$j$7$A$c$C$F$k:#F|$3$N:"!#(B $B$C$F$f!<%o%1$G!"%"%J%?$K$*p!JN^!K$G$3$s$J%5%$%H$N(B $B1?1D$r$*
=1B$B$O$8$a$^$7$F!"$j$+$G!<$9!#=1B(B

=1B$BFMA3$G$9$,!":G6a!"$= I!<$b!VF|>H$j!W$,B3$$$F$k$N$h$M!#=1B(B
=1B$B$"!<$C!"$I$C$+$K$$$$CK!"$$= $J$$$+$J!<$C!"$J!<$s$F=1B(B
=1B$B;W$C$?$j$7$A$c$C$F$k:#F|$3$N:"!#=1B(B=

=1B$B$C$F$f!<%o%1$G!"%"%J%?$K$*
=1B$B%V%7%D%1$J%a!<%k$+$b$7$l$J$$$1$I!"5v$7$F$M!#=1B(B
=1B$B$$$= i$J$$$J$i%4%_H"$K%]%$$7$F2<$5$$$M!#=1B(B

=1B$B;d$,$I$s$J%R%H$+$H$f= !<$H!"4G8nIX$r$7$F$k$s$@$1$I!"=1B(B
=1B$B=3DtHL$N;v>p!JN^!K$G$3$s$J%5%= $%H$N=1B(B
=1B$B1?1D$r$*
http://210.155.111.19= 4/joshiryo/index.html
http://www.kk.iij4u.or.jp/~wa= iwai/

=1B$B$*;~4V$,$"$kJ}$O$<$R0lEY%h%m%7%/!#=1B(B

p.s.= =1B$B;d$O$I$3$K$$$k$G$7$g$&!)!!$h!<$/C5$7$F$M!*!*=1B(B
= ------=_NextPart_000_0099_01BECFA5.C9F23600-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Fri Jul 16 2:51: 6 1999 Delivered-To: freebsd-current@freebsd.org Received: from not.demophon.com (ns.demophon.com [193.65.70.13]) by hub.freebsd.org (Postfix) with ESMTP id BC82115682 for ; Fri, 16 Jul 1999 02:51:00 -0700 (PDT) (envelope-from will@not.demophon.com) Received: (from will@localhost) by not.demophon.com (8.9.3/8.8.7) id MAA13525; Fri, 16 Jul 1999 12:45:52 +0300 (EEST) (envelope-from will) To: Christopher Sedore Cc: current@freebsd.org Subject: Re: aio and fd patches References: From: Ville-Pertti Keinonen Date: 16 Jul 1999 12:45:51 +0300 In-Reply-To: Christopher Sedore's message of "15 Jul 1999 21:27:57 +0300" Message-ID: <86lnchlygg.fsf@not.demophon.com> Lines: 20 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Christopher Sedore writes: > You can see my report of issues in kern/12053. I somehow managed to > include a mangled and outdated version of the patch with that report, so > that patch shouldn't be integrated. An updated patch is available at > http://tfeed.maxwell.syr.edu/aio-diff It looks like you're introducing yet another race condition by not ensuring that the file doesn't change from under a socket operation. This can't be fixed the same way my patches fix all (hopefully) of the other races. It might be a good idea to add a 'struct file *' field to the aiocblist structure and forget about the file descriptor number after initially looking it up. This is based on a quick glance, there may be other issues. Note that the style police may want you to consistently add spaces after commas and between binary operators and their operands. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 17 1:58: 6 1999 Delivered-To: freebsd-current@freebsd.org Received: from mercury.is.co.za (mercury.is.co.za [196.4.160.222]) by hub.freebsd.org (Postfix) with ESMTP id 933DE14C8B for ; Sat, 17 Jul 1999 01:57:59 -0700 (PDT) (envelope-from geoffr@is.co.za) Received: from ISJHBEX (isjhbexnode.is.co.za [196.26.1.2]) by mercury.is.co.za (8.9.3/8.9.3) with ESMTP id KAA08226 for ; Sat, 17 Jul 1999 10:56:06 +0200 Received: by isjhbex.is.co.za with Internet Mail Service (5.5.2448.0) id <39ZYKSC9>; Sat, 17 Jul 1999 10:59:56 +0200 Message-ID: From: Geoff Rehmet To: "'current@freebsd.org'" Subject: TCP SACK Date: Sat, 17 Jul 1999 10:59:56 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I was wondering if anyone was busy looking at implementing TCP SACk (selective ack) on FreeBSD. Thanks, Geoff. -- Geoff Rehmet, The Internet Solution - Infrastructure tel: +27-11-283-5462, fax: +27-11-283-5401 mobile: +27-83-292-5800 email: geoffr@is.co.za URL: http://www.is.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 17 5:57:58 1999 Delivered-To: freebsd-current@freebsd.org Received: from fep2.post.tele.dk (fep2.post.tele.dk [195.41.46.135]) by hub.freebsd.org (Postfix) with ESMTP id A791314E1D for ; Sat, 17 Jul 1999 05:57:45 -0700 (PDT) (envelope-from peter@holm.cc) Received: from holm.cc ([195.249.209.44]) by fep2.post.tele.dk (InterMail v4.0 201-221) with ESMTP id <19990717125809.QAUA3647.fep2@holm.cc> for ; Sat, 17 Jul 1999 14:58:09 +0200 Message-ID: <37907E52.7A257D9E@holm.cc> Date: Sat, 17 Jul 1999 15:00:02 +0200 From: Peter Holm X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Freebsd-current@freebsd.org Subject: Out of swap handling Content-Type: multipart/mixed; boundary="------------2FD23224575AA298CF8FBAE3" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------2FD23224575AA298CF8FBAE3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have tested out of swap handling in current. The situation is that the system just lockes up, "looping" in vm_pageout_scan. I have experimented with some modifications to vm_pageout.c that seems to improve the chances for a recovery drastically. All tests were done on my 128Mb RAM / 256 Mb swap box. The changes consists of: * Killing all running user processes when less than 1024 pages swap left. * Sleeping after each kill to allow the user process to run. * Pausing the vmdaemon when in kill mode. I have tried different strategies for when to stop killing but only this one seems to guaranty recovery. I have included my changes. Regards, -- Peter Holm | mailto:peter@holm.cc | http://login.dknet.dk/~pho/ -[ Member of the BSD-Dk User Group / http://www.bsd-dk.dk/ ] - --------------2FD23224575AA298CF8FBAE3 Content-Type: text/plain; charset=us-ascii; name="patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch" *** sys/vm/vm_pageout.c~ Sun Jul 4 13:53:49 1999 --- sys/vm/vm_pageout.c Sat Jul 17 13:51:39 1999 *************** *** 154,159 **** --- 154,162 ---- static int vm_swap_idle_enabled=0; #endif + static int kill_mode = 0; + static pid_t last_killed_pid = 0; + SYSCTL_INT(_vm, VM_PAGEOUT_ALGORITHM, pageout_algorithm, CTLFLAG_RW, &vm_pageout_algorithm_lru, 0, "LRU page mgmt"); *************** *** 204,209 **** --- 207,213 ---- #endif static void vm_pageout_page_stats(void); + /* * vm_pageout_clean: * *************** *** 1126,1175 **** } /* ! * make sure that we have swap space -- if we are low on memory and * swap -- then kill the biggest process. */ ! if ((vm_swap_size == 0 || swap_pager_full) && ! ((cnt.v_free_count + cnt.v_cache_count) < cnt.v_free_min)) { ! bigproc = NULL; ! bigsize = 0; ! for (p = allproc.lh_first; p != 0; p = p->p_list.le_next) { ! /* ! * if this is a system process, skip it ! */ ! if ((p->p_flag & P_SYSTEM) || (p->p_lock > 0) || ! (p->p_pid == 1) || ! ((p->p_pid < 48) && (vm_swap_size != 0))) { ! continue; ! } ! /* ! * if the process is in a non-running type state, ! * don't touch it. ! */ ! if (p->p_stat != SRUN && p->p_stat != SSLEEP) { ! continue; } ! /* ! * get the process size ! */ ! size = vmspace_resident_count(p->p_vmspace); ! /* ! * if the this process is bigger than the biggest one ! * remember it. ! */ ! if (size > bigsize) { ! bigproc = p; ! bigsize = size; } ! } ! if (bigproc != NULL) { ! killproc(bigproc, "out of swap space"); ! bigproc->p_estcpu = 0; ! bigproc->p_nice = PRIO_MIN; ! resetpriority(bigproc); ! wakeup(&cnt.v_free_count); ! } ! } return force_wakeup; } --- 1130,1196 ---- } /* ! * make sure that we have swap space -- if we are low on * swap -- then kill the biggest process. */ ! #ifdef NO_SWAPPING ! if (kill_mode) ! kill_mode = ((cnt.v_free_count + cnt.v_cache_count) < ! 3*cnt.v_free_min); ! else ! kill_mode = ((cnt.v_free_count + cnt.v_cache_count) < ! cnt.v_free_min); ! #else ! if (kill_mode) ! kill_mode = (vm_swap_size < 3072); ! else ! kill_mode = (vm_swap_size < 1024); ! #endif ! ! if (kill_mode) { /* Kill all running user procs, biggest first */ ! do { ! bigproc = NULL; ! bigsize = 0; ! for (p = allproc.lh_first; p != 0; p = p->p_list.le_next) { ! /* ! * if this is a system process, skip it ! */ ! if ((p->p_flag & P_SYSTEM) || (p->p_lock > 0) || ! (p->p_pid == 1) || ! ((p->p_pid < 48) && (vm_swap_size != 0))) { ! continue; ! } ! /* ! * if the process is in a non-running type state, ! * don't touch it. ! */ ! if (p->p_stat != SRUN) continue; ! if (p->p_siglist & (SIGKILL | P_WEXIT)) continue; ! if (p->p_cred->p_ruid < 2) continue; ! if (p->p_pid == last_killed_pid) continue; ! /* ! * get the process size ! */ ! size = vmspace_resident_count(p->p_vmspace); ! /* ! * if the this process is bigger than the biggest one ! * remember it. ! */ ! if (size > bigsize) { ! bigproc = p; ! bigsize = size; ! } } ! if (bigproc != NULL) { ! killproc(bigproc, "out of swap space"); ! last_killed_pid = bigproc->p_pid; ! s = splvm(); ! tsleep(&vm_pages_needed, PVM, "psleep", hz/30); ! splx(s); } ! } while (bigproc); ! } /* kill mode */ ! wakeup(&cnt.v_free_count); return force_wakeup; } *************** *** 1404,1411 **** --- 1425,1439 ---- vm_daemon() { struct proc *p; + int s; while (TRUE) { + if (kill_mode) { + /* Give killed user procs a chance to die */ + s = splvm(); + tsleep(&vm_pages_needed, PVM, "psleep", hz); + splx(s); + } tsleep(&vm_daemon_needed, PPAUSE, "psleep", 0); if (vm_pageout_req_swapout) { swapout_procs(vm_pageout_req_swapout); *** sys/vm/swap_pager.c~ Tue Jun 29 21:45:31 1999 --- sys/vm/swap_pager.c Fri Jul 16 17:49:45 1999 *************** *** 214,220 **** --- 214,222 ---- { if (vm_swap_size < nswap_lowat) { if (swap_pager_almost_full == 0) { + #ifdef DISGNOSTIC printf("swap_pager: out of swap space\n"); + #endif swap_pager_almost_full = 1; } } else { *************** *** 470,476 **** --- 472,480 ---- if ((blk = blist_alloc(swapblist, npages)) == SWAPBLK_NONE) { if (swap_pager_full != 2) { + #ifdef DIAGNOSTIC printf("swap_pager_getswapspace: failed\n"); + #endif swap_pager_full = 2; swap_pager_almost_full = 1; } --------------2FD23224575AA298CF8FBAE3-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 17 8:39:41 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 9254814BDD for ; Sat, 17 Jul 1999 08:39:35 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id IAA74731; Sat, 17 Jul 1999 08:39:19 -0700 (PDT) (envelope-from dillon) Date: Sat, 17 Jul 1999 08:39:19 -0700 (PDT) From: Matthew Dillon Message-Id: <199907171539.IAA74731@apollo.backplane.com> To: Peter Holm Cc: Freebsd-current@FreeBSD.ORG Subject: Re: Out of swap handling References: <37907E52.7A257D9E@holm.cc> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :I have tested out of swap handling in current. The situation is that the : :system just lockes up, "looping" in vm_pageout_scan. Yah, this is a known problem. I'll take a look at your patch but I was thinking of something a little simpler. But I wasn't planning on fixing it for a few months because there are too many things happening to other parts of the VM and VFS/BIO system right now. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 17 11:23:50 1999 Delivered-To: freebsd-current@freebsd.org Received: from uni-sb.de (uni-sb.de [134.96.252.33]) by hub.freebsd.org (Postfix) with ESMTP id 7DDBB14BD5 for ; Sat, 17 Jul 1999 11:23:31 -0700 (PDT) (envelope-from schuerge@wjpserver.CS.Uni-SB.DE) Received: from cs.uni-sb.de (cs.uni-sb.de [134.96.252.31]) by uni-sb.de (8.9.3/1999070600) with ESMTP id UAA12023 for ; Sat, 17 Jul 1999 20:23:28 +0200 (CEST) Received: from wjpserver.cs.uni-sb.de (wjpserver.cs.uni-sb.de [134.96.247.42]) by cs.uni-sb.de (8.9.3/1999031900) with ESMTP id UAA19192 for ; Sat, 17 Jul 1999 20:23:27 +0200 (CEST) Received: (from schuerge@localhost) by wjpserver.cs.uni-sb.de (8.9.3/8.9.3/wjp-SVR4/1999052600) id UAA18032 for freebsd-current@freebsd.org; Sat, 17 Jul 1999 20:23:27 +0200 (MET DST) From: Thomas Schuerger Message-Id: <199907171823.UAA18032@wjpserver.cs.uni-sb.de> Subject: i/o problems gone To: freebsd-current@freebsd.org Date: Sat, 17 Jul 1999 20:23:27 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL57 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi! Some time ago I reported I/O problems in FreeBSD when having time-consuming processes (like seti@home or rc5des) in the background. I had experienced these problems since I installed freebsd 9 months ago (I made world frequently in between). After making and installing a new world some days ago, these problems were gone! Now it doesn't matter whether there's anything running in the background or not. Good job! :-) What has been changed? :) Ciao, Thomas. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 17 11:29:11 1999 Delivered-To: freebsd-current@freebsd.org Received: from uni-sb.de (uni-sb.de [134.96.252.33]) by hub.freebsd.org (Postfix) with ESMTP id 1873E14BD5 for ; Sat, 17 Jul 1999 11:29:08 -0700 (PDT) (envelope-from schuerge@wjpserver.CS.Uni-SB.DE) Received: from cs.uni-sb.de (cs.uni-sb.de [134.96.252.31]) by uni-sb.de (8.9.3/1999070600) with ESMTP id UAA12031 for ; Sat, 17 Jul 1999 20:29:06 +0200 (CEST) Received: from wjpserver.cs.uni-sb.de (wjpserver.cs.uni-sb.de [134.96.247.42]) by cs.uni-sb.de (8.9.3/1999031900) with ESMTP id UAA19226 for ; Sat, 17 Jul 1999 20:29:06 +0200 (CEST) Received: (from schuerge@localhost) by wjpserver.cs.uni-sb.de (8.9.3/8.9.3/wjp-SVR4/1999052600) id UAA18073 for freebsd-current@freebsd.org; Sat, 17 Jul 1999 20:29:05 +0200 (MET DST) From: Thomas Schuerger Message-Id: <199907171829.UAA18073@wjpserver.cs.uni-sb.de> Subject: ata delay To: freebsd-current@freebsd.org Date: Sat, 17 Jul 1999 20:29:05 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL57 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi! I switched to the ata IDE driver some time ago. Since then, booting stops for about 30 seconds when the driver is installed. It didn't happen when using the old wd driver. I'm using controller ata0 device atadisk0 # ATA disk drives in my kernel. From dmesg: ... isab0: at device 4.0 on pci0 ata-pci0: at device 4.1 on pci0 ata-pci0: Busmastering DMA supported ata0 at 0x00x1f0 irq 14 on ata-pci0 Here booting stops for quite a while and then continues. chip1: irq 19 at device 4.2 on pci0 chip2: at device 4.3 on pci0 ahc0: irq 19 at device 6.0 on pci0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs ... Is there anything I'm doing wrong or is there a timeout that can be decreased? Ciao, Thomas. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 17 13:21:24 1999 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id ECCEF14DC6 for ; Sat, 17 Jul 1999 13:21:12 -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 WAA10558 for ; Sat, 17 Jul 1999 22:20:43 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org Subject: please test (linux emulation) From: Poul-Henning Kamp Date: Sat, 17 Jul 1999 22:20:43 +0200 Message-ID: <10556.932242843@critter.freebsd.dk> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have no idea how to excercise this piece of code, if somebody could verify that it still DTRT I would be most grateful. Poul-Henning Index: linux_file.c =================================================================== RCS file: /home/ncvs/src/sys/i386/linux/linux_file.c,v retrieving revision 1.26 diff -u -r1.26 linux_file.c --- linux_file.c 1999/05/11 19:54:19 1.26 +++ linux_file.c 1999/07/17 20:18:42 @@ -43,6 +43,7 @@ #include #include #include +#include #include #include @@ -199,7 +200,6 @@ struct filedesc *fdp; struct file *fp; struct vnode *vp; - struct vattr va; long pgid; struct pgrp *pgrp; struct tty *tp, *(*d_tty) __P((dev_t)); @@ -304,10 +304,7 @@ vp = (struct vnode *)fp->f_data; if (vp->v_type != VCHR) return EINVAL; - if ((error = VOP_GETATTR(vp, &va, p->p_ucred, p))) - return error; - - dev = udev2dev(va.va_rdev, 0); /* XXX vp->v_rdev ? */ + dev = vp->v_rdev; d_tty = devsw(dev)->d_devtotty; if (!d_tty || (!(tp = (*d_tty)(dev)))) return EINVAL; -- 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-current" in the body of the message From owner-freebsd-current Sat Jul 17 15:42:38 1999 Delivered-To: freebsd-current@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 8FF4514BEC for ; Sat, 17 Jul 1999 15:42:25 -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 D1F719B; Sun, 18 Jul 1999 06:40:45 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Geoff Rehmet Cc: "'current@freebsd.org'" Subject: Re: TCP SACK In-reply-to: Your message of "Sat, 17 Jul 1999 10:59:56 +0200." Date: Sun, 18 Jul 1999 06:40:45 +0800 From: Peter Wemm Message-Id: <19990717224045.D1F719B@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Geoff Rehmet wrote: > I was wondering if anyone was busy looking at implementing > TCP SACk (selective ack) on FreeBSD. > > Thanks, > Geoff. Luigi did one, for 2.2.x I think: http://www.iet.unipi.it/~luigi/ # Luigi's page http://www.iet.unipi.it/~luigi/selack.ps # TCP SACK issues http://www.iet.unipi.it/~luigi/sack.html # TCP SACK implementation Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From owner-freebsd-current Sat Jul 17 20:31:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 2CC5F14D17 for ; Sat, 17 Jul 1999 20:30:38 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.9.3/8.9.3) id WAA07748; Sat, 17 Jul 1999 22:27:01 -0500 (CDT) (envelope-from dan) Date: Sat, 17 Jul 1999 22:27:00 -0500 From: Dan Nelson To: Peter Wemm Cc: Geoff Rehmet , "'current@freebsd.org'" Subject: Re: TCP SACK Message-ID: <19990717222700.A7166@dan.emsphone.com> References: <19990717224045.D1F719B@overcee.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <19990717224045.D1F719B@overcee.netplex.com.au>; from "Peter Wemm" on Sun Jul 18 06:40:45 GMT 1999 X-OS: FreeBSD 4.0-CURRENT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Jul 18), Peter Wemm said: > Geoff Rehmet wrote: > > I was wondering if anyone was busy looking at implementing TCP SACK > > (selective ack) on FreeBSD. > > > > Thanks, > > Geoff. > > Luigi did one, for 2.2.x I think: > > http://www.iet.unipi.it/~luigi/ # Luigi's page > http://www.iet.unipi.it/~luigi/selack.ps # TCP SACK issues > http://www.iet.unipi.it/~luigi/sack.html # TCP SACK implementation Luigi's patches are for 2.1.6 I believe. I have patches to his code that apply to 2.2.8 and 3.0 as well. If you know the TCP code you could probably merge them to 3.2 or 4.0 with no problems (I don't :) -Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message