From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 5 00:56:31 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2333D16A4B3 for ; Sun, 5 Oct 2003 00:56:31 -0700 (PDT) Received: from skywalker.rogness.net (skywalker.rogness.net [64.251.173.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id F26E243F85 for ; Sun, 5 Oct 2003 00:56:29 -0700 (PDT) (envelope-from nick@rogness.net) Received: from skywalker.rogness.net (localhost [127.0.0.1]) by skywalker.rogness.net (8.12.5/8.12.5) with ESMTP id h95827Vs045356; Sun, 5 Oct 2003 02:02:08 -0600 (MDT) (envelope-from nick@rogness.net) Received: from localhost (nick@localhost)h95827im045353; Sun, 5 Oct 2003 02:02:07 -0600 (MDT) X-Authentication-Warning: skywalker.rogness.net: nick owned process doing -bs Date: Sun, 5 Oct 2003 02:02:00 -0600 (MDT) From: Nick Rogness To: Leo Bicknell In-Reply-To: <20031004235400.GA20943@ussenterprise.ufp.org> Message-ID: <20031005014620.H45148-100000@skywalker.rogness.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: Changing the NAT IP on demand? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2003 07:56:31 -0000 On Sat, 4 Oct 2003, Leo Bicknell wrote: > > I'm considering options for a new project, and I think I've discovered > what I think is the best idea, but I don't think current software > supports the config. I'd like to get some confirmation, and comments on > if it would be hard to implement. > > Consider: > > > ISP #1-------\ > \ > FreeBSD Box----LAN > / > ISP #2-------/ > > In this case the LAN would be 1918 space, the two ISP's would each > provide a public IP for the FreeBSD box. > > Now, NAT would be required. What I want to do is write an external > application to decide the performance of ISP #1 and ISP#2, and > somehow tell NAT which outside address to use. > > That, by itself, is not hard. Here's the trick. I want the switch > to be seamless. That is, if NAT is translating to ISP #1 and the > application says switch to #2 the existing translations to #1 (until > they go away naturally) should be kept, while new ones go to #2. > > The only ways I know to change the outside address seem to tear down > all existing connections. > > Is it possible to make this work today? Would it be hard to fix if > it doesn't work today? This can simply not work without resetting connections. The socket pair on the "outside" would break as your outside traffic switches from one to the other (src/dst would change). There is no fix, as this breaks basic IP principals. A suggestion to make this kinda work would be to get a range that ISP#1 && ISP#2 would both allow you to route in/out. Then you would have to write some app that routes your traffic out either ISP, keeping the same "outside" range. So you get a range (or single IP), call it X.X.X.X. This is your external (non 1918) address. When packets leave your FreeBSD machine destined for the Internet, the source IP would be X.X.X.X. Since both ISP's allow source IP X.X.X.X out, it is only a matter of determining which ISP to send the traffic out to. This would be done by modifying the routing table (or with fw forwarding of some sort). The inverse is true with traffic inbound from the Internet to X.X.X.X. However, if you are going to go through this type of trouble, you might as well just route peer with the ISPs via BGP or whatnot. Nick Rogness - How many people here have telekenetic powers? Raise my hand. -Emo Philips From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 5 05:31:54 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FE5216A4B3 for ; Sun, 5 Oct 2003 05:31:54 -0700 (PDT) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC54643FE3 for ; Sun, 5 Oct 2003 05:31:52 -0700 (PDT) (envelope-from wkb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.9p1/8.12.9) with ESMTP id h95CVoZ8011321; Sun, 5 Oct 2003 14:31:50 +0200 (CEST) (envelope-from wkb@freebie.xs4all.nl) Received: (from wkb@localhost) by freebie.xs4all.nl (8.12.9p1/8.12.9/Submit) id h95CVnNb011320; Sun, 5 Oct 2003 14:31:49 +0200 (CEST) (envelope-from wkb) Date: Sun, 5 Oct 2003 14:31:49 +0200 From: Wilko Bulte To: Kris Kennaway Message-ID: <20031005123149.GB11276@freebie.xs4all.nl> References: <20031004190251.GA60026@rot13.obsecurity.org> <3F7F1D63.2010703@mindspring.com> <20031004200435.GA60432@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031004200435.GA60432@rot13.obsecurity.org> User-Agent: Mutt/1.4.1i X-OS: FreeBSD 4.9-PRERELEASE X-PGP: finger wilko@freebsd.org cc: Richard Coleman cc: Mikulas Patocka cc: freebsd-hackers@freebsd.org Subject: Re: Hyperthreading slowdown X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2003 12:31:54 -0000 On Sat, Oct 04, 2003 at 01:04:35PM -0700, Kris Kennaway wrote: > On Sat, Oct 04, 2003 at 03:20:03PM -0400, Richard Coleman wrote: > > Kris Kennaway wrote: > > >On Sat, Oct 04, 2003 at 04:39:03PM +0200, Mikulas Patocka wrote: > > >>I installed FreeBSD 4.9RC1 on P4 3GHz with hyperthreading and I see > > >>drastic slowdown when kernel with hyperthreading is booted. For example > > >>program compilation took this time: > > >> > > >>hyperthreading kernel, make -j 1 --- 1:09 > > >>hyperthreading kernel, make -j 2 --- 0:42 > > >>singlethreading kernel, make -j 1 --- 0:45 > > >>singlethreading kernel, make -j 2 --- 0:41 > > >> > > >>Compilation does very few system calls so when I compile with only one > > >>process (-j 1), it should be as fast as with singlethreading kernel. Do > > >>you have any idea why is it so slow? > > > > > >Do you realise that hyperthreading != a secret extra CPU in your system? > > > > > >Kris > > > > I didn't see anywhere in the message where he implied that. To me, the > > interesting thing is that there is such a larger difference between the > > compile time for -j1 and -j2 when using hyperthreading as compared to > > the difference between -j1 and -j2 for a single threaded kernel. It's > > over a 50% slowdown. > > Yes, that's because (as discussed in the archives) the kernel treats > it like an extra, completely decoupled physical CPU and schedules > processes on it without further consideration. This is presumably the > cause of the slowdown, because it's only efficient to use the virtual > CPU under certain workload patterns. HTT is not magic performance > beans. Right. And in addition it makes the system considerably more power hungry.. I measured both with and without SMP on my P4/2.4G HTT CPU. -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 5 06:29:26 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41AA616A4B3 for ; Sun, 5 Oct 2003 06:29:26 -0700 (PDT) Received: from hannibal.servitor.co.uk (hannibal.servitor.co.uk [195.188.15.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1124143F75 for ; Sun, 5 Oct 2003 06:29:23 -0700 (PDT) (envelope-from paul@iconoplex.co.uk) Received: from hannibal.servitor.co.uk ([195.188.15.48] helo=iconoplex.co.uk) by hannibal.servitor.co.uk with esmtp (Exim 4.14) id 1A690K-000GpU-32; Sun, 05 Oct 2003 14:32:56 +0100 Message-ID: <3F801CA7.60201@iconoplex.co.uk> Date: Sun, 05 Oct 2003 14:29:11 +0100 From: Paul Robinson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Leo Bicknell References: <20031004235400.GA20943@ussenterprise.ufp.org> In-Reply-To: <20031004235400.GA20943@ussenterprise.ufp.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: Changing the NAT IP on demand? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2003 13:29:26 -0000 Leo Bicknell wrote: >Now, NAT would be required. What I want to do is write an external >application to decide the performance of ISP #1 and ISP#2, and >somehow tell NAT which outside address to use. > Depends on how much money you have, but had you considered getting your own address range and BGP peering with your ISPs? I'd consider talking to them about it. It'll take some time to setup, but it means your "switching" is done at the router, not at the NAT box, which is the wrong place to do it anyway. -- Paul Robinson From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 5 07:54:38 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FC7816A4B3 for ; Sun, 5 Oct 2003 07:54:38 -0700 (PDT) Received: from storming.org (MG035035.user.veloxzone.com.br [200.165.35.35]) by mx1.FreeBSD.org (Postfix) with SMTP id 4F47243FE3 for ; Sun, 5 Oct 2003 07:54:36 -0700 (PDT) (envelope-from fred@storming.org) Received: (qmail 57005 invoked by uid 1000); 5 Oct 2003 11:54:31 -0300 Date: Sun, 5 Oct 2003 11:54:31 -0300 From: Fred Souza To: Paul Robinson Message-ID: <20031005145431.GA42245@torment.storming.org> References: <20031004235400.GA20943@ussenterprise.ufp.org> <3F801CA7.60201@iconoplex.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: <3F801CA7.60201@iconoplex.co.uk> X-Sender: fred@storming.org cc: freebsd-hackers@freebsd.org Subject: Re: Changing the NAT IP on demand? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: fred@storming.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2003 14:54:38 -0000 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > Depends on how much money you have, but had you considered getting your= =20 > own address range and BGP peering with your ISPs? I'd consider talking=20 > to them about it. It'll take some time to setup, but it means your=20 > "switching" is done at the router, not at the NAT box, which is the=20 > wrong place to do it anyway. I think I have an inelegant solution to this, but one that could be implemented with even a simple script. If I understood what Leo asked correctly, what's needed is to change the default route on the FreeBSD gateway whenever an event tells it to (in this case, the increase/decrease in performance for the ISPs). The concern here is to keep currently-stablished connections alive, so the process is carried out seamlessly. Unless my tests were wrong, there's a way around it with the very base system tools. The idea is simple: Say the box has two valid IP addresses A.A.A.A and B.B.B.B, and that at a given moment A.A.A.A is being used as the default route. Whenever the event telling the system to switch the routes to B.B.B.B happens, you could parse the current routing table and the current list of open connections, and add a temporary, static route for each of these entries pointing A.A.A.A (the current default gateway) as their gateway (route add X.X.X.X A.A.A.A (or A.A.A.A's remote peer) - where X.X.X.X is the address of one of the open connections). Once you do that for all the current active connections, they'll be guaranteed to stay up when the next step takes place. Now you'd remove the default gateway entry in your routing table and add B.B.B.B (or its remote peer) as the default gateway. From this point on, all connections will use this route as the default, and noone should see the change. The downpoint of this approach is that the system will have to monitor the active connections periodically and remove the static routes after their previously active connections finish; This is because if you don't do so, all connections to a given address will be routed out through the default route at the time the first switch was made and there was a connection to that address. Another concern would be the decrease in perfomance on the FreeBSD gateway if its routing table gets too large (over tens of thousands of static routes). What makes this to work is that static routes have priority over default ones. One could work this up from this point. =20 =20 Fred --=20 "Real programmers argue with the systems analyst as a matter of principle." --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/gDCnZNmEsrl+ROERAqMTAKC0l3UVy1Rt709qkwuRhyDlfLEh3QCgugGT W1zIKhbeI4JlYM1NlRViLyM= =8UqY -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS-- From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 5 08:28:58 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E8F316A4B3 for ; Sun, 5 Oct 2003 08:28:58 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id B527D4400B for ; Sun, 5 Oct 2003 08:28:50 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <4CQ6MM1K>; Sun, 5 Oct 2003 11:28:48 -0400 Message-ID: From: Don Bowman To: 'Wilko Bulte' , Kris Kennaway Date: Sun, 5 Oct 2003 11:28:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" cc: Richard Coleman cc: Mikulas Patocka cc: freebsd-hackers@freebsd.org Subject: RE: Hyperthreading slowdown X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2003 15:28:58 -0000 From: Wilko Bulte [mailto:wkb@freebie.xs4all.nl] > On Sat, Oct 04, 2003 at 01:04:35PM -0700, Kris Kennaway wrote: > > On Sat, Oct 04, 2003 at 03:20:03PM -0400, Richard Coleman wrote: > > > Kris Kennaway wrote: > > > >On Sat, Oct 04, 2003 at 04:39:03PM +0200, Mikulas Patocka wrote: > > > >>I installed FreeBSD 4.9RC1 on P4 3GHz with > hyperthreading and I see > > > >>drastic slowdown when kernel with hyperthreading is > booted. For example > > > >>program compilation took this time: > > > >> > > > >>hyperthreading kernel, make -j 1 --- 1:09 > > > >>hyperthreading kernel, make -j 2 --- 0:42 > > > >>singlethreading kernel, make -j 1 --- 0:45 > > > >>singlethreading kernel, make -j 2 --- 0:41 > > > >> > > > >>Compilation does very few system calls so when I > compile with only one > > > >>process (-j 1), it should be as fast as with > singlethreading kernel. Do > > > >>you have any idea why is it so slow? > > > > > > > >Do you realise that hyperthreading != a secret extra CPU > in your system? > > > > > > > >Kris > > > > > > I didn't see anywhere in the message where he implied > that. To me, the > > > interesting thing is that there is such a larger > difference between the > > > compile time for -j1 and -j2 when using hyperthreading as > compared to > > > the difference between -j1 and -j2 for a single threaded > kernel. It's > > > over a 50% slowdown. > > > > Yes, that's because (as discussed in the archives) the kernel treats > > it like an extra, completely decoupled physical CPU and schedules > > processes on it without further consideration. This is > presumably the > > cause of the slowdown, because it's only efficient to use > the virtual > > CPU under certain workload patterns. HTT is not magic performance > > beans. > > Right. And in addition it makes the system considerably more > power hungry.. > I measured both with and without SMP on my P4/2.4G HTT CPU. FWIW, if you set the machdep.cpu_idle_hlt=1, your power will go down considerably (our AC inlet power dropped 0.94A @ 110V). The performance will also go up considerably. HTT seems to get a lot of bad press on this list, and its due to this sysctl having the wrong default. If you are using an intel hyperthreading (aka symmetric multi threading) system, you should have machdep.cpu_idle_hlt=1 on. I emailed the poster this last week, and his performance rose dramatically. In our applications it also is much faster to use HTT than to have it off, since it hides the latencies associated with memory access. His comment after enabling halt was: >Thanks, that's it (maybe it should be enabled by default on HT kernels or >written as a comment around HTT option). Now it takes 41 seconds with -j 1 >(faster than non-ht kernel because it uses -pipe) and 32 to 38 seconds >with -j 2. > >Mikulas --don From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 5 08:32:14 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 746AB16A4B3 for ; Sun, 5 Oct 2003 08:32:14 -0700 (PDT) Received: from xeon.unixathome.org (bast.unixathome.org [66.11.174.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07FDB43FE3 for ; Sun, 5 Oct 2003 08:32:13 -0700 (PDT) (envelope-from dan@langille.org) Received: by xeon.unixathome.org (Postfix, from userid 1000) id 4FCC43E4F; Sun, 5 Oct 2003 11:32:11 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by xeon.unixathome.org (Postfix) with ESMTP id 4636C3E4E for ; Sun, 5 Oct 2003 11:32:11 -0400 (EDT) Date: Sun, 5 Oct 2003 11:32:11 -0400 (EDT) From: Dan Langille X-X-Sender: dan@xeon.unixathome.org To: freebsd-hackers@freebsd.org Message-ID: <20031005111656.R18760@xeon.unixathome.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: testing for substrings in perl X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2003 15:32:14 -0000 Hi, I have a perl regex to test if a file resides under a particular directory. The test looks like this: if ($filename =~ $directory) { # yes, this filename resides under directory } This is working for most cases. However, it fails is the directory contains a +. For example: $filename = 'ports/www/privoxy+ipv6/files/patch-src::addrlist.c'; $match = "^/?" . 'ports/www/privoxy+ipv6' . "/"; if ($filename =~ $match) { print "found\n"; } else{ print "NOT found\n"; } Yes, I can escapte the + in the directory name, but then I'd have to test for all those special regex characters and escape them too. I think it might just be easier to do a straight comparison of the first N characters of the two strings where N = length of the directory name. Any suggestions? thanks From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 5 08:47:09 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C77E516A4B3 for ; Sun, 5 Oct 2003 08:47:09 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1ABBC43FCB for ; Sun, 5 Oct 2003 08:47:09 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <4CQ6MMF1>; Sun, 5 Oct 2003 11:47:08 -0400 Message-ID: From: Don Bowman To: 'Leo Bicknell' , freebsd-hackers@freebsd.org Date: Sun, 5 Oct 2003 11:47:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Changing the NAT IP on demand? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2003 15:47:09 -0000 From: Leo Bicknell [mailto:bicknell@ufp.org] > > I'm considering options for a new project, and I think I've discovered > what I think is the best idea, but I don't think current software > supports the config. I'd like to get some confirmation, and > comments on > if it would be hard to implement. > > Consider: > > > ISP #1-------\ > \ > FreeBSD Box----LAN > / > ISP #2-------/ > > In this case the LAN would be 1918 space, the two ISP's would each > provide a public IP for the FreeBSD box. > > Now, NAT would be required. What I want to do is write an external > application to decide the performance of ISP #1 and ISP#2, and > somehow tell NAT which outside address to use. > > That, by itself, is not hard. Here's the trick. I want the switch > to be seamless. That is, if NAT is translating to ISP #1 and the > application says switch to #2 the existing translations to #1 (until > they go away naturally) should be kept, while new ones go to #2. > > The only ways I know to change the outside address seem to tear down > all existing connections. > > Is it possible to make this work today? Would it be hard to fix if > it doesn't work today? i wonder if ipfw stateful rules can be used to keep sessions bound to the same instance of natd, thus keeping the same external address for the duration of the layer-4 session? From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 5 09:26:34 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C46F016A4B3 for ; Sun, 5 Oct 2003 09:26:34 -0700 (PDT) Received: from storming.org (MG035035.user.veloxzone.com.br [200.165.35.35]) by mx1.FreeBSD.org (Postfix) with SMTP id E9F7A43FEC for ; Sun, 5 Oct 2003 09:26:32 -0700 (PDT) (envelope-from fred@storming.org) Received: (qmail 1225 invoked by uid 1000); 5 Oct 2003 13:26:31 -0300 Date: Sun, 5 Oct 2003 13:26:30 -0300 From: Fred Souza To: Dan Langille Message-ID: <20031005162630.GA1158@torment.storming.org> References: <20031005111656.R18760@xeon.unixathome.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline In-Reply-To: <20031005111656.R18760@xeon.unixathome.org> X-Sender: fred@storming.org cc: freebsd-hackers@freebsd.org Subject: Re: testing for substrings in perl X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: fred@storming.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2003 16:26:34 -0000 --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > I think it might just be easier to do a straight comparison of the first N > characters of the two strings where N =3D length of the directory name. >=20 > Any suggestions? You might try index() or substr(). Fred --=20 "MOTHER: Half a word." --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/gEY2ZNmEsrl+ROERAm3LAKChsuRvqdjsdIFFFytsy32ZT0xrBgCgtY5G KDzF/R8wCb8VffhjfF75B/g= =/qxq -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu-- From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 5 09:41:12 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAF7E16A4C1 for ; Sun, 5 Oct 2003 09:41:12 -0700 (PDT) Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id B56C243FE3 for ; Sun, 5 Oct 2003 09:41:11 -0700 (PDT) (envelope-from mbsd@pacbell.net) Received: from atlas (adsl-64-165-199-197.dsl.snfc21.pacbell.net [64.165.199.197]) by mta7.pltn13.pbi.net (8.12.9/8.12.3) with ESMTP id h95GfB1S005450; Sun, 5 Oct 2003 09:41:11 -0700 (PDT) Date: Sun, 5 Oct 2003 09:41:10 -0700 (PDT) From: =?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= X-X-Sender: mikko@atlas.home To: Dan Langille In-Reply-To: <20031005111656.R18760@xeon.unixathome.org> Message-ID: <20031005092645.J3248@atlas.home> References: <20031005111656.R18760@xeon.unixathome.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: testing for substrings in perl X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2003 16:41:13 -0000 On Sun, 5 Oct 2003, Dan Langille wrote: > Hi, > > I have a perl regex to test if a file resides under a particular > directory. The test looks like this: > > if ($filename =~ $directory) { > # yes, this filename resides under directory > } > > This is working for most cases. However, it fails is the directory > contains a +. For example: > > $filename = 'ports/www/privoxy+ipv6/files/patch-src::addrlist.c'; > > $match = "^/?" . 'ports/www/privoxy+ipv6' . "/"; > if ($filename =~ $match) { > print "found\n"; > } else{ > print "NOT found\n"; > } > > Yes, I can escapte the + in the directory name, but then I'd have to test > for all those special regex characters and escape them too. Or use quotemeta()... > I think it might just be easier to do a straight comparison of the first N > characters of the two strings where N = length of the directory name. > > Any suggestions? ...or the \Q operator. Thus: $filename = 'ports/www/privoxy+ipv6/files/patch-src::addrlist.c'; $dir = 'ports/www/privoxy+ipv6'; if ($filename =~ m:^/?\Q$dir\E/:) { print "found\n"; } else{ print "NOT found\n"; } $.02, /Mikko From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 5 09:43:26 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03C2E16A4B3 for ; Sun, 5 Oct 2003 09:43:26 -0700 (PDT) Received: from smtp.infracaninophile.co.uk (ns0.infracaninophile.co.uk [81.2.69.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A13743FBD for ; Sun, 5 Oct 2003 09:43:24 -0700 (PDT) (envelope-from m.seaman@infracaninophile.co.uk) Received: from happy-idiot-talk.infracaninophile.co.uk (localhost [127.0.0.1]) h95GhF9E060895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Oct 2003 17:43:20 +0100 (BST) (envelope-from matthew@happy-idiot-talk.infracaninophile.co.uk) Received: (from matthew@localhost)id h95GhEKH060894; Sun, 5 Oct 2003 17:43:14 +0100 (BST) (envelope-from matthew) Date: Sun, 5 Oct 2003 17:43:14 +0100 From: Matthew Seaman To: Dan Langille Message-ID: <20031005164314.GA60739@happy-idiot-talk.infracaninophile.co.uk> Mail-Followup-To: Dan Langille , freebsd-hackers@freebsd.org References: <20031005111656.R18760@xeon.unixathome.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline In-Reply-To: <20031005111656.R18760@xeon.unixathome.org> User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on happy-idiot-talk.infracaninophile.co.uk cc: freebsd-hackers@freebsd.org Subject: Re: testing for substrings in perl X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2003 16:43:26 -0000 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 05, 2003 at 11:32:11AM -0400, Dan Langille wrote: > Hi, >=20 > I have a perl regex to test if a file resides under a particular > directory. The test looks like this: >=20 > if ($filename =3D~ $directory) { > # yes, this filename resides under directory > } >=20 > This is working for most cases. However, it fails is the directory > contains a +. For example: >=20 > $filename =3D 'ports/www/privoxy+ipv6/files/patch-src::addrlist.c'; >=20 > $match =3D "^/?" . 'ports/www/privoxy+ipv6' . "/"; > if ($filename =3D~ $match) { > print "found\n"; > } else{ > print "NOT found\n"; > } >=20 > Yes, I can escapte the + in the directory name, but then I'd have to test > for all those special regex characters and escape them too. That's why perl has the \Q...\E metasymbols: Try: $match =3D qr{^/?\Q$dirname\E/}; See perldoc perlre for details. Cheers, Matthew =09 --=20 Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/gEoidtESqEQa7a0RAkNZAJ0TKLvKNDTpDHZ2A2gdMovT76+0IgCfSnxR Mf5zNo444doKLwtyLfr0J/8= =eUbW -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 5 10:38:57 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E77B16A4B3 for ; Sun, 5 Oct 2003 10:38:57 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCE0243FE9 for ; Sun, 5 Oct 2003 10:38:56 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.9/8.12.6) with ESMTP id h95HcsKw052024; Sun, 5 Oct 2003 10:38:54 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9/8.12.6/Submit) id h95Hcslx052023; Sun, 5 Oct 2003 10:38:54 -0700 (PDT) (envelope-from dillon) Date: Sun, 5 Oct 2003 10:38:54 -0700 (PDT) From: Matthew Dillon Message-Id: <200310051738.h95Hcslx052023@apollo.backplane.com> To: Don Bowman References: cc: freebsd-hackers@freebsd.org cc: Kris Kennaway Subject: RE: Hyperthreading slowdown X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2003 17:38:57 -0000 :FWIW, if you set the machdep.cpu_idle_hlt=1, your power will :go down considerably (our AC inlet power dropped 0.94A @ 110V). :The performance will also go up considerably. : :HTT seems to get a lot of bad press on this list, and its due :to this sysctl having the wrong default. Sheesh, nobody has fixed HLT's (minor) performance issues yet? All it takes is something like this: i386/i386/machdep.c, cpu_idle(): ... if (cpu_idle_hlt) { disable_intr(); PCPU_SET(amhalted, 1); if (sched_runnable()) { enable_intr(); } else { /* * we must absolutely guarentee that hlt is the * absolute next instruction after sti or we * introduce a timing window. */ __asm __volatile("sti; hlt"); } PCPU_SET(amhalted, 0); } And then somewhere in the scheduler's wakeup code: ... targetcpu = td->td_lastcpu; if (targetcpu >= 0 && PCPUFORCPUID(targetcpu)->amhalted) { PCPUFORCPUID(targetcpu)->amhalted = 0; /* ignore cache coherency race*/ ... queue async IPI to wakeup targetcpu ... } So if the target thread wants to be woken up on a particular cpu (cpu affinity), then we IPI that cpu. If the target thread doesn't care we let the clock interrupt deal with it. I'll leave it others to figure out how to get the per-cpu structure pointer for a particular cpu and where to put the code, but basically that is all you have to do and then you can make cpu_idle_hlt the default, saving all the headaches. One could even send the IPI passively.. that is, if the APIC is already busy you just give up. If the APIC isn't busy you queue the IPI and return. And if you are worried about sleep/wakeup ping-ponging between two processes becoming non-optimal, just have the idle loop loop for a few microseconds before it actually HLT's. It's a no-brainer. -Matt From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 5 11:21:46 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CC9916A4B3 for ; Sun, 5 Oct 2003 11:21:46 -0700 (PDT) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0363043FAF for ; Sun, 5 Oct 2003 11:21:46 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from foogate.softweyr.com (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id B26D75B652; Sun, 5 Oct 2003 11:20:19 -0700 (PDT) From: Wes Peters Organization: Softweyr LLC To: "Dan Langille" , Daniel Eischen Date: Sun, 5 Oct 2003 11:21:29 -0700 User-Agent: KMail/1.5.2 References: <3F77D27E.6203.3321BA14@localhost> <3F7E9F1D.14593.4DB108E2@localhost> In-Reply-To: <3F7E9F1D.14593.4DB108E2@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310051121.29282.wes@softweyr.com> cc: hackers@freebsd.org Subject: Re: [PATCH] : libc_r/uthread/uthread_write.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2003 18:21:46 -0000 On Saturday 04 October 2003 07:21 am, Dan Langille wrote: > On 4 Oct 2003 at 10:17, Daniel Eischen wrote: > > On Mon, 29 Sep 2003, Dan Langille wrote: > > > All our testing on this patch has been successful. I'm going to > > > do a few more tests on different hardware under 4.8-stable. > > > > > > What's the next step? Commit it? Get others to test with it > > > first? > > > > It's already in -current. > > Thanks for that commit. > > > You'll have to wait for the code > > freeze to thaw in -stable before it goes in there. > > Bugger... which means it won't be into 4.9-RELEASE. If it is important, forward the code and the reason it is needed to re@. Code freeze means 'only critical bug fixes'; if this is one of those, let's get it in. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 5 13:43:05 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F08016A4B3; Sun, 5 Oct 2003 13:43:05 -0700 (PDT) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DD7D43FDD; Sun, 5 Oct 2003 13:43:03 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from foogate.softweyr.com (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 2417B5B6AB; Sun, 5 Oct 2003 13:41:37 -0700 (PDT) From: Wes Peters Organization: Softweyr LLC To: Nick Rogness , Leo Bicknell Date: Sun, 5 Oct 2003 13:43:01 -0700 User-Agent: KMail/1.5.2 References: <20031005014620.H45148-100000@skywalker.rogness.net> In-Reply-To: <20031005014620.H45148-100000@skywalker.rogness.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310051343.01251.wes@softweyr.com> cc: darrenr@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: Changing the NAT IP on demand? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2003 20:43:05 -0000 On Sunday 05 October 2003 01:02 am, Nick Rogness wrote: > On Sat, 4 Oct 2003, Leo Bicknell wrote: > > I'm considering options for a new project, and I think I've > > discovered what I think is the best idea, but I don't think current > > software supports the config. I'd like to get some confirmation, > > and comments on if it would be hard to implement. > > > > Consider: > > > > > > ISP #1-------\ > > \ > > FreeBSD Box----LAN > > / > > ISP #2-------/ > > > > In this case the LAN would be 1918 space, the two ISP's would each > > provide a public IP for the FreeBSD box. > > > > Now, NAT would be required. What I want to do is write an external > > application to decide the performance of ISP #1 and ISP#2, and > > somehow tell NAT which outside address to use. > > > > That, by itself, is not hard. Here's the trick. I want the switch > > to be seamless. That is, if NAT is translating to ISP #1 and the > > application says switch to #2 the existing translations to #1 > > (until they go away naturally) should be kept, while new ones go to > > #2. > > > > The only ways I know to change the outside address seem to tear > > down all existing connections. > > > > Is it possible to make this work today? Would it be hard to fix if > > it doesn't work today? > > This can simply not work without resetting connections. The > socket pair on the "outside" would break as your outside traffic > switches from one to the other (src/dst would change). There is > no fix, as this breaks basic IP principals. That's not at all what Leo was asking. Leo, you may be able to do this with ipfilter's ipnat. Nat rules are traditionally processed with 'ipnat -CF', the -C clears the rules and the -F option clears the currently active NAT mappings. You should experiment with rewriting the rules and instantiating them with -C only. This should leave the existing stateful mappings to the formerly preferred interface while creating all new mappings on the newly preferred interface. This might tend to confuse UDP-based services, which might see the next request as a different 'session', but I doubt those are much a problem across the internet. Good luck. If you run into bugs, I've always found Darren Reed to be helpful and interested in improving ipfilter/ipnat. This might even be a feature that intriques him enough to pique his interest in making it a feature of ipnat. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 5 17:45:24 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96F3816A4B3 for ; Sun, 5 Oct 2003 17:45:24 -0700 (PDT) Received: from ussenterprise.ufp.org (ussenterprise.ufp.org [208.185.30.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4115A43FA3 for ; Sun, 5 Oct 2003 17:45:23 -0700 (PDT) (envelope-from bicknell@ussenterprise.ufp.org) Received: from ussenterprise.ufp.org (bicknell@localhost [127.0.0.1]) by ussenterprise.ufp.org (8.12.9/8.12.9) with ESMTP id h960jM8i062521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 5 Oct 2003 20:45:22 -0400 (EDT) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.12.9/8.12.9/Submit) id h960jMkS062520 for freebsd-hackers@freebsd.org; Sun, 5 Oct 2003 20:45:22 -0400 (EDT) Date: Sun, 5 Oct 2003 20:45:22 -0400 From: Leo Bicknell To: freebsd-hackers@freebsd.org Message-ID: <20031006004522.GA62232@ussenterprise.ufp.org> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20031004235400.GA20943@ussenterprise.ufp.org> <3F801CA7.60201@iconoplex.co.uk> <20031005145431.GA42245@torment.storming.org> <20031004235400.GA20943@ussenterprise.ufp.org> <3F801CA7.60201@iconoplex.co.uk> <20031005014620.H45148-100000@skywalker.rogness.net> <200310051343.01251.wes@softweyr.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr" Content-Disposition: inline In-Reply-To: <20031005145431.GA42245@torment.storming.org> <3F801CA7.60201@iconoplex.co.uk> <200310051343.01251.wes@softweyr.com> Organization: United Federation of Planets X-PGP-Key: http://www.ufp.org/~bicknell/ Subject: Re: Changing the NAT IP on demand? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2003 00:45:24 -0000 --liOOAslEiF7prFVr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In a message written on Sun, Oct 05, 2003 at 01:43:01PM -0700, Wes Peters w= rote: > Leo, you may be able to do this with ipfilter's ipnat. Nat rules are=20 > traditionally processed with 'ipnat -CF', the -C clears the rules and=20 > the -F option clears the currently active NAT mappings. You should=20 > experiment with rewriting the rules and instantiating them with -C=20 > only. This should leave the existing stateful mappings to the formerly= =20 > preferred interface while creating all new mappings on the newly=20 > preferred interface. That's interesting. I've never used ipnat before with ipfilter, but from some quick man page reads that looks good. Save a second problem I just noticed...see below. > This might tend to confuse UDP-based services, which might see the next= =20 > request as a different 'session', but I doubt those are much a problem=20 > across the internet. TCP only is good for my application. In a message written on Sun, Oct 05, 2003 at 02:29:11PM +0100, Paul Robinso= n wrote: > Depends on how much money you have, but had you considered getting your= =20 > own address range and BGP peering with your ISPs? I'd consider talking=20 > to them about it. It'll take some time to setup, but it means your=20 > "switching" is done at the router, not at the NAT box, which is the=20 > wrong place to do it anyway. This application is for cheap + fast redundancy. Think getting 2xDSL line, or DSL + Cable modem for a quick conference / classroom deal and wanting some redundancy. In a message written on Sun, Oct 05, 2003 at 11:54:31AM -0300, Fred Souza w= rote: > If I understood what Leo asked correctly, what's needed is to change > the default route on the FreeBSD gateway whenever an event tells it > to (in this case, the increase/decrease in performance for the ISPs). > The concern here is to keep currently-stablished connections alive, so > the process is carried out seamlessly. Actually, no not exactly, but this brings up a new problem. If you have box with link A, and IP a.a.a.a, and link B, and IP b.b.b.b I want a packet with source address b.b.b.b to have a "default route" out link B, and a packet with source a.a.a.a to route out link A. I then want NAT to be able to switch, on the fly from using a.a.a.a, or b.b.b.b. So, in network speak I want to "policy route", and the do NAT to two different IP's, with only one active at a time. I'd then do some external monitoring to decide which IP to use. Again, think like 2xDSL line, 1 (possibly dynamic) IP from each. Do the policy route (eg if you wrote an application on the box to bind to a.a.a.a or b.b.b.b it would use only that link) thing, and then have NAT pick an IP on the fly. They key is when nat switches not to dump the existing connections so it appears to be a "seamless" switch over. --=20 Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org --liOOAslEiF7prFVr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/gLsiNh6mMG5yMTYRAnrQAJ9+mKn9Fjz961e9S4/LVXK8Zu0c6wCcCGxN xhdEqvVUNDLTo/EqtvrPXZw= =WdR1 -----END PGP SIGNATURE----- --liOOAslEiF7prFVr-- From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 5 19:05:33 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6107716A4B3; Sun, 5 Oct 2003 19:05:33 -0700 (PDT) Received: from skywalker.rogness.net (skywalker.rogness.net [64.251.173.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C97643FB1; Sun, 5 Oct 2003 19:05:32 -0700 (PDT) (envelope-from nick@rogness.net) Received: from skywalker.rogness.net (localhost [127.0.0.1]) by skywalker.rogness.net (8.12.5/8.12.5) with ESMTP id h962B8Vs047326; Sun, 5 Oct 2003 20:11:08 -0600 (MDT) (envelope-from nick@rogness.net) Received: from localhost (nick@localhost)h962B7ru047323; Sun, 5 Oct 2003 20:11:07 -0600 (MDT) X-Authentication-Warning: skywalker.rogness.net: nick owned process doing -bs Date: Sun, 5 Oct 2003 20:11:05 -0600 (MDT) From: Nick Rogness To: Wes Peters In-Reply-To: <200310051343.01251.wes@softweyr.com> Message-ID: <20031005193343.F47183-100000@skywalker.rogness.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: darrenr@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: Changing the NAT IP on demand? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2003 02:05:33 -0000 On Sun, 5 Oct 2003, Wes Peters wrote: > On Sunday 05 October 2003 01:02 am, Nick Rogness wrote: > > On Sat, 4 Oct 2003, Leo Bicknell wrote: > > > I'm considering options for a new project, and I think I've > > > discovered what I think is the best idea, but I don't think current > > > software supports the config. I'd like to get some confirmation, > > > and comments on if it would be hard to implement. > > > > > > Consider: > > > > > > > > > ISP #1-------\ > > > \ > > > FreeBSD Box----LAN > > > / > > > ISP #2-------/ > > > > > > In this case the LAN would be 1918 space, the two ISP's would each > > > provide a public IP for the FreeBSD box. > > > > > > Now, NAT would be required. What I want to do is write an external > > > application to decide the performance of ISP #1 and ISP#2, and > > > somehow tell NAT which outside address to use. > > > > > > That, by itself, is not hard. Here's the trick. I want the switch > > > to be seamless. That is, if NAT is translating to ISP #1 and the > > > application says switch to #2 the existing translations to #1 (until > > > they go away naturally) should be kept, while new ones go to #2. > > > > > > The only ways I know to change the outside address seem to tear > > > down all existing connections. > > > > > > Is it possible to make this work today? Would it be hard to fix if > > > it doesn't work today? > > > > This can simply not work without resetting connections. The > > socket pair on the "outside" would break as your outside traffic > > switches from one to the other (src/dst would change). There is > > no fix, as this breaks basic IP principals. > > That's not at all what Leo was asking. Sorry bout that, didn't read carefully enough. I understand the question now after more careful reading. > > Leo, you may be able to do this with ipfilter's ipnat. Nat rules are > traditionally processed with 'ipnat -CF', the -C clears the rules and > the -F option clears the currently active NAT mappings. You should > experiment with rewriting the rules and instantiating them with -C only. > This should leave the existing stateful mappings to the formerly > preferred interface while creating all new mappings on the newly > preferred interface. In addition to keeping your NAT translations (as suggested by Wes), you need to also keep routes for those entries as well, so that preserved traffic remains to route out the right ISP even if a switch occurs. The reason for this is simple. When you switch the route(s) to the other ISP (which you would have to do), your existing translations would get routed out to the wrong ISP. You would need to keep routes for existing translations to make sure they leave the proper 'old' interface. This would not be necessary if each ISP allowed you to use either public IP on each others network (not likely). Nat (AFAIK) does not determine which interface to leave. You can change the source address in the packet to anything you want, this will not tell it to leave 'interace_to_ISP#1' or 'interface_to_ISP#2'. That is a decision made using the routing table. Your app would have to keep track of these NAT things and also add and remove routes from the routing table. That is, if everything is going out ISP#1 and you decide to switch to ISP#2 you would need to: 1) Keep exisiting NAT translation(s) like suggested by Wes. 2) Add routing table entry for each of the NAT translations you want to preserve to ISP#1 3) Switch default routing to ISP#2 4) When sessions are finsihed and NAT translations removed to ISP#1, the route(s) that pertain to those NAT translations would need to be removed. Nick Rogness - How many people here have telekenetic powers? Raise my hand. -Emo Philips From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 6 00:06:34 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C1CE16A4B3 for ; Mon, 6 Oct 2003 00:06:34 -0700 (PDT) Received: from priv-edtnes46.telusplanet.net (defout.telus.net [199.185.220.240]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E0FE43FDD for ; Mon, 6 Oct 2003 00:06:33 -0700 (PDT) (envelope-from sh@bel.bc.ca) Received: from antalus ([154.5.106.237]) by priv-edtnes46.telusplanet.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with SMTP id <20031006070632.RZOY22757.priv-edtnes46.telusplanet.net@antalus> for ; Mon, 6 Oct 2003 01:06:32 -0600 Message-ID: <000501c38bd8$6016ce50$0300000a@antalus> From: "Sean Hamilton" To: Date: Mon, 6 Oct 2003 00:06:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: VT8237 serial-ATA support, Promise ATA stalls, GEOM noise X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2003 07:06:34 -0000 I'm looking to replace an aging fileserver with an Asus A7V600 board. Presently it appears FreeBSD does not support the serial ATA interface on the south bridge. As this appears to be the first Via serial ATA controller, am I safe in assuming this will not be supported for some time? I have two Asus boards (A7V8X and A7V) which have in common a Promise ATA controller. Both of these boards hang up for about a minute during the boot of 5.1-RELEASE, and emit messages about ad* devices being reset -- I cannot paste them verbatim as they seem to have been omitted from my dmesg. In the case of the A7V8X, the controller is unused and disabled in the BIOS. Has this been rectified for 5.2? When using atacontrol's software RAID functionality, GEOM laments "Opened disk ad6 -> 1" at boot. This seems like benign noise, perhaps it should be removed -- it appears to be a forgotten debug message, /sys/geom/geom_disk.c 1.72, line 115. From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 6 00:11:00 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39A1B16A4BF for ; Mon, 6 Oct 2003 00:11:00 -0700 (PDT) Received: from spider.deepcore.dk (cpe.atm2-0-56339.0x50c6aa0a.abnxx2.customer.tele.dk [80.198.170.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F9AF43FE1 for ; Mon, 6 Oct 2003 00:10:58 -0700 (PDT) (envelope-from sos@spider.deepcore.dk) Received: from spider.deepcore.dk (localhost [127.0.0.1]) by spider.deepcore.dk (8.12.9/8.12.9) with ESMTP id h967Ap5t040749; Mon, 6 Oct 2003 09:10:51 +0200 (CEST) (envelope-from sos@spider.deepcore.dk) Received: (from sos@localhost) by spider.deepcore.dk (8.12.9/8.12.9/Submit) id h967ApF0040748; Mon, 6 Oct 2003 09:10:51 +0200 (CEST) From: Soren Schmidt Message-Id: <200310060710.h967ApF0040748@spider.deepcore.dk> In-Reply-To: <000501c38bd8$6016ce50$0300000a@antalus> To: Sean Hamilton Date: Mon, 6 Oct 2003 09:10:51 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL99f (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 X-mail-scanned: by DeepCore Virus & Spam killer v1.3 cc: hackers@FreeBSD.ORG Subject: Re: VT8237 serial-ATA support, Promise ATA stalls, GEOM noise X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2003 07:11:00 -0000 It seems Sean Hamilton wrote: > I'm looking to replace an aging fileserver with an Asus A7V600 board. > Presently it appears FreeBSD does not support the serial ATA interface on > the south bridge. As this appears to be the first Via serial ATA controller, > am I safe in assuming this will not be supported for some time? Probably, VIA has newer been keen on sharing docs, so this can take some time to get done and might just stall until I get such HW here to do the needed magic on. > I have two Asus boards (A7V8X and A7V) which have in common a Promise ATA > controller. Both of these boards hang up for about a minute during the boot > of 5.1-RELEASE, and emit messages about ad* devices being reset -- I cannot > paste them verbatim as they seem to have been omitted from my dmesg. In the > case of the A7V8X, the controller is unused and disabled in the BIOS. Has > this been rectified for 5.2? Should not happen on -current. -Søren From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 6 05:09:37 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 259CE16A4B3 for ; Mon, 6 Oct 2003 05:09:37 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 844CF43FFD for ; Mon, 6 Oct 2003 05:09:32 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id D39466542F; Mon, 6 Oct 2003 13:09:30 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 30359-01; Mon, 6 Oct 2003 13:09:30 +0100 (BST) Received: from saboteur.dek.spc.org (unknown [81.3.72.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id B90BA65400; Mon, 6 Oct 2003 13:09:29 +0100 (BST) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id F19EA15; Mon, 6 Oct 2003 13:09:20 +0100 (BST) Date: Mon, 6 Oct 2003 13:09:20 +0100 From: Bruce M Simpson To: matt@domsch.com Message-ID: <20031006120920.GC31567@saboteur.dek.spc.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JYK4vJDZwFMowpUq" Content-Disposition: inline cc: hackers@FreeBSD.org cc: chuck@NetBSD.org Subject: afaapps port committed to FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2003 12:09:37 -0000 --JYK4vJDZwFMowpUq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I'm a FreeBSD src committer who deals with Dell hardware a lot. I've just committed a port of afaapps to FreeBSD. I should be grateful if you could add this to your extremely useful list of resources. Please pass on my sincere thanks to your colleagues at Dell for providing us with these tools. I've tested the tools with Scott Long's aac(4) driver. This has a passthrough for the ioctls which the afacli tool uses. Version 2.7 of the tools, with a PowerEdge 2400 chassis' Dell PERC 2/Si running firmware 2.1, work perfectly under Linux emulation in FreeBSD 4.9-RC. I understand that Dell do not officially support FreeBSD; members of the Project certainly hope that will change in future, as the forthcoming 5.2 release is looking very promising. I also understand that distribution restrictions exist on Dell software, therefore the port has been marked RESTRICTED (binaries will not be distributed as part of FreeBSD releases), in accordance with Dell's wishes. Kind regards, Bruce M. Simpson <---> bms@spc.org / bms@FreeBSD.org / vm/net hacker --JYK4vJDZwFMowpUq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQE/gVtvueUpAYYNtTsRAku4AJ9lMxGnHAoCSMC6UmQoLHzstlXkEACeLrr2 uuW47awzRAFL4URT+daG4es= =e6Wt -----END PGP SIGNATURE----- --JYK4vJDZwFMowpUq-- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 6 06:29:20 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C075D16A4B3 for ; Mon, 6 Oct 2003 06:29:20 -0700 (PDT) Received: from comp.chem.msu.su (comp-ext.chem.msu.su [158.250.32.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id E34C443FE1 for ; Mon, 6 Oct 2003 06:29:12 -0700 (PDT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.12.3p3/8.12.3) with ESMTP id h96DSx4Z072775 for ; Mon, 6 Oct 2003 17:28:59 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.12.3p3/8.12.3/Submit) id h96DSwJo072774 for freebsd-hackers@freebsd.org; Mon, 6 Oct 2003 17:28:58 +0400 (MSD) (envelope-from yar) Date: Mon, 6 Oct 2003 17:28:57 +0400 From: Yar Tikhiy To: freebsd-hackers@freebsd.org Message-ID: <20031006132857.GA71659@comp.chem.msu.su> References: <20031004235400.GA20943@ussenterprise.ufp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031004235400.GA20943@ussenterprise.ufp.org> User-Agent: Mutt/1.5.3i Subject: Re: Changing the NAT IP on demand? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2003 13:29:20 -0000 On Sat, Oct 04, 2003 at 07:54:00PM -0400, Leo Bicknell wrote: > > That, by itself, is not hard. Here's the trick. I want the switch > to be seamless. That is, if NAT is translating to ISP #1 and the > application says switch to #2 the existing translations to #1 (until > they go away naturally) should be kept, while new ones go to #2. Just a random thought: If natd(8) were taught to change its default alias address on the fly (it's just a single variable,) then the desired effect would be achieved exactly. That's because any session already having its own entry in natd's aliasing table would use its old alias address kept in the entry. BTW, one could switch between even more than 2 external connections in that manner. And that's just a step away from session-aware load-balancing with natd(8). -- Yar From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 6 06:43:50 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 892FE16A4B3 for ; Mon, 6 Oct 2003 06:43:50 -0700 (PDT) Received: from ussenterprise.ufp.org (ussenterprise.ufp.org [208.185.30.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8566E43FEA for ; Mon, 6 Oct 2003 06:43:47 -0700 (PDT) (envelope-from bicknell@ussenterprise.ufp.org) Received: from ussenterprise.ufp.org (bicknell@localhost [127.0.0.1]) by ussenterprise.ufp.org (8.12.9/8.12.9) with ESMTP id h96Dhk8i085394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 6 Oct 2003 09:43:47 -0400 (EDT) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.12.9/8.12.9/Submit) id h96Dhkde085393 for freebsd-hackers@freebsd.org; Mon, 6 Oct 2003 09:43:46 -0400 (EDT) Date: Mon, 6 Oct 2003 09:43:46 -0400 From: Leo Bicknell To: freebsd-hackers@freebsd.org Message-ID: <20031006134346.GA84944@ussenterprise.ufp.org> Mail-Followup-To: freebsd-hackers@freebsd.org References: <20031004235400.GA20943@ussenterprise.ufp.org> <20031006132857.GA71659@comp.chem.msu.su> <200310051343.01251.wes@softweyr.com> <20031005193343.F47183-100000@skywalker.rogness.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <20031006132857.GA71659@comp.chem.msu.su> <20031005193343.F47183-100000@skywalker.rogness.net> Organization: United Federation of Planets X-PGP-Key: http://www.ufp.org/~bicknell/ Subject: Re: Changing the NAT IP on demand? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2003 13:43:50 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In a message written on Sun, Oct 05, 2003 at 08:11:05PM -0600, Nick Rogness= wrote: > In addition to keeping your NAT translations (as suggested by > Wes), you need to also keep routes for those entries as well, so > that preserved traffic remains to route out the right ISP even if > a switch occurs. You're right, however I would go with a different mechanism, but one I've also never tried to do. What you want is routing based on the source address of the packet, not the destination as per usual. You want to be able to say "source a.a.a.a goes out link A". I've never tried to do it on FreeBSD (it's easy on say Cisco's, with a bit of a performance hit on some platforms). =20 In a message written on Mon, Oct 06, 2003 at 05:28:57PM +0400, Yar Tikhiy w= rote: > Just a random thought: If natd(8) were taught to change its default > alias address on the fly (it's just a single variable,) then the > desired effect would be achieved exactly. That's because any session > already having its own entry in natd's aliasing table would use its > old alias address kept in the entry. BTW, one could switch between > even more than 2 external connections in that manner. And that's > just a step away from session-aware load-balancing with natd(8). That's exactly what I was thinking, and more or less why I asked. Note, I think this configuration would be useful in a lot of other applications as well. Consider someone who can get, say, a 128k symmetric DSL line, and a 56k up 1M down satellite link. If using this "trick" you could direct latency sensitive (ssh, telnet, ntp) traffic over the DSL line, and send bulk data (http, ftp) over the satellite link that could be quite useful. I think I'm going to have to set up a lab box now and dig into this at a deeper level. --=20 Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/gXGSNh6mMG5yMTYRAkTFAJ9Rhv6q5LI6I1shQduxWUMZZiZlfQCfUWsb Y4PmF5CZ0Gzt8kJ7gakGu0Q= =3b5F -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO-- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 6 08:04:20 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41AC816A4BF for ; Mon, 6 Oct 2003 08:04:20 -0700 (PDT) Received: from mail.seekingfire.com (coyote.seekingfire.com [24.72.10.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2483743FA3 for ; Mon, 6 Oct 2003 08:04:18 -0700 (PDT) (envelope-from tillman@seekingfire.com) Received: from blues.seekingfire.prv (blues.seekingfire.prv [192.168.23.211]) by mail.seekingfire.com (Postfix) with ESMTP id CE47056 for ; Mon, 6 Oct 2003 09:04:16 -0600 (CST) Received: (from tillman@localhost) by blues.seekingfire.prv (8.11.6/8.11.6) id h96F4G213924 for freebsd-hackers@freebsd.org; Mon, 6 Oct 2003 09:04:16 -0600 Date: Mon, 6 Oct 2003 09:04:16 -0600 From: Tillman Hodgson To: freebsd-hackers@freebsd.org Message-ID: <20031006090416.I11569@seekingfire.com> References: <20031004235400.GA20943@ussenterprise.ufp.org> <20031006132857.GA71659@comp.chem.msu.su> <200310051343.01251.wes@softweyr.com> <20031005193343.F47183-100000@skywalker.rogness.net> <20031006132857.GA71659@comp.chem.msu.su> <20031006134346.GA84944@ussenterprise.ufp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20031006134346.GA84944@ussenterprise.ufp.org>; from bicknell@ufp.org on Mon, Oct 06, 2003 at 09:43:46AM -0400 X-Urban-Legend: There is lots of hidden information in headers Subject: Re: Changing the NAT IP on demand? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2003 15:04:20 -0000 On Mon, Oct 06, 2003 at 09:43:46AM -0400, Leo Bicknell wrote: > In a message written on Sun, Oct 05, 2003 at 08:11:05PM -0600, Nick Rogness wrote: > > In addition to keeping your NAT translations (as suggested by > > Wes), you need to also keep routes for those entries as well, so > > that preserved traffic remains to route out the right ISP even if > > a switch occurs. > > You're right, however I would go with a different mechanism, but one > I've also never tried to do. What you want is routing based on the > source address of the packet, not the destination as per usual. You > want to be able to say "source a.a.a.a goes out link A". I've never > tried to do it on FreeBSD (it's easy on say Cisco's, with a bit of a > performance hit on some platforms). This can be done with ipfw's 'fwd' or ipf's 'pass out quick on '. It's not a clean solution, though - looking at the routing table won't tell you that yoru firewall is routing some/all of the packets. Another interesting approach is splitting NAT traffic across two lines by destination. I'm using ipf rather than ipfw to do this, but the principle is the same. A simplified snippet from my ipnat.rules: # Map all regular traffic out the cablemodem map rl1 192.168.23.0/24 -> rl1/32 portmap tcp/udp 48000:50000 # ... mirrors.accesscomm.ca goes out the ADSL line map rl2 from 192.168.23.0/24 to 204.83.142.81/32 -> rl2/32 Now that just changes which IP the packet is NAT'ed onto. It'll still go out the default gateway. Sooo .... a snippet from my rc.conf: static_routes="foo bar baz mirrors" route_mirrors="204.83.142.81/32 64.201.208.254" There, now when I NAT onto the secondary Internet connection IP it'll be routed to the correct gateway. I haven't looked into using 'fwd' to accomplish the routng based on source for this situation yet (though I do use it to route some interesting OpenVPN tunnels). I suspect that I could reduce the routing from one route per destination down to a single 'fwd' statement, depending on whether or not NAT happens before or after ipfw 'fwd'. I'd also love to NAT by protocol (as you mention in the rest of your email). If you come up with a configuration for that, please share it with the list :-) -T -- >I've gone through over-stressed to physical exhaustion... what's next? Tuesday - A.S.R. quote (Simon Burr & Kyle Hearn) From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 6 09:27:53 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68BF516A4B3 for ; Mon, 6 Oct 2003 09:27:53 -0700 (PDT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 121DD43FD7 for ; Mon, 6 Oct 2003 09:27:52 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by comcast.net (sccrmhc12) with ESMTP id <2003100616275001200huc9le>; Mon, 6 Oct 2003 16:27:51 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id JAA43713; Mon, 6 Oct 2003 09:27:50 -0700 (PDT) Date: Mon, 6 Oct 2003 09:27:49 -0700 (PDT) From: Julian Elischer To: Leo Bicknell In-Reply-To: <20031006134346.GA84944@ussenterprise.ufp.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: Changing the NAT IP on demand? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2003 16:27:53 -0000 On Mon, 6 Oct 2003, Leo Bicknell wrote: > In a message written on Sun, Oct 05, 2003 at 08:11:05PM -0600, Nick Rogness wrote: > > In addition to keeping your NAT translations (as suggested by > > Wes), you need to also keep routes for those entries as well, so > > that preserved traffic remains to route out the right ISP even if > > a switch occurs. > > You're right, however I would go with a different mechanism, but one > I've also never tried to do. What you want is routing based on the > source address of the packet, not the destination as per usual. You > want to be able to say "source a.a.a.a goes out link A". I've never > tried to do it on FreeBSD (it's easy on say Cisco's, with a bit of a > performance hit on some platforms). this is very easy using the ipfw 'fwd' rule.. > > In a message written on Mon, Oct 06, 2003 at 05:28:57PM +0400, Yar Tikhiy wrote: > > Just a random thought: If natd(8) were taught to change its default > > alias address on the fly (it's just a single variable,) then the > > desired effect would be achieved exactly. That's because any session > > already having its own entry in natd's aliasing table would use its > > old alias address kept in the entry. BTW, one could switch between > > even more than 2 external connections in that manner. And that's > > just a step away from session-aware load-balancing with natd(8). > > That's exactly what I was thinking, and more or less why I asked. > > Note, I think this configuration would be useful in a lot of other > applications as well. Consider someone who can get, say, a 128k > symmetric DSL line, and a 56k up 1M down satellite link. If using > this "trick" you could direct latency sensitive (ssh, telnet, ntp) > traffic over the DSL line, and send bulk data (http, ftp) over the > satellite link that could be quite useful. > > I think I'm going to have to set up a lab box now and dig into this > at a deeper level. > > -- > Leo Bicknell - bicknell@ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org > From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 6 15:55:48 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4703D16A4B3 for ; Mon, 6 Oct 2003 15:55:48 -0700 (PDT) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9FD943F3F for ; Mon, 6 Oct 2003 15:55:46 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from salty.rapid.stbernard.com (corp-2.ipinc.com [199.245.188.2]) by smtp-relay.omnis.com (Postfix) with ESMTP id 6E08D72DDC; Mon, 6 Oct 2003 15:54:11 -0700 (PDT) From: Wes Peters Organization: Softweyr.com To: Leo Bicknell , freebsd-hackers@freebsd.org Date: Mon, 6 Oct 2003 15:55:39 -0700 User-Agent: KMail/1.5.2 References: <20031004235400.GA20943@ussenterprise.ufp.org> <20031005193343.F47183-100000@skywalker.rogness.net> <20031006134346.GA84944@ussenterprise.ufp.org> In-Reply-To: <20031006134346.GA84944@ussenterprise.ufp.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310061555.39768.wes@softweyr.com> Subject: Re: Changing the NAT IP on demand? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2003 22:55:48 -0000 On Monday 06 October 2003 06:43, Leo Bicknell wrote: > > Note, I think this configuration would be useful in a lot of other > applications as well. Consider someone who can get, say, a 128k > symmetric DSL line, and a 56k up 1M down satellite link. If using > this "trick" you could direct latency sensitive (ssh, telnet, ntp) > traffic over the DSL line, and send bulk data (http, ftp) over the > satellite link that could be quite useful. > > I think I'm going to have to set up a lab box now and dig into this > at a deeper level. Linux apparently has some software available to does at least part of this; others who have asked similar questions in the past have referred to such capabilities. A grep through the archives might be in order, but I can't recall enough to give you a guideline on what to search for. Maybe 'nat' and 'multiple' or something like that. Good luck! -- "Where am I, and what am I doing in this handbasket?" Wes Peters wes@softweyr.com From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 6 16:10:29 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6231216A4B3 for ; Mon, 6 Oct 2003 16:10:29 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6320343FAF for ; Mon, 6 Oct 2003 16:10:28 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id h96NAPgG012939; Mon, 6 Oct 2003 19:10:25 -0400 (EDT) Date: Mon, 6 Oct 2003 19:10:25 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Dan Langille In-Reply-To: <3F77D27E.6203.3321BA14@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org Subject: Re: [PATCH] : libc_r/uthread/uthread_write.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2003 23:10:29 -0000 Is your mailer screwed up? We're getting duplicates (a few days later). On Mon, 29 Sep 2003, Dan Langille wrote: > On 18 Sep 2003 at 7:50, Daniel Eischen wrote: > > > On Wed, 17 Sep 2003, Dan Langille wrote: > > > > > On 16 Sep 2003 at 20:49, Daniel Eischen wrote: > > > > > > > On Tue, 16 Sep 2003, Dan Langille wrote: > > > > > > > > > I've had preliminary success with this patch. More testing needs > > > > > to be done, but in the meantime, I would appreciate reviews and > > > > > comments. The patched code is available from > > > > > http://beta.freebsddiary.org/tmp/uthread_write.c and the patch > > > > > appears below. > > > > > > > > > > In short, the logic has been changed to ensure that if __sys_write > > > > > returns zero, this value is returned by _write. > > > > > > > > I think this is not quite correct. Since libc_r is looping > > > > and some data may have been read, then the partial byte count > > > > should be returned, not zero. It is possible the partial byte > > > > count could also be zero in some cases, so it would result > > > > in zero being returned in those instances. > > > > > > I see what you mean. Please have a look at > > > http://beta.freebsddiary.org/tmp/uthread_write.c2 > > > The patch appears at the end of this message. > > > > Right, this seems correct to me. > > All our testing on this patch has been successful. I'm going to do a > few more tests on different hardware under 4.8-stable. > > What's the next step? Commit it? Get others to test with it first? > > > > > I think the problem lies with the SCSI tape device. It should > > > > either return 0 or -1 with errno=ENOSPC on a write that detects > > > > an EOT, not partial byte count. > > > > > > You are referring to sa(4)? > > > > Yes. > > > > > > If you are using libkse or > > > > libthr, you will get a partial byte count and not zero because > > > > the tape driver returns the (partial) bytes written. So exiting > > > > the loop in libc_r and returning 0 would only seem to correct > > > > the "problem" for libc_r. > > > > If there is a difference, it could be because libc_r is using non-blocking > > IO behind the scenes, and sa(4) may be returning partial byte count > > in the non-blocking case and 0 (or -1 and ENOSPC) in the blocking case > > (which is what you'd get using libkse/libthr). > > > > > The problem found when running under pthreads on 4.8-stable [i.e. > > > EOT is not returned to the application code] is not found with libkse > > > on 5.1-current. > > FWIW: our regression tests are failing under 5.1 and we suspect that > MTIOCERRSTAT ioctl() has changed since 4.8. We're getting: > > btape: dev.c:1119 Doing MTIOCERRSTAT errno=22 ERR=Invalid argument > > We'll continue with our 5.1 work, but we'd like to finish up with 4.8 > ASAP. > -- > Dan Langille : http://www.langille.org/ > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- "Some folks are into open source, but me, I'm into open bar." -- Spencer F. Katt From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 6 18:44:51 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A31E16A4B3 for ; Mon, 6 Oct 2003 18:44:51 -0700 (PDT) Received: from bast.unixathome.org (bast.unixathome.org [66.11.174.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 396B243FDF for ; Mon, 6 Oct 2003 18:44:50 -0700 (PDT) (envelope-from dan@langille.org) Received: from wocker (wocker.unixathome.org [192.168.0.99]) by bast.unixathome.org (Postfix) with ESMTP id A24F83D28; Mon, 6 Oct 2003 21:44:16 -0400 (EDT) From: "Dan Langille" To: Daniel Eischen Date: Mon, 06 Oct 2003 21:46:24 -0400 MIME-Version: 1.0 Message-ID: <3F81E2B0.19840.5A70FD0A@localhost> Priority: normal References: <3F77D27E.6203.3321BA14@localhost> In-reply-to: X-mailer: Pegasus Mail for Windows (v4.02a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body cc: hackers@freebsd.org Subject: Re: [PATCH] : libc_r/uthread/uthread_write.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2003 01:44:51 -0000 On 6 Oct 2003 at 19:10, Daniel Eischen wrote: > Is your mailer screwed up? We're getting duplicates (a few > days later). I don't think so. Could they have been moderated? What do the headers say? -- Dan Langille : http://www.langille.org/ From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 6 18:59:14 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2DFA016A4BF for ; Mon, 6 Oct 2003 18:59:14 -0700 (PDT) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC86C43FB1 for ; Mon, 6 Oct 2003 18:59:12 -0700 (PDT) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (blackwater.lemis.com [192.109.197.80]) by ozlabs.org (Postfix) with ESMTP id A8AAB2BC0D for ; Tue, 7 Oct 2003 11:59:10 +1000 (EST) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 80FE051836; Tue, 7 Oct 2003 11:29:07 +0930 (CST) Date: Tue, 7 Oct 2003 11:29:07 +0930 From: Greg 'groggy' Lehey To: Dan Langille Message-ID: <20031007015907.GN47054@wantadilla.lemis.com> References: <3F77D27E.6203.3321BA14@localhost> <3F81E2B0.19840.5A70FD0A@localhost> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Vxa5joy26gVGOrvU" Content-Disposition: inline In-Reply-To: <3F81E2B0.19840.5A70FD0A@localhost> User-Agent: Mutt/1.4i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 cc: hackers@freebsd.org Subject: Repeated messages (was: [PATCH] : libc_r/uthread/uthread_write.c) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2003 01:59:14 -0000 --Vxa5joy26gVGOrvU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Monday, 6 October 2003 at 21:46:24 -0400, Dan Langille wrote: > On 6 Oct 2003 at 19:10, Daniel Eischen wrote: > >> Is your mailer screwed up? We're getting duplicates (a few >> days later). > > I don't think so. Could they have been moderated? What do the > headers say? Somebody in France has set up a selective mail loop. I've seen a couple of my own messages like this. The FreeBSD postmaster is aware of the problem, but it's difficult to catch just the occasional message. Greg -- See complete headers for address and phone numbers. --Vxa5joy26gVGOrvU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQE/gh3rIubykFB6QiMRAg9BAKCfF+7YLMD4+VAOLPQ2+dTfFUFV/QCgrwMB +FX16Love324wl3qjXQ668Y= =yloO -----END PGP SIGNATURE----- --Vxa5joy26gVGOrvU-- From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 6 23:43:47 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4F6816A4BF for ; Mon, 6 Oct 2003 23:43:47 -0700 (PDT) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 162A343FDD for ; Mon, 6 Oct 2003 23:43:45 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id CC18D5B653; Mon, 6 Oct 2003 23:42:06 -0700 (PDT) From: Wes Peters Organization: Softweyr To: Soren Schmidt , Sean Hamilton Date: Mon, 6 Oct 2003 23:43:43 -0700 User-Agent: KMail/1.5.4 References: <200310060710.h967ApF0040748@spider.deepcore.dk> In-Reply-To: <200310060710.h967ApF0040748@spider.deepcore.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310062343.43621.wes@softweyr.com> cc: hackers@FreeBSD.ORG Subject: Re: VT8237 serial-ATA support, Promise ATA stalls, GEOM noise X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2003 06:43:47 -0000 On Monday 06 October 2003 12:10 am, Soren Schmidt wrote: > It seems Sean Hamilton wrote: > > > > I have two Asus boards (A7V8X and A7V) which have in common a > > Promise ATA controller. Both of these boards hang up for about a > > minute during the boot of 5.1-RELEASE, and emit messages about ad* > > devices being reset -- I cannot paste them verbatim as they seem to > > have been omitted from my dmesg. In the case of the A7V8X, the > > controller is unused and disabled in the BIOS. Has this been > > rectified for 5.2? > > Should not happen on -current. I haven't seen this on my A7V, running a week-old -current: atapci0: port 0xb000-0xb00f at device 17.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ad0: 76319MB [155061/16/63] at ata0-master UDMA100 acd0: CD-RW at ata1-master PIO4 The system is quite fast; it outperforms my P4 2.0 workstation at work on 'worldstones' by several minutes. -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 7 03:32:19 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F38116A4B3 for ; Tue, 7 Oct 2003 03:32:19 -0700 (PDT) Received: from mayo.ewwww.com (mayo.ewwww.com [216.27.179.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFFDE43FE5 for ; Tue, 7 Oct 2003 03:32:18 -0700 (PDT) (envelope-from bharris@mayo.ewwww.com) Received: from localhost (localhost [127.0.0.1]) by mayo.ewwww.com (Postfix) with ESMTP id 5D4C510A9E; Tue, 7 Oct 2003 03:32:18 -0700 (PDT) Received: from mayo.ewwww.com ([127.0.0.1]) by localhost (mayo [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04747-10; Tue, 7 Oct 2003 03:32:16 -0700 (PDT) Received: from mayo.ewwww.com (localhost [127.0.0.1]) by mayo.ewwww.com (Postfix) with ESMTP id 7908010A87; Tue, 7 Oct 2003 03:32:16 -0700 (PDT) Received: (from bharris@localhost) by mayo.ewwww.com (8.12.9+Sun/8.12.2/Submit) id h97AWFfx005099; Tue, 7 Oct 2003 03:32:15 -0700 (PDT) Date: Tue, 7 Oct 2003 03:32:15 -0700 From: Brendan Harris To: freebsd-hackers@freebsd.org Message-ID: <20031007103215.GA29943@stotch.com> References: <20031004235400.GA20943@ussenterprise.ufp.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031004235400.GA20943@ussenterprise.ufp.org> User-Agent: Mutt/1.4.1i Subject: Re: Changing the NAT IP on demand? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2003 10:32:19 -0000 On Sat, Oct 04, 2003 at 07:54:00PM -0400, Leo Bicknell wrote: > > I'm considering options for a new project, and I think I've discovered > what I think is the best idea, but I don't think current software > supports the config. I'd like to get some confirmation, and comments on > if it would be hard to implement. > > Consider: > > > ISP #1-------\ > \ > FreeBSD Box----LAN > / > ISP #2-------/ > > In this case the LAN would be 1918 space, the two ISP's would each > provide a public IP for the FreeBSD box. > > Now, NAT would be required. What I want to do is write an external > application to decide the performance of ISP #1 and ISP#2, and > somehow tell NAT which outside address to use. > > That, by itself, is not hard. Here's the trick. I want the switch > to be seamless. That is, if NAT is translating to ISP #1 and the > application says switch to #2 the existing translations to #1 (until > they go away naturally) should be kept, while new ones go to #2. > > The only ways I know to change the outside address seem to tear down > all existing connections. > > Is it possible to make this work today? Would it be hard to fix if > it doesn't work today? Reading all of the replies and thinking about this a bit, really, I can see only one worthwhile solution to this: Run a routing protocol that can choose amongst static routes based on 'latency, hops and integrity' and just let it do it's own route-choosing on a per-connection basis. Trying to lock "sessions" to a route is going to be a headache and won't provide you much more benefit than per-connection routing (unless a project you're doing requires the routes to be predictable for active sessions.) If you _really_ want to write the interfacing application to achieve this, go for it. But I would not do this if I were you. Also, you're going to have a hell of a time achieving this when it comes to connection-less datagram protocols (e.g. UDP.) So, I really recommend just letting a routing protocol handle this. Also, someone mentioned a Linux solution to this. I know there is an OpenBSD solution, using Packet Filter and NAT. The two can interact with eachother seamlessly and I have done this before with OpenBSD. You'll just need to choose a good routing protocol and learn the dirty details of Packet Filter and NAT (relatively the same as ipfilter and ipnat.) You might want to look into that as a possible solution. --Brendan From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 7 03:33:06 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FE4716A4C4 for ; Tue, 7 Oct 2003 03:33:06 -0700 (PDT) Received: from firecrest.mail.pas.earthlink.net (firecrest.mail.pas.earthlink.net [207.217.121.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAF5744014 for ; Tue, 7 Oct 2003 03:33:03 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-38lc0jm.dialup.mindspring.com ([209.86.2.118] helo=mindspring.com) by firecrest.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1A6p9D-0006y1-00; Tue, 07 Oct 2003 03:32:56 -0700 Message-ID: <3F8295BC.1F785B97@mindspring.com> Date: Tue, 07 Oct 2003 03:30:20 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a44de2f16a8be604121215e486a0c3121ca8438e0f32a48e08350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org Subject: Re: Changing the NAT IP on demand? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2003 10:33:06 -0000 Julian Elischer wrote: > On Mon, 6 Oct 2003, Leo Bicknell wrote: > > In a message written on Sun, Oct 05, 2003 at 08:11:05PM -0600, Nick Rogness wrote: > > > In addition to keeping your NAT translations (as suggested by > > > Wes), you need to also keep routes for those entries as well, so > > > that preserved traffic remains to route out the right ISP even if > > > a switch occurs. > > > > You're right, however I would go with a different mechanism, but one > > I've also never tried to do. What you want is routing based on the > > source address of the packet, not the destination as per usual. You > > want to be able to say "source a.a.a.a goes out link A". I've never > > tried to do it on FreeBSD (it's easy on say Cisco's, with a bit of a > > performance hit on some platforms). > > this is very easy using the ipfw 'fwd' rule.. Actually, it's very hard; the 'fwd' rule doesn't quite cut it for things like, for example, NFS. It also fails to work with aliases, when you want the packet sent from a specific IP on a given interface. There are some workarounds, like binding it locally to an IP, but that's not so good when you are wanting to be able to change IP addresses, as in the case in point. Cisco really does routing differently. One thing that would be handy is a socket type that was a TCP stream socket, but which was bound to an interface, rather than to a specific IP address. This only solves some of the problems, like not having to restart your already listening servers when the IP address changes out from under it (e.g. the "kick sendmail in the head" issue we had with the InterJet I's & II's when they were running dialup in dial-on-demand mode). Really, you need to have routing implemented like it's implemented in Cisco's, and associate the reverse route with the last packet you received from a given IP address (you always have this because you had to have it to do the handshake). The FreeBSD routing code tends to get the routing wrong some of the time, particularly in picking the local address to send a packet "from". The problem with the ipfw forwarding is that you don't apriori know who's going to be talking to you, so you can't really make preestablished rules for the forwarding for every possible IP address that's non-local and across one link or the other. I suppose you could establish rules when you saw packets, but that would require running as root, and hacking all your servers to "do the right thing" anytime you got a connection. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 7 07:46:39 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 11BC016A4B3 for ; Tue, 7 Oct 2003 07:46:39 -0700 (PDT) Received: from pixies.tirloni.org (pixies.tirloni.org [200.203.183.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2C9D43FBD for ; Tue, 7 Oct 2003 07:46:37 -0700 (PDT) (envelope-from tirloni@tirloni.org) Received: by pixies.tirloni.org (Postfix, from userid 1000) id AD4F71E1426; Tue, 7 Oct 2003 11:46:35 -0300 (BRT) Date: Tue, 7 Oct 2003 11:46:35 -0300 From: "Giovanni P. Tirloni" To: freebsd-hackers@freebsd.org Message-ID: <20031007144635.GP25542@pixies.tirloni.org> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: netisr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2003 14:46:39 -0000 Hi folks, I'm studying the network stack and now I'm confronted with something called netisr. It seems ether_demux puts the packet in a netisr queue instead of passing it directly to ip_input (if that was the packet's type). Is this derived from LRP ? I've read their paper and it looks like their network channel (ni) but I'm not sure. I also read about it in 5.2 TODO list about fine-grained locking. Where can I find more information on this? Thanks -- Giovanni P. Tirloni Fingerprint: 8C3F BEC5 79BD 3E9B EDB8 72F4 16E8 BA5E D031 5C26 From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 7 11:35:38 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C3B6B16A4B3; Tue, 7 Oct 2003 11:35:38 -0700 (PDT) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC56343FCB; Tue, 7 Oct 2003 11:35:37 -0700 (PDT) (envelope-from nork@FreeBSD.org) Received: from pelsia.ninth-nine.com (pelsia.ninth-nine.com [219.127.74.123]) (authenticated bits=0) by sakura.ninth-nine.com (8.12.9p2/8.12.9/NinthNine) with ESMTP id h97IZaiS034451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Oct 2003 03:35:36 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Wed, 8 Oct 2003 03:35:36 +0900 From: Norikatsu Shigemura To: freebsd-stable@FreeBSD.org, freebsd-hackers@FreeBSD.org Message-Id: <20031008033536.7f6099b5.nork@FreeBSD.org> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-mozilla@FreeBSD.org cc: freebsd-gnome@FreeBSD.org Subject: HEADS UP: pelase test /etc/libmap.conf feature on 4-stable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2003 18:35:39 -0000 Hi, for Flash Plugin Wrapper user on 4-stable. I MFCed /etc/libmap.conf feature written by mdodd for current. Please get&patch following URL. http://tmp.ninth-nine.com/libmap_4/libmap_4stable.diff For new flash6 wrapper, maybe, please set following lines. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [/usr/local/lib/linux-flashplugin6/libflashplayer.so] libpthread.so.0 liblthread.so.2 libdl.so.2 pluginwrapper.so libz.so.1 libz.so.2 libstdc++-libc6.2-2.so.3 liblstdc++.so.3 libm.so.6 libm.so.2 libc.so.6 pluginwrapper.so - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Sorry, I checked minimum test. I didn't check with mozilla, yet. From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 7 12:50:31 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA82316A4B3; Tue, 7 Oct 2003 12:50:31 -0700 (PDT) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA86A43FE3; Tue, 7 Oct 2003 12:50:30 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from salty.rapid.stbernard.com (corp-2.ipinc.com [199.245.188.2]) by smtp-relay.omnis.com (Postfix) with ESMTP id 8F66C9BE8E; Tue, 7 Oct 2003 12:48:47 -0700 (PDT) From: Wes Peters Organization: Softweyr.com To: Nick Rogness Date: Tue, 7 Oct 2003 12:50:21 -0700 User-Agent: KMail/1.5.2 References: <20031005193343.F47183-100000@skywalker.rogness.net> In-Reply-To: <20031005193343.F47183-100000@skywalker.rogness.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310071250.21692.wes@softweyr.com> cc: darrenr@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: Changing the NAT IP on demand? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2003 19:50:31 -0000 On Sunday 05 October 2003 19:11, Nick Rogness wrote: > On Sun, 5 Oct 2003, Wes Peters wrote: > > On Sunday 05 October 2003 01:02 am, Nick Rogness wrote: > > > On Sat, 4 Oct 2003, Leo Bicknell wrote: > > > > I'm considering options for a new project, and I think I've > > > > discovered what I think is the best idea, but I don't think > > > > current software supports the config. I'd like to get some > > > > confirmation, and comments on if it would be hard to implement. > > > > > > > > Consider: > > > > > > > > > > > > ISP #1-------\ > > > > \ > > > > FreeBSD Box----LAN > > > > / > > > > ISP #2-------/ > > > > > > > > In this case the LAN would be 1918 space, the two ISP's would > > > > each provide a public IP for the FreeBSD box. > > > > > > > > Now, NAT would be required. What I want to do is write an > > > > external application to decide the performance of ISP #1 and > > > > ISP#2, and somehow tell NAT which outside address to use. > > > > > > > > That, by itself, is not hard. Here's the trick. I want the > > > > switch to be seamless. That is, if NAT is translating to ISP > > > > #1 and the application says switch to #2 the existing > > > > translations to #1 (until they go away naturally) should be > > > > kept, while new ones go to #2. > > > > > > > > The only ways I know to change the outside address seem to tear > > > > down all existing connections. > > > > > > > > Is it possible to make this work today? Would it be hard to > > > > fix if it doesn't work today? > > > > > > This can simply not work without resetting connections. The > > > socket pair on the "outside" would break as your outside traffic > > > switches from one to the other (src/dst would change). There is > > > no fix, as this breaks basic IP principals. > > > > That's not at all what Leo was asking. > > Sorry bout that, didn't read carefully enough. I understand the > question now after more careful reading. > > > Leo, you may be able to do this with ipfilter's ipnat. Nat rules > > are traditionally processed with 'ipnat -CF', the -C clears the > > rules and the -F option clears the currently active NAT mappings. > > You should experiment with rewriting the rules and instantiating > > them with -C only. This should leave the existing stateful mappings > > to the formerly preferred interface while creating all new mappings > > on the newly preferred interface. > > In addition to keeping your NAT translations (as suggested by > Wes), you need to also keep routes for those entries as well, so > that preserved traffic remains to route out the right ISP even if > a switch occurs. Ah, yes, another sticky bit of the problem. It seems you could do a least a partial workaround by creating and maintaining a host route for each active NAT mapping. The NAT engine would have to reference-count the routes it is maintaining. This *is* a simpler alternative than hacking source routing into FreeBSD at this point. > The reason for this is simple. > When you switch the route(s) to the other ISP (which you would > have to do), your existing translations would get routed out to > the wrong ISP. You would need to keep routes for existing > translations to make sure they leave the proper 'old' interface. > This would not be necessary if each ISP allowed you to use either > public IP on each others network (not likely). > > Nat (AFAIK) does not determine which interface to leave. You can ipnat operates quite differently from natd; it bears looking into. It's been a while since I was intimate with ipnat, so I can't say off the top of my head how hard this might be. > change the source address in the packet to anything you want, this > will not tell it to leave 'interace_to_ISP#1' or > 'interface_to_ISP#2'. That is a decision made using the routing > table. ipnat redirections already have a limited sort of round-robin load balancing capability. A quick read through ipnat(5) may enlighten. It would be instructive to search out the round-robin code and think about how to extend it into a mechanism to do failover or smarter load balancing. > Your app would have to keep track of these NAT things and > also add and remove routes from the routing table. Nat mappings are already available, via the /dev/ipnat device and ioctl's, with ipnat. > That is, if everything is going out ISP#1 and you decide to switch > to ISP#2 you would need to: > > 1) Keep exisiting NAT translation(s) like suggested by > Wes. > 2) Add routing table entry for each of the NAT > translations you want to preserve to ISP#1 > 3) Switch default routing to ISP#2 > 4) When sessions are finsihed and NAT translations > removed to ISP#1, the route(s) that pertain to those > NAT translations would need to be removed. Yeah, conceptually it's pretty simple isn't it? The devil is, as always, in the details. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters wes@softweyr.com From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 7 13:17:09 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD45316A4B3 for ; Tue, 7 Oct 2003 13:17:09 -0700 (PDT) Received: from smtp.jeans.ocn.ne.jp (jeans.ocn.ne.jp [211.6.83.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id B59B043FEA for ; Tue, 7 Oct 2003 13:17:08 -0700 (PDT) (envelope-from shirube@jeans.ocn.ne.jp) Received: from localhost (p8186-ipad53marunouchi.tokyo.ocn.ne.jp [219.160.140.186]) by smtp.jeans.ocn.ne.jp (Postfix) with ESMTP id 9813233AF; Wed, 8 Oct 2003 05:17:07 +0900 (JST) To: bharris@stotch.com In-Reply-To: <20031007103215.GA29943@stotch.com> References: <20031004235400.GA20943@ussenterprise.ufp.org> <20031007103215.GA29943@stotch.com> X-Mailer: Mew version 1.94.2 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Message-Id: <20031008051657N.shirube@jeans.ocn.ne.jp> Date: Wed, 08 Oct 2003 05:16:57 +0900 From: S.Yamagishi X-Dispatcher: imput version 20000228(IM140) Lines: 5 cc: freebsd-hackers@freebsd.org Subject: Re: Changing the NAT IP on demand? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2003 20:17:09 -0000 $BEl$5$s$N%Q%9%o!<%I$O0c$$$^$9!#7/$,=q$$$?$N$O(BFileserver$B$N$G$9!#(B $B$D$+$l$?$d(B Tel.:090-2439-5219 Fax :0423-64-6293 From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 7 16:35:58 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A4DE16A4B3 for ; Tue, 7 Oct 2003 16:35:58 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFBB943FBD for ; Tue, 7 Oct 2003 16:35:57 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.3) with ESMTP id h97NZrsd092737; Tue, 7 Oct 2003 16:35:53 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id h97NZreS092736; Tue, 7 Oct 2003 16:35:53 -0700 (PDT) (envelope-from rizzo) Date: Tue, 7 Oct 2003 16:35:52 -0700 From: Luigi Rizzo To: "akanwar@digitarchy.com" Message-ID: <20031007163552.A92652@xorpc.icir.org> References: <410-22003102722174477@M2W077.mail2web.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <410-22003102722174477@M2W077.mail2web.com>; from akanwar@digitarchy.com on Tue, Oct 07, 2003 at 06:17:04PM -0400 cc: freebsd-hackers@freebsd.org Subject: Re: HZ = 1000 slows down application X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2003 23:35:58 -0000 On Tue, Oct 07, 2003 at 06:17:04PM -0400, akanwar@digitarchy.com wrote: > Hi Luigi, Mark, > > Thanks for your replies. > > We did some intensive profiling of our application. It does not seem like > we are depending on clock ticks for any calculations. > > On the other hand we notice that our slow iterations happen almost at the > same instant as "microuptime went backward" messages in the system log. We if this is the case, probably your code at some point computes a time difference which turns out negative (or if it is unsigned, it becomes very very large) upon those events, thus causing some loop to explode. It should be easy to check if this is the case, and just ignore those outliers rather than trying to figure out why the clock goes backward. I used to see the same "microuptime went backwards" msg on some of my 400MHz boxes, even without NTP enabled. Maybe a buggy timer, not sure which timecounter was used on that box (i read some time ago that the cpu on the soekris4801 has a weird TSC implementation where the upper 32 bits change when the lower 32 bits are 0xfffffffd, who knows what other bugs might be in other hardware...) cheers luigi > were told that ntpd is correcting the time when these messages appear. The > vexing problem is that making HZ=1000 has increased the rate at which ntp > updates the time. Is this possible ? Does ntp count the number of ticks > before applying a correction ? > > This is the point we are at now. Any help to shed more light on this is > appreciated. > > Thanks, > -ansh > > > > > > Original Message: > ----------------- > From: Mark Santcroos marks@ripe.net > Date: Tue, 7 Oct 2003 19:16:14 +0200 > To: akanwar@digitarchy.com > Subject: Re: HZ = 1000 slows down application > > > On Mon, Sep 22, 2003 at 02:22:02PM -0700, Luigi Rizzo wrote: > > On Mon, Sep 22, 2003 at 02:43:40PM -0400, akanwar@digitarchy.com wrote: > > ... > > > But now I noticed that my application is occassionally doing slower > > > iterations. Average iteration time used to be 0.2 ms without polling > > > enabled. With the device polling changes, the average time is still > around > > > the same, but once every few minutes the application sees iterations > that > > > are 3.3 seconds (*seconds*, not a typo) long. > > > > most likely your application makes some assumptions on the duration of > > a clock tick and then it gets confused when, say, a select returns > > quicker, or some time difference becomes negative, etc. etc. because > > of the finer granularity. > > > > very common type of bug. > > Hi, > > What was the outcome of this? > > Thanks > > Mark > > > > > -------------------------------------------------------------------- > mail2web - Check your email from the web at > http://mail2web.com/ . > > From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 7 20:29:07 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66E3B16A4B3 for ; Tue, 7 Oct 2003 20:29:07 -0700 (PDT) Received: from mail.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2654543FCB for ; Tue, 7 Oct 2003 20:29:06 -0700 (PDT) (envelope-from don@sandvine.com) Received: by mail.sandvine.com with Internet Mail Service (5.5.2653.19) id <4CQ6MTBB>; Tue, 7 Oct 2003 23:29:05 -0400 Message-ID: From: Don Bowman To: akanwar@digitarchy.com Date: Tue, 7 Oct 2003 23:29:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" cc: freebsd-hackers@freebsd.org Subject: RE: HZ = 1000 slows down application X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2003 03:29:07 -0000 From: Luigi Rizzo [mailto:rizzo@icir.org] > On Tue, Oct 07, 2003 at 06:17:04PM -0400, > akanwar@digitarchy.com wrote: > > Hi Luigi, Mark, > > > > Thanks for your replies. > > > > We did some intensive profiling of our application. It does > not seem like > > we are depending on clock ticks for any calculations. > > > > On the other hand we notice that our slow iterations happen > almost at the > > same instant as "microuptime went backward" messages in the > system log. We > I think you need kern.timecounter.method=1 in sysctl.conf. From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 00:20:29 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D18916A4B3 for ; Wed, 8 Oct 2003 00:20:29 -0700 (PDT) Received: from razorbill.mail.pas.earthlink.net (razorbill.mail.pas.earthlink.net [207.217.121.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4838643F3F for ; Wed, 8 Oct 2003 00:20:28 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfldf.dialup.mindspring.com ([165.247.213.175] helo=mindspring.com) by razorbill.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1A78cT-0004Ra-00; Wed, 08 Oct 2003 00:20:26 -0700 Message-ID: <3F83BA8C.7149BB52@mindspring.com> Date: Wed, 08 Oct 2003 00:19:40 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo References: <410-22003102722174477@M2W077.mail2web.com> <20031007163552.A92652@xorpc.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4a1b368cc57ebe6f2ebda69331abe2d2ea2d4e88014a4647c350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org cc: "akanwar@digitarchy.com" Subject: Re: HZ = 1000 slows down application X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2003 07:20:29 -0000 Luigi Rizzo wrote: > On Tue, Oct 07, 2003 at 06:17:04PM -0400, akanwar@digitarchy.com wrote: > > We did some intensive profiling of our application. It does not seem like > > we are depending on clock ticks for any calculations. > > > > On the other hand we notice that our slow iterations happen almost at the > > same instant as "microuptime went backward" messages in the system log. We > > if this is the case, probably your code at some point computes a > time difference which turns out negative (or if it is unsigned, it > becomes very very large) upon those events, thus causing some loop > to explode. > It should be easy to check if this is the case, and just ignore > those outliers rather than trying to figure out why the clock > goes backward. I used to see the same "microuptime went backwards" > msg on some of my 400MHz boxes, even without NTP enabled. > Maybe a buggy timer, not sure which timecounter was used on that > box (i read some time ago that the cpu on the soekris4801 has a > weird TSC implementation where the upper 32 bits change when the > lower 32 bits are 0xfffffffd, who knows what other bugs might be > in other hardware...) FWIW: Internally, MacOS X supports "monotime", which is a monotonically increasing time counter, guaranteed to not go backwards. That avoids problems exactly like what you are describing. FreeBSD should consider supporting a "monotime". -- Terry From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 00:40:19 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C093C16A4B3 for ; Wed, 8 Oct 2003 00:40:19 -0700 (PDT) Received: from razorbill.mail.pas.earthlink.net (razorbill.mail.pas.earthlink.net [207.217.121.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F0B143FF3 for ; Wed, 8 Oct 2003 00:40:17 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfldf.dialup.mindspring.com ([165.247.213.175] helo=mindspring.com) by razorbill.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1A78vd-0006Xs-00; Wed, 08 Oct 2003 00:40:14 -0700 Message-ID: <3F83BF33.46696D6C@mindspring.com> Date: Wed, 08 Oct 2003 00:39:31 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Giovanni P. Tirloni" References: <20031007144635.GP25542@pixies.tirloni.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a478dcff46fda39db27594e2704a729f6c3ca473d225a0f487350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org Subject: Re: netisr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2003 07:40:20 -0000 "Giovanni P. Tirloni" wrote: > I'm studying the network stack and now I'm confronted with something > called netisr. It seems ether_demux puts the packet in a netisr queue > instead of passing it directly to ip_input (if that was the packet's > type). Is this derived from LRP ? No. NETISR is a software interrupt that runs when software interrupts run, which is to say, when the SPL is lowered as a result of returning from the last nested hardware interrupt, which means on hardware and clock interrupts. It is completely antithetical to LRP, which, despite the name "Lazy Receiver Processing", is mostly only lazy about direct dispatch. > I've read their paper and it looks > like their network channel (ni) but I'm not sure. No. There are two LRP papers from Rice University. The first was against FreeBSD 3.2, and dealt with just the idea of LRP. The scond makes things much more complicated than they need to be, in order to introduce a concept called "ResCon", or resource containers. Neither set of code is really production, because it uses an alternate protocol family definition and a seperately hacked uipc_socket.c and uipc_socket2.c, along with the totally parallel TCP/IP stack. The closest you can come to LRP in FreeBSD 5.x is to use the sysctl's for "direct dispatch", which will, in fact, directly call ip_input() from interrupt. This isn't a full LRP, since it doesn't add a receive buffer into the proc structure for per-process enqueuing of packets. When I implemented the 3.x version of Rice's LRP in FreeBSD 4.3, I avoided this hack. The main reason for the hack was to deal with accepting connections, since at interrupt, without a proc structure, there was no way to deal with the socket creation for the accept, due to a lack of an appropriate credential. The sneaky approach I used for this was to create the accept socket using the cred that was present on the listen socket on which the connection had come in. For this to be at all useful, you need to extend kevent accept filters to allow creation of accepted descriptor instances in the process context, and throw them onto the kqueue that was set up against the listen socket. I recommend that if you want to play with LRP, you add an attribute flag to the protocol stack structure to indicate an LRP capable vs. an LRP incapable stack, and then implement it inline, rather than as a separate thing. I also recommend that if you do this, you do it using the Rice 3.x code, and ignore the "ResCon" stuff, which I think is an interesting idea, but which adds very little in the way of real value to things (though it does add overhead). > Where can I find more information on this? If you are asking about NETISR, then I recommend W. Richard Steven's books, specifically "TCP/IP Illustrated, Volume 2: The Implementation". If you are asking about LRP, then any search engine search for "Lazy Receiver Processing" should turn up the two Rice University and the one Duke University reference, as well as dozens of other references, including the one to the Lucent/IBM work on QLinux (which has some other neat information on things like WFS Queueing and other things that are actually necessary to avoid the potential for livelock at the user/kernel boundary). FWIW: Interrupt threads, as they are used in 5.x, are pretty much antithetical to an LRP implementation, since you can still end up live-locked under heavy load (or denial of service attack), which is why you wanted LRP in the first place: to make progress under a load heavier than you could possibly respond to in a reasonable time. The problem is that the requeing to the interrupt thread adds back in the same type of transition boundary you were trying to take out by getting rid of NETISR in the first place. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 01:25:28 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 957BC16A4B3 for ; Wed, 8 Oct 2003 01:25:28 -0700 (PDT) Received: from lilith.bellavista.cz (lilith.bellavista.cz [213.235.167.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B19943FEA for ; Wed, 8 Oct 2003 01:25:27 -0700 (PDT) (envelope-from neuhauser@bellavista.cz) Received: from freepuppy.bellavista.cz (freepuppy.bellavista.cz [10.0.0.10]) by lilith.bellavista.cz (Postfix) with ESMTP id 79F045C for ; Wed, 8 Oct 2003 10:25:25 +0200 (CEST) Received: by freepuppy.bellavista.cz (Postfix, from userid 1001) id 54EDE2FDA01; Wed, 8 Oct 2003 10:25:25 +0200 (CEST) Date: Wed, 8 Oct 2003 10:25:25 +0200 From: Roman Neuhauser To: freebsd-hackers Message-ID: <20031008082525.GM348@freepuppy.bellavista.cz> Mail-Followup-To: freebsd-hackers Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: /etc/services strange X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2003 08:25:28 -0000 According to http://www.iana.org/assignments/port-numbers, tcp/udp port 1000 is for "cadlock2". Our /etc/services claims 1000/tcp is "cadlock", and 1000/ucp "ock". Also: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/54371 -- If you cc me or remove the list(s) completely I'll most likely ignore your message. see http://www.eyrie.org./~eagle/faqs/questions.html From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 01:28:32 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A7E216A4B3; Wed, 8 Oct 2003 01:28:32 -0700 (PDT) Received: from milla.ask33.net (milla.ask33.net [217.197.166.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BED043FF5; Wed, 8 Oct 2003 01:28:31 -0700 (PDT) (envelope-from nick@milla.ask33.net) Received: by milla.ask33.net (Postfix, from userid 1001) id 248133ABB35; Wed, 8 Oct 2003 10:30:59 +0200 (CEST) Date: Wed, 8 Oct 2003 10:30:59 +0200 From: Pawel Jakub Dawidek To: freebsd-hackers@freebsd.org Message-ID: <20031008083059.GA520@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="JAtnJwvplI04zgov" Content-Disposition: inline X-PGP-Key-URL: http://garage.freebsd.pl/jules.asc X-OS: FreeBSD 4.8-RELEASE-p9 i386 X-URL: http://garage.freebsd.pl User-Agent: Mutt/1.5.1i cc: hsu@freebsd.org cc: rwatson@freebsd.org Subject: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2003 08:28:32 -0000 --JAtnJwvplI04zgov Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello hackers... I'm wondering... Jeffrey Hsu was talking about this at BSDCon03. There is no need to lock data when we just made simple read, for example: mtx_lock(&foo_mtx); foo =3D 5; mtx_unlock(&foo_mtx); but only: bar =3D foo; IMHO this is quite dangerous. Let's see: thread1 thread2 mtx_lock(&foo_mtx); foo =3D data_from_user; bar =3D foo; foo &=3D MASK; mtx_unlock(&foo_mtx); In this case we have really dangerous race if data from user are safe only when we made 'and' operation on them. OR of course we can just store wrong value in 'bar' and this could be case of different problems. So I'm not sure now if I understand everything well. We can't just say 'We never split such writes. We always do: foo =3D (data_from_user & MASK)', because author of some 3rd party kernel module will be sure that when he locks writes to some variable this operation is safe and he could split such writes and in kernel could be dynamic read without lock. Does this make any sense? --=20 Pawel Jakub Dawidek pawel@dawidek.net UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net --JAtnJwvplI04zgov Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iQCVAwUBP4PLQz/PhmMH/Mf1AQGI2AP+L4sKXqGib5doLjD3Q326HpaXW7IB8nSE PwX73LSV0TWtIHKLkidGr7JifOnk5TWmdkKJtKYu2nNkX28zUCanIzvlFi24r98q l8dtHmNzTpkZKyPlMwafDMo0CwQqLJS/Bvvgu3PYnTyshFuMYW5WLolueB5ORrFg YRC/o414IIg= =srlU -----END PGP SIGNATURE----- --JAtnJwvplI04zgov-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 01:49:37 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF9FD16A4B3 for ; Wed, 8 Oct 2003 01:49:37 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8286843FF2 for ; Wed, 8 Oct 2003 01:49:36 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 9F589653BA for ; Wed, 8 Oct 2003 09:49:35 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 50847-03-3 for ; Wed, 8 Oct 2003 09:49:35 +0100 (BST) Received: from saboteur.dek.spc.org (unknown [81.3.72.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 10898653D4 for ; Wed, 8 Oct 2003 09:49:35 +0100 (BST) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 75CF825; Wed, 8 Oct 2003 09:49:21 +0100 (BST) Date: Wed, 8 Oct 2003 09:49:21 +0100 From: Bruce M Simpson To: freebsd-hackers Message-ID: <20031008084921.GE6524@saboteur.dek.spc.org> Mail-Followup-To: freebsd-hackers References: <20031008082525.GM348@freepuppy.bellavista.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031008082525.GM348@freepuppy.bellavista.cz> Subject: Re: /etc/services strange X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2003 08:49:37 -0000 On Wed, Oct 08, 2003 at 10:25:25AM +0200, Roman Neuhauser wrote: > According to http://www.iana.org/assignments/port-numbers, > tcp/udp port 1000 is for "cadlock2". Our /etc/services claims > 1000/tcp is "cadlock", and 1000/ucp "ock". > > Also: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/54371 Committed to -HEAD. I don't want to disrupt RELENG_4 (or re) with unnecessary changes at the moment. Thanks! BMS From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 02:01:15 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FD8116A4B3 for ; Wed, 8 Oct 2003 02:01:15 -0700 (PDT) Received: from lilith.bellavista.cz (lilith.bellavista.cz [213.235.167.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C43B43F75 for ; Wed, 8 Oct 2003 02:01:14 -0700 (PDT) (envelope-from neuhauser@bellavista.cz) Received: from freepuppy.bellavista.cz (freepuppy.bellavista.cz [10.0.0.10]) by lilith.bellavista.cz (Postfix) with ESMTP id 15AEB5C for ; Wed, 8 Oct 2003 11:01:07 +0200 (CEST) Received: by freepuppy.bellavista.cz (Postfix, from userid 1001) id 0C5F02FDA01; Wed, 8 Oct 2003 11:01:07 +0200 (CEST) Date: Wed, 8 Oct 2003 11:01:06 +0200 From: Roman Neuhauser To: freebsd-hackers Message-ID: <20031008090106.GN348@freepuppy.bellavista.cz> Mail-Followup-To: freebsd-hackers References: <20031008082525.GM348@freepuppy.bellavista.cz> <20031008084921.GE6524@saboteur.dek.spc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031008084921.GE6524@saboteur.dek.spc.org> User-Agent: Mutt/1.5.4i Subject: Re: /etc/services strange X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2003 09:01:15 -0000 # bms@spc.org / 2003-10-08 09:49:21 +0100: > On Wed, Oct 08, 2003 at 10:25:25AM +0200, Roman Neuhauser wrote: > > According to http://www.iana.org/assignments/port-numbers, > > tcp/udp port 1000 is for "cadlock2". Our /etc/services claims > > 1000/tcp is "cadlock", and 1000/ucp "ock". > > > > Also: http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/54371 > > Committed to -HEAD. I don't want to disrupt RELENG_4 (or re) with > unnecessary changes at the moment. thanks! -- If you cc me or remove the list(s) completely I'll most likely ignore your message. see http://www.eyrie.org./~eagle/faqs/questions.html From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 02:51:12 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D75E16A4B3; Wed, 8 Oct 2003 02:51:12 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 965FC43FB1; Wed, 8 Oct 2003 02:51:10 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h989p6S11794; Wed, 8 Oct 2003 11:51:06 +0200 (MEST) Date: Wed, 8 Oct 2003 11:51:06 +0200 (CEST) From: Harti Brandt To: Pawel Jakub Dawidek In-Reply-To: <20031008083059.GA520@garage.freebsd.pl> Message-ID: <20031008114506.I63940@beagle.fokus.fraunhofer.de> References: <20031008083059.GA520@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: hsu@freebsd.org cc: rwatson@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2003 09:51:12 -0000 On Wed, 8 Oct 2003, Pawel Jakub Dawidek wrote: PJD>Hello hackers... PJD> PJD>I'm wondering... PJD>Jeffrey Hsu was talking about this at BSDCon03. PJD>There is no need to lock data when we just made simple read, for example: PJD> PJD> mtx_lock(&foo_mtx); PJD> foo = 5; PJD> mtx_unlock(&foo_mtx); PJD>but only: PJD> bar = foo; PJD> PJD>IMHO this is quite dangerous. PJD>Let's see: PJD> PJD> thread1 thread2 PJD> mtx_lock(&foo_mtx); PJD> foo = data_from_user; PJD> bar = foo; PJD> foo &= MASK; PJD> mtx_unlock(&foo_mtx); PJD> PJD>In this case we have really dangerous race if data from user are PJD>safe only when we made 'and' operation on them. PJD>OR of course we can just store wrong value in 'bar' and this could PJD>be case of different problems. PJD> PJD>So I'm not sure now if I understand everything well. We can't just say PJD>'We never split such writes. We always do: foo = (data_from_user & MASK)', PJD>because author of some 3rd party kernel module will be sure that when PJD>he locks writes to some variable this operation is safe and he could PJD>split such writes and in kernel could be dynamic read without lock. PJD> PJD>Does this make any sense? You need to lock when reading if you insist on consistent data. Even a simple read may be non-atomic (this should be the case for 64bit operations on all our platforms). So you need to do mtx_lock(&foo_mtx); bar = foo; mtx_unlock(&foo_mtx); if foo is a datatype that is not guaranteed to be red atomically. For 8-bit data you should be safe without the lock on any architecture. I'm not sure for 16 and 32 bit, but for 64-bit you need the look for all our architectures, I think. If you don't care about occasionally reading false data (for statistics or such stuff) you can go without the lock. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 03:09:55 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F63C16A4B3; Wed, 8 Oct 2003 03:09:55 -0700 (PDT) Received: from milla.ask33.net (milla.ask33.net [217.197.166.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id A254343FE0; Wed, 8 Oct 2003 03:09:54 -0700 (PDT) (envelope-from nick@milla.ask33.net) Received: by milla.ask33.net (Postfix, from userid 1001) id E5F0B3ABB35; Wed, 8 Oct 2003 12:12:22 +0200 (CEST) Date: Wed, 8 Oct 2003 12:12:22 +0200 From: Pawel Jakub Dawidek To: Harti Brandt Message-ID: <20031008101222.GB520@garage.freebsd.pl> References: <20031008083059.GA520@garage.freebsd.pl> <20031008114506.I63940@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="KqIDP7BYbqnwKRO+" Content-Disposition: inline In-Reply-To: <20031008114506.I63940@beagle.fokus.fraunhofer.de> X-PGP-Key-URL: http://garage.freebsd.pl/jules.asc X-OS: FreeBSD 4.8-RELEASE-p9 i386 X-URL: http://garage.freebsd.pl User-Agent: Mutt/1.5.1i cc: freebsd-hackers@freebsd.org cc: hsu@freebsd.org cc: rwatson@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2003 10:09:55 -0000 --KqIDP7BYbqnwKRO+ Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 08, 2003 at 11:51:06AM +0200, Harti Brandt wrote: +> You need to lock when reading if you insist on consistent data. Even a +> simple read may be non-atomic (this should be the case for 64bit +> operations on all our platforms). So you need to do +>=20 +> mtx_lock(&foo_mtx); +> bar =3D foo; +> mtx_unlock(&foo_mtx); +>=20 +> if foo is a datatype that is not guaranteed to be red atomically. For +> 8-bit data you should be safe without the lock on any architecture. I'm +> not sure for 16 and 32 bit, but for 64-bit you need the look for all +> our architectures, I think. But I'm not talking about non-atomic reads. What I'm want to show is that even atomic read (without lock) is dangerous in some cases. +> If you don't care about occasionally reading false data (for statistics = or +> such stuff) you can go without the lock. I'm afraid that many developers thinks that atomic reads are always safe without locks (there are many such reads in sources). I hope I'm wrong. --=20 Pawel Jakub Dawidek pawel@dawidek.net UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net --KqIDP7BYbqnwKRO+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iQCVAwUBP4PjBj/PhmMH/Mf1AQGS/wQAhEFJbDlDKRSAgG1SCE6eC01e2x7DyovZ rRJhXdNwwf4ZvEfKgQXuSq7C9hALh/xvGr5nJOB5d+8/b7Nc99oLCzvNIEqYW89g nQ+IkD0Xywc9IpiKUAkKeWeUqznGM9JV/b8ZAqXUi/jnjvdma+ruJ/LUTJW+rEft SJgvseL2QIs= =qQV1 -----END PGP SIGNATURE----- --KqIDP7BYbqnwKRO+-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 03:11:40 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C402716A4B3 for ; Wed, 8 Oct 2003 03:11:40 -0700 (PDT) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A7B743F85 for ; Wed, 8 Oct 2003 03:11:37 -0700 (PDT) (envelope-from peter.bozarov@moniforce.com) Received: from moniforce.com (213-84-208-64.adsl.xs4all.nl [213.84.208.64]) by smtpzilla1.xs4all.nl (8.12.9/8.12.9) with ESMTP id h98ABavY054707 for ; Wed, 8 Oct 2003 12:11:36 +0200 (CEST) Message-ID: <3F83E2A7.8070209@moniforce.com> Date: Wed, 08 Oct 2003 12:10:47 +0200 From: Peter Bozarov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Recovery from mbuf cluster exhaustion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2003 10:11:40 -0000 Hi, all, (First off, I hope I'm posting to the right list.) I have the following question regarding mbuf cluster exhaustion. If I've managed to exhaust the pool, I start getting the usual "All mbuf clusters exhausted, please see tuning(7)." message. Now, at that point this is what my mbuf pool looked like: [grid] ~ $ netstat -m 4305/4944/18240 mbufs in use (current/peak/max): 4305 mbufs allocated to data 4560/4560/4560 mbuf clusters in use (current/peak/max) 10356 Kbytes allocated to network (75% of mb_map in use) 8832 requests for memory denied 1 requests for memory delayed 0 calls to protocol drain routines [grid] ~ $ Now, the problem is not in the fact that this occurs, and tuning the kernel parameters is not what I'm interested in, since I don't need a larger pool. What I can't seem to figure out is how to flush out the "stale" mbufs/clusters. I can close down all network interfaces, and kill/restart most of the processes that I presume use up the mbufs. At a given point, there can't possibly be any processes that are hogging the mbuf clusters. Yet, a while later, this is what the pool looks like [grid] ~ $ netstat -m 4305/4944/18240 mbufs in use (current/peak/max): 4305 mbufs allocated to data 4304/4560/4560 mbuf clusters in use (current/peak/max) 10356 Kbytes allocated to network (75% of mb_map in use) 8832 requests for memory denied 1 requests for memory delayed 0 calls to protocol drain routines [grid] ~ $ A few clusters have been freed. But not much. Now, if (presumably) no clusters are being used by a process, should they not be released by the kernel? Alternatively, how can I enforce this (short of rebooting the machine, which is *not* the solution I'm looking for)? Thanks a lot for any input! Peter From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 03:13:12 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AC9416A4B3; Wed, 8 Oct 2003 03:13:12 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05ECD43FB1; Wed, 8 Oct 2003 03:13:11 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 8BEEE6546E; Wed, 8 Oct 2003 11:13:09 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 51715-01-3; Wed, 8 Oct 2003 11:13:09 +0100 (BST) Received: from saboteur.dek.spc.org (unknown [81.3.72.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 0852A653BA; Wed, 8 Oct 2003 11:13:05 +0100 (BST) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 1BD7338; Wed, 8 Oct 2003 11:12:51 +0100 (BST) Date: Wed, 8 Oct 2003 11:12:51 +0100 From: Bruce M Simpson To: Harti Brandt Message-ID: <20031008101251.GG6524@saboteur.dek.spc.org> Mail-Followup-To: Harti Brandt , Pawel Jakub Dawidek , freebsd-hackers@freebsd.org, hsu@freebsd.org, rwatson@freebsd.org References: <20031008083059.GA520@garage.freebsd.pl> <20031008114506.I63940@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031008114506.I63940@beagle.fokus.fraunhofer.de> cc: hsu@freebsd.org cc: rwatson@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2003 10:13:12 -0000 On Wed, Oct 08, 2003 at 11:51:06AM +0200, Harti Brandt wrote: > You need to lock when reading if you insist on consistent data. Even a > simple read may be non-atomic (this should be the case for 64bit > operations on all our platforms). Or keep a generation count to detect pre-emption (the devstat code does this, amongst other things), and try again if you lost the race. Or insist on atomic reads, which must complete and must not be pre-empted by definition (although the SMP case is/can be different!). BMS From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 03:15:34 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFA8616A4B3; Wed, 8 Oct 2003 03:15:34 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id D083943FDD; Wed, 8 Oct 2003 03:15:33 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 17CDA653C2; Wed, 8 Oct 2003 11:15:33 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 51625-02-2; Wed, 8 Oct 2003 11:15:32 +0100 (BST) Received: from saboteur.dek.spc.org (unknown [81.3.72.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 83CEE653BA; Wed, 8 Oct 2003 11:15:32 +0100 (BST) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 7211738; Wed, 8 Oct 2003 11:15:18 +0100 (BST) Date: Wed, 8 Oct 2003 11:15:18 +0100 From: Bruce M Simpson To: Pawel Jakub Dawidek Message-ID: <20031008101518.GH6524@saboteur.dek.spc.org> Mail-Followup-To: Pawel Jakub Dawidek , Harti Brandt , freebsd-hackers@freebsd.org, hsu@freebsd.org, rwatson@freebsd.org References: <20031008083059.GA520@garage.freebsd.pl> <20031008114506.I63940@beagle.fokus.fraunhofer.de> <20031008101222.GB520@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline In-Reply-To: <20031008101222.GB520@garage.freebsd.pl> cc: rwatson@freebsd.org cc: freebsd-hackers@freebsd.org cc: hsu@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2003 10:15:35 -0000 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 08, 2003 at 12:12:22PM +0200, Pawel Jakub Dawidek wrote: > But I'm not talking about non-atomic reads. What I'm want to show is that > even atomic read (without lock) is dangerous in some cases. >=20 > +> If you don't care about occasionally reading false data (for statistic= s or > +> such stuff) you can go without the lock. >=20 > I'm afraid that many developers thinks that atomic reads are always safe > without locks (there are many such reads in sources). I hope I'm wrong. Correcto. A while back peter@ and I discussed this. If you can think of such places, share what you've found, and let's discuss fixing the offending code so as to avoid nasty races. BMS --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: '' iD8DBQE/g+O1ueUpAYYNtTsRAgdDAJ94v8Xv46lNm5eUGrcn+XUO5RHTBgCgh5iR N7yUSOR1WKgbHq2oltOJH2w= =RJcJ -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 03:21:04 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FB8516A4B3; Wed, 8 Oct 2003 03:21:04 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACD3543F3F; Wed, 8 Oct 2003 03:21:02 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h98AL0S18200; Wed, 8 Oct 2003 12:21:00 +0200 (MEST) Date: Wed, 8 Oct 2003 12:21:00 +0200 (CEST) From: Harti Brandt To: Pawel Jakub Dawidek In-Reply-To: <20031008101222.GB520@garage.freebsd.pl> Message-ID: <20031008121734.G63940@beagle.fokus.fraunhofer.de> References: <20031008083059.GA520@garage.freebsd.pl> <20031008101222.GB520@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: hsu@freebsd.org cc: rwatson@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2003 10:21:04 -0000 X-List-Received-Date: Wed, 08 Oct 2003 10:21:04 -0000 On Wed, 8 Oct 2003, Pawel Jakub Dawidek wrote: PJD>On Wed, Oct 08, 2003 at 11:51:06AM +0200, Harti Brandt wrote: PJD>+> You need to lock when reading if you insist on consistent data. Even a PJD>+> simple read may be non-atomic (this should be the case for 64bit PJD>+> operations on all our platforms). So you need to do PJD>+> PJD>+> mtx_lock(&foo_mtx); PJD>+> bar = foo; PJD>+> mtx_unlock(&foo_mtx); PJD>+> PJD>+> if foo is a datatype that is not guaranteed to be red atomically. For PJD>+> 8-bit data you should be safe without the lock on any architecture. I'm PJD>+> not sure for 16 and 32 bit, but for 64-bit you need the look for all PJD>+> our architectures, I think. PJD> PJD>But I'm not talking about non-atomic reads. What I'm want to show is that PJD>even atomic read (without lock) is dangerous in some cases. PJD> PJD>+> If you don't care about occasionally reading false data (for statistics or PJD>+> such stuff) you can go without the lock. PJD> PJD>I'm afraid that many developers thinks that atomic reads are always safe PJD>without locks (there are many such reads in sources). I hope I'm wrong. Well, I see your point. If the writer does a non-atomic write by doing: foo = data; foo &= mask; then nothing helps. If he would do foo = data & mask; on an atomic object things may work (well, one has to read the C-standard to find out wether the compiler is allowed to convert the 2nd form to the first one.). harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 03:22:55 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5BA8E16A4B3; Wed, 8 Oct 2003 03:22:55 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id A436C43FB1; Wed, 8 Oct 2003 03:22:53 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h98AMoS18599; Wed, 8 Oct 2003 12:22:50 +0200 (MEST) Date: Wed, 8 Oct 2003 12:22:50 +0200 (CEST) From: Harti Brandt To: Bruce M Simpson In-Reply-To: <20031008101251.GG6524@saboteur.dek.spc.org> Message-ID: <20031008122203.M63940@beagle.fokus.fraunhofer.de> References: <20031008083059.GA520@garage.freebsd.pl> <20031008101251.GG6524@saboteur.dek.spc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hsu@freebsd.org cc: rwatson@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2003 10:22:55 -0000 On Wed, 8 Oct 2003, Bruce M Simpson wrote: BMS>On Wed, Oct 08, 2003 at 11:51:06AM +0200, Harti Brandt wrote: BMS>> You need to lock when reading if you insist on consistent data. Even a BMS>> simple read may be non-atomic (this should be the case for 64bit BMS>> operations on all our platforms). BMS> BMS>Or keep a generation count to detect pre-emption (the devstat code does BMS>this, amongst other things), and try again if you lost the race. BMS> BMS>Or insist on atomic reads, which must complete and must not be pre-empted BMS>by definition (although the SMP case is/can be different!). That does not help if the writes are semantically not atomic: foo = data; foo &= mask; harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 05:02:04 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B64C016A4B3; Wed, 8 Oct 2003 05:02:04 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 868A543FA3; Wed, 8 Oct 2003 05:02:02 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) h98C1dt2073758 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 8 Oct 2003 14:01:45 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id h98C1aS8026913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Oct 2003 14:01:37 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.10/8.12.10) with ESMTP id h98C1a2u033196; Wed, 8 Oct 2003 14:01:36 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.10/8.12.10/Submit) id h98C1ZPY033195; Wed, 8 Oct 2003 14:01:35 +0200 (CEST) (envelope-from ticso) Date: Wed, 8 Oct 2003 14:01:35 +0200 From: Bernd Walter To: Pawel Jakub Dawidek Message-ID: <20031008120134.GA13791@cicely12.cicely.de> References: <20031008083059.GA520@garage.freebsd.pl> <20031008114506.I63940@beagle.fokus.fraunhofer.de> <20031008101222.GB520@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031008101222.GB520@garage.freebsd.pl> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-CURRENT alpha User-Agent: Mutt/1.5.4i cc: rwatson@freebsd.org cc: freebsd-hackers@freebsd.org cc: hsu@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2003 12:02:04 -0000 On Wed, Oct 08, 2003 at 12:12:22PM +0200, Pawel Jakub Dawidek wrote: > On Wed, Oct 08, 2003 at 11:51:06AM +0200, Harti Brandt wrote: > +> You need to lock when reading if you insist on consistent data. Even a > +> simple read may be non-atomic (this should be the case for 64bit > +> operations on all our platforms). So you need to do > +> > +> mtx_lock(&foo_mtx); > +> bar = foo; > +> mtx_unlock(&foo_mtx); > +> > +> if foo is a datatype that is not guaranteed to be red atomically. For > +> 8-bit data you should be safe without the lock on any architecture. I'm > +> not sure for 16 and 32 bit, but for 64-bit you need the look for all > +> our architectures, I think. > > But I'm not talking about non-atomic reads. What I'm want to show is that > even atomic read (without lock) is dangerous in some cases. > > +> If you don't care about occasionally reading false data (for statistics or > +> such stuff) you can go without the lock. > > I'm afraid that many developers thinks that atomic reads are always safe > without locks (there are many such reads in sources). I hope I'm wrong. It depends on the architecture and usage. bar = foo might be non-interruptable, but that doesn't say anything about cache consistency. If foo was written by another thread then you can have trouble with register caching unless the variable is volatile. If the other thread was/is running on another CPU then you might read an outdated value from cache. mtx_lock/mtx_unlock takes care about caching. However - if you read a value (e.g.) for statistic output - then it won't hurt to get a cached value which is a few subseconds behind the real value. The only point to take care in this case is that the read is atomic and that all bytes in the read value are consistent. The above mtx_lock/read/mt_unlock case doesn't make sense, because it only garanties an up to date value, but you cache it in a local variable which again brings it out of date when used outside the lock. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 05:05:53 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 46D4416A4B3 for ; Wed, 8 Oct 2003 05:05:53 -0700 (PDT) Received: from pixies.tirloni.org (pixies.tirloni.org [200.203.183.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7E6243FBF for ; Wed, 8 Oct 2003 05:05:51 -0700 (PDT) (envelope-from tirloni@tirloni.org) Received: by pixies.tirloni.org (Postfix, from userid 1000) id C418B1E1433; Wed, 8 Oct 2003 09:05:49 -0300 (BRT) Date: Wed, 8 Oct 2003 09:05:49 -0300 From: "Giovanni P. Tirloni" To: Terry Lambert Message-ID: <20031008120549.GD52403@pixies.tirloni.org> Mail-Followup-To: Terry Lambert , freebsd-hackers@freebsd.org References: <20031007144635.GP25542@pixies.tirloni.org> <3F83BF33.46696D6C@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <3F83BF33.46696D6C@mindspring.com> User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org Subject: Re: netisr X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2003 12:05:53 -0000 * Terry Lambert (tlambert2@mindspring.com) wrote: > No. NETISR is a software interrupt that runs when software > interrupts run, which is to say, when the SPL is lowered as > a result of returning from the last nested hardware interrupt, > which means on hardware and clock interrupts. Yes, I missed the page in 4.4BSD D&I. > No. There are two LRP papers from Rice University. The first > was against FreeBSD 3.2, and dealt with just the idea of LRP. > The scond makes things much more complicated than they need to > be, in order to introduce a concept called "ResCon", or resource > containers. Neither set of code is really production, because > it uses an alternate protocol family definition and a seperately > hacked uipc_socket.c and uipc_socket2.c, along with the totally > parallel TCP/IP stack. I've read their first paper. > The closest you can come to LRP in FreeBSD 5.x is to use the > sysctl's for "direct dispatch", which will, in fact, directly > call ip_input() from interrupt. I'll be experimenting with it this week (like rwatson requested). > This isn't a full LRP, since it doesn't add a receive buffer > into the proc structure for per-process enqueuing of packets. > > When I implemented the 3.x version of Rice's LRP in FreeBSD 4.3, > I avoided this hack. The main reason for the hack was to deal > with accepting connections, since at interrupt, without a proc > structure, there was no way to deal with the socket creation for > the accept, due to a lack of an appropriate credential. The > sneaky approach I used for this was to create the accept socket > using the cred that was present on the listen socket on which > the connection had come in. For this to be at all useful, you > need to extend kevent accept filters to allow creation of accepted > descriptor instances in the process context, and throw them onto > the kqueue that was set up against the listen socket. > > I recommend that if you want to play with LRP, you add an attribute > flag to the protocol stack structure to indicate an LRP capable vs. > an LRP incapable stack, and then implement it inline, rather than > as a separate thing. I also recommend that if you do this, you do > it using the Rice 3.x code, and ignore the "ResCon" stuff, which I > think is an interesting idea, but which adds very little in the way > of real value to things (though it does add overhead). I'll have to research more about it but I'm taking notes about all this. > If you are asking about NETISR, then I recommend W. Richard Steven's > books, specifically "TCP/IP Illustrated, Volume 2: The Implementation". Yes. I found the page about it 5 minutes after I sent this email. Shame on me.. > FWIW: Interrupt threads, as they are used in 5.x, are pretty much > antithetical to an LRP implementation, since you can still end up > live-locked under heavy load (or denial of service attack), which > is why you wanted LRP in the first place: to make progress under a > load heavier than you could possibly respond to in a reasonable > time. The problem is that the requeing to the interrupt thread adds > back in the same type of transition boundary you were trying to take > out by getting rid of NETISR in the first place. Thank you very much for answering my question. Things are much clear now! -- Giovanni P. Tirloni Fingerprint: 8C3F BEC5 79BD 3E9B EDB8 72F4 16E8 BA5E D031 5C26 From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 05:11:23 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E68316A4B3; Wed, 8 Oct 2003 05:11:23 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E00743F3F; Wed, 8 Oct 2003 05:11:21 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h98CBCS10741; Wed, 8 Oct 2003 14:11:12 +0200 (MEST) Date: Wed, 8 Oct 2003 14:11:12 +0200 (CEST) From: Harti Brandt To: ticso@cicely.de In-Reply-To: <20031008120134.GA13791@cicely12.cicely.de> Message-ID: <20031008140803.U63940@beagle.fokus.fraunhofer.de> References: <20031008083059.GA520@garage.freebsd.pl> <20031008101222.GB520@garage.freebsd.pl> <20031008120134.GA13791@cicely12.cicely.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hsu@freebsd.org cc: rwatson@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2003 12:11:23 -0000 On Wed, 8 Oct 2003, Bernd Walter wrote: BW>On Wed, Oct 08, 2003 at 12:12:22PM +0200, Pawel Jakub Dawidek wrote: BW>> On Wed, Oct 08, 2003 at 11:51:06AM +0200, Harti Brandt wrote: BW>> +> You need to lock when reading if you insist on consistent data. Even a BW>> +> simple read may be non-atomic (this should be the case for 64bit BW>> +> operations on all our platforms). So you need to do BW>> +> BW>> +> mtx_lock(&foo_mtx); BW>> +> bar = foo; BW>> +> mtx_unlock(&foo_mtx); BW>> +> BW>> +> if foo is a datatype that is not guaranteed to be red atomically. For BW>> +> 8-bit data you should be safe without the lock on any architecture. I'm BW>> +> not sure for 16 and 32 bit, but for 64-bit you need the look for all BW>> +> our architectures, I think. BW>> BW>> But I'm not talking about non-atomic reads. What I'm want to show is that BW>> even atomic read (without lock) is dangerous in some cases. BW>> BW>> +> If you don't care about occasionally reading false data (for statistics or BW>> +> such stuff) you can go without the lock. BW>> BW>> I'm afraid that many developers thinks that atomic reads are always safe BW>> without locks (there are many such reads in sources). I hope I'm wrong. BW> BW>It depends on the architecture and usage. BW>bar = foo might be non-interruptable, but that doesn't say anything BW>about cache consistency. BW>If foo was written by another thread then you can have trouble with BW>register caching unless the variable is volatile. BW>If the other thread was/is running on another CPU then you might read BW>an outdated value from cache. BW>mtx_lock/mtx_unlock takes care about caching. BW> BW>However - if you read a value (e.g.) for statistic output - then it BW>won't hurt to get a cached value which is a few subseconds behind the BW>real value. BW>The only point to take care in this case is that the read is atomic and BW>that all bytes in the read value are consistent. BW> BW>The above mtx_lock/read/mt_unlock case doesn't make sense, because it BW>only garanties an up to date value, but you cache it in a local BW>variable which again brings it out of date when used outside the lock. You might (for what ever reason) not care that the value gets out of date later on, but care that it is correct and consistent in itself. In this case, if foo is large (64-bit or a structure) the mtx_lock/read/mtx_unlock makes perfect sense because it guarantees that the value is not changed while you're copying it (non-atomically). harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 05:45:56 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CA3716A4B3; Wed, 8 Oct 2003 05:45:56 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8105D43FBF; Wed, 8 Oct 2003 05:45:54 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) h98Cjit2074420 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 8 Oct 2003 14:45:48 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id h98CjgS8027142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Oct 2003 14:45:43 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.10/8.12.10) with ESMTP id h98Cjg2u033321; Wed, 8 Oct 2003 14:45:42 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.10/8.12.10/Submit) id h98Cjgkx033320; Wed, 8 Oct 2003 14:45:42 +0200 (CEST) (envelope-from ticso) Date: Wed, 8 Oct 2003 14:45:42 +0200 From: Bernd Walter To: Harti Brandt Message-ID: <20031008124541.GB13791@cicely12.cicely.de> References: <20031008083059.GA520@garage.freebsd.pl> <20031008114506.I63940@beagle.fokus.fraunhofer.de> <20031008101222.GB520@garage.freebsd.pl> <20031008120134.GA13791@cicely12.cicely.de> <20031008140803.U63940@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031008140803.U63940@beagle.fokus.fraunhofer.de> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-CURRENT alpha User-Agent: Mutt/1.5.4i cc: hsu@freebsd.org cc: rwatson@freebsd.org cc: ticso@cicely.de cc: freebsd-hackers@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2003 12:45:56 -0000 On Wed, Oct 08, 2003 at 02:11:12PM +0200, Harti Brandt wrote: > On Wed, 8 Oct 2003, Bernd Walter wrote: > > BW>On Wed, Oct 08, 2003 at 12:12:22PM +0200, Pawel Jakub Dawidek wrote: > BW>> But I'm not talking about non-atomic reads. What I'm want to show is that > BW>> even atomic read (without lock) is dangerous in some cases. > BW> > BW>The above mtx_lock/read/mt_unlock case doesn't make sense, because it > BW>only garanties an up to date value, but you cache it in a local > BW>variable which again brings it out of date when used outside the lock. > > You might (for what ever reason) not care that the value gets out of date > later on, but care that it is correct and consistent in itself. In this > case, if foo is large (64-bit or a structure) the mtx_lock/read/mtx_unlock > makes perfect sense because it guarantees that the value is not changed > while you're copying it (non-atomically). We agree here, but the topic was for atomic reads. If you read a 64 bit value you have to be shure that 64 bit values can be read atomicaly and if they are also written atomicaly then there is no reason to worry about the cosistency of the value itself. I'm not shure if 64 bit values are atomic on all platforms, but they are on some - at least on alpha. On all our platforms reading and writing 8, 16 and 32 bit values should be atomic if they are naturaly aligned - correct me if I'm wrong. Well if you write a 32 bit value with byte acces (e.g. with byte order macros), then you are lost even with a atomic 32 bit read. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 05:58:09 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 723EA16A4B3; Wed, 8 Oct 2003 05:58:09 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6990D43FDF; Wed, 8 Oct 2003 05:58:07 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h98Cw2S24022; Wed, 8 Oct 2003 14:58:02 +0200 (MEST) Date: Wed, 8 Oct 2003 14:58:02 +0200 (CEST) From: Harti Brandt To: ticso@cicely.de In-Reply-To: <20031008124541.GB13791@cicely12.cicely.de> Message-ID: <20031008144935.O63940@beagle.fokus.fraunhofer.de> References: <20031008083059.GA520@garage.freebsd.pl> <20031008101222.GB520@garage.freebsd.pl> <20031008140803.U63940@beagle.fokus.fraunhofer.de> <20031008124541.GB13791@cicely12.cicely.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hsu@freebsd.org cc: rwatson@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2003 12:58:09 -0000 On Wed, 8 Oct 2003, Bernd Walter wrote: BW>On Wed, Oct 08, 2003 at 02:11:12PM +0200, Harti Brandt wrote: BW>> On Wed, 8 Oct 2003, Bernd Walter wrote: BW>> BW>> BW>On Wed, Oct 08, 2003 at 12:12:22PM +0200, Pawel Jakub Dawidek wrote: BW>> BW>> But I'm not talking about non-atomic reads. What I'm want to show is that BW>> BW>> even atomic read (without lock) is dangerous in some cases. BW>> BW> BW>> BW>The above mtx_lock/read/mt_unlock case doesn't make sense, because it BW>> BW>only garanties an up to date value, but you cache it in a local BW>> BW>variable which again brings it out of date when used outside the lock. BW>> BW>> You might (for what ever reason) not care that the value gets out of date BW>> later on, but care that it is correct and consistent in itself. In this BW>> case, if foo is large (64-bit or a structure) the mtx_lock/read/mtx_unlock BW>> makes perfect sense because it guarantees that the value is not changed BW>> while you're copying it (non-atomically). BW> BW>We agree here, but the topic was for atomic reads. BW>If you read a 64 bit value you have to be shure that 64 bit values can BW>be read atomicaly and if they are also written atomicaly then there is BW>no reason to worry about the cosistency of the value itself. BW>I'm not shure if 64 bit values are atomic on all platforms, but they BW>are on some - at least on alpha. BW>On all our platforms reading and writing 8, 16 and 32 bit values should BW>be atomic if they are naturaly aligned - correct me if I'm wrong. BW>Well if you write a 32 bit value with byte acces (e.g. with byte order BW>macros), then you are lost even with a atomic 32 bit read. Well, yes. The original question, however, did non-trivial processing of the value on the writer side: foo = data; foo &= mask; Even if foo is guaranteed to be atomic on your architecture a non locking reader may slip in just between writing into foo and masking it thus getting a (semantically) inconsistent or incorrect value. Therefor whether you need to lock to read even an atomic datatype depends on the atomicity of all writers with regard to the semantics of the value. Suppose you have a variable that should only have values between 0 and 31. You may define a uint8_t foo; (guaranteeing that the data type itself is atomic). But if a writer sets foo as above and you read foo without locking, you might get a wrong value: mtx_lock(...) foo = 77; -> bar = foo; /* bar is 77 */ foo &= 0x1f; mtx_unlock(...) Even if you write foo = data & 0x1f it may not help (one has to understand all that stuff about sequence points in the C-standard). So you can go without locking in the reader only if: - the datatype is atomic (depends on your architecture) - all writers ensure that they write only consistent values to the variable The 2nd point needs very careful thinking in every case. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 07:55:18 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80C5616A4BF; Wed, 8 Oct 2003 07:55:18 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id C40BD43FE1; Wed, 8 Oct 2003 07:55:13 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) h98Et4t2076022 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 8 Oct 2003 16:55:07 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id h98Et1S8027818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Oct 2003 16:55:02 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.10/8.12.10) with ESMTP id h98Et12u033756; Wed, 8 Oct 2003 16:55:01 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.10/8.12.10/Submit) id h98EswQD033751; Wed, 8 Oct 2003 16:54:58 +0200 (CEST) (envelope-from ticso) Date: Wed, 8 Oct 2003 16:54:57 +0200 From: Bernd Walter To: Harti Brandt Message-ID: <20031008145457.GD13791@cicely12.cicely.de> References: <20031008083059.GA520@garage.freebsd.pl> <20031008114506.I63940@beagle.fokus.fraunhofer.de> <20031008101222.GB520@garage.freebsd.pl> <20031008120134.GA13791@cicely12.cicely.de> <20031008140803.U63940@beagle.fokus.fraunhofer.de> <20031008124541.GB13791@cicely12.cicely.de> <20031008144935.O63940@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031008144935.O63940@beagle.fokus.fraunhofer.de> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-CURRENT alpha User-Agent: Mutt/1.5.4i cc: hsu@freebsd.org cc: rwatson@freebsd.org cc: ticso@cicely.de cc: freebsd-hackers@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2003 14:55:18 -0000 On Wed, Oct 08, 2003 at 02:58:02PM +0200, Harti Brandt wrote: > uint8_t foo; > > (guaranteeing that the data type itself is atomic). But if a writer sets > foo as above and you read foo without locking, you might get a wrong > value: > > mtx_lock(...) > foo = 77; > > -> bar = foo; /* bar is 77 */ > > foo &= 0x1f; > mtx_unlock(...) That part is obviuosly. > Even if you write > > foo = data & 0x1f > > it may not help (one has to understand all that stuff about sequence > points in the C-standard). Unlikely, but I agree that it might cause problems. Maybe we should have atomic_load/atomic_store without barriers to be 100% shure on that. > So you can go without locking in the reader only if: > > - the datatype is atomic (depends on your architecture) > - all writers ensure that they write only consistent values to the > variable > > The 2nd point needs very careful thinking in every case. Agreed. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 08:36:28 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 538B416A4B3; Wed, 8 Oct 2003 08:36:28 -0700 (PDT) Received: from tinker.exit.com (tinker.exit.com [206.223.0.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A96343FEC; Wed, 8 Oct 2003 08:36:19 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime [206.223.0.5]) by tinker.exit.com (8.12.9/8.12.9) with ESMTP id h98FaHgv026114; Wed, 8 Oct 2003 08:36:17 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (localhost [127.0.0.1]) by realtime.exit.com (8.12.9/8.12.6) with ESMTP id h98FaHX7087801; Wed, 8 Oct 2003 08:36:17 -0700 (PDT) (envelope-from frank@realtime.exit.com) Received: (from frank@localhost) by realtime.exit.com (8.12.9/8.12.9/Submit) id h98FaFa1087800; Wed, 8 Oct 2003 08:36:15 -0700 (PDT) From: Frank Mayhar Message-Id: <200310081536.h98FaFa1087800@realtime.exit.com> In-Reply-To: <20031008083059.GA520@garage.freebsd.pl> To: Pawel Jakub Dawidek Date: Wed, 8 Oct 2003 08:36:15 -0700 (PDT) X-Copyright0: Copyright 2003 Frank Mayhar. All Rights Reserved. X-Copyright1: Permission granted for electronic reproduction as Usenet News or email only. X-Mailer: ELM [version 2.4ME+ PL99f (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: hsu@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: frank@exit.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2003 15:36:28 -0000 I read the thread hoping to see a succint response to this and so far I don't see it. Here goes... Pawel Jakub Dawidek wrote: > I'm wondering... > Jeffrey Hsu was talking about this at BSDCon03. > There is no need to lock data when we just made simple read, for example: > > mtx_lock(&foo_mtx); > foo = 5; > mtx_unlock(&foo_mtx); > but only: > bar = foo; > > IMHO this is quite dangerous. > Let's see: > > thread1 thread2 > mtx_lock(&foo_mtx); > foo = data_from_user; > bar = foo; > foo &= MASK; > mtx_unlock(&foo_mtx); > > In this case we have really dangerous race if data from user are > safe only when we made 'and' operation on them. > OR of course we can just store wrong value in 'bar' and this could > be case of different problems. There are at least two different things going on here. First off, in general an unlocked read is generally only "safe" if the writes themselves are atomic. And I mean atomic _without_ using locks. So the locked update of "foo" up there should really be: thread1 thread2 foo = (data_from_user & MASK) bar = foo So you see there is a simple race here. As long as the write to foo in thread1 is atomic by nature (which really depends on the architecture, but that's a different thread), either thread2 will end up with a stale value or it will end up with the new value. Either way, it will be a _valid_ value. > So I'm not sure now if I understand everything well. We can't just say > 'We never split such writes. We always do: foo = (data_from_user & MASK)', > because author of some 3rd party kernel module will be sure that when > he locks writes to some variable this operation is safe and he could > split such writes and in kernel could be dynamic read without lock. The other thing is that the unlocked reads about which I assume Jeffrey Hsu was speaking can only be used in very specific cases, where one has control over both the write and the read. If you have to handle unmodified third-party modules, you have no choice but to do locking, for the reason you indicate. On the other hand, you can indeed make such a rule as you describe: For this global datum, we always either write or read it in a single operation, we never do a write/read/modify/write. Hey, if it's your kernel, you can make the rules you want to make! But it's better to not allow third-party modules to use those global data. In fact, it could be that the compiler may optimize your example into a single operation. The way it is written, it's just bad coding practice, at least in this case. I don't really see that there's much about which to disagree, here. Jeffrey is right in at least certain well-defined cases. In the general case, though, you have to use some kind of explicit serialization. -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 10:46:45 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D15816A4B3 for ; Wed, 8 Oct 2003 10:46:45 -0700 (PDT) Received: from fry.webpack.hosteurope.de (fry.one-2-one.net [217.115.142.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6108843F75 for ; Wed, 8 Oct 2003 10:46:43 -0700 (PDT) (envelope-from nornagest@hackerboard.de) Received: from norna-laptop.mshome.net (l001-3.fem.tu-ilmenau.de [141.24.54.2]) (authenticated)h98Hke107547 for ; Wed, 8 Oct 2003 19:46:41 +0200 Date: Wed, 8 Oct 2003 19:45:04 +0200 From: Hagen =?ISO-8859-1?Q?K=FChl?= To: freebsd-hackers@freebsd.org Message-Id: <20031008194504.19c04286.nornagest@hackerboard.de> In-Reply-To: <20031007190052.91BF416A4C0@hub.freebsd.org> References: <20031007190052.91BF416A4C0@hub.freebsd.org> X-Mailer: Sylpheed version 0.9.3claws (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: FreeBSD 5.1 via8233 module no sound X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2003 17:46:45 -0000 Hello folks, a good friend of mine has some problems with the snd_via8233.ko sound driver module. He uses an Asus A7V8X-X mainboard with an via VT8233 AC97 compatible sound device (as scanpci says) and he's got no sound at all. #cat /dev/sndstat shows: FreeBSD Audio Driver (newpcm) Installed devices: pcm0: at io 0xe000 irq 3 (5p/1r/0v channels duplex default) scanpci shows: VIA Technologies, Inc. VT8233 AC97 Audio Controller On my laptop, where I use the same driver, I sometimes have a similar problem, but when I change the volume it works. (at my friends computer it doesn't help) I hope someone here knows help, or can do something, cause both of us can't hack the driver to work or something and we don't know how to fix it otherways. Hagen -- Scientia est potentia! E-Mail: nornagest[at]hackerboard[dot]de From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 14:29:41 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 245A716A4BF; Wed, 8 Oct 2003 14:29:41 -0700 (PDT) Received: from tinker.exit.com (tinker.exit.com [206.223.0.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70BA943F93; Wed, 8 Oct 2003 14:29:39 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime [206.223.0.5]) by tinker.exit.com (8.12.9/8.12.9) with ESMTP id h98LTcgv028144; Wed, 8 Oct 2003 14:29:39 -0700 (PDT) (envelope-from frank@exit.com) Received: from realtime.exit.com (localhost [127.0.0.1]) by realtime.exit.com (8.12.9/8.12.6) with ESMTP id h98LTcX7060016; Wed, 8 Oct 2003 14:29:38 -0700 (PDT) (envelope-from frank@realtime.exit.com) Received: (from frank@localhost) by realtime.exit.com (8.12.9/8.12.9/Submit) id h98LTcfq060015; Wed, 8 Oct 2003 14:29:38 -0700 (PDT) From: Frank Mayhar Message-Id: <200310082129.h98LTcfq060015@realtime.exit.com> To: hackers@freebsd.org, stable@freebsd.org Date: Wed, 8 Oct 2003 14:29:38 -0700 (PDT) X-Copyright0: Copyright 2003 Frank Mayhar. All Rights Reserved. X-Copyright1: Permission granted for electronic reproduction as Usenet News or email only. X-Mailer: ELM [version 2.4ME+ PL99f (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Subject: Specialix I/O8+ driver available for abuse. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: frank@exit.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2003 21:29:41 -0000 I've finally finished that driver I've been working on, for the Specialix I/O8+ multiport serial card. I've dropped a source tarball into http://www.exit.com/Archives/FreeBSD/ It has a manpage as well as a file "sx-kern-patches" which patches conf/files and conf/options to allow you to build the thing. It has not yet been really heavily tested (although it works just fine in my limited use of it). Check the manpage for configuration info. If you run into any bugs, let me know. Note that this driver is for -stable _only_. When I start running 5.x I'll port it, but not until then. Enjoy. -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 14:52:12 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D68FD16A4B3 for ; Wed, 8 Oct 2003 14:52:12 -0700 (PDT) Received: from genius.tao.org.uk (genius.tao.org.uk [212.135.162.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3671643FDF for ; Wed, 8 Oct 2003 14:52:12 -0700 (PDT) (envelope-from joe@genius.tao.org.uk) Received: by genius.tao.org.uk (Postfix, from userid 100) id CB0A845A3; Wed, 8 Oct 2003 22:52:10 +0100 (BST) Date: Wed, 8 Oct 2003 22:52:10 +0100 From: Josef Karthauser To: hackers@freebsd.org Message-ID: <20031008215210.GA50402@genius.tao.org.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: gcc object format -> need motorola s-records. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2003 21:52:13 -0000 --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Does anyone know how to control the type of output files that gcc creates? I need to generate motorola S-records instead of ELF files, but I can't find a switch to make this happen. Do I need to build a new compiler by hand, and if so, does anyone know what the backend object format is called? Thanks, Joe --=20 Josef Karthauser (joe@tao.org.uk) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D An eclectic mix of fact an= d theory. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iEYEARECAAYFAj+EhwoACgkQXVIcjOaxUBZlpgCg7tNoKRI5DNGWqVwCFt1R4Amq E4oAn3Bi1+x6BmfdeGftiem0yFV+QFae =rLbg -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 15:30:35 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34FC816A4B3; Wed, 8 Oct 2003 15:30:35 -0700 (PDT) Received: from april.chuckr.org (dsl092-151-030.wdc2.dsl.speakeasy.net [66.92.151.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3E5E43FE0; Wed, 8 Oct 2003 15:30:33 -0700 (PDT) (envelope-from chuckr@chuckr.org) Received: from chuckr.org (dsl092-151-044.wdc2.dsl.speakeasy.net [66.92.151.44]) by april.chuckr.org (Postfix) with ESMTP id 48AF711AF3; Wed, 8 Oct 2003 18:08:20 -0400 (EDT) Message-ID: <3F849006.2030607@chuckr.org> Date: Wed, 08 Oct 2003 15:30:30 -0700 From: chuckr User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030902 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Josef Karthauser References: <20031008215210.GA50402@genius.tao.org.uk> In-Reply-To: <20031008215210.GA50402@genius.tao.org.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: hackers@freebsd.org Subject: Re: gcc object format -> need motorola s-records. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2003 22:30:35 -0000 Josef Karthauser wrote: >Does anyone know how to control the type of output files that gcc >creates? I need to generate motorola S-records instead of ELF files, >but I can't find a switch to make this happen. Do I need to build a new >compiler by hand, and if so, does anyone know what the backend object >format is called? > >Thanks, >Joe > > you need to option this capability into gcc on the build, it's not automatically brought in. From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 16:14:54 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EE0816A4B3 for ; Wed, 8 Oct 2003 16:14:54 -0700 (PDT) Received: from smtp03.mrf.mail.rcn.net (smtp03.mrf.mail.rcn.net [207.172.4.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92CD643FDF for ; Wed, 8 Oct 2003 16:14:53 -0700 (PDT) (envelope-from eaja@erols.com) X-Info: This message was accepted for relay by smtp03.mrf.mail.rcn.net as the sender used SMTP authentication X-Trace: UmFuZG9tSVYecrdlpLWlMQolpkJHDRU1Vc+TBae0wM5L6e85uWfSzyig7MJC9XpP Received: from 165.sub-166-141-30.myvzw.com ([166.141.30.165] helo=localhost) by smtp03.mrf.mail.rcn.net with asmtp (Exim 3.35 #4) id 1A7NW6-0006EN-00 for freebsd-hackers@freebsd.org; Wed, 08 Oct 2003 19:14:51 -0400 Date: Wed, 8 Oct 2003 19:13:28 -0400 From: Eric Jacobs To: freebsd-hackers@freebsd.org Message-Id: <20031008191328.0f342714.eaja@erols.com> In-Reply-To: <20031008215210.GA50402@genius.tao.org.uk> References: <20031008215210.GA50402@genius.tao.org.uk> X-Mailer: Sylpheed version 0.8.5 (GTK+ 1.2.10; i386-portbld-freebsd4.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: gcc object format -> need motorola s-records. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2003 23:14:54 -0000 On Wed, 8 Oct 2003 22:52:10 +0100 Josef Karthauser wrote: > Does anyone know how to control the type of output files that gcc > creates? I need to generate motorola S-records instead of ELF files, > but I can't find a switch to make this happen. Do I need to build a new > compiler by hand, and if so, does anyone know what the backend object > format is called? gcc -Wl,--oformat -Wl,srec should do it. Eric From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 17:54:08 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D72316A4BF; Wed, 8 Oct 2003 17:54:08 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C19DB43FD7; Wed, 8 Oct 2003 17:54:06 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id h990s5gG008033; Wed, 8 Oct 2003 20:54:05 -0400 (EDT) Date: Wed, 8 Oct 2003 20:54:05 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Eric Jacobs In-Reply-To: <20031008191328.0f342714.eaja@erols.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: gcc object format -> need motorola s-records. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2003 00:54:08 -0000 On Wed, 8 Oct 2003, Eric Jacobs wrote: > On Wed, 8 Oct 2003 22:52:10 +0100 > Josef Karthauser wrote: > > > Does anyone know how to control the type of output files that gcc > > creates? I need to generate motorola S-records instead of ELF files, > > but I can't find a switch to make this happen. Do I need to build a new > > compiler by hand, and if so, does anyone know what the backend object > > format is called? > > gcc -Wl,--oformat -Wl,srec I can't get that to work for me, but: objcopy -O srec works. -- Dan Eischen From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 21:47:37 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66A2216A4B3 for ; Wed, 8 Oct 2003 21:47:37 -0700 (PDT) Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8194343F93 for ; Wed, 8 Oct 2003 21:47:36 -0700 (PDT) (envelope-from earthman@inbox.ru) Received: from [213.179.248.1] (port=3536 helo=hp6100) by mx2.mail.ru with esmtp id 1A7Si6-000K0V-00 for freebsd-hackers@freebsd.org; Thu, 09 Oct 2003 08:47:35 +0400 Date: Thu, 9 Oct 2003 07:46:45 +0300 From: earthman X-Mailer: The Bat! (v1.62r) Organization: home!!! X-Priority: 3 (Normal) Message-ID: <1197083983.20031009074645@inbox.ru> To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam: Not detected Subject: On-line judgment kernel module X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: earthman List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2003 04:47:37 -0000 I want to create on-line judge for acm like olympiads. So I have to execute some code that came in source from outside(www). Thus security problem is my main problem. The idea is to deny all syscalls for specific process p. This is possible even without rewriting kernel by kernel module. Now I'm thinking how to do this. Possibly it would be easy to point p->sv_sysent to the structure that points sv_prepsyscall to some function that denies some system calls. (kill process, make some record in module about restricted call) But I don't understand how to cancel syscall out of those function. Maybe it's possible to change code parameter to something else. -- Best regards, earthman mailto:earthman@inbox.ru icq: 145680330 From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 22:11:41 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1EF716A4B3 for ; Wed, 8 Oct 2003 22:11:41 -0700 (PDT) Received: from relay.macomnet.ru (relay.macomnet.ru [195.128.64.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4500043FBD for ; Wed, 8 Oct 2003 22:11:40 -0700 (PDT) (envelope-from maxim@macomnet.ru) Received: from news1.macomnet.ru (c16szmqi@news1.macomnet.ru [195.128.64.14]) by relay.macomnet.ru (8.12.10/8.12.10) with ESMTP id h995BbDt18308122; Thu, 9 Oct 2003 09:11:37 +0400 (MSD) Date: Thu, 9 Oct 2003 09:11:37 +0400 (MSD) From: Maxim Konovalov To: earthman In-Reply-To: <1197083983.20031009074645@inbox.ru> Message-ID: <20031009091036.X69716@news1.macomnet.ru> References: <1197083983.20031009074645@inbox.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: On-line judgment kernel module X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2003 05:11:41 -0000 On Thu, 9 Oct 2003, 07:46+0300, earthman wrote: > > I want to create on-line judge for acm like > olympiads. So I have to execute some code > that came in source from outside(www). > Thus security problem is my main problem. > > The idea is to deny all syscalls for specific > process p. This is possible even without rewriting > kernel by kernel module. You need SPY: http://people.freebsd.org/~abial/ -- Maxim Konovalov, maxim@macomnet.ru, maxim@FreeBSD.org From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 23:11:11 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 732D716A4C0 for ; Wed, 8 Oct 2003 23:11:11 -0700 (PDT) Received: from smtp.mho.com (smtp.mho.net [64.58.4.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 5E5BB43FF2 for ; Wed, 8 Oct 2003 23:11:01 -0700 (PDT) (envelope-from scottl@freebsd.org) Received: (qmail 97102 invoked by uid 1002); 9 Oct 2003 06:10:59 -0000 Received: from unknown (HELO freebsd.org) (64.58.1.252) by smtp.mho.net with SMTP; 9 Oct 2003 06:10:59 -0000 Message-ID: <3F84FBF0.5010808@freebsd.org> Date: Thu, 09 Oct 2003 00:10:56 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org, current@freebsd.org, stable@freebsd.org Content-Type: text/plain; name="report-mar-2003-sep-2003.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="report-mar-2003-sep-2003.txt" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Mar 2003 - Sep 2003 FreeBSD Status Report X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2003 06:11:11 -0000 Navigation Bar March-September 2003 Status Report Introduction: The FreeBSD Bi-monthly status reports are back! In this edition, we catch up on seven highly productive months and look forward to the end of 2003. As always, the FreeBSD development crew has been hard at work. Support for the AMD64 platform quickly sprang up and is nearly complete. KSE has improved greatly since the 5.1 release and will soon become the default threading package in FreeBSD. Many other projects are in the works to improve performance, enhance the user experience, and expand FreeBSD into new areas. Take a look below at the impressive summary of work! Scott Long, Robert Watson * Bluetooth stack for FreeBSD (Netgraph implementation) * ACPI Status Report * AMD64 Porting * ATAPI/CAM Status Report * Binary security updates for FreeBSD * bsd.java.mk version 2.0 * Compile FreeBSD with Intels C compiler (icc) * Cryptographic Support * Device_t locking * Disk I/O * Dynamically Linked Root Support * FreeBSD Java Project * FreeBSD ports monitoring system * FreeBSD/ia64 * jpman project * KDE FreeBSD Project * kgi4BSD Status Report * KSE * Network Subsystem Locking and Performance * Porting OpenBSD's pf * PowerPC Port * Release Engineering Status * Rescue build infrastructure * uart(4) * VideoBSD * WifiBSD Status Report * Wireless Networking Support Bluetooth stack for FreeBSD (Netgraph implementation) URL: http://www.geocities.com/m_evmenkin/ URL: http://bluez.sf.net URL: http://sourceforge.net/projects/openobex/ Contact: Maksim Yevmenkin I'm very pleased to announce that another release is available for download at http://www.geocities.com/m_evmenkin/ngbt-fbsd-20030908.tar.gz. I have also prepared patch for the FreeBSD source tree. The patch was submitted for review to the committers. Fixed few bugs in kernel modules. The ng_hci(4) and ng_l2cap(4) modules were changed to fix issue with Netgraph timeouts. The ng_ubt(4) module was changed to fix compilation issue on -current. Improved user-space utilities. Implemented new libsdp(3). Added new sdpcontrol(8) utility. The rfcomm_sppd(1), rfcomm_pppd(8) and obexapp(1) were changed and now can obtain RFCOMM channel via SDP from the server. The hccontorol(8) utility now has four new commands. The hcsecd(8) daemon now saves link keys on the disk. I've been recently contacted by few individuals who whould like to port current FreeBSD Bluetooth code to other BSD systems (OpenBSD and NetBSD). The work is slowly progressing towards un-Netgraph'ing current code. In the mean time Netgraph version will be the primary supported version of the code. _________________________________________________________________ ACPI Status Report URL: http://www.root.org/~nate/freebsd/ Contact: Nate Lawson Work is continuing on updating ACPI with new features as well as bugfixing. A new embedded controller driver was written in July with support for the ACPI 2.0 ECDT as well as more robust polling support. Also, a buffer overflow in the ACPICA resource list handling that caused panics for some users was fixed. Marcel helped get acpidump(8) tested and basically working on ia64. Upcoming work includes integrating ACPI notifies with devd(8), committing user-submitted drivers for ASUS and Toshiba hotkeys, Cx processor sleep states (so my laptop doesn't burn my lap), and power resource support for intelligently powering down unused or idle devices. Users who have problems with ACPI are encouraged to submit a PR and email its number to acpi-jp@jp.freebsd.org. Bug reports of panics or crashes have first priority and non-working features or missing devices (except suspend/resume problems) second. Reports of failed suspend/resume should NOT be submitted as PRs at this time due to most of them being a result of incomplete device support that is being addressed. However, feel free to mail them to the list as any information is helpful. _________________________________________________________________ AMD64 Porting Contact: Peter Wemm The last known bug that prevented AMD64 machines completing a full release has been fixed - one single character error that caused ghostscript to crash during rendering diagrams. SMP work is nearing completion and should be committed within the next few days. The SMP code uses the ACPI MADT table based on John Baldwin's work-in-progress there for i386. We need to spend some time on low level optimization because there are several suboptimal places that have been ignored for simplicity, context switching in particular. MTRR support has been committed and XFree86 can use it. cvsup now works but the ezm3 port has not been updated yet. The default data segment size limit is 8GB instead of 512M, and the (primitive) i386 binary emulation support knows how to lower the rlimits for executing 32 bit binaries. Notable things missing still: Hardware debug register support needs to be written; gdb is still being done as an external set of patches relative to the not-yet-released FSF gdb tree; DDB does not disassemble properly; DDB cannot do stack traces without -fno-omit-frame-pointer - a stack unwinder is needed; i386 and amd64 linux binary emulation is needed, and the i386 FreeBSD binary emulation still needs work - removing the stackgap code in particular. The platform in general is very reliable although a couple of problems have been reported over the last week. One appears to be a stuck interrupt, but all that code has been redone for SMP support. _________________________________________________________________ ATAPI/CAM Status Report Contact: Thomas Quinot With the introduction of ATAng, some users of ATAPI/CAM have experienced various problems. These have been mostly tracked down to issues in the new ATA code, as well as two long-standing problems in portions of the CAM layer that are rarely exercised with "real" SCSI SIMs. This has also been an occasion to cleanup ATAPI/CAM to make it more robust, and to enable DMA for devices accessed through it, resulting in improved performances. _________________________________________________________________ Binary security updates for FreeBSD URL: http://www.daemonology.net/freebsd-update/ Contact: Colin Percival FreeBSD Update is a system for tracking the FreeBSD release (security) branches. In addition to being faster and more convenient than source updates, FreeBSD Update also requires less bandwidth and is more secure than source updates via CVSup. However, FreeBSD Update is limited; it can only update files which were installed from an official RELEASE image and not recompiled locally. Right now I'm publishing binary updates for 4.7-RELEASE and 4.8-RELEASE; since my only available box takes 3.5 hours to buildworld, I don't have enough resources to do any more than that. In the near future, I'd like to: Find someone who is willing to donate a faster buildbox; start building updates for other releases (at a minimum, for all "supported" FreeBSD releases); add warnings if a file would have been updated but can't be updated because it was recompiled locally; add code to compare the local system against a list of "valid" MD5 hashes for intrusion detection purposes; and add support for cross-signing, whereby several machines could build updates independently to protect against buildbox compromise. _________________________________________________________________ bsd.java.mk version 2.0 URL: http://www.esil.univ-mrs.fr/~hquiroz/freebsd/bsd.java.mk-2.0.html Contact: Ernst De Haan Contact: Herve Quiroz The FreeBSD Java community has started an effort to improve the current framework for Java-based ports. The main objective is the automation of JDK/JRE build and run dependency checking. The original version was aimed to ease the life of porters. Although it has proved to be useful and reliable to a great extend, we are currently working on a new version. We intend to reach a high degree of flexibility to cope with the recent increase of available JDK/JRE flavors. Furthermore, the new version will be easier to maintain, which means improved reliability, and hopefully more frequent updates. _________________________________________________________________ Compile FreeBSD with Intels C compiler (icc) URL: http://www.Leidinger.net/FreeBSD/ Contact: Alexander Leidinger Since I ported icc to FreeBSD I wanted to build FreeBSD with icc. Now with icc 7.1 (and some patches) it is possible. There are still some bugs, e.g. NFS doesn't work with an icc compiled kernel, IP seems to be fragile, and some advanced optimizations trigger an ICE (Intel is working on it). At the moment I'm waiting for our admins to install icc on the FreeBSD cluster (we got a commercial license from Intel, so we are allowed to distribute binaries which are compiled with icc), after that I will try to convince some people with more knowledge of the IP and NFS parts of the kernel to debug the remaining problems. When the icc compiled kernel seems to work mostly bugfree the userland will get the porting focus. Interested people may try to do a build of the ports tree with icc independently from the status of the porting of the userland... if this happens at the FreeBSD cluster, we would also be allowed to distribute the binaries. Benefits include: another set of compiler errors (debugging help), more portable source, and code which is better optimized for a P4 (gcc has some drawbacks in this area) _________________________________________________________________ Cryptographic Support Contact: Sam Leffler Support for several new crypto devices was added. The SafeNet 1141 is a medium performance part that is not yet available on retail products. The Hifn 7955 and 7956 parts are starting to appear on retail products that should be available by the end of the year. Both devices support AES encryption. Support for public key operations for the SafeNet devices was recently done for OpenBSD and will be backported. Public key support for the Hifn parts is planned. A paper about the performance work done on the cryptographic subsystem was presented at the Usenix BSDCon 2003 conference and received the best paper award. NetBSD recently imported the cryptographic subsystem. _________________________________________________________________ Device_t locking Contact: Warner Losh A number of races have been identified in locking device_t. Most of the races have been identified in making device_t have to do with how drivers are written. Efforts are underway to identify all the races, and to contact the authors of subsystems that can help the drivers. Of special concern is the need for the driver to ensure that all threads are completely out of the driver code before detach() finishes. Of additional concern is making sure that all sleepers are woken up before certain routines are called so that other subsystems can ensure the last condition and leave no dangling references. Locking device_t is relatively straight forward apart from these issues. Towards the end of proper locking, sample strawmen drivers are being used to work out what, exactly proper is. Once these issues are all known and documented in the code, efforts will be made to update relevant documentation in the tree. There are many problems with driver locking that has been done to date, but until we nail down how to write a driver in current, it will be premature to contact specific driver writers with specific concerns. _________________________________________________________________ Disk I/O Contact: Poul-Henning Kamp The following items are in progress in the Disk I/O area: Turn scsi_cd.c into a GEOM driver. (Patch out for review). Turn atapi-cd.c into a GEOM driver. Turn fd.c into a GEOM driver. Move softupdates and snapshot processing from SPECFS to UFS/FFS. Move userland access to device drivers out of vnodes. Once these preliminaries are dealt with, scatter/gather and mapped/unmapped support will be added to struct bio/GEOM. _________________________________________________________________ Dynamically Linked Root Support Contact: Gordon Tetlow Support for a dynamically linked /bin and /sbin has been committed, although it is not turned on by default. Adventurous users can try it out by building /bin and /sbin using the WITH_DYNAMICROOT make flag. More testing is needed to determine if this is going to be default for 5.2-RELEASE. If anyone would like to benchmark worldstones with and without dynamically linked /bin and /sbin, please feel free to do so and submit the results. _________________________________________________________________ FreeBSD Java Project URL: http://www.freebsd.org/java/ Contact: Greg Lewis The BSD Java Porting Team has recently reached an exciting milestone with the release of the first "Diablo" JDK and JRE courtesy of the FreeBSD Foundation. The release of Diablo Caffe and Diablo Latte 1.3.1 was the first binary release of a native FreeBSD JDK since 1.1.8 and marks an important step forward in FreeBSD Java support. The team is continuing development work, with a focus on achieving a compliant JDK 1.4 release in the near future. _________________________________________________________________ FreeBSD ports monitoring system URL: http://lonesome.dyndns.org:4802/bento/errorlogs/index.html Contact: Mark Linimon Several months ago, I took it upon myself to to try present the information contained on the bento build cluster to be presented in a more user-friendly fashion; that is, to be browsed by error type, by maintainer, and so forth. An early addition was code to attempt to classify ports PRs by either "existing port" (after assiging the most likely category and portname); "new port"; "framework" (e.g. bsd.port.mk changes); and "unknown". Various columns about the ports PRs were added to the reports. The initial intent of this was to make life easier for ports maintainers; however, the "general" reports are also useful to anyone who just wants to, e.g., find out if a particular port is working on their particular architecture and OS combination before downloading it. Those with that general interest should start with the overview of one port. _________________________________________________________________ FreeBSD/ia64 URL: http://www.FreeBSD.org/platforms/ia64/index.html Contact: Marcel Moolenaar Much has happened since the last bi-monthly report, which was more than half a year ago. FreeBSD 5.0 and FreeBSD 5.1 have been released for example. With FreeBSD 5.2 approaching quickly, we're not going to look back too far when it comes to our achievements. There's too much ahead of us... Two milestones have been reached after FreeBSD 5.1. The first is the ability to support both Intel and HP machines with sources in CVS. This due to a whole new driver for serial ports, or UARTs. Unfortunately this still implies that syscons is not configured. That's another task for another time, but keep an eye on KGI/FreeBSD... The second milestone is the completion of KSE support. Both M:N and 1:1 threading is functional on ia64 and the old libc_r library has been obsoleted. Testing has shown that KSE (i.e. M:N) may well become the default threading model. It's looking good. The ABI hasn't changed after 5.1 and the expectation is that it won't change much. This means that we can think about becoming a tier 1 platform. This also means we need gdb(1) support. Work on it has been started but the road is bumpy and long. Kernel stability also has improved significantly and we typically have one kernel panic remaining: VM fault on no fault entry. This will be addressed with the long awaited PMAP overhaul (see below). Most work for FreeBSD 5.2 will be "sharpening the saw". Get those loose ends tied. This is a slight change of plan made possible by a slip in the release schedule. The 5.2 release is not going to be the start of the -stable branch; it has been moved to 5.3. So, we use the extra time to prepare the ground for 5.3. The planned PMAP overhaul will probably be finished after 5.2. This should address all known issues with SMP and fix those last panics. As a side-effect, major performance improvements can be expected. More news about this in the next status reports. _________________________________________________________________ jpman project URL: http://www.jp.FreeBSD.org/man-jp/ URL: ftp://daemon.jp.FreeBSD.org/pub/FreeBSD-jp/man-jp/packages-5.1.0/ja-ma n-doc-5.1.tbz Contact: Kazuo Horikawa We have released Japanese translation of 5.1-RELEASE online manual pages on June 10. _________________________________________________________________ KDE FreeBSD Project URL: http://freebsd.kde.org/ Contact: KDE-FreeBSD Mailinglist The FreeBSD ports were updated to KDE 3.1.4, another bug- and security-fixes release. With this update, the QT port was updated to version 3.2. Both will be included in FreeBSD 4.9. Significant work was spent to fix KDE on FreeBSD-CURRENT after the removal of the gcc -pthread Option. Automatic package builds from KDE CVS continued to ensure and improve the quality of the upcoming KDE 3.2 release. Future: Work is in progress to setup a new server for hosting the KDE-FreeBSD Website, Repository and another KDE CVS mirror. With help from Marcel Moolenaar the project will try to make KDE compile and working on the Intel IA64. And last but not least efforts are being made to fix the currently broken kdesu program. _________________________________________________________________ kgi4BSD Status Report URL: http://www.FreeBSD.org/~nsouch/kgi4BSD Contact: Nicholas Souchu A lot of work done since last report: site reworked completly (see new URL), console design with console message in text or graphic modes implemented, implementation of a compatibility layer to compile Linux fbdev drivers with more or less changes in the original driver (experimental). Except some memory allocation bugs, X (XGGI based on XFree 3.3.6) is now working with the same driver as the console. A basic terminal has now to be implemented. Volonteers are welcome to the project... _________________________________________________________________ KSE URL: http://www.freebsd.org/kse/index.html Contact: Dan Eischen Contact: David Xu KSE seems to be working well on x86, amd64, and ia64. The alpha userland bits are done, but a couple of functions are unimplemented in the kernel. For sparc64, the necessary functions are implemented in the kernel, but the userland context switching functions need more attention. Since 5.1, efficient scope system threads (no upcalls when they block) have been implemented, and KSE based pthread library can have both POSIX scope process threads and scope system threads. It is also possible that KSE based pthread library can implement pthread both in 1:1 and M:N mode, I know Dan has such Makefile file patch for libkse not yet committed. KSE program now can work under ULE scheduler, its efficient should be improved under the new scheduler in future. BSD scheduler is still the best scheduler for current KSE implement. _________________________________________________________________ Network Subsystem Locking and Performance Contact: Sam Leffler The purpose of this project is to improve performance of the network subsystem. A major part of this work is to complete the locking of the networking subsystem so that it no longer depends on the "Giant lock" for proper operation. Removing the use of Giant will improve performance and permit multiple instances of the network stack to operate concurrently on multiprocessor systems. This project started in August. The emphasis has been on locking the "lower half" of the networking code so that packet forwarding through the IPv4 path can operate without the Giant lock as part of the 5.2 release. To this end locking was added to several network interface drivers and much of the "middleware" code in the network was locked (e.g. ipfw, dummynet, then routing table, multicast routing support, etc). Work towards this goal is still ongoing but should be ready for 5.2. A variety of test systems have been running for several months without the Giant lock in the network drivers and IP layer. Past the 5.2 release Giant will be removed from the "upper half" of the network subsystem and the socket layer. Once this is done the plan is to measure and improve performance (though some work of this sort is always happening). The ultimate goal is a system that performs at least as well as 4.x for normal use on uniprocessor systems. On multiprocessor systems we expect to see significantly better performance than 4.x due to greater concurrency and reduced latency. _________________________________________________________________ Porting OpenBSD's pf URL: http://pf4freebsd.love2party.net URL: http://www.benzedrine.cx/pf.html URL: http://openbsd.org/faq/pf/index.html Contact: Max Laier Contact: Pyun YongHyeon The project started this spring and released version 1.0 with a port installation (security/pf) in may 2003. Version 2.0 is on the doorstep as OpenBSD 3.4 will be released. Due to the porting efforts we were able to reveal some bugs in the OpenBSD code and provided locking for the PFIL_HOOKS, which we utilize. Tarball installation of a loadable kernel module for testing can be found on the project homepage, a patchset is in the making. PF was started at OpenBSD as a substitute for ipfilter and provides the same function set. However, in the two years it exists now, it has gained many superior features that no other packet filter has. For a impression take a look at the pf FAQ. We hope to be eventually integrated into the base system. Before that we have to resolve some issues with tcpdump and kame. _________________________________________________________________ PowerPC Port Contact: Peter Grehan Work has restarted after a hiatus. Current focus is on getting loadable modules working, NEWBUSing the NetBSD dbdma code, and completing the BMAC ethernet driver. There is a huge amount of work to do. Volunteers more than welcome! _________________________________________________________________ Release Engineering Status Contact: Scott Long The release of 4.9 is just around the corner and offers Physical Address Extensions (PAE) for x86 along with the same world-class stability and performance that is expected from the 4-STABLE series. As always, don't forget to purchase a copy of the CD set from your favorite FreeBSD vendor. FreeBSD 5.1 was released in June and offered vastly improved stability over 5.0 along with a working implementation of Kernel Scheduled Entities, allowing for true multithreading of applications across multiple CPUs. FreeBSD 5.2 will be released by the end of 2003 and will focus on improved network and overall performance. _________________________________________________________________ Rescue build infrastructure Contact: Gordon Tetlow Contact: Tim Kientzle The rescue build infrastructure has been committed. There is one known issue with make using both the '-s' and '-j' flags that appears to be a bug in make. Anyone interested in tracking down should contact us. _________________________________________________________________ uart(4) Contact: Marcel Moolenaar The uart(4) project was born out of the need to have a working serial interface (i.e. an RS-232-C interface) in a legacy-free configuration and after an unsuccessful attempt to convert sio(4). The biggest problem with sio(4) is that it has been intertwined in many ugly ways into the kernel's core. Conversion could not happen without breaking something that invariably affects some group of people negatively. With sio(4) as a good bad example and a strong desire to solve multiple problems at once, the idea of an UART (Universal Asynchronuous Receiver/Transmitter) device that, given its generic name, could handle different flavors of UART hardware started to settle firmly in the authors mind. The biggest challenge was of course solving the problem of the low-level console access prior to the initialization of the bus infrastructure and still have a driver that uses the bus access exclusively. Along the way the problem of having an UART function as the keyboard on sparc64 was solved with the introduction of system devices, which also encapsulated the console as a system device. The uart(4) driver can be enhanced to support the various UART hardware on pc98 and this is currently being worked on. Keyboard support on sparc64 is underway as well. Plans exist for a rewrite of the remote gdb support that uses a generic interface to allow various drivers, including uart(4), to register itself as a communications channel. And since uart(4) does not support multi- port cards by itself, we likely need to either enhance puc(4) or otherwise introduce other umbrella drivers _________________________________________________________________ VideoBSD URL: http://people.FreeBSD.org/~jmg/videobsd.html Contact: John-Mark Gurney Still in the planning stage. Working on creating an extensible interface that is usable for both userland and kernel implementations for device drivers. Deciding on how to interface userland implemented device drivers with applications. _________________________________________________________________ WifiBSD Status Report URL: http://www.wifibsd.org Contact: Jon Disnard WifiBSD is a miniture version of FreeBSD for wireless applications. Originally for the Soekris Net45xx line of main-boards, but is now capable of being targeted to any hardware/architecture FreeBSD itself supports. Although not feature complete, WifiBSD is expected to be ready for 5.2-RELEASE. The design goal is to meet, or exceed, the functionality of commercial/consumer 802.11 wireless gear. Features that need attention (to name just a few) are: http interface, consol menu interface, and installation. Volunters are welcome. _________________________________________________________________ Wireless Networking Support Contact: Sam Leffler Numerous bugs have been fixed since the last status report (and of course a few new ones added). Progress on improved security has been slowed by other work. But new features and fixes are coming in from other groups that are now sharing the code. In particular NetBSD recently imported the revised 802.11 layer and the Linux-based MADWIFI project is using it too (albeit in an older form). The MADWIFI users have already contributed features such as fragmentation reassembly of 802.11 frames and improved signal monitoring. Power save polling and an improved rate control algorothm are expected to come in from the NetBSD folks. WPA support is still in the plans; the best estimate is that work on that will start in January. _________________________________________________________________ News Home | Status Reports Home _________________________________________________________________ freebsd-questions@FreeBSD.org Copyright © 1995-2003 the FreeBSD Project. All rights reserved. From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 9 01:15:23 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55C8616A4B3 for ; Thu, 9 Oct 2003 01:15:23 -0700 (PDT) Received: from milla.ask33.net (milla.ask33.net [217.197.166.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AF9843FE1 for ; Thu, 9 Oct 2003 01:15:20 -0700 (PDT) (envelope-from nick@milla.ask33.net) Received: by milla.ask33.net (Postfix, from userid 1001) id B751C3ABB35; Thu, 9 Oct 2003 10:17:53 +0200 (CEST) Date: Thu, 9 Oct 2003 10:17:53 +0200 From: Pawel Jakub Dawidek To: earthman Message-ID: <20031009081753.GE520@garage.freebsd.pl> References: <1197083983.20031009074645@inbox.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="Vo48LVc30GAQuLuW" Content-Disposition: inline In-Reply-To: <1197083983.20031009074645@inbox.ru> X-PGP-Key-URL: http://garage.freebsd.pl/jules.asc X-OS: FreeBSD 4.8-RELEASE-p9 i386 X-URL: http://garage.freebsd.pl User-Agent: Mutt/1.5.1i cc: freebsd-hackers@freebsd.org Subject: Re: On-line judgment kernel module X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2003 08:15:23 -0000 --Vo48LVc30GAQuLuW Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 09, 2003 at 07:46:45AM +0300, earthman wrote: +> The idea is to deny all syscalls for specific +> process p. This is possible even without rewriting +> kernel by kernel module. +>=20 +> Now I'm thinking how to do this. +> Possibly it would be easy to point p->sv_sysent +> to the structure that points sv_prepsyscall +> to some function that denies some system calls. +> (kill process, make some record in module about +> restricted call) +> But I don't understand how to cancel syscall +> out of those function. Maybe it's possible +> to change code parameter to something else. You may just try CerbNG: http://cerber.sourceforge.net It was presented on WIP session at BSDCon03, slides are here: http://garage.freebsd.pl/CerbNG.pdf 1.0-RC3 will be avaliable in near future. --=20 Pawel Jakub Dawidek pawel@dawidek.net UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net --Vo48LVc30GAQuLuW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iQCVAwUBP4UZsT/PhmMH/Mf1AQH9mwP/aYVqOcSU8hHSlvaobCLcEK3H31W20YuZ RRYtyhqUVHv0mAM0OkKixHRAxlYXu8rdICfjk8SDethOgjv5yin9BgSlbaHMWsFM a30Ltbcz0DJ2yTguttSmmcHeU+NVyTPuxjM//Pxi2cZqSMn9QLsxJhdamQR3uiSi mmPVgnhtRp4= =ZiAJ -----END PGP SIGNATURE----- --Vo48LVc30GAQuLuW-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 9 02:19:50 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C2BD16A4B3; Thu, 9 Oct 2003 02:19:50 -0700 (PDT) Received: from razorbill.mail.pas.earthlink.net (razorbill.mail.pas.earthlink.net [207.217.121.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48F5F43FF3; Thu, 9 Oct 2003 02:19:49 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfl87.dialup.mindspring.com ([165.247.213.7] helo=mindspring.com) by razorbill.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1A7Wx8-0005hJ-00; Thu, 09 Oct 2003 02:19:23 -0700 Message-ID: <3F8527E1.26ED0CF6@mindspring.com> Date: Thu, 09 Oct 2003 02:18:25 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Harti Brandt References: <20031008083059.GA520@garage.freebsd.pl> <20031008114506.I63940@beagle.fokus.fraunhofer.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4213b3ac24222c14692ec78144de9356b2601a10902912494350badd9bab72f9c350badd9bab72f9c cc: hsu@freebsd.org cc: rwatson@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2003 09:19:50 -0000 Harti Brandt wrote: > You need to lock when reading if you insist on consistent data. Even a > simple read may be non-atomic (this should be the case for 64bit > operations on all our platforms). So you need to do > > mtx_lock(&foo_mtx); > bar = foo; > mtx_unlock(&foo_mtx); > > if foo is a datatype that is not guaranteed to be red atomically. For > 8-bit data you should be safe without the lock on any architecture. I'm > not sure for 16 and 32 bit, but for 64-bit you need the look for all > our architectures, I think. > > If you don't care about occasionally reading false data (for statistics or > such stuff) you can go without the lock. For a read-before-write type read, this is always true. For an interlock read, this is also true, if you intend to use the data you read as a timing-dependent one-shot (e.g. for a condition variable, etc.). For certain uses, however, it's safe to not lock before the read *on Intel architectures*. This can go out the window on SPARC or PPC, or any architecture where there is no guarantee that there won't be speculative execution or out-of-order execution without explicit synchronization. For instance, on a PPC, there are two instructions that are used to implement a mutext, "isync" and "dsync", one which is used to check it, and the other which is used to take it. Using these, it's a lot less expensive to implement a mutex, and you are guaranteed that after you take a mutex, there's no speculative execution coherency issues left outstanding. For things with an explicit periodicity, with no explicit guarantee of order of operation, reading without a lock will do no damage. For example, consider the case of a push-model migration of processes from one CPU to another, and a (in the general case) lockless implementation of a per CPU scheduler queue with explicit migration requirements -- this avoids the FreeBSD issue of having to take a lock each time you enter the scheduler, and avoids the IPI that results, as well as implying implicit CPU affinity; here's how it works: Each CPU has 3 values associated with it: int load ptr migration queue ptr run queue When it's time to schedule a process on a given CPU, here is the order of operation: 1) Compare migration queue ptr to NULL; this is a lockless operation. 2) If the ptr is non-NULL, a) take a lock on the migration queue. b) move items on it to the per CPU run queue -- LIFO; writing the per CPU run queue is a lockless operation, since no other CPU is permited access to it (no "pull" of work for migration). c) NULL the migration queue head of the now empty migration queue. d) drop the migration queue lock. 3) Take the entry off the top of my run queue; this is what I'm going to run next. 4) Compare my 'load' value against that of other CPUs; since a CPU is the only one permitted to write it's own load value, this is a lockless operation for the read of all other CPU's 'load' value, so long as that value is accessible in a single bus/memory cycle. 5) If my load is significantly higher than the lowest of all other CPU's, consider migrating work to the lowest of all other CPU's: a) Locate any candidates for migration; these is the current top of my own run queue *after* the removal of the next thing I'm going to run, *without* the "don't migrate" bit set. b) If a candidate exists, i) Remove the item from the local run queue (lockless). ii) Take the lock on the target CPU migration queue. iii) Put the item on the target migration queue. iv) Drop the migration queue lock. 6) Recalculate my local 'load' value for the benefit of other CPUs. 7) Start executing the item obtained in step #3. Because the operation occurs periodically, and because you skip items that are marked non-migrate (you could have a bounded depth to the search, if so desired), there is the ability to implement explicit CPU affinity, and there is also the ability to implement implicit CPU affinity (since there is hysteresis in the act of deciding to "push" work off to another CPU). The purpose of LIFO ordering, and examining the migration queue before examining the local run queue *after* the LIFO ordering of inserts of work from other CPUs is that the work on the other CPU that pushed to you was at the top of its run queue, and this avoids penalizing migrated objects one scheduler cycle latency. Note that all this works, even in a decoherent system on the migration queue examination, since the worst case is you delay a migration for up to two scheduling cycles (one for the 'load' value on the origin, one for the migration queue examination on the target), and the common case is a 1.5 cycle delay (since the grab of the migration queue mutex by the origin forces a coherency cycle). And you are guaranteed to be delaying the thing to run until the next scheduling cycle on the origin CPU anyway. So there *are* cases, where it's safe, as long as you have either: 1) Multiple reader, single fixed writer, OR 2) Multiple locked writer, singe fixed reader, AND 3) Repetition with implicit hystersis, AND 4) Insensitivity to order of operation I'm pretty sure that the cases Jeffrey was thinking about all fall into that description bucket. If they don't, then he's probably not caring about SPARC and PPC, which would make sense, in terms of the model that Dragonfly BSD is using -- though I expect that they will fail to support NUMA or clustered systems properly, if that's the case (which I doubt). -- Terry From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 9 02:40:53 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEF3616A4B3; Thu, 9 Oct 2003 02:40:53 -0700 (PDT) Received: from c211-28-27-130.belrs2.nsw.optusnet.com.au (c211-28-27-130.belrs2.nsw.optusnet.com.au [211.28.27.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 325B143FF2; Thu, 9 Oct 2003 02:40:52 -0700 (PDT) (envelope-from peterjeremy@optushome.com.au) Received: from server.c211-28-27-130.belrs2.nsw.optusnet.com.au (localhost.c211-28-27-130.belrs2.nsw.optusnet.com.au [127.0.0.1]) ESMTP id h999cIdb069100; Thu, 9 Oct 2003 19:38:18 +1000 (EST) peter@server.c211-28-27-130.belrs2.nsw.optusnet.com.au) Received: (from peter@localhost) (8.12.9p1/8.12.9/Submit) id h999bgnL069097; Thu, 9 Oct 2003 19:37:42 +1000 (EST) (envelope-from peter) Date: Thu, 9 Oct 2003 19:37:42 +1000 From: Peter Jeremy To: Harti Brandt Message-ID: <20031009093741.GA69062@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> References: <20031008083059.GA520@garage.freebsd.pl> <20031008114506.I63940@beagle.fokus.fraunhofer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031008114506.I63940@beagle.fokus.fraunhofer.de> User-Agent: Mutt/1.4.1i cc: hsu@freebsd.org cc: rwatson@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2003 09:40:53 -0000 On Wed, Oct 08, 2003 at 11:51:06AM +0200, Harti Brandt wrote: >You need to lock when reading if you insist on consistent data. Even a >simple read may be non-atomic (this should be the case for 64bit >operations on all our platforms). So you need to do > >mtx_lock(&foo_mtx); >bar = foo; >mtx_unlock(&foo_mtx); > >if foo is a datatype that is not guaranteed to be red atomically. For >8-bit data you should be safe without the lock on any architecture. I'm >not sure for 16 and 32 bit, but for 64-bit you need the look for all >our architectures, I think. AFAIK, aligned 64-bit reads should be atomic on all 64-bit architectures, ie everything except i386. Smaller aligned reads should be atomic on all supported architectures. Unaligned reads are not atomic anywhere. Note that, possibly contrary to expectations, 8-bit and 16-bit _writes_ are not atomic on many (all?) the 64-bit architectures. Small writes are generally done by doing a 64-bit read, insert under mask and 64-bit write. Peter From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 9 02:41:25 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C7C916A4B3; Thu, 9 Oct 2003 02:41:25 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9C9F43FDD; Thu, 9 Oct 2003 02:41:22 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfl87.dialup.mindspring.com ([165.247.213.7] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1A7XH9-000342-00; Thu, 09 Oct 2003 02:40:05 -0700 Message-ID: <3F852C7B.81133DDE@mindspring.com> Date: Thu, 09 Oct 2003 02:38:03 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: frank@exit.com References: <200310081536.h98FaFa1087800@realtime.exit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a434d8e57a3429c19af59236b412d246723ca473d225a0f487350badd9bab72f9c350badd9bab72f9c cc: hsu@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2003 09:41:25 -0000 Frank Mayhar wrote: > The other thing is that the unlocked reads about which I assume Jeffrey > Hsu was speaking can only be used in very specific cases, where one has > control over both the write and the read. If you have to handle unmodified > third-party modules, you have no choice but to do locking, for the reason > you indicate. On the other hand, you can indeed make such a rule as you > describe: For this global datum, we always either write or read it in a > single operation, we never do a write/read/modify/write. Hey, if it's > your kernel, you can make the rules you want to make! But it's better > to not allow third-party modules to use those global data. I'm pretty sure that Jeffrey is aware of read-modify-write issues with atomic vs. idempotent multi-instruction operations, since he generally knows what he's doing. 8-). Probably the most interesting cases, from his perspective in the network stack, are queue insertions and removals for singly linked queues, where the insertion OR removal can be done atomically without taking locks (but not both, except on fully MESI coherent systems without speculative execution). FreeBSD's use of queue structures is sometimes overkill, and the macro order of operations as they are currently defined prevent non-locking operations, even where they would be safe, if the order of operation were reversed (e.g. for a simple singly linked tail queue). -- Terry From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 9 03:29:55 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84DCD16A4B3 for ; Thu, 9 Oct 2003 03:29:55 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8F8443FF5 for ; Thu, 9 Oct 2003 03:29:54 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfl87.dialup.mindspring.com ([165.247.213.7] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 1A7Y2O-00070r-00; Thu, 09 Oct 2003 03:28:53 -0700 Message-ID: <3F8537D5.8A674A9B@mindspring.com> Date: Thu, 09 Oct 2003 03:26:29 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Bozarov References: <3F83E2A7.8070209@moniforce.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4c19cfdeeb3ff8ccc13b6d053db3375dda8438e0f32a48e08350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org Subject: Re: Recovery from mbuf cluster exhaustion X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2003 10:29:55 -0000 Peter Bozarov wrote: [ ... ] > What I can't seem to figure out is how to flush out the > "stale" mbufs/clusters. I can close down all network > interfaces, and kill/restart most of the processes that I > presume use up the mbufs. At a given point, there can't > possibly be any processes that are hogging the mbuf > clusters. Yet, a while later, this is what the pool > looks like > > [grid] ~ $ netstat -m > 4305/4944/18240 mbufs in use (current/peak/max): > 4305 mbufs allocated to data > 4304/4560/4560 mbuf clusters in use (current/peak/max) > 10356 Kbytes allocated to network (75% of mb_map in use) > 8832 requests for memory denied > 1 requests for memory delayed > 0 calls to protocol drain routines > [grid] ~ $ > > A few clusters have been freed. But not much. Now, if > (presumably) no clusters are being used by a process, > should they not be released by the kernel? Alternatively, > how can I enforce this (short of rebooting the machine, > which is *not* the solution I'm looking for)? Wait for 2*MSL for the network connections to go away. Assuming the other end is still there, and not some network loading device that effectively SYN-floods and establishes "real" connections (e.g. a "Web Avalanche" or similar product). Doing a "netstat -a" will show you a list of active connections, of which I'm sure you have more than a few hanging around, even though you killed the process that opened them. You will see a number of bytes in the receive queue or transmit queue columns, and these will indicate the amount of data that you have pending in queues that's either not being read by your application, or that your application has written, but which cannot be sent because the other side of the connection has been shut off, lost network connectivity, died, or intentionally started a transfer with no intention of actually reading the data you were going to send (e.g. the Microsoft "WAST" web tool for benchmarking does this, and so does "httpload"). Probably, you need more mbuf clusters, and therefore more mbufs as well. -- Terry From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 9 05:51:03 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1C6216A4B3 for ; Thu, 9 Oct 2003 05:51:03 -0700 (PDT) Received: from host.server-23.net (host.server-23.net [64.191.95.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBA7543FEC for ; Thu, 9 Oct 2003 05:51:02 -0700 (PDT) (envelope-from samy@kerneled.com) Received: from dial36-239.sbm.net.sa ([212.46.36.239] helo=beastie.freebsd.local) by host.server-23.net with asmtp (Exim 4.24) id 1A7aFs-0004kB-97; Thu, 09 Oct 2003 05:50:57 -0700 Date: Thu, 9 Oct 2003 15:52:21 +0300 From: Samy Al Bahra To: earthman Message-Id: <20031009155221.3b29fb82.samy@kerneled.com> In-Reply-To: <1197083983.20031009074645@inbox.ru> References: <1197083983.20031009074645@inbox.ru> Organization: Kerneled X-Mailer: Sylpheed version 0.9.5-gtk2-20030906 (GTK+ 2.2.1; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.server-23.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - kerneled.com cc: freebsd-hackers@freebsd.org Subject: Re: On-line judgment kernel module X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2003 12:51:03 -0000 On Thu, 9 Oct 2003 07:46:45 +0300 earthman wrote: > Now I'm thinking how to do this. > Possibly it would be easy to point p->sv_sysent > to the structure that points sv_prepsyscall > to some function that denies some system calls. > (kill process, make some record in module about > restricted call That would work. If you prefer more granularity you may change individual sysent entries as well to point to your own functions/system calls. > But I don't understand how to cancel syscall > out of those function. Maybe it's possible > to change code parameter to something else. You may return a value (from the system call) that designates an error. Please consult the errno man page for more information. -- +-----------------------------------+ | Samy Al Bahra | samy@kerneled.com | |-----------------------------------| | B3A7 F5BE B2AE 67B1 AC4B | | 0983 956D 1F4A AA54 47CB | |-----------------------------------| | http://www.kerneled.com | +-----------------------------------+ From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 9 08:40:33 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C663816A4B3 for ; Thu, 9 Oct 2003 08:40:33 -0700 (PDT) Received: from mailout.informatik.tu-muenchen.de (mailout.informatik.tu-muenchen.de [131.159.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2462B43FD7 for ; Thu, 9 Oct 2003 08:40:32 -0700 (PDT) (envelope-from langd@informatik.tu-muenchen.de) Date: Thu, 9 Oct 2003 17:40:30 +0200 From: Daniel Lang To: hackers@freebsd.org Message-ID: <20031009154030.GI2407@atrbg11.informatik.tu-muenchen.de> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="yiup30KVCQiHUZFC" Content-Disposition: inline X-Geek: GCS/CC d-- s: a- C++$ UBS++++$ P+++$ L- E-(---) W+++(--) N++ o K w--- O? M? V? PS+(++) PE--(+) Y+ PGP+ t++ 5+++ X R+(-) tv+ b+ DI++ D++ G++ e+++ h---(-) r++>+++ y+ User-Agent: Mutt/1.5.1i X-Virus-Scanned: by amavisd-new at informatik.tu-muenchen.de Subject: Matrox Parhelia XFree86 Busmastering kernel module? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2003 15:40:33 -0000 --yiup30KVCQiHUZFC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hiho, There seems no freebsd-xfree list, but this is only XFree related, it's rather kernel oriented. Matrox offers a RedHat-Linux driver for their Parhelia based boards (Parhelia, P650, P750). The XFree86 driver module mtx_drv.o itself is OS independent and works with FreeBSD, as successfully tested on my desk, even with a multihead configuration. :) Alas, to use acceleration (2D xaa as well as 3D dri, OpenGL, etc) it requires a kernel module to enable bus mastering on the card. (I don't know if this is a common thing with Linux, or with some graphic boards? I am not aware of bus mastering is required for AGP boards, isn't AGP a dedicated bus anyway?) The kernel module for bus mastering is partially available in source. Unfortunately a core object is distributed in binary form. There are versions for RedHat 7.3 8.x and 9.=20 It seems possible to port these kind of drivers, since it worked with vmware, etc. Further it might be possible to convince matrix to share the sources of the core module or even to provide a native FreeBSD version. I did not try this, yet. So my question is: has someone attempted a port of this module? Is someone willing to do it?=20 To prevent default answers, I won't do it without specific lead from someone more experienced. (In the past I have attempted to develop other kernel drivers on my own, but failed due to lack of experience but rather due to lack of time to work on the driver and finally due to the fact, the need to get the hardware running vanished). What I can offer: testing (I own a P650 board) and also programming work, as soon as I know what it's all about and a guiding frame exists. Pointers and hints are appreciated as well. Thanks and best regards, Daniel --=20 IRCnet: Mr-Spock - Der Zweite Platz ist Dreck - Daniel Lang * dl@leo.org * +49 89 289 18532 * http://www.leo.org/~dl/ --yiup30KVCQiHUZFC Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIXgAYJKoZIhvcNAQcCoIIXcTCCF20CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FUAwggbMMIIFtKADAgECAgIVezANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCREUxETAP BgNVBAcTCE11ZW5jaGVuMSkwJwYDVQQKEyBUZWNobmlzY2hlIFVuaXZlcnNpdGFldCBNdWVu Y2hlbjEiMCAGA1UECxMZRmFrdWx0YWV0IGZ1ZXIgSW5mb3JtYXRpazEYMBYGA1UEAxMPUkJH LUJlbnV0emVyLUNBMRswGQYJKoZIhvcNAQkBFgxjYUBpbi50dW0uZGUwHhcNMDMwNTIwMTIz MTQyWhcNMDQwNTIxMDAwMDAwWjCBqzELMAkGA1UEBhMCREUxETAPBgNVBAcTCE11ZW5jaGVu MSkwJwYDVQQKEyBUZWNobmlzY2hlIFVuaXZlcnNpdGFldCBNdWVuY2hlbjEiMCAGA1UECxMZ RmFrdWx0YWV0IGZ1ZXIgSW5mb3JtYXRpazEUMBIGA1UEAxMLRGFuaWVsIExhbmcxJDAiBgkq hkiG9w0BCQEWFWRhbmllbC5sYW5nQGluLnR1bS5kZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAk55VXazdhYUuEJAHmO439gJwKVfvcdF64VyP8tzhYwiIx/9FOsQj8r8Gw2g0MDCa X2mCNiSKz32sUI33SQFhBhwxoF6bpq7d6pfeJ7UL+2T/bkRVF/Y7zPuMMK/wMbiEwyfvdjxk 8XsVtpj500LjW7QYdAHlijHRAY2nFk4f8bcCAwEAAaOCA38wggN7MAwGA1UdEwEB/wQCMAAw HQYDVR0OBBYEFPMLcu3eegcL6m8ObwlveYDdoYOpMIHKBgNVHSMEgcIwgb+AFK81Ou8wbY/H n0tx1dgCig9IKGPUoYGjpIGgMIGdMQswCQYDVQQGEwJERTERMA8GA1UEBxMITXVlbmNoZW4x KTAnBgNVBAoTIFRlY2huaXNjaGUgVW5pdmVyc2l0YWV0IE11ZW5jaGVuMSIwIAYDVQQLExlG YWt1bHRhZXQgZnVlciBJbmZvcm1hdGlrMQ8wDQYDVQQDEwZSQkctQ0ExGzAZBgkqhkiG9w0B CQEWDGNhQGluLnR1bS5kZYIBAjAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMIGxBgNVHREEgakwgaaBD2xhbmdkQGluLnR1bS5kZYEVZGFuaWVsLmxh bmdAaW4udHVtLmRlgR9sYW5nZEBpbmZvcm1hdGlrLnR1LW11ZW5jaGVuLmRlgSVkYW5pZWwu bGFuZ0BpbmZvcm1hdGlrLnR1LW11ZW5jaGVuLmRlgRBsYW5nZEBjcy50dW0uZWR1gRZkYW5p ZWwubGFuZ0Bjcy50dW0uZWR1gQpkbEBsZW8ub3JnMAkGA1UdEgQCMAAwOAYDVR0fBDEwLzAt oCugKYYnaHR0cDovL2NhLmluLnR1bS5kZS9jcmxzL3VzZXJjYV9jcmwuY3JsMBEGCWCGSAGG +EIBAQQEAwIFoDCBnwYJYIZIAYb4QgENBIGRFoGORGllc2VzIFplcnRpZmlrYXQgd3VyZGUg YXVzZ2VzdGVsbHQgZnVlciBEYW5pZWwgTGFuZyB2b24gZGVyIFJCRy1CZW51dHplci1DQSwg RmFrdWx0YWV0IGZ1ZXIgSW5mb3JtYXRpayBkZXIgVGVjaG5pc2NoZW4gVW5pdmVyc2l0YWV0 IE11ZW5jaGVuLjA2BglghkgBhvhCAQMEKRYnaHR0cDovL2NhLmluLnR1bS5kZS9jZ2ktYmlu L3VzZXJjYS1yZXY/MDIGCWCGSAGG+EIBBAQlFiNodHRwOi8vY2EuaW4udHVtLmRlL2NnaS1i aW4vY2EtcmV2PzA2BglghkgBhvhCAQgEKRYnaHR0cDovL2NhLmluLnR1bS5kZS9wb2xpY2ll cy9yYmdjYS5odG1sMA0GCSqGSIb3DQEBBQUAA4IBAQAGrfB5rH9D6jl6Tx+hwXpv0a/TuV39 vIQWMCA1hi0V4pI+bMyGTW1k/Ve5C58wRZv7CSTnxTGoqZmqnV37GGQlZBmvsDE+u3FKL/T7 Tk/rlVajExCXGHwjgHp2FfCaVMawKSUrI60aDcUgLUtT2DKpEfKfr/MC7CDtCaYy6TW93cHc uv2oM+1PN+CIcR5PaqEySmeYoXBMXd6sktjyNUWLxsNhtFMVnOiwF3SZYbRbRobuEWM3o+W7 nijECUIKz8rvK3f/c8v9HlVitMbeaTs4J1nZUR9lsvGLik6vsfIgbmuP6MMkrKFYwq5XTR1x JtMcmvnqcWytpYFDVPGuGaj1MIIHKDCCBRCgAwIBAgIBATANBgkqhkiG9w0BAQUFADCBnTEL MAkGA1UEBhMCREUxETAPBgNVBAcTCE11ZW5jaGVuMSkwJwYDVQQKEyBUZWNobmlzY2hlIFVu aXZlcnNpdGFldCBNdWVuY2hlbjEiMCAGA1UECxMZRmFrdWx0YWV0IGZ1ZXIgSW5mb3JtYXRp azEPMA0GA1UEAxMGUkJHLUNBMRswGQYJKoZIhvcNAQkBFgxjYUBpbi50dW0uZGUwHhcNMDIx MDA5MTY0MTAzWhcNMDQwNTIxMDAwMDAwWjCBpDELMAkGA1UEBhMCREUxETAPBgNVBAcTCE11 ZW5jaGVuMSkwJwYDVQQKEyBUZWNobmlzY2hlIFVuaXZlcnNpdGFldCBNdWVuY2hlbjEiMCAG A1UECxMZRmFrdWx0YWV0IGZ1ZXIgSW5mb3JtYXRpazEWMBQGA1UEAxMNUkJHLVNlcnZlci1D QTEbMBkGCSqGSIb3DQEJARYMY2FAaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAzAHBIFy4tKTvbMMg037hc9t2jR5MVpEUIPvrSWC4xpbr6Hw7abQW/lRfFpV8 enf9tSgfcl8kvGjAAD8AYeuDash6TQSUjBdZCe7V297oZ0dsuurZBkM5BwvLWF8vMiY+SD/+ XTqhnU6B/E9C+R5VXjXsXV2u9hDtKVC5hqVgnxRM5rT/LsUhcchgAXk2WuI8r9Llb+voPWwM FmHk2jxUwhvxZfGo15HDrvJUgzYsL36SmeYMI9Eo70uGmAQRPVVq2zn/3AC4z8X1cBd3ItnH YPbx0iUH5kEGq2KH5iCndwNq9oaFhKj+Y34wEv5BYl6sb5C9EBvtGyebNwuvmtC3tQIDAQAB o4ICaDCCAmQwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUH9QPe0VQVF1D2v8Su/itK/4O QMwwgcoGA1UdIwSBwjCBv4AU2WV+TUF/hD+1KtZ7E519yuW0XRqhgaOkgaAwgZ0xCzAJBgNV BAYTAkRFMREwDwYDVQQHEwhNdWVuY2hlbjEpMCcGA1UEChMgVGVjaG5pc2NoZSBVbml2ZXJz aXRhZXQgTXVlbmNoZW4xIjAgBgNVBAsTGUZha3VsdGFldCBmdWVyIEluZm9ybWF0aWsxDzAN BgNVBAMTBlJCRy1DQTEbMBkGCSqGSIb3DQEJARYMY2FAaW4udHVtLmRlggEAMA4GA1UdDwEB /wQEAwIBBjATBgNVHSUEDDAKBggrBgEFBQcDATA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8v Y2EuaW4udHVtLmRlL2NybHMvY2FfY3JsLmNybDARBglghkgBhvhCAQEEBAMCAgQwgYQGCWCG SAGG+EIBDQR3FnVaZXJ0aWZpa2F0IGZ1ZXIgUkJHLVNlcnZlci1DQSBhdXNnZXN0ZWxsdCB2 b24gUkJHLUNBLCBGYWt1bHRhZXQgZnVlciBJbmZvcm1hdGlrIGRlciBUZWNobmlzY2hlbiBV bml2ZXJzaXRhZXQgTXVlbmNoZW4wMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jYS5pbi50dW0u ZGUvY2dpLWJpbi9jYS1yZXY/MDwGCWCGSAGG+EIBCAQvFi1odHRwOi8vY2EuaW4udHVtLmRl L3BvbGljaWVzL3NlcnZlcmNhcG9sLmh0bWwwDQYJKoZIhvcNAQEFBQADggIBAMzKnULQb6Kd hPNmKKmPSJJUOtbHxGH7Qi8paskt7dzDja/X7wz3524LGN2f05c1uAfyAP9Ar0nFthWy0qeM ueOtrOcSCj8AYwYN5H4drMC8GglQwlkD0M/nhPJ5xtAj8JzNYHzG1DK5tVgoJnF+t4KmTpI6 QJ6Dh3XDoZXubWd0jkHxQIzOKhs9PPjEzydmerC7B3Zt8vh7457Sk6wwZFhXc+nkeIIplnlD sBioOSyF7hZOwx4I2Auxss1zsyUQHCX88sOuZC0kYB7yRd1TMRti8josznux8k13sZBezFMP S2yCuKRBEk5Nt57OyGbIF4O7Mhn01mTnol2BDpTKJek45bIpRvSLl/xRPpjnzxLO1rXtXgCs GtkmXj+Zwo5fnL6OvZIiFgMV4ASsFclZexceHxDjpia1IHSFB/4I5fAys8Bw03idI+rfsla1 mW0AJuw260QgoBz+b+LKGosJdNosMfOJmNl0vW3Kq6NfYpZLkG0YJF9Xo6vsATFk9kNq56ye ila80uE2wDO/BGAcBMWQ4uwfrWqVPoW5X/oHcPISApnCBeZ+LyWvnTkgxCUeyqyxNOvaA/j7 jUoBb9l+GWup8EGND16mR/wYWAxYLgis1pn5QmSTbbKSWKcqDo6HBo1Zx9XRf76CZc7RJRp9 EXqYrkmlL9eg7qcnnS1rJbqxMIIHQDCCBSigAwIBAgIBAjANBgkqhkiG9w0BAQUFADCBnTEL MAkGA1UEBhMCREUxETAPBgNVBAcTCE11ZW5jaGVuMSkwJwYDVQQKEyBUZWNobmlzY2hlIFVu aXZlcnNpdGFldCBNdWVuY2hlbjEiMCAGA1UECxMZRmFrdWx0YWV0IGZ1ZXIgSW5mb3JtYXRp azEPMA0GA1UEAxMGUkJHLUNBMRswGQYJKoZIhvcNAQkBFgxjYUBpbi50dW0uZGUwHhcNMDIx MDA5MTcwMzUyWhcNMDQwNTIxMDAwMDAwWjCBpjELMAkGA1UEBhMCREUxETAPBgNVBAcTCE11 ZW5jaGVuMSkwJwYDVQQKEyBUZWNobmlzY2hlIFVuaXZlcnNpdGFldCBNdWVuY2hlbjEiMCAG A1UECxMZRmFrdWx0YWV0IGZ1ZXIgSW5mb3JtYXRpazEYMBYGA1UEAxMPUkJHLUJlbnV0emVy LUNBMRswGQYJKoZIhvcNAQkBFgxjYUBpbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCtYQ5ycRY6fyrlvJgpeQCNhPxQduU59Kpv6xWId9sHL8NyI7nlmlWzMroD ddIqeg7QvvtPS+xorbQJ9rxh94lXZtwlGPYg4LC/1PHGnDt+8RGiq8GLbHyeJZoQnEGSovyn uR4wZ9qnApFRsXcUZ5W/CSSwjKnQeN39oFj8EC4xtmUuudV65sxGuGToRVoSnjeULJKYBNnC RxVx2MU5exKGQAuvgaVd7Ozb7ziZyWxhVCNrUQOGrSKDgyKLguWTNnD7sSOiOpie3IX8H2DV DvbcKcmMQr8ojwWutNDPadOth+J6qd/modqxB1VbH8wu0lezbhPM5dh7yUFCEqZoXXh9AgMB AAGjggJ+MIICejAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSvNTrvMG2Px59LcdXYAooP SChj1DCBygYDVR0jBIHCMIG/gBTZZX5NQX+EP7Uq1nsTnX3K5bRdGqGBo6SBoDCBnTELMAkG A1UEBhMCREUxETAPBgNVBAcTCE11ZW5jaGVuMSkwJwYDVQQKEyBUZWNobmlzY2hlIFVuaXZl cnNpdGFldCBNdWVuY2hlbjEiMCAGA1UECxMZRmFrdWx0YWV0IGZ1ZXIgSW5mb3JtYXRpazEP MA0GA1UEAxMGUkJHLUNBMRswGQYJKoZIhvcNAQkBFgxjYUBpbi50dW0uZGWCAQAwDgYDVR0P AQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDA0BgNVHR8ELTArMCmg J6AlhiNodHRwOi8vY2EuaW4udHVtLmRlL2NybHMvY2FfY3JsLmNybDAJBgNVHRIEAjAAMBEG CWCGSAGG+EIBAQQEAwIBBjCBhwYJYIZIAYb4QgENBHoWeFplcnRpZmlrYXQgZnVlciBSQkct QmVudXR6ZXItQ0EsIGF1c2dlc3RlbGx0IHZvbiBSQkctQ0EsIEZha3VsdGFldCBmdWVyIElu Zm9ybWF0aWsgZGVyIFRlY2huaXNjaGVuIFVuaXZlcnNpdGFldCBNdWVuY2hlbjAyBglghkgB hvhCAQQEJRYjaHR0cDovL2NhLmluLnR1bS5kZS9jZ2ktYmluL2NhLXJldj8wOgYJYIZIAYb4 QgEIBC0WK2h0dHA6Ly9jYS5pbi50dW0uZGUvcG9saWNpZXMvdXNlcmNhcG9sLmh0bWwwDQYJ KoZIhvcNAQEFBQADggIBAJapnE3b+p2nrryUkfTEl5iKTl7o8hLrB4FbLZsdBs16pIb0fIIq yGR0wlv0Qq5OLHm1hQzGkfhqEb2O+oBQJgaykxAB+6rKKOJdL12LSQrYXbDV8t/isyurwkFi fmcWDxVF4reDcz8F61KrVz46k2KtdY39CcuW+x1xQZRgier+jdBLLsbkM21XkufUrwnnO5Vr j0cD48XmcsVuWF0EkGo49jPHk8LG2cMyhQR/ZT4f1kegi9WmoV4NjKJnEU2QaTfbLUb2i509 RYf31oDnhq6oO1wCcRvVeDfyx5aj0y68sL1ySNmTQEELOmOFPqmVqa9BAR4wzuTXJi9UvOwF tQMsKq9AX4cFegDl4D4E5QQ7JladBMvJ0VALdGSGlGHARQGvO8SvapsOTVPC5n+UD6jwhTw0 pCPSypzIIrpT9vjxD7bDvudOfKguVRuX8poWID7yXcB0ApHdoNIMrGJx1Tc6SN6rGKWYre+W y/AsqMNNmR+YrJn/UOs6lKX9TtaHOFbxNPwo7RgdRg/srESEtIQ5IKkPA0Vt9Eh5H3VWBhrU b1gmvyNTwJFRqYmFhr7jFFdgnX3Jsbw81jl1z4jLdeeslLxs8vmnwQvWRz3BEPo+g0mrIuYt QjSdgGF8xHgyeRxfa8o3P/rncBysyNYe/AdWd6UGPmompEBZuFzSN+G8MYICCDCCAgQCAQEw ga0wgaYxCzAJBgNVBAYTAkRFMREwDwYDVQQHEwhNdWVuY2hlbjEpMCcGA1UEChMgVGVjaG5p c2NoZSBVbml2ZXJzaXRhZXQgTXVlbmNoZW4xIjAgBgNVBAsTGUZha3VsdGFldCBmdWVyIElu Zm9ybWF0aWsxGDAWBgNVBAMTD1JCRy1CZW51dHplci1DQTEbMBkGCSqGSIb3DQEJARYMY2FA aW4udHVtLmRlAgIVezAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAzMTAwOTE1NDAzMFowIwYJKoZIhvcNAQkEMRYEFPXhg2tgnocf uAVa5qgXerYJzAZYMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEB AQUABIGAXYXZG/UNxcb/rz8jP94PHaW5wbypFvoROFvhY60ewW/nz6ze8xTmrCxQX7K/j357 0lD9BH12c6/LL1opI6QeJUuEg2o+fU6DNId5F8BjNqCeQ1FLLtPeC8xetenXYBEpUBjorLUL c4+U6cPjL+t2NtdhIJ3jCgqZXreKAXoGsWU= --yiup30KVCQiHUZFC-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 9 10:04:27 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EABA16A4B3 for ; Thu, 9 Oct 2003 10:04:27 -0700 (PDT) Received: from mayo.ewwww.com (mayo.ewwww.com [216.27.179.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A41843FEA for ; Thu, 9 Oct 2003 10:04:26 -0700 (PDT) (envelope-from bharris@mayo.ewwww.com) Received: from localhost (localhost [127.0.0.1]) by mayo.ewwww.com (Postfix) with ESMTP id 41D1910A95 for ; Thu, 9 Oct 2003 10:04:26 -0700 (PDT) Received: from mayo.ewwww.com ([127.0.0.1]) by localhost (mayo [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15754-05 for ; Thu, 9 Oct 2003 10:04:25 -0700 (PDT) Received: from mayo.ewwww.com (localhost [127.0.0.1]) by mayo.ewwww.com (Postfix) with ESMTP id EB88010A91 for ; Thu, 9 Oct 2003 10:04:24 -0700 (PDT) Received: (from bharris@localhost) by mayo.ewwww.com (8.12.9+Sun/8.12.2/Submit) id h99H4OcU015903 for freebsd-hackers@freebsd.org; Thu, 9 Oct 2003 10:04:24 -0700 (PDT) Date: Thu, 9 Oct 2003 10:04:24 -0700 From: Brendan Harris To: freebsd-hackers@freebsd.org Message-ID: <20031009170424.GB29943@stotch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: Compiling Perl on SMP 5.1-RELEASE box X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2003 17:04:27 -0000 I figured this was more appropriate for freebsd-hackers than freebsd-questions. Here's the deal. I'm trying to compile Perl 5.8.1 on a FreeBSD 5.1 SMP box. The kernel is compiled with SMP, APIC and npx support. GCC is version 3.3.1, compiled with POSIX thread support. When I configure Perl with -Dusethreads -Duseithreads (or even 5005threads), it configures properly with no errors, but when I do `make' I get the following error: `sh cflags "optimize='-O'" miniperlmain.o` miniperlmain.c CCCMD = /usr/bin/gcc -DPERL_CORE -c -DAPPLLIB_EXP=/usr/local/lib/perl5/5.8.1/BSDPAN -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -ansi -ffloat-store -fno-strict-aliasing -I/usr/local/include -O -Wall `sh cflags "optimize='-O'" perl.o` perl.c CCCMD = /usr/bin/gcc -DPERL_CORE -c -DAPPLLIB_EXP=/usr/local/lib/perl5/5.8.1/BSDPAN -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -ansi -ffloat-store -fno-strict-aliasing -I/usr/local/include -O -Wall perl.c: In function `S_init_perllib': perl.c:3949: error: parse error before '/' token perl.c:3949:42: too many decimal points in number *** Error code 1 I added in the "-ansi" and "-ffloat_store" gcc arguments after I was already getting this error, just to see if it would fix the problem, but it did not fix it. I can compile Perl without thread support and it works fine. But with thread support it gives me the same error every time. The box is a dual CPU Pentium III 600 and is loading the Pentium Pro MTRR support. This happens with Perl 5.8.0 as well. Anyone have any ideas? --Brendan From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 9 10:24:34 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4395416A4B3; Thu, 9 Oct 2003 10:24:34 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09A2A43FEC; Thu, 9 Oct 2003 10:24:31 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) h99HOJt2099486 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 9 Oct 2003 19:24:22 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id h99HOHS8036540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Oct 2003 19:24:18 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.10/8.12.10) with ESMTP id h99HOH2u039406; Thu, 9 Oct 2003 19:24:17 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.10/8.12.10/Submit) id h99HOFAJ039394; Thu, 9 Oct 2003 19:24:15 +0200 (CEST) (envelope-from ticso) Date: Thu, 9 Oct 2003 19:24:15 +0200 From: Bernd Walter To: Peter Jeremy Message-ID: <20031009172414.GY13791@cicely12.cicely.de> References: <20031008083059.GA520@garage.freebsd.pl> <20031008114506.I63940@beagle.fokus.fraunhofer.de> <20031009093741.GA69062@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031009093741.GA69062@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-CURRENT alpha User-Agent: Mutt/1.5.4i cc: rwatson@freebsd.org cc: hsu@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2003 17:24:34 -0000 On Thu, Oct 09, 2003 at 07:37:42PM +1000, Peter Jeremy wrote: > On Wed, Oct 08, 2003 at 11:51:06AM +0200, Harti Brandt wrote: > >You need to lock when reading if you insist on consistent data. Even a > >simple read may be non-atomic (this should be the case for 64bit > >operations on all our platforms). So you need to do > > > >mtx_lock(&foo_mtx); > >bar = foo; > >mtx_unlock(&foo_mtx); > > > >if foo is a datatype that is not guaranteed to be red atomically. For > >8-bit data you should be safe without the lock on any architecture. I'm > >not sure for 16 and 32 bit, but for 64-bit you need the look for all > >our architectures, I think. > > AFAIK, aligned 64-bit reads should be atomic on all 64-bit > architectures, ie everything except i386. Smaller aligned reads > should be atomic on all supported architectures. Unaligned reads > are not atomic anywhere. > > Note that, possibly contrary to expectations, 8-bit and 16-bit > _writes_ are not atomic on many (all?) the 64-bit architectures. > Small writes are generally done by doing a 64-bit read, insert > under mask and 64-bit write. The mask case is true - e.g. on alpha <=ev5, but it's still atomic. You write the 8 or 16 bit in a single step, but the other bits of the same 32bit memory location are loaded into a register as well and masked. Note that this is semanticaly in no way different from a CPU loading a whole cacheline to change a single byte which is what every modern system does. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 9 10:42:16 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D161616A4B3; Thu, 9 Oct 2003 10:42:16 -0700 (PDT) Received: from mailout.informatik.tu-muenchen.de (mailout.informatik.tu-muenchen.de [131.159.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4785143FE5; Thu, 9 Oct 2003 10:42:13 -0700 (PDT) (envelope-from barner@in.tum.de) Received: by zi025.glhnet.mhn.de (Postfix, from userid 1000) id 8300D3BA26; Thu, 9 Oct 2003 19:42:11 +0200 (CEST) Date: Thu, 9 Oct 2003 19:42:11 +0200 From: Simon Barner To: Norikatsu Shigemura Message-ID: <20031009174211.GA364@zi025.glhnet.mhn.de> References: <20031008033536.7f6099b5.nork@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline In-Reply-To: <20031008033536.7f6099b5.nork@FreeBSD.org> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-new at informatik.tu-muenchen.de cc: freebsd-hackers@FreeBSD.org cc: freebsd-stable@FreeBSD.org cc: freebsd-mozilla@FreeBSD.org cc: freebsd-gnome@FreeBSD.org Subject: Re: HEADS UP: pelase test /etc/libmap.conf feature on 4-stable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2003 17:42:17 -0000 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I tested your patch, and it worked, but I had to modify the following things: Fetch libmapc. and libmap.h from the CVS repository (latest revisions). Add libmap.c to SRC section in Makefile. After these changes, I was able to compile a ld-elf.so with libmap support. > libstdc++-libc6.2-2.so.3 liblstdc++.so.3 ^--- where is this file? I changed it to libstdc++.so.3, and it worked I performed some tests with mozilla, and I ended up with exactly the same results as I pointed out in this email: http://freebsd.rambler.ru/bsdmail/freebsd-mozilla_curr/msg00012.html Another result is that mozilla locks up after successfully showing almost any of the flash plugins I tried (I afraid I cannot offer more details on this issue at the present, but I am investigating it). Regards, Simon --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/hZ3zCkn+/eutqCoRAh9FAJ91r5jbSCqhzb5uWe4Cnq6IYxocVgCgj6rC rP4uka/x3C07tYxHLc3hOow= =72D9 -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 9 11:52:21 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA63416A4B3 for ; Thu, 9 Oct 2003 11:52:21 -0700 (PDT) Received: from mx1.mail.ru (mx1.mail.ru [194.67.23.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADC6243FA3 for ; Thu, 9 Oct 2003 11:52:20 -0700 (PDT) (envelope-from earthman@inbox.ru) Received: from [213.179.248.78] (port=3642 helo=hp6100) by mx1.mail.ru with esmtp id 1A7ftb-0001xG-00; Thu, 09 Oct 2003 22:52:19 +0400 Date: Thu, 9 Oct 2003 21:52:15 +0300 From: earthman X-Mailer: The Bat! (v1.62r) Organization: home!!! X-Priority: 3 (Normal) Message-ID: <1071728001.20031009215215@inbox.ru> To: Pawel Jakub Dawidek , freebsd-hackers@freebsd.org In-Reply-To: <20031009081753.GE520@garage.freebsd.pl> References: <1197083983.20031009074645@inbox.ru> <20031009081753.GE520@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam: Not detected Subject: Re[2]: On-line judgment kernel module X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: earthman List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2003 18:52:21 -0000 PJD> You may just try CerbNG: PJD> http://cerber.sourceforge.net PJD> It was presented on WIP session at BSDCon03, slides are here: PJD> http://garage.freebsd.pl/CerbNG.pdf PJD> 1.0-RC3 will be avaliable in near future. Before I wanted to create some cerber based solution but I think it would be better to avoid scripts in such kind of tasks. I think it's even easier to make this directly. Anyway thank you for such a great security solution. I'll think more about this may be I'll give it a try. -- Best regards, earthman mailto:earthman@inbox.ru icq: 145680330 From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 9 12:27:11 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CF2D16A4B3 for ; Thu, 9 Oct 2003 12:27:11 -0700 (PDT) Received: from ussenterprise.ufp.org (ussenterprise.ufp.org [208.185.30.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DA6143FD7 for ; Thu, 9 Oct 2003 12:27:08 -0700 (PDT) (envelope-from bicknell@ussenterprise.ufp.org) Received: from ussenterprise.ufp.org (bicknell@localhost [127.0.0.1]) by ussenterprise.ufp.org (8.12.9/8.12.9) with ESMTP id h99JR78i057707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Oct 2003 15:27:07 -0400 (EDT) Received: (from bicknell@localhost) by ussenterprise.ufp.org (8.12.9/8.12.9/Submit) id h99JR7Vx057706 for freebsd-hackers@freebsd.org; Thu, 9 Oct 2003 15:27:07 -0400 (EDT) Date: Thu, 9 Oct 2003 15:27:07 -0400 From: Leo Bicknell To: freebsd-hackers@freebsd.org Message-ID: <20031009192707.GA57227@ussenterprise.ufp.org> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline Organization: United Federation of Planets X-PGP-Key: http://www.ufp.org/~bicknell/ Subject: 802.11 AP Status? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2003 19:27:11 -0000 --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I need to make a FreeBSD box be a proper 802.11 AP (BSS Mode). I've got a pile of Orinoco cards here, but they seem to still not be supported. What ever happened to that effort? Assuming they still aren't supported any recomendations on a cheap PCMCIA and/or PCI 802.11 card that is well supported in BSS Mode on FreeBSD? --=20 Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/hbaKNh6mMG5yMTYRAtc5AJ9UZVGtGtd6vGMp+zNm05wpzG9oxgCbBQcq kW8CxcJvpXE/+54JWvSqBgY= =sT/O -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 9 12:46:44 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 558) id 50B9116A4BF; Thu, 9 Oct 2003 12:46:44 -0700 (PDT) To: nick@garage.freebsd.pl Message-Id: <20031009194644.50B9116A4BF@hub.freebsd.org> Date: Thu, 9 Oct 2003 12:46:44 -0700 (PDT) From: hsu@FreeBSD.ORG (Jeffrey Hsu) cc: freebsd-hackers@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2003 19:46:44 -0000 > I'm wondering... > Jeffrey Hsu was talking about this at BSDCon03. > There is no need to lock data when we just made simple read, for example: > > mtx_lock(&foo_mtx); > foo = 5; > mtx_unlock(&foo_mtx); > but only: > bar = foo; > > IMHO this is quite dangerous. > Let's see: > > thread1 thread2 > mtx_lock(&foo_mtx); > foo = data_from_user; > bar = foo; > foo &= MASK; > mtx_unlock(&foo_mtx); > > In this case we have really dangerous race if data from user are > safe only when we made 'and' operation on them. > OR of course we can just store wrong value in 'bar' and this could > be case of different problems. This case (along with some other cases where locks of atomic reads are required) is covered in the paper as But, one case where locks would be required is if the field temporarily holds a value that no one else is supposed to see and the writer, operating with the lock held, will store a valid value before releasing his lock. In this case, both the writer and reader need to hold the lock before accessing this field. Jeffrey From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 9 14:59:52 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3220516A4B3 for ; Thu, 9 Oct 2003 14:59:52 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 3C30B43FEA for ; Thu, 9 Oct 2003 14:59:49 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 71514 invoked from network); 9 Oct 2003 21:59:47 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 9 Oct 2003 21:59:47 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 9 Oct 2003 16:59:46 -0500 (CDT) From: Mike Silbersack To: Leo Bicknell In-Reply-To: <20031009192707.GA57227@ussenterprise.ufp.org> Message-ID: <20031009165331.Q61977@odysseus.silby.com> References: <20031009192707.GA57227@ussenterprise.ufp.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: 802.11 AP Status? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2003 21:59:52 -0000 On Thu, 9 Oct 2003, Leo Bicknell wrote: > > I need to make a FreeBSD box be a proper 802.11 AP (BSS Mode). I've > got a pile of Orinoco cards here, but they seem to still not be > supported. What ever happened to that effort? > > Assuming they still aren't supported any recomendations on a cheap > PCMCIA and/or PCI 802.11 card that is well supported in BSS Mode on > FreeBSD? > > -- > Leo Bicknell - bicknell@ufp.org - CCIE 3440 I have a Netgear MA311 (Prism 2.5 chipset) doing its job as a BSS under -stable, and it works pretty well. Now, take that with a grain of salt, because I only run one node off of it, and that's a machine also running FreeBSD. That machine is running a Netgear MA401, which is the PCMCIA version of the 311. Note that if you're willing to run -current, your options are even better: According to the ath manpage, the Atheros based cards support BSS mode, they're a/b/g capable, and they're true PCI/cardbus cards, so they should perform better. Mike "Silby" Silbersack From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 9 17:38:45 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A2D816A500 for ; Thu, 9 Oct 2003 17:38:45 -0700 (PDT) Received: from obsecurity.dyndns.org (adsl-64-169-107-253.dsl.lsan03.pacbell.net [64.169.107.253]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07CFC43F85 for ; Thu, 9 Oct 2003 17:38:42 -0700 (PDT) (envelope-from kris@obsecurity.org) Received: from rot13.obsecurity.org (rot13.obsecurity.org [10.0.0.5]) by obsecurity.dyndns.org (Postfix) with ESMTP id 459D366D97; Thu, 9 Oct 2003 17:38:31 -0700 (PDT) Received: by rot13.obsecurity.org (Postfix, from userid 1000) id 06FD8B87; Thu, 9 Oct 2003 17:38:31 -0700 (PDT) Date: Thu, 9 Oct 2003 17:38:30 -0700 From: Kris Kennaway To: Brendan Harris Message-ID: <20031010003830.GA10632@rot13.obsecurity.org> References: <20031009170424.GB29943@stotch.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: <20031009170424.GB29943@stotch.com> User-Agent: Mutt/1.4.1i cc: freebsd-hackers@freebsd.org Subject: Re: Compiling Perl on SMP 5.1-RELEASE box X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 00:38:45 -0000 --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 09, 2003 at 10:04:24AM -0700, Brendan Harris wrote: > I figured this was more appropriate for freebsd-hackers than freebsd-ques= tions. >=20 > Here's the deal. I'm trying to compile Perl 5.8.1 on a FreeBSD 5.1 > SMP box. The kernel is compiled with SMP, APIC and npx support. > GCC is version 3.3.1, compiled with POSIX thread support. 1) Please wrap your lines at 70 characters so your emails may be easily read. 2) This should probably be raised with the perl people instead, because it looks like a code bug in perl (or possibly user error). FYI, the details of the FreeBSD kernel configuration are not relevant. Kris --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/hf+GWry0BWjoQKURAswwAJ4hMsFSScjQDPGLRFNQNqMJtO4JtACgqHsm Auvd3SmFYXHpIz5yWgBrK90= =pTc8 -----END PGP SIGNATURE----- --a8Wt8u1KmwUX3Y2C-- From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 9 18:39:46 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7615A16A4B3; Thu, 9 Oct 2003 18:39:46 -0700 (PDT) Received: from april.chuckr.org (dsl092-151-030.wdc2.dsl.speakeasy.net [66.92.151.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 343DC43FB1; Thu, 9 Oct 2003 18:39:45 -0700 (PDT) (envelope-from chuckr@chuckr.org) Received: from chuckr.org (dsl092-151-044.wdc2.dsl.speakeasy.net [66.92.151.44]) by april.chuckr.org (Postfix) with ESMTP id 6DB7E1152A; Thu, 9 Oct 2003 21:17:13 -0400 (EDT) Message-ID: <3F860DE4.90007@chuckr.org> Date: Thu, 09 Oct 2003 18:39:48 -0700 From: chuckr User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030902 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: deischen@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Eric Jacobs cc: freebsd-hackers@freebsd.org Subject: Re: gcc object format -> need motorola s-records. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 01:39:46 -0000 Daniel Eischen wrote: >On Wed, 8 Oct 2003, Eric Jacobs wrote: > > > >>On Wed, 8 Oct 2003 22:52:10 +0100 >>Josef Karthauser wrote: >> >> >> >>>Does anyone know how to control the type of output files that gcc >>>creates? I need to generate motorola S-records instead of ELF files, >>>but I can't find a switch to make this happen. Do I need to build a new >>>compiler by hand, and if so, does anyone know what the backend object >>>format is called? >>> >>> >>gcc -Wl,--oformat -Wl,srec >> >> > >I can't get that to work for me, but: > > objcopy -O srec > >works. > > > I really think you had to recompile all of gcc (like I;d posted before). I know it's a method that's available from libiberty, but I didn't think it was compiled in unless you specifically optioned it. At that point, then, you could give the options you mentioned and get it to work. From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 00:18:10 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D70216A4DE; Fri, 10 Oct 2003 00:18:10 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C84843F75; Fri, 10 Oct 2003 00:18:08 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h9A7I7302361; Fri, 10 Oct 2003 09:18:07 +0200 (MEST) Date: Fri, 10 Oct 2003 09:18:07 +0200 (CEST) From: Harti Brandt To: Jeffrey Hsu In-Reply-To: <20031009194644.50B9116A4BF@hub.freebsd.org> Message-ID: <20031010091003.Q95881@beagle.fokus.fraunhofer.de> References: <20031009194644.50B9116A4BF@hub.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 07:18:10 -0000 On Thu, 9 Oct 2003, Jeffrey Hsu wrote: JH> > I'm wondering... JH> > Jeffrey Hsu was talking about this at BSDCon03. JH> > There is no need to lock data when we just made simple read, for example: JH> > JH> > mtx_lock(&foo_mtx); JH> > foo = 5; JH> > mtx_unlock(&foo_mtx); JH> > but only: JH> > bar = foo; JH> > JH> > IMHO this is quite dangerous. JH> > Let's see: JH> > JH> > thread1 thread2 JH> > mtx_lock(&foo_mtx); JH> > foo = data_from_user; JH> > bar = foo; JH> > foo &= MASK; JH> > mtx_unlock(&foo_mtx); JH> > JH> > In this case we have really dangerous race if data from user are JH> > safe only when we made 'and' operation on them. JH> > OR of course we can just store wrong value in 'bar' and this could JH> > be case of different problems. JH> JH>This case (along with some other cases where locks of atomic reads JH>are required) is covered in the paper as JH> JH> But, one case where locks would be required is if the field JH> temporarily holds a value that no one else is supposed to see and JH> the writer, operating with the lock held, will store a valid value JH> before releasing his lock. In this case, both the writer and JH> reader need to hold the lock before accessing this field. Yes. When I read the C standard foo = data & mask; wouldn't also help, because there is no sequence point in this statement except at the ;. So the compiler is free to compile this as foo = data, foo &= mask; unless foo is declared as volatile (in this case the write to foo is supposed to have a side effect so that the compiler cannot write twice to foo when only one write is specified). So I suppose that a lockless read is (in MI code) only allowed if the object is 32-bit and is written too with a simple assigment or is declared volatile. harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 00:33:24 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A67D16A4B3 for ; Fri, 10 Oct 2003 00:33:24 -0700 (PDT) Received: from mailbo.vtcif.telstra.com.au (mailbo.vtcif.telstra.com.au [202.12.144.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2989E43FDF for ; Fri, 10 Oct 2003 00:33:23 -0700 (PDT) (envelope-from ghd832332157@geckomail.org) Received: by mailbo.vtcif.telstra.com.au (Postfix, from userid 5) id D2354228F1; Fri, 10 Oct 2003 17:33:20 +1000 (EST) Received: from mailbi.vtcif.telstra.com.au(202.12.142.19) via SMTP by mailbo.vtcif.telstra.com.au, id smtpdM_aqrU; Fri Oct 10 17:33:12 2003 Received: from mailbi.vtcif.telstra.com.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 3153B22885 for ; Fri, 10 Oct 2003 17:33:10 +1000 (EST) Received: from mail.cdn.telstra.com.au (mail.cdn.telstra.com.au [144.135.138.138]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id 721792289F for ; Fri, 10 Oct 2003 17:33:08 +1000 (EST) Received: from fuzzy.trl.telstra.com.au (fuzzy.trl.telstra.com.au [137.147.132.229]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with SMTP id RAA16219 for ; Fri, 10 Oct 2003 17:33:08 +1000 (EST) Received: (qmail 14187 invoked from network); 10 Oct 2003 07:33:08 -0000 Received: from buttercup.trl.telstra.com.au (HELO ?137.147.132.188?) (137.147.132.188) by elvin.trl.telstra.com.au with SMTP; 10 Oct 2003 07:33:08 -0000 From: CJ East To: freebsd-hackers@freebsd.org Content-Type: text/plain Message-Id: <1065771155.977.79.camel@buttercup.trl.telstra.com.au> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 10 Oct 2003 17:32:36 +1000 Content-Transfer-Encoding: 7bit Subject: Hey :P X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 07:33:24 -0000 Hi all :P My apologies if this is a fixed problem/etc I'm new to FreeBSD so here goes... I'm running a 1-week on 5.1-STABLE world / i386 , but my sound card intermittently stops playing under xmms. PR Kern/40711 looks very similar, it looks to have the same symptoms as my own, however my looking has lead me to snd_pcm.ko module as the root cause. Specifically, I can reproduce the problem (making hw.snd.pcm0.vchans=8) and have taken it as far as sndbuf_remalloc (in /usr/src/sys/dev/sound/pcm/buffer.c), in which one of two malloc calls fail, unwinding all the way to the top where xmms prints it's lovely message. The actual call to malloc looks sane enough to my eyes (131072 bytes, it does this successfully beforehand so I'm guessing no probs there). I'm suspecting that there's a leak somewhere and we've hit a hard limit. (Of course, I'm just stabbing in the dark, so let me know if y'all have another idea) If somebody could let me know where to run with this it would be quite helpful (I'm assuming there's some way of checking the amount allocated to M_DEVBUF, but I've no idea how! :( ) -- I can reproduce the problem (reasonably sporadically, about once an hour or so with xmms playing) I looked at the underlying malloc function but I'm a little retiscent to start putting printf's in there... ;) What's the best course of action somebody? -cje- From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 00:44:56 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABE8E16A4BF for ; Fri, 10 Oct 2003 00:44:56 -0700 (PDT) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02A2843FA3 for ; Fri, 10 Oct 2003 00:44:55 -0700 (PDT) (envelope-from des@des.no) Received: from smtp.des.no (37.80-203-228.nextgentel.com [80.203.228.37]) by mail.broadpark.no (Postfix) with ESMTP id 85D8178642; Fri, 10 Oct 2003 09:44:53 +0200 (MEST) Received: by smtp.des.no (Pony Express, from userid 666) id 3C4FA9C2CB; Fri, 10 Oct 2003 09:44:53 +0200 (CEST) Received: from dwp.des.no (dwp.des.no [10.0.0.4]) by smtp.des.no (Pony Express) with ESMTP id 3B7A79C2BF; Fri, 10 Oct 2003 09:44:49 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 2CF8BB824; Fri, 10 Oct 2003 09:44:49 +0200 (CEST) To: CJ East References: <1065771155.977.79.camel@buttercup.trl.telstra.com.au> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Fri, 10 Oct 2003 09:44:49 +0200 In-Reply-To: <1065771155.977.79.camel@buttercup.trl.telstra.com.au> (CJ East's message of "Fri, 10 Oct 2003 17:32:36 +1000") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, hits=-2.1 required=8.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,MAILTO_TO_SPAM_ADDR,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-hackers@freebsd.org Subject: Re: Hey :P X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 07:44:56 -0000 CJ East writes: > I'm running a 1-week on 5.1-STABLE world / i386 There is no 5.1-STABLE, and hackers@ is not the right place to ask this kind of question. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 00:46:03 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08EAD16A4B3 for ; Fri, 10 Oct 2003 00:46:03 -0700 (PDT) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65DE343FEC for ; Fri, 10 Oct 2003 00:45:56 -0700 (PDT) (envelope-from kientzle@acm.org) Received: from acm.org ([66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id h9A7jlkX044947; Fri, 10 Oct 2003 00:45:47 -0700 (PDT) (envelope-from kientzle@acm.org) Message-ID: <3F8663AA.4010707@acm.org> Date: Fri, 10 Oct 2003 00:45:46 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harti Brandt References: <20031009194644.50B9116A4BF@hub.freebsd.org> <20031010091003.Q95881@beagle.fokus.fraunhofer.de> In-Reply-To: <20031010091003.Q95881@beagle.fokus.fraunhofer.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kientzle@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 07:46:03 -0000 Harti Brandt wrote: > Yes. When I read the C standard > foo = data & mask; > wouldn't also help, because there is no sequence point in this statement > except at the ;. Before anyone takes this particular line of reasoning seriously, I feel compelled to point out that sequence points have nothing to do with this. a) Sequence points are an "as if" requirement. The program must produce the same results "as if" it strictly obeyed sequence points. It doesn't have to really operate that way. (And, in fact, well-optimized programs running on modern processors rarely do.) b) Sequence points say NOTHING about how multiple threads or processors interact. Sorry, but the C standard doesn't help here. The C standard does not address multi-threading at all. Tim Kientzle From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 00:57:25 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AAADE16A4B3; Fri, 10 Oct 2003 00:57:25 -0700 (PDT) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CAD743FAF; Fri, 10 Oct 2003 00:57:24 -0700 (PDT) (envelope-from kientzle@acm.org) Received: from acm.org ([66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id h9A7vGkX044990; Fri, 10 Oct 2003 00:57:16 -0700 (PDT) (envelope-from kientzle@acm.org) Message-ID: <3F86665A.8050209@acm.org> Date: Fri, 10 Oct 2003 00:57:14 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Terry Lambert References: <20031008083059.GA520@garage.freebsd.pl> <20031008114506.I63940@beagle.fokus.fraunhofer.de> <3F8527E1.26ED0CF6@mindspring.com> In-Reply-To: <3F8527E1.26ED0CF6@mindspring.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: rwatson@freebsd.org cc: hsu@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kientzle@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 07:57:25 -0000 Terry Lambert wrote: > For certain uses, however, it's safe to not lock before the > read *on Intel architectures*. This can go out the window on > SPARC or PPC, or any architecture where there is no guarantee > that there won't be speculative execution or out-of-order > execution without explicit synchronization. Even on Intel architectures, the compiler can and will reorder operations. Hardware-level issues are only a part of the story. I followed the Java Memory Model mailing lists for a while. A lot of very bright, very experienced people thought they had found ways to avoid locking and were wrong. This stuff is hard. Do NOT underestimate it. Tim From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 01:22:27 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8B1016A4B3; Fri, 10 Oct 2003 01:22:27 -0700 (PDT) Received: from milla.ask33.net (milla.ask33.net [217.197.166.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0441943FDF; Fri, 10 Oct 2003 01:22:27 -0700 (PDT) (envelope-from nick@milla.ask33.net) Received: by milla.ask33.net (Postfix, from userid 1001) id D27593ABB35; Fri, 10 Oct 2003 10:25:05 +0200 (CEST) Date: Fri, 10 Oct 2003 10:25:05 +0200 From: Pawel Jakub Dawidek To: Jeffrey Hsu Message-ID: <20031010082505.GG520@garage.freebsd.pl> References: <20031009194644.50B9116A4BF@hub.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="W302I+VHGNbNYdEm" Content-Disposition: inline In-Reply-To: <20031009194644.50B9116A4BF@hub.freebsd.org> X-PGP-Key-URL: http://garage.freebsd.pl/jules.asc X-OS: FreeBSD 4.8-RELEASE-p9 i386 X-URL: http://garage.freebsd.pl User-Agent: Mutt/1.5.1i cc: freebsd-hackers@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 08:22:27 -0000 --W302I+VHGNbNYdEm Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 09, 2003 at 12:46:44PM -0700, Jeffrey Hsu wrote: +> This case (along with some other cases where locks of atomic reads +> are required) is covered in the paper as +>=20 +> But, one case where locks would be required is if the field +> temporarily holds a value that no one else is supposed to see and +> the writer, operating with the lock held, will store a valid value +> before releasing his lock. In this case, both the writer and +> reader need to hold the lock before accessing this field. This isn't trivial problem for me, because: 1. Are we permitted to don't use locks while atomic read if it depends on writter, not on reader? If I'm adding variable modification and this modification have to be safe, I've to check every read of this variable and add locks everywhere. This order isn't quite correct. 2. If there is a chance for race while writting data not-atomically why we only permit atomic reads? In atomic vs. not-atomic read only probability of race is smaller, but it is still there. --=20 Pawel Jakub Dawidek pawel@dawidek.net UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net --W302I+VHGNbNYdEm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iQCVAwUBP4Zs4T/PhmMH/Mf1AQFYfQP/bUSgpQudG3h5HQ6lW0GMZw0k0U75t65C L7kBG3xx1iPMdOiTHW+/iHjPtwQLZ/V7SmcyrAYiGEnEg12bISNPfjR1zTMYoNnu clqSaaRxAEsQuMCx2fSJrMr4CSeRU3cas7HZgIl/m5toHCJ6fMTpLro+w+ns0LM2 0wqe14JBIBQ= =ijTX -----END PGP SIGNATURE----- --W302I+VHGNbNYdEm-- From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 02:46:46 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B66616A4BF for ; Fri, 10 Oct 2003 02:46:46 -0700 (PDT) Received: from mayo.ewwww.com (mayo.ewwww.com [216.27.179.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B4CB43FBF for ; Fri, 10 Oct 2003 02:46:45 -0700 (PDT) (envelope-from bharris@mayo.ewwww.com) Received: from localhost (localhost [127.0.0.1]) by mayo.ewwww.com (Postfix) with ESMTP id BC6AE10AD2; Fri, 10 Oct 2003 02:46:42 -0700 (PDT) Received: from mayo.ewwww.com ([127.0.0.1]) by localhost (mayo [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18852-08; Fri, 10 Oct 2003 02:46:41 -0700 (PDT) Received: from mayo.ewwww.com (localhost [127.0.0.1]) by mayo.ewwww.com (Postfix) with ESMTP id 844B410AD1; Fri, 10 Oct 2003 02:46:41 -0700 (PDT) Received: (from bharris@localhost) by mayo.ewwww.com (8.12.9+Sun/8.12.2/Submit) id h9A9keLp019096; Fri, 10 Oct 2003 02:46:40 -0700 (PDT) Date: Fri, 10 Oct 2003 02:46:40 -0700 From: Brendan Harris To: Kris Kennaway Message-ID: <20031010094640.GC29943@stotch.com> References: <20031009170424.GB29943@stotch.com> <20031010003830.GA10632@rot13.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031010003830.GA10632@rot13.obsecurity.org> User-Agent: Mutt/1.4.1i cc: freebsd-hackers@freebsd.org Subject: Re: Compiling Perl on SMP 5.1-RELEASE box X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 09:46:46 -0000 On Thu, Oct 09, 2003 at 05:38:30PM -0700, Kris Kennaway wrote: > On Thu, Oct 09, 2003 at 10:04:24AM -0700, Brendan Harris wrote: > > I figured this was more appropriate for freebsd-hackers than freebsd-questions. > > > > Here's the deal. I'm trying to compile Perl 5.8.1 on a FreeBSD 5.1 > > SMP box. The kernel is compiled with SMP, APIC and npx support. > > GCC is version 3.3.1, compiled with POSIX thread support. > > 1) Please wrap your lines at 70 characters so your emails may be > easily read. Sorry about that. > 2) This should probably be raised with the perl people instead, > because it looks like a code bug in perl (or possibly user error). > FYI, the details of the FreeBSD kernel configuration are not relevant. After doing some research online, it seems like a kernel optimization error with threads. And it looks more like a GCC problem to me, rather than a perl code bug. I think it's a problem with the way I configured GCC. I'll look into it more, but thanks for the help anyway. --Brendan From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 03:36:40 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 729) id 6F5A216A4BF; Fri, 10 Oct 2003 03:36:40 -0700 (PDT) To: freebsd-hackers@freebsd.org Cc: Message-Id: <20031010103640.6F5A216A4BF@hub.freebsd.org> Date: Fri, 10 Oct 2003 03:36:40 -0700 (PDT) From: jkoshy@FreeBSD.ORG (Joseph Koshy) Subject: Determining CPU features / cache organization from userland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 10:36:40 -0000 Hi -hackers, I'm looking for ways that a userland program can determine the CPU features available on an SMP machine -- processor model, stepping numbers, supported features, cache organization etc. For example, on some x86 processors the CPUID instruction could be used to determine some of these parameters, but using this instruction in an SMP context is a little tricky since we do not know which CPU gets to execute the instruction. Would you know of any existing APIs, in use in other OSes, for retrieving this kind of information? Regards, Koshy From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 04:00:29 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB33D16A4BF for ; Fri, 10 Oct 2003 04:00:29 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 7C53A43FDD for ; Fri, 10 Oct 2003 04:00:28 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 11827 invoked from network); 10 Oct 2003 11:00:27 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 10 Oct 2003 11:00:27 -0000 X-pair-Authenticated: 209.68.2.70 Date: Fri, 10 Oct 2003 06:00:26 -0500 (CDT) From: Mike Silbersack To: Joseph Koshy In-Reply-To: <20031010103640.6F5A216A4BF@hub.freebsd.org> Message-ID: <20031010055857.M1695@odysseus.silby.com> References: <20031010103640.6F5A216A4BF@hub.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org Subject: Re: Determining CPU features / cache organization from userland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 11:00:29 -0000 On Fri, 10 Oct 2003, Joseph Koshy wrote: > Hi -hackers, > > I'm looking for ways that a userland program can determine the CPU > features available on an SMP machine -- processor model, stepping > numbers, supported features, cache organization etc. > > For example, on some x86 processors the CPUID instruction could be > used to determine some of these parameters, but using this instruction > in an SMP context is a little tricky since we do not know which CPU > gets to execute the instruction. At least in the Intel world, multiprocessor systems are _always_ supposed to have matching processor steppings, so the reliability of the information should be very good indeed. Mike "Silby" Silbersack From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 05:42:28 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCAE416A4BF for ; Fri, 10 Oct 2003 05:42:27 -0700 (PDT) Received: from smtp.noos.fr (nan-smtp-01.noos.net [212.198.2.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BDB043F93 for ; Fri, 10 Oct 2003 05:42:13 -0700 (PDT) (envelope-from root@noos.fr) Received: (qmail 30232997 invoked by uid 0); 10 Oct 2003 11:34:42 -0000 Received: (qmail 29608619 invoked by uid 0); 9 Oct 2003 07:13:26 -0000 Received: from unknown (HELO mx2.freebsd.org) ([216.136.204.119]) (envelope-sender ) by 212.198.2.70 (qmail-ldap-1.03) with SMTP for ; 9 Oct 2003 07:13:26 -0000 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id B1D8156730; Wed, 8 Oct 2003 23:12:50 -0700 (PDT) (envelope-from owner-freebsd-current@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id A020D16A4FD; Wed, 8 Oct 2003 23:12:47 -0700 (PDT) Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D33B216A4BF for ; Wed, 8 Oct 2003 23:11:11 -0700 (PDT) Received: from smtp.mho.com (smtp.mho.net [64.58.4.6]) by mx1.FreeBSD.org (Postfix) with SMTP id B887F43FE1 for ; Wed, 8 Oct 2003 23:11:01 -0700 (PDT) (envelope-from scottl@freebsd.org) Received: (qmail 97102 invoked by uid 1002); 9 Oct 2003 06:10:59 -0000 Received: from unknown (HELO freebsd.org) (64.58.1.252) by smtp.mho.net with SMTP; 9 Oct 2003 06:10:59 -0000 Message-ID: <3F84FBF0.5010808@freebsd.org> Date: Thu, 09 Oct 2003 00:10:56 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org, current@freebsd.org, stable@freebsd.org Content-Type: text/plain; name="report-mar-2003-sep-2003.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="report-mar-2003-sep-2003.txt" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org Subject: Mar 2003 - Sep 2003 FreeBSD Status Report X-BeenThere: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 12:42:28 -0000 Navigation Bar March-September 2003 Status Report Introduction: The FreeBSD Bi-monthly status reports are back! In this edition, we catch up on seven highly productive months and look forward to the end of 2003. As always, the FreeBSD development crew has been hard at work. Support for the AMD64 platform quickly sprang up and is nearly complete. KSE has improved greatly since the 5.1 release and will soon become the default threading package in FreeBSD. Many other projects are in the works to improve performance, enhance the user experience, and expand FreeBSD into new areas. Take a look below at the impressive summary of work! Scott Long, Robert Watson * Bluetooth stack for FreeBSD (Netgraph implementation) * ACPI Status Report * AMD64 Porting * ATAPI/CAM Status Report * Binary security updates for FreeBSD * bsd.java.mk version 2.0 * Compile FreeBSD with Intels C compiler (icc) * Cryptographic Support * Device_t locking * Disk I/O * Dynamically Linked Root Support * FreeBSD Java Project * FreeBSD ports monitoring system * FreeBSD/ia64 * jpman project * KDE FreeBSD Project * kgi4BSD Status Report * KSE * Network Subsystem Locking and Performance * Porting OpenBSD's pf * PowerPC Port * Release Engineering Status * Rescue build infrastructure * uart(4) * VideoBSD * WifiBSD Status Report * Wireless Networking Support Bluetooth stack for FreeBSD (Netgraph implementation) URL: http://www.geocities.com/m_evmenkin/ URL: http://bluez.sf.net URL: http://sourceforge.net/projects/openobex/ Contact: Maksim Yevmenkin I'm very pleased to announce that another release is available for download at http://www.geocities.com/m_evmenkin/ngbt-fbsd-20030908.tar.gz. I have also prepared patch for the FreeBSD source tree. The patch was submitted for review to the committers. Fixed few bugs in kernel modules. The ng_hci(4) and ng_l2cap(4) modules were changed to fix issue with Netgraph timeouts. The ng_ubt(4) module was changed to fix compilation issue on -current. Improved user-space utilities. Implemented new libsdp(3). Added new sdpcontrol(8) utility. The rfcomm_sppd(1), rfcomm_pppd(8) and obexapp(1) were changed and now can obtain RFCOMM channel via SDP from the server. The hccontorol(8) utility now has four new commands. The hcsecd(8) daemon now saves link keys on the disk. I've been recently contacted by few individuals who whould like to port current FreeBSD Bluetooth code to other BSD systems (OpenBSD and NetBSD). The work is slowly progressing towards un-Netgraph'ing current code. In the mean time Netgraph version will be the primary supported version of the code. _________________________________________________________________ ACPI Status Report URL: http://www.root.org/~nate/freebsd/ Contact: Nate Lawson Work is continuing on updating ACPI with new features as well as bugfixing. A new embedded controller driver was written in July with support for the ACPI 2.0 ECDT as well as more robust polling support. Also, a buffer overflow in the ACPICA resource list handling that caused panics for some users was fixed. Marcel helped get acpidump(8) tested and basically working on ia64. Upcoming work includes integrating ACPI notifies with devd(8), committing user-submitted drivers for ASUS and Toshiba hotkeys, Cx processor sleep states (so my laptop doesn't burn my lap), and power resource support for intelligently powering down unused or idle devices. Users who have problems with ACPI are encouraged to submit a PR and email its number to acpi-jp@jp.freebsd.org. Bug reports of panics or crashes have first priority and non-working features or missing devices (except suspend/resume problems) second. Reports of failed suspend/resume should NOT be submitted as PRs at this time due to most of them being a result of incomplete device support that is being addressed. However, feel free to mail them to the list as any information is helpful. _________________________________________________________________ AMD64 Porting Contact: Peter Wemm The last known bug that prevented AMD64 machines completing a full release has been fixed - one single character error that caused ghostscript to crash during rendering diagrams. SMP work is nearing completion and should be committed within the next few days. The SMP code uses the ACPI MADT table based on John Baldwin's work-in-progress there for i386. We need to spend some time on low level optimization because there are several suboptimal places that have been ignored for simplicity, context switching in particular. MTRR support has been committed and XFree86 can use it. cvsup now works but the ezm3 port has not been updated yet. The default data segment size limit is 8GB instead of 512M, and the (primitive) i386 binary emulation support knows how to lower the rlimits for executing 32 bit binaries. Notable things missing still: Hardware debug register support needs to be written; gdb is still being done as an external set of patches relative to the not-yet-released FSF gdb tree; DDB does not disassemble properly; DDB cannot do stack traces without -fno-omit-frame-pointer - a stack unwinder is needed; i386 and amd64 linux binary emulation is needed, and the i386 FreeBSD binary emulation still needs work - removing the stackgap code in particular. The platform in general is very reliable although a couple of problems have been reported over the last week. One appears to be a stuck interrupt, but all that code has been redone for SMP support. _________________________________________________________________ ATAPI/CAM Status Report Contact: Thomas Quinot With the introduction of ATAng, some users of ATAPI/CAM have experienced various problems. These have been mostly tracked down to issues in the new ATA code, as well as two long-standing problems in portions of the CAM layer that are rarely exercised with "real" SCSI SIMs. This has also been an occasion to cleanup ATAPI/CAM to make it more robust, and to enable DMA for devices accessed through it, resulting in improved performances. _________________________________________________________________ Binary security updates for FreeBSD URL: http://www.daemonology.net/freebsd-update/ Contact: Colin Percival FreeBSD Update is a system for tracking the FreeBSD release (security) branches. In addition to being faster and more convenient than source updates, FreeBSD Update also requires less bandwidth and is more secure than source updates via CVSup. However, FreeBSD Update is limited; it can only update files which were installed from an official RELEASE image and not recompiled locally. Right now I'm publishing binary updates for 4.7-RELEASE and 4.8-RELEASE; since my only available box takes 3.5 hours to buildworld, I don't have enough resources to do any more than that. In the near future, I'd like to: Find someone who is willing to donate a faster buildbox; start building updates for other releases (at a minimum, for all "supported" FreeBSD releases); add warnings if a file would have been updated but can't be updated because it was recompiled locally; add code to compare the local system against a list of "valid" MD5 hashes for intrusion detection purposes; and add support for cross-signing, whereby several machines could build updates independently to protect against buildbox compromise. _________________________________________________________________ bsd.java.mk version 2.0 URL: http://www.esil.univ-mrs.fr/~hquiroz/freebsd/bsd.java.mk-2.0.html Contact: Ernst De Haan Contact: Herve Quiroz The FreeBSD Java community has started an effort to improve the current framework for Java-based ports. The main objective is the automation of JDK/JRE build and run dependency checking. The original version was aimed to ease the life of porters. Although it has proved to be useful and reliable to a great extend, we are currently working on a new version. We intend to reach a high degree of flexibility to cope with the recent increase of available JDK/JRE flavors. Furthermore, the new version will be easier to maintain, which means improved reliability, and hopefully more frequent updates. _________________________________________________________________ Compile FreeBSD with Intels C compiler (icc) URL: http://www.Leidinger.net/FreeBSD/ Contact: Alexander Leidinger Since I ported icc to FreeBSD I wanted to build FreeBSD with icc. Now with icc 7.1 (and some patches) it is possible. There are still some bugs, e.g. NFS doesn't work with an icc compiled kernel, IP seems to be fragile, and some advanced optimizations trigger an ICE (Intel is working on it). At the moment I'm waiting for our admins to install icc on the FreeBSD cluster (we got a commercial license from Intel, so we are allowed to distribute binaries which are compiled with icc), after that I will try to convince some people with more knowledge of the IP and NFS parts of the kernel to debug the remaining problems. When the icc compiled kernel seems to work mostly bugfree the userland will get the porting focus. Interested people may try to do a build of the ports tree with icc independently from the status of the porting of the userland... if this happens at the FreeBSD cluster, we would also be allowed to distribute the binaries. Benefits include: another set of compiler errors (debugging help), more portable source, and code which is better optimized for a P4 (gcc has some drawbacks in this area) _________________________________________________________________ Cryptographic Support Contact: Sam Leffler Support for several new crypto devices was added. The SafeNet 1141 is a medium performance part that is not yet available on retail products. The Hifn 7955 and 7956 parts are starting to appear on retail products that should be available by the end of the year. Both devices support AES encryption. Support for public key operations for the SafeNet devices was recently done for OpenBSD and will be backported. Public key support for the Hifn parts is planned. A paper about the performance work done on the cryptographic subsystem was presented at the Usenix BSDCon 2003 conference and received the best paper award. NetBSD recently imported the cryptographic subsystem. _________________________________________________________________ Device_t locking Contact: Warner Losh A number of races have been identified in locking device_t. Most of the races have been identified in making device_t have to do with how drivers are written. Efforts are underway to identify all the races, and to contact the authors of subsystems that can help the drivers. Of special concern is the need for the driver to ensure that all threads are completely out of the driver code before detach() finishes. Of additional concern is making sure that all sleepers are woken up before certain routines are called so that other subsystems can ensure the last condition and leave no dangling references. Locking device_t is relatively straight forward apart from these issues. Towards the end of proper locking, sample strawmen drivers are being used to work out what, exactly proper is. Once these issues are all known and documented in the code, efforts will be made to update relevant documentation in the tree. There are many problems with driver locking that has been done to date, but until we nail down how to write a driver in current, it will be premature to contact specific driver writers with specific concerns. _________________________________________________________________ Disk I/O Contact: Poul-Henning Kamp The following items are in progress in the Disk I/O area: Turn scsi_cd.c into a GEOM driver. (Patch out for review). Turn atapi-cd.c into a GEOM driver. Turn fd.c into a GEOM driver. Move softupdates and snapshot processing from SPECFS to UFS/FFS. Move userland access to device drivers out of vnodes. Once these preliminaries are dealt with, scatter/gather and mapped/unmapped support will be added to struct bio/GEOM. _________________________________________________________________ Dynamically Linked Root Support Contact: Gordon Tetlow Support for a dynamically linked /bin and /sbin has been committed, although it is not turned on by default. Adventurous users can try it out by building /bin and /sbin using the WITH_DYNAMICROOT make flag. More testing is needed to determine if this is going to be default for 5.2-RELEASE. If anyone would like to benchmark worldstones with and without dynamically linked /bin and /sbin, please feel free to do so and submit the results. _________________________________________________________________ FreeBSD Java Project URL: http://www.freebsd.org/java/ Contact: Greg Lewis The BSD Java Porting Team has recently reached an exciting milestone with the release of the first "Diablo" JDK and JRE courtesy of the FreeBSD Foundation. The release of Diablo Caffe and Diablo Latte 1.3.1 was the first binary release of a native FreeBSD JDK since 1.1.8 and marks an important step forward in FreeBSD Java support. The team is continuing development work, with a focus on achieving a compliant JDK 1.4 release in the near future. _________________________________________________________________ FreeBSD ports monitoring system URL: http://lonesome.dyndns.org:4802/bento/errorlogs/index.html Contact: Mark Linimon Several months ago, I took it upon myself to to try present the information contained on the bento build cluster to be presented in a more user-friendly fashion; that is, to be browsed by error type, by maintainer, and so forth. An early addition was code to attempt to classify ports PRs by either "existing port" (after assiging the most likely category and portname); "new port"; "framework" (e.g. bsd.port.mk changes); and "unknown". Various columns about the ports PRs were added to the reports. The initial intent of this was to make life easier for ports maintainers; however, the "general" reports are also useful to anyone who just wants to, e.g., find out if a particular port is working on their particular architecture and OS combination before downloading it. Those with that general interest should start with the overview of one port. _________________________________________________________________ FreeBSD/ia64 URL: http://www.FreeBSD.org/platforms/ia64/index.html Contact: Marcel Moolenaar Much has happened since the last bi-monthly report, which was more than half a year ago. FreeBSD 5.0 and FreeBSD 5.1 have been released for example. With FreeBSD 5.2 approaching quickly, we're not going to look back too far when it comes to our achievements. There's too much ahead of us... Two milestones have been reached after FreeBSD 5.1. The first is the ability to support both Intel and HP machines with sources in CVS. This due to a whole new driver for serial ports, or UARTs. Unfortunately this still implies that syscons is not configured. That's another task for another time, but keep an eye on KGI/FreeBSD... The second milestone is the completion of KSE support. Both M:N and 1:1 threading is functional on ia64 and the old libc_r library has been obsoleted. Testing has shown that KSE (i.e. M:N) may well become the default threading model. It's looking good. The ABI hasn't changed after 5.1 and the expectation is that it won't change much. This means that we can think about becoming a tier 1 platform. This also means we need gdb(1) support. Work on it has been started but the road is bumpy and long. Kernel stability also has improved significantly and we typically have one kernel panic remaining: VM fault on no fault entry. This will be addressed with the long awaited PMAP overhaul (see below). Most work for FreeBSD 5.2 will be "sharpening the saw". Get those loose ends tied. This is a slight change of plan made possible by a slip in the release schedule. The 5.2 release is not going to be the start of the -stable branch; it has been moved to 5.3. So, we use the extra time to prepare the ground for 5.3. The planned PMAP overhaul will probably be finished after 5.2. This should address all known issues with SMP and fix those last panics. As a side-effect, major performance improvements can be expected. More news about this in the next status reports. _________________________________________________________________ jpman project URL: http://www.jp.FreeBSD.org/man-jp/ URL: ftp://daemon.jp.FreeBSD.org/pub/FreeBSD-jp/man-jp/packages-5.1.0/ja-ma n-doc-5.1.tbz Contact: Kazuo Horikawa We have released Japanese translation of 5.1-RELEASE online manual pages on June 10. _________________________________________________________________ KDE FreeBSD Project URL: http://freebsd.kde.org/ Contact: KDE-FreeBSD Mailinglist The FreeBSD ports were updated to KDE 3.1.4, another bug- and security-fixes release. With this update, the QT port was updated to version 3.2. Both will be included in FreeBSD 4.9. Significant work was spent to fix KDE on FreeBSD-CURRENT after the removal of the gcc -pthread Option. Automatic package builds from KDE CVS continued to ensure and improve the quality of the upcoming KDE 3.2 release. Future: Work is in progress to setup a new server for hosting the KDE-FreeBSD Website, Repository and another KDE CVS mirror. With help from Marcel Moolenaar the project will try to make KDE compile and working on the Intel IA64. And last but not least efforts are being made to fix the currently broken kdesu program. _________________________________________________________________ kgi4BSD Status Report URL: http://www.FreeBSD.org/~nsouch/kgi4BSD Contact: Nicholas Souchu A lot of work done since last report: site reworked completly (see new URL), console design with console message in text or graphic modes implemented, implementation of a compatibility layer to compile Linux fbdev drivers with more or less changes in the original driver (experimental). Except some memory allocation bugs, X (XGGI based on XFree 3.3.6) is now working with the same driver as the console. A basic terminal has now to be implemented. Volonteers are welcome to the project... _________________________________________________________________ KSE URL: http://www.freebsd.org/kse/index.html Contact: Dan Eischen Contact: David Xu KSE seems to be working well on x86, amd64, and ia64. The alpha userland bits are done, but a couple of functions are unimplemented in the kernel. For sparc64, the necessary functions are implemented in the kernel, but the userland context switching functions need more attention. Since 5.1, efficient scope system threads (no upcalls when they block) have been implemented, and KSE based pthread library can have both POSIX scope process threads and scope system threads. It is also possible that KSE based pthread library can implement pthread both in 1:1 and M:N mode, I know Dan has such Makefile file patch for libkse not yet committed. KSE program now can work under ULE scheduler, its efficient should be improved under the new scheduler in future. BSD scheduler is still the best scheduler for current KSE implement. _________________________________________________________________ Network Subsystem Locking and Performance Contact: Sam Leffler The purpose of this project is to improve performance of the network subsystem. A major part of this work is to complete the locking of the networking subsystem so that it no longer depends on the "Giant lock" for proper operation. Removing the use of Giant will improve performance and permit multiple instances of the network stack to operate concurrently on multiprocessor systems. This project started in August. The emphasis has been on locking the "lower half" of the networking code so that packet forwarding through the IPv4 path can operate without the Giant lock as part of the 5.2 release. To this end locking was added to several network interface drivers and much of the "middleware" code in the network was locked (e.g. ipfw, dummynet, then routing table, multicast routing support, etc). Work towards this goal is still ongoing but should be ready for 5.2. A variety of test systems have been running for several months without the Giant lock in the network drivers and IP layer. Past the 5.2 release Giant will be removed from the "upper half" of the network subsystem and the socket layer. Once this is done the plan is to measure and improve performance (though some work of this sort is always happening). The ultimate goal is a system that performs at least as well as 4.x for normal use on uniprocessor systems. On multiprocessor systems we expect to see significantly better performance than 4.x due to greater concurrency and reduced latency. _________________________________________________________________ Porting OpenBSD's pf URL: http://pf4freebsd.love2party.net URL: http://www.benzedrine.cx/pf.html URL: http://openbsd.org/faq/pf/index.html Contact: Max Laier Contact: Pyun YongHyeon The project started this spring and released version 1.0 with a port installation (security/pf) in may 2003. Version 2.0 is on the doorstep as OpenBSD 3.4 will be released. Due to the porting efforts we were able to reveal some bugs in the OpenBSD code and provided locking for the PFIL_HOOKS, which we utilize. Tarball installation of a loadable kernel module for testing can be found on the project homepage, a patchset is in the making. PF was started at OpenBSD as a substitute for ipfilter and provides the same function set. However, in the two years it exists now, it has gained many superior features that no other packet filter has. For a impression take a look at the pf FAQ. We hope to be eventually integrated into the base system. Before that we have to resolve some issues with tcpdump and kame. _________________________________________________________________ PowerPC Port Contact: Peter Grehan Work has restarted after a hiatus. Current focus is on getting loadable modules working, NEWBUSing the NetBSD dbdma code, and completing the BMAC ethernet driver. There is a huge amount of work to do. Volunteers more than welcome! _________________________________________________________________ Release Engineering Status Contact: Scott Long The release of 4.9 is just around the corner and offers Physical Address Extensions (PAE) for x86 along with the same world-class stability and performance that is expected from the 4-STABLE series. As always, don't forget to purchase a copy of the CD set from your favorite FreeBSD vendor. FreeBSD 5.1 was released in June and offered vastly improved stability over 5.0 along with a working implementation of Kernel Scheduled Entities, allowing for true multithreading of applications across multiple CPUs. FreeBSD 5.2 will be released by the end of 2003 and will focus on improved network and overall performance. _________________________________________________________________ Rescue build infrastructure Contact: Gordon Tetlow Contact: Tim Kientzle The rescue build infrastructure has been committed. There is one known issue with make using both the '-s' and '-j' flags that appears to be a bug in make. Anyone interested in tracking down should contact us. _________________________________________________________________ uart(4) Contact: Marcel Moolenaar The uart(4) project was born out of the need to have a working serial interface (i.e. an RS-232-C interface) in a legacy-free configuration and after an unsuccessful attempt to convert sio(4). The biggest problem with sio(4) is that it has been intertwined in many ugly ways into the kernel's core. Conversion could not happen without breaking something that invariably affects some group of people negatively. With sio(4) as a good bad example and a strong desire to solve multiple problems at once, the idea of an UART (Universal Asynchronuous Receiver/Transmitter) device that, given its generic name, could handle different flavors of UART hardware started to settle firmly in the authors mind. The biggest challenge was of course solving the problem of the low-level console access prior to the initialization of the bus infrastructure and still have a driver that uses the bus access exclusively. Along the way the problem of having an UART function as the keyboard on sparc64 was solved with the introduction of system devices, which also encapsulated the console as a system device. The uart(4) driver can be enhanced to support the various UART hardware on pc98 and this is currently being worked on. Keyboard support on sparc64 is underway as well. Plans exist for a rewrite of the remote gdb support that uses a generic interface to allow various drivers, including uart(4), to register itself as a communications channel. And since uart(4) does not support multi- port cards by itself, we likely need to either enhance puc(4) or otherwise introduce other umbrella drivers _________________________________________________________________ VideoBSD URL: http://people.FreeBSD.org/~jmg/videobsd.html Contact: John-Mark Gurney Still in the planning stage. Working on creating an extensible interface that is usable for both userland and kernel implementations for device drivers. Deciding on how to interface userland implemented device drivers with applications. _________________________________________________________________ WifiBSD Status Report URL: http://www.wifibsd.org Contact: Jon Disnard WifiBSD is a miniture version of FreeBSD for wireless applications. Originally for the Soekris Net45xx line of main-boards, but is now capable of being targeted to any hardware/architecture FreeBSD itself supports. Although not feature complete, WifiBSD is expected to be ready for 5.2-RELEASE. The design goal is to meet, or exceed, the functionality of commercial/consumer 802.11 wireless gear. Features that need attention (to name just a few) are: http interface, consol menu interface, and installation. Volunters are welcome. _________________________________________________________________ Wireless Networking Support Contact: Sam Leffler Numerous bugs have been fixed since the last status report (and of course a few new ones added). Progress on improved security has been slowed by other work. But new features and fixes are coming in from other groups that are now sharing the code. In particular NetBSD recently imported the revised 802.11 layer and the Linux-based MADWIFI project is using it too (albeit in an older form). The MADWIFI users have already contributed features such as fragmentation reassembly of 802.11 frames and improved signal monitoring. Power save polling and an improved rate control algorothm are expected to come in from the NetBSD folks. WPA support is still in the plans; the best estimate is that work on that will start in January. _________________________________________________________________ News Home | Status Reports Home _________________________________________________________________ freebsd-questions@FreeBSD.org Copyright © 1995-2003 the FreeBSD Project. All rights reserved. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 06:44:08 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4028A16A4B3; Fri, 10 Oct 2003 06:44:08 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC33043FDD; Fri, 10 Oct 2003 06:44:03 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 3814B654F9; Fri, 10 Oct 2003 14:44:02 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 77681-01-3; Fri, 10 Oct 2003 14:44:01 +0100 (BST) Received: from saboteur.dek.spc.org (unknown [81.3.72.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 8B57C654F7; Fri, 10 Oct 2003 14:44:01 +0100 (BST) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id BB2295; Fri, 10 Oct 2003 14:44:00 +0100 (BST) Date: Fri, 10 Oct 2003 14:44:00 +0100 From: Bruce M Simpson To: Joseph Koshy Message-ID: <20031010134400.GE803@saboteur.dek.spc.org> Mail-Followup-To: Joseph Koshy , freebsd-hackers@freebsd.org References: <20031010103640.6F5A216A4BF@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20031010103640.6F5A216A4BF@hub.freebsd.org> cc: freebsd-hackers@freebsd.org Subject: Re: Determining CPU features / cache organization from userland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 13:44:08 -0000 On Fri, Oct 10, 2003 at 03:36:40AM -0700, Joseph Koshy wrote: > I'm looking for ways that a userland program can determine the CPU > features available on an SMP machine -- processor model, stepping > numbers, supported features, cache organization etc. "What Silby said" and have a look at the sysutils/x86info port. I've been thinking we should definitely make the cache organization info available via sysctl. I am thinking we should do this to make the UMA_ALIGN_CACHE definition mean something... I will probably throw diffs Jeff's way soon for this but I'm recovering =66rom a bit of a nasty cold right now. BMS From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 07:13:06 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1077F16A4B3 for ; Fri, 10 Oct 2003 07:13:06 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC19D43F75 for ; Fri, 10 Oct 2003 07:13:03 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9p2/8.12.9) with ESMTP id h9AECxE7008092 for ; Fri, 10 Oct 2003 08:12:59 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 10 Oct 2003 08:12:28 -0600 (MDT) Message-Id: <20031010.081228.77323310.imp@bsdimp.com> To: hackers@freebsd.org From: "M. Warner Losh" X-Mailer: Mew version 2.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Panic X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 14:13:06 -0000 I have a dual system, and got this panic last night during installworld. Has anybody else seen this? Or have ideas on tracking it down. Looks like a race in vm somehow. Warner Fatal trap 12: page fault while in kernel mode cpuid = 0; lapic.id = 01000000 fault virtual address = 0xbfca03cc fault code = supervisor read, page not present instruction pointer = 0x8:0xc07c11e8 stack pointer = 0x10:0xe9234b0c frame pointer = 0x10:0xe9234b40 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 21802 (sh) kernel: type 12 trap, code=0 Stopped at pmap_enter+0x98: movl 0(%edx),%esi db> trace pmap_enter(c82053a4,280f3000,c27fe088,5,0) at pmap_enter+0x98 vm_fault(c82052f4,280f3000,1,0,c78d4e40) at vm_fault+0x16b2 trap_pfault(e9234d48,1,280f3038,e9234d34,280f3038) at trap_pfault+0x155 trap(2f,2f,2f,0,810c000) at trap+0x1fc calltrap() at calltrap+0x5 --- trap 0xc, eip = 0x80b0fdc, esp = 0xbfbfe6a0, ebp = 0xbfbfe6b8 --- db> panic panic: from debugger cpuid = 0; lapic.id = 01000000 Debugger("panic") Fatal trap 3: breakpoint instruction fault while in kernel mode cpuid = 0; lapic.id = 01000000 (ooops, no core dump) From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 07:17:47 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F22A16A4BF for ; Fri, 10 Oct 2003 07:17:47 -0700 (PDT) Received: from www.kukulies.org (www.kukulies.org [213.146.112.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id E129F43FAF for ; Fri, 10 Oct 2003 07:17:45 -0700 (PDT) (envelope-from kuku@www.kukulies.org) Received: from www.kukulies.org (localhost [127.0.0.1]) by www.kukulies.org (8.12.10/8.12.6) with ESMTP id h9AEHhgv025077 for ; Fri, 10 Oct 2003 16:17:43 +0200 (CEST) (envelope-from kuku@www.kukulies.org) Received: (from kuku@localhost) by www.kukulies.org (8.12.10/8.12.6/Submit) id h9AEHb4n025071 for hackers@freebsd.org; Fri, 10 Oct 2003 16:17:37 +0200 (CEST) Date: Fri, 10 Oct 2003 16:17:37 +0200 (CEST) From: "C. Kukulies" Message-Id: <200310101417.h9AEHb4n025071@www.kukulies.org> To: hackers@freebsd.org Subject: smallest piece of hardware that runs *BSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 14:17:47 -0000 1990: In ten years, computers will just be bumps in cables. (Gordon Bell) Remember that quote? Now, we are not far from that. I'm thinking of some CPU with TP Ethernet and memory of size of an USB stick. Anyone knowing such or having experience? -- Christoph P. U. Kukulies kuku (at) physik.rwth-aachen.de From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 09:14:12 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85E6716A4B3 for ; Fri, 10 Oct 2003 09:14:12 -0700 (PDT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2FF143FBF for ; Fri, 10 Oct 2003 09:14:10 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.9/8.12.9) id h9AGE9C6038662; Fri, 10 Oct 2003 11:14:09 -0500 (CDT) (envelope-from dan) Date: Fri, 10 Oct 2003 11:14:09 -0500 From: Dan Nelson To: "C. Kukulies" Message-ID: <20031010161409.GA77306@dan.emsphone.com> References: <200310101417.h9AEHb4n025071@www.kukulies.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310101417.h9AEHb4n025071@www.kukulies.org> X-OS: FreeBSD 5.1-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.4i cc: hackers@freebsd.org Subject: Re: smallest piece of hardware that runs *BSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 16:14:12 -0000 In the last episode (Oct 10), C. Kukulies said: > 1990: In ten years, computers will just be bumps in cables. (Gordon Bell) > > Remember that quote? > > Now, we are not far from that. I'm thinking of some CPU with TP Ethernet > and memory of size of an USB stick. Anyone knowing such or having > experience? Lantronix's XPort product is definitely in your size range (embedded management device built into an rj45 jack), but I don't believe you can put just any OS on it, though. It runs on a custom 16-bit 80186 CPU. http://www.lantronix.com/products/eds/xport/index.html -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 09:26:15 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D04816A4B3 for ; Fri, 10 Oct 2003 09:26:15 -0700 (PDT) Received: from mail.numachi.com (meisai.numachi.com [198.175.254.6]) by mx1.FreeBSD.org (Postfix) with SMTP id B683543F93 for ; Fri, 10 Oct 2003 09:26:13 -0700 (PDT) (envelope-from reichert@numachi.com) Received: (qmail 79217 invoked from network); 10 Oct 2003 16:26:13 -0000 Received: from natto.numachi.com (198.175.254.216) by meisai.numachi.com with SMTP; 10 Oct 2003 16:26:13 -0000 Received: (qmail 74457 invoked by uid 1001); 10 Oct 2003 16:26:13 -0000 Date: Fri, 10 Oct 2003 12:26:13 -0400 From: Brian Reichert To: Joseph Koshy , freebsd-hackers@freebsd.org Message-ID: <20031010162613.GP56167@numachi.com> References: <20031010103640.6F5A216A4BF@hub.freebsd.org> <20031010134400.GE803@saboteur.dek.spc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031010134400.GE803@saboteur.dek.spc.org> User-Agent: Mutt/1.4i Subject: Re: Determining CPU features / cache organization from userland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 16:26:15 -0000 On Fri, Oct 10, 2003 at 02:44:00PM +0100, Bruce M Simpson wrote: > On Fri, Oct 10, 2003 at 03:36:40AM -0700, Joseph Koshy wrote: > > I'm looking for ways that a userland program can determine the CPU > > features available on an SMP machine -- processor model, stepping > > numbers, supported features, cache organization etc. > > "What Silby said" and have a look at the sysutils/x86info port. Hey, cool, I'd never heard about this. Just tried this, and got some wierdness. Can I ask about it here, or do I poke at the port maintainer? > I've been thinking we should definitely make the cache organization > info available via sysctl. I am thinking we should do this to make > the UMA_ALIGN_CACHE definition mean something... > > I will probably throw diffs Jeff's way soon for this but I'm recovering > from a bit of a nasty cold right now. > > BMS > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Brian 'you Bastard' Reichert 37 Crystal Ave. #303 Daytime number: (603) 434-6842 Derry NH 03038-1713 USA BSD admin/developer at large From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 11:14:00 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD76E16A4C0 for ; Fri, 10 Oct 2003 11:14:00 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id E670243FCB for ; Fri, 10 Oct 2003 11:13:57 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) h9AIDqt2021280 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Fri, 10 Oct 2003 20:13:55 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id h9AIDoS8044727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Oct 2003 20:13:51 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.10/8.12.10) with ESMTP id h9AIDo2u044070 for ; Fri, 10 Oct 2003 20:13:50 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.10/8.12.10/Submit) id h9AIDoJH044069 for freebsd-hackers@freebsd.org; Fri, 10 Oct 2003 20:13:50 +0200 (CEST) (envelope-from ticso) Date: Fri, 10 Oct 2003 20:13:49 +0200 From: Bernd Walter To: freebsd-hackers@freebsd.org Message-ID: <20031010181349.GG13791@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD cicely12.cicely.de 5.1-CURRENT alpha User-Agent: Mutt/1.5.4i Subject: setting sio to even parity failed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 18:14:00 -0000 void opensio(char* devname) { struct termios buf; int val; fd = open(devname, O_RDWR); if (fd < 0) { printf("open serial %s failed: %s\n", devname, strerror(errno)); exit(1); } val = fcntl(fd, F_GETFL, 0); fcntl(fd, F_SETFL, val | O_NONBLOCK); if (tcgetattr(fd, &buf) < 0) { printf("tcgetattr failed: %s\n", strerror(errno)); exit (1); } cfmakeraw(&buf); buf.c_iflag |= IGNBRK; buf.c_cflag &= ~(CSIZE | PARODD); buf.c_cflag |= CS8 | CLOCAL | PARENB; if (tcsetattr(fd, TCSAFLUSH, &buf) < 0) { printf("tcsetattr failed: %s\n", strerror(errno)); exit (1); } } If I do PARENB or not doesn't change anything in the output pattern. However it does change handling in receiving characters. The OS is a real old -current from 8th Feb 2003. Unfortunately it's a RS485 application and I can't easily test the situation on a system with a more recent version and I can't easily update the given system. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 11:26:41 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4794416A4B3 for ; Fri, 10 Oct 2003 11:26:41 -0700 (PDT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 639EC43F75 for ; Fri, 10 Oct 2003 11:26:38 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.9/8.12.9) id h9AIQXot065019; Fri, 10 Oct 2003 13:26:33 -0500 (CDT) (envelope-from dan) Date: Fri, 10 Oct 2003 13:26:33 -0500 From: Dan Nelson To: ticso@cicely.de Message-ID: <20031010182633.GD77306@dan.emsphone.com> References: <20031010181349.GG13791@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031010181349.GG13791@cicely12.cicely.de> X-OS: FreeBSD 5.1-CURRENT X-message-flag: Outlook Error User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org Subject: Re: setting sio to even parity failed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 18:26:41 -0000 In the last episode (Oct 10), Bernd Walter said: > buf.c_iflag |= IGNBRK; > buf.c_cflag &= ~(CSIZE | PARODD); > buf.c_cflag |= CS8 | CLOCAL | PARENB; Do you maybe want CS7 here? -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 11:34:00 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D18A216A4B3 for ; Fri, 10 Oct 2003 11:34:00 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6741743FE1 for ; Fri, 10 Oct 2003 11:33:58 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) h9AIXnt2021596 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 10 Oct 2003 20:33:51 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id h9AIXlS8044833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Oct 2003 20:33:48 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.10/8.12.10) with ESMTP id h9AIXl2u044149; Fri, 10 Oct 2003 20:33:47 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.10/8.12.10/Submit) id h9AIXkpk044148; Fri, 10 Oct 2003 20:33:46 +0200 (CEST) (envelope-from ticso) Date: Fri, 10 Oct 2003 20:33:46 +0200 From: Bernd Walter To: Dan Nelson Message-ID: <20031010183346.GH13791@cicely12.cicely.de> References: <20031010181349.GG13791@cicely12.cicely.de> <20031010182633.GD77306@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031010182633.GD77306@dan.emsphone.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-CURRENT alpha User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org cc: ticso@cicely.de Subject: Re: setting sio to even parity failed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 18:34:00 -0000 On Fri, Oct 10, 2003 at 01:26:33PM -0500, Dan Nelson wrote: > In the last episode (Oct 10), Bernd Walter said: > > buf.c_iflag |= IGNBRK; > > buf.c_cflag &= ~(CSIZE | PARODD); > > buf.c_cflag |= CS8 | CLOCAL | PARENB; > > Do you maybe want CS7 here? No I need 8e1, but the output still looks like 8n1. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 12:09:55 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72CBE16A4B3 for ; Fri, 10 Oct 2003 12:09:55 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89F1F43FDF for ; Fri, 10 Oct 2003 12:09:54 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.10/8.12.10) with ESMTP id h9AJ9rn6027352 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 10 Oct 2003 15:09:53 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h9AJ9lB24121; Fri, 10 Oct 2003 15:09:47 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16263.1019.939450.708832@grasshopper.cs.duke.edu> Date: Fri, 10 Oct 2003 15:09:47 -0400 (EDT) To: Bruce M Simpson In-Reply-To: <20031010134400.GE803@saboteur.dek.spc.org> References: <20031010103640.6F5A216A4BF@hub.freebsd.org> <20031010134400.GE803@saboteur.dek.spc.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-hackers@freebsd.org Subject: Re: Determining CPU features / cache organization from userland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 19:09:55 -0000 Bruce M Simpson writes: > I've been thinking we should definitely make the cache organization > info available via sysctl. I am thinking we should do this to make > the UMA_ALIGN_CACHE definition mean something... If you do this, it may make sense to use the same names as MacOSX. Eg: g51% sysctl hw | grep cache hw.cachelinesize: 128 hw.l1icachesize: 65536 hw.l1dcachesize: 32768 hw.l2cachesize: 524288 Drew From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 12:23:23 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF41A16A4C0 for ; Fri, 10 Oct 2003 12:23:23 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58BE043FFB for ; Fri, 10 Oct 2003 12:23:07 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id AC06B654B2; Fri, 10 Oct 2003 20:23:05 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 81531-03; Fri, 10 Oct 2003 20:23:05 +0100 (BST) Received: from saboteur.dek.spc.org (unknown [81.3.72.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id EE50D65439; Fri, 10 Oct 2003 20:23:04 +0100 (BST) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 915D814; Fri, 10 Oct 2003 20:23:03 +0100 (BST) Date: Fri, 10 Oct 2003 20:23:03 +0100 From: Bruce M Simpson To: Andrew Gallatin Message-ID: <20031010192303.GC2325@saboteur.dek.spc.org> Mail-Followup-To: Andrew Gallatin , freebsd-hackers@freebsd.org References: <20031010103640.6F5A216A4BF@hub.freebsd.org> <20031010134400.GE803@saboteur.dek.spc.org> <16263.1019.939450.708832@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16263.1019.939450.708832@grasshopper.cs.duke.edu> cc: freebsd-hackers@freebsd.org Subject: Re: Determining CPU features / cache organization from userland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 19:23:23 -0000 On Fri, Oct 10, 2003 at 03:09:47PM -0400, Andrew Gallatin wrote: > Bruce M Simpson writes: > > I've been thinking we should definitely make the cache organization > > info available via sysctl. I am thinking we should do this to make > > the UMA_ALIGN_CACHE definition mean something... > > If you do this, it may make sense to use the same names as MacOSX. > > Eg: > > g51% sysctl hw | grep cache > hw.cachelinesize: 128 > hw.l1icachesize: 65536 > hw.l1dcachesize: 32768 > hw.l2cachesize: 524288 Er, that's weird, considering POWER has the CLCS instruction which is intended to support variable cache line sizes. Doesn't POWER4 and POWER5 have a cache which is split in this way? Also can we assume they are the same for all CPUs in an SMP system? I'd like to think that that is the case. BMS From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 14:08:22 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 951A516A4BF for ; Fri, 10 Oct 2003 14:08:22 -0700 (PDT) Received: from merlot.juniper.net (natint2.juniper.net [207.17.136.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03AE043FBD for ; Fri, 10 Oct 2003 14:08:22 -0700 (PDT) (envelope-from skumar@juniper.net) Received: from juniper.net (skumar-bsd.juniper.net [172.17.12.161]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h9AL8Lj95724 for ; Fri, 10 Oct 2003 14:08:21 -0700 (PDT) (envelope-from skumar@juniper.net) Message-ID: <3F871FC5.5060900@juniper.net> Date: Fri, 10 Oct 2003 14:08:21 -0700 From: Sandeep Kumar User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2.1) Gecko/20030317 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Archive for cvs-src X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 21:08:22 -0000 Hi, The oldest message in http://lists.freebsd.org/pipermail/cvs-src.mbox/cvs-src.mbox seems to be from 2003/03/24. Is there a way to get messages prior to that? Thanks, Sandeep From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 14:25:37 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48FAF16A4B3 for ; Fri, 10 Oct 2003 14:25:37 -0700 (PDT) Received: from falcon.midgard.homeip.net (h76n3fls24o1048.bredband.comhem.se [213.67.148.76]) by mx1.FreeBSD.org (Postfix) with SMTP id CCE7E43FBD for ; Fri, 10 Oct 2003 14:25:32 -0700 (PDT) (envelope-from ertr1013@student.uu.se) Received: (qmail 26651 invoked by uid 1001); 10 Oct 2003 21:25:29 -0000 Date: Fri, 10 Oct 2003 23:25:29 +0200 From: Erik Trulsson To: Sandeep Kumar Message-ID: <20031010212529.GA25322@falcon.midgard.homeip.net> Mail-Followup-To: Sandeep Kumar , freebsd-hackers@freebsd.org References: <3F871FC5.5060900@juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F871FC5.5060900@juniper.net> User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org Subject: Re: Archive for cvs-src X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 21:25:37 -0000 On Fri, Oct 10, 2003 at 02:08:21PM -0700, Sandeep Kumar wrote: > Hi, > > The oldest message in > http://lists.freebsd.org/pipermail/cvs-src.mbox/cvs-src.mbox seems to be > from 2003/03/24. > Is there a way to get messages prior to that? And what makes you think there are any prior messages? If I remember correctly it was about that time that cvs-src, cvs-ports, cvs-doc, etc. were created. Previously all commit-messages were sent to cvs-all only, so you will have to search that list for older messages. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 14:26:43 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEC5B16A4D8 for ; Fri, 10 Oct 2003 14:26:43 -0700 (PDT) Received: from arthur.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 941C843F3F for ; Fri, 10 Oct 2003 14:26:42 -0700 (PDT) (envelope-from simon@arthur.nitro.dk) Received: by arthur.nitro.dk (Postfix, from userid 1000) id 0DE6610BFAA; Fri, 10 Oct 2003 23:26:41 +0200 (CEST) Date: Fri, 10 Oct 2003 23:26:40 +0200 From: "Simon L. Nielsen" To: Sandeep Kumar Message-ID: <20031010212638.GA388@FreeBSD.org> References: <3F871FC5.5060900@juniper.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n8g4imXOkfNTN/H1" Content-Disposition: inline In-Reply-To: <3F871FC5.5060900@juniper.net> User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org Subject: Re: Archive for cvs-src X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 21:26:44 -0000 --n8g4imXOkfNTN/H1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2003.10.10 14:08:21 -0700, Sandeep Kumar wrote: > Hi, >=20 > The oldest message in=20 > http://lists.freebsd.org/pipermail/cvs-src.mbox/cvs-src.mbox seems to be= =20 > from 2003/03/24. > Is there a way to get messages prior to that? Older messages for all the mailing lists are at http://docs.freebsd.org/mail/ . The source commit logs can also be found in CVSROOT-src/commitlogs in the CVS repository. --=20 Simon L. Nielsen FreeBSD Documentation Team --n8g4imXOkfNTN/H1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/hyQOh9pcDSc1mlERApu0AKC8Z4UQ3p9MfBy2NXRW5mOVLJ9q+wCeI+N/ Z2buh/Y1vpcUuxJo71ATtBs= =L4CP -----END PGP SIGNATURE----- --n8g4imXOkfNTN/H1-- From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 15:13:18 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79AB816A4B3 for ; Fri, 10 Oct 2003 15:13:18 -0700 (PDT) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73DC443FDD for ; Fri, 10 Oct 2003 15:13:16 -0700 (PDT) (envelope-from des@des.no) Received: from smtp.des.no (37.80-203-228.nextgentel.com [80.203.228.37]) by mail.broadpark.no (Postfix) with ESMTP id 6E8A578FB0; Sat, 11 Oct 2003 00:13:15 +0200 (MEST) Received: by smtp.des.no (Pony Express, from userid 666) id 3B50B9C2A9; Sat, 11 Oct 2003 00:13:15 +0200 (CEST) Received: from dwp.des.no (dwp.des.no [10.0.0.4]) by smtp.des.no (Pony Express) with ESMTP id 2A1C19BCD9; Sat, 11 Oct 2003 00:13:11 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id CBB73B823; Sat, 11 Oct 2003 00:13:10 +0200 (CEST) To: Sandeep Kumar References: <3F871FC5.5060900@juniper.net> <20031010212529.GA25322@falcon.midgard.homeip.net> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Sat, 11 Oct 2003 00:13:10 +0200 In-Reply-To: <20031010212529.GA25322@falcon.midgard.homeip.net> (Erik Trulsson's message of "Fri, 10 Oct 2003 23:25:29 +0200") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on dsa.des.no X-Spam-Level: s X-Spam-Status: No, hits=1.1 required=5.0 tests=MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 cc: freebsd-hackers@freebsd.org Subject: Re: Archive for cvs-src X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 22:13:18 -0000 Erik Trulsson writes: > On Fri, Oct 10, 2003 at 02:08:21PM -0700, Sandeep Kumar wrote: >> The oldest message in=20 >> http://lists.freebsd.org/pipermail/cvs-src.mbox/cvs-src.mbox seems to be= =20 >> from 2003/03/24. >> Is there a way to get messages prior to that? > > And what makes you think there are any prior messages? > If I remember correctly it was about that time that cvs-src, cvs-ports, > cvs-doc, etc. were created. Previously all commit-messages were sent to > cvs-all only, so you will have to search that list for older messages. Wrong. These lists have existed for years. The reason why older messages aren't in pipermail is that 2003/03/24 is when we switched from majordomo to mailman. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 15:20:38 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B34B216A4B3 for ; Fri, 10 Oct 2003 15:20:38 -0700 (PDT) Received: from falcon.midgard.homeip.net (h76n3fls24o1048.bredband.comhem.se [213.67.148.76]) by mx1.FreeBSD.org (Postfix) with SMTP id 5209B43FDD for ; Fri, 10 Oct 2003 15:20:35 -0700 (PDT) (envelope-from ertr1013@student.uu.se) Received: (qmail 37510 invoked by uid 1001); 10 Oct 2003 22:20:33 -0000 Date: Sat, 11 Oct 2003 00:20:33 +0200 From: Erik Trulsson To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20031010222033.GA36420@falcon.midgard.homeip.net> Mail-Followup-To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , Sandeep Kumar , freebsd-hackers@freebsd.org References: <3F871FC5.5060900@juniper.net> <20031010212529.GA25322@falcon.midgard.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org cc: Sandeep Kumar Subject: Re: Archive for cvs-src X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 22:20:38 -0000 On Sat, Oct 11, 2003 at 12:13:10AM +0200, Dag-Erling Sm=F8rgrav wrote: > Erik Trulsson writes: > > On Fri, Oct 10, 2003 at 02:08:21PM -0700, Sandeep Kumar wrote: > >> The oldest message in=20 > >> http://lists.freebsd.org/pipermail/cvs-src.mbox/cvs-src.mbox seems to = be=20 > >> from 2003/03/24. > >> Is there a way to get messages prior to that? > > > > And what makes you think there are any prior messages? > > If I remember correctly it was about that time that cvs-src, cvs-ports, > > cvs-doc, etc. were created. Previously all commit-messages were sent to > > cvs-all only, so you will have to search that list for older messages. >=20 > Wrong. These lists have existed for years. Are you sure? Well, then I am probably confusing it with the split of CVSROOT in the repository. >=20 > The reason why older messages aren't in pipermail is that 2003/03/24 > is when we switched from majordomo to mailman. --=20 Erik Trulsson ertr1013@student.uu.se From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 15:43:37 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3B9916A4B3 for ; Fri, 10 Oct 2003 15:43:36 -0700 (PDT) Received: from merlot.juniper.net (natint2.juniper.net [207.17.136.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F99843F85 for ; Fri, 10 Oct 2003 15:43:36 -0700 (PDT) (envelope-from skumar@juniper.net) Received: from juniper.net (skumar-bsd.juniper.net [172.17.12.161]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h9AMhUj14886; Fri, 10 Oct 2003 15:43:30 -0700 (PDT) (envelope-from skumar@juniper.net) Message-ID: <3F873612.5000704@juniper.net> Date: Fri, 10 Oct 2003 15:43:30 -0700 From: Sandeep Kumar User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2.1) Gecko/20030317 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Trulsson References: <3F871FC5.5060900@juniper.net> <20031010212529.GA25322@falcon.midgard.homeip.net> <20031010222033.GA36420@falcon.midgard.homeip.net> In-Reply-To: <20031010222033.GA36420@falcon.midgard.homeip.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= cc: freebsd-hackers@freebsd.org Subject: Re: Archive for cvs-src X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 22:43:37 -0000 Erik Trulsson wrote: Thanks everybody for your replies. >On Sat, Oct 11, 2003 at 12:13:10AM +0200, Dag-Erling Smørgrav wrote: > > >>Erik Trulsson writes: >> >> >>>On Fri, Oct 10, 2003 at 02:08:21PM -0700, Sandeep Kumar wrote: >>> >>> >>>>The oldest message in >>>>http://lists.freebsd.org/pipermail/cvs-src.mbox/cvs-src.mbox seems to be >>>>from 2003/03/24. >>>> Is there a way to get messages prior to that? >>>> >>>> >>>And what makes you think there are any prior messages? >>>If I remember correctly it was about that time that cvs-src, cvs-ports, >>>cvs-doc, etc. were created. Previously all commit-messages were sent to >>>cvs-all only, so you will have to search that list for older messages. >>> >>> >>Wrong. These lists have existed for years. >> Actually not. Although majordomo lists contain cvs-all, I didn't find other cvs-* over there http://docs.freebsd.org/mail/archive/2002/ >Are you sure? Well, then I am probably confusing it with the split of >CVSROOT in the repository. > > >>The reason why older messages aren't in pipermail is that 2003/03/24 >>is when we switched from majordomo to mailman. >> Yes, http://www.freebsd.org/search/search.html clearly states the following: An alternative way to read the mailing lists archives is to use the Mailman/Pipermail list archive (note that this archive only carries messages from March 2003 onward). From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 16:08:30 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4DA7516A4B3 for ; Fri, 10 Oct 2003 16:08:30 -0700 (PDT) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76A8E43F93 for ; Fri, 10 Oct 2003 16:08:28 -0700 (PDT) (envelope-from des@des.no) Received: from smtp.des.no (37.80-203-228.nextgentel.com [80.203.228.37]) by mail.broadpark.no (Postfix) with ESMTP id 0E7AF788B1; Sat, 11 Oct 2003 01:08:27 +0200 (MEST) Received: by smtp.des.no (Pony Express, from userid 666) id BB7419C2D5; Sat, 11 Oct 2003 01:08:26 +0200 (CEST) Received: from dwp.des.no (dwp.des.no [10.0.0.4]) by smtp.des.no (Pony Express) with ESMTP id A5C5A9C2BF; Sat, 11 Oct 2003 01:08:21 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 86F06B823; Sat, 11 Oct 2003 01:08:21 +0200 (CEST) To: Sandeep Kumar References: <3F871FC5.5060900@juniper.net> <20031010212529.GA25322@falcon.midgard.homeip.net> <20031010222033.GA36420@falcon.midgard.homeip.net> <3F873612.5000704@juniper.net> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Sat, 11 Oct 2003 01:08:21 +0200 In-Reply-To: <3F873612.5000704@juniper.net> (Sandeep Kumar's message of "Fri, 10 Oct 2003 15:43:30 -0700") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on dsa.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 cc: freebsd-hackers@freebsd.org Subject: Re: Archive for cvs-src X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 23:08:30 -0000 Sandeep Kumar writes: > On Sat, Oct 11, 2003 at 12:13:10AM +0200, Dag-Erling Sm=F8rgrav wrote: > > Wrong. These lists have existed for years. > Actually not. Although majordomo lists contain cvs-all, I didn't find > other cvs-* over there we used to have a whole lot of these: des@dwp /home/cvsup/freebsd/mail/archive% ls -d 1999/cvs-* 1999/cvs-CVSROOT/ 1999/cvs-gnu/ 1999/cvs-sbin/ 1999/cvs-all/ 1999/cvs-include/ 1999/cvs-share/ 1999/cvs-bin/ 1999/cvs-kerberosIV/ 1999/cvs-sys/ 1999/cvs-contrib/ 1999/cvs-lib/ 1999/cvs-tools/ 1999/cvs-distrib/ 1999/cvs-libexec/ 1999/cvs-user/ 1999/cvs-doc/ 1999/cvs-lkm/ 1999/cvs-usrbin/ 1999/cvs-eBones/ 1999/cvs-other/ 1999/cvs-usrsbin/ 1999/cvs-etc/ 1999/cvs-ports/ 1999/cvs-www/ 1999/cvs-games/ 1999/cvs-release/ most of them were discontinued sometime in 1999; cvs-src, cvs-ports and cvs-doc were resurrected when the repo was split, which was pretty much the same time as the switch to mailman. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 16:32:36 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52A1216A4B3; Fri, 10 Oct 2003 16:32:36 -0700 (PDT) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01C8743FA3; Fri, 10 Oct 2003 16:32:35 -0700 (PDT) (envelope-from nork@FreeBSD.org) Received: from pelsia.ninth-nine.com (pelsia.ninth-nine.com [219.127.74.123]) (authenticated bits=0) by sakura.ninth-nine.com (8.12.9p2/8.12.9/NinthNine) with ESMTP id h9ANWWiS011169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Oct 2003 08:32:33 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sat, 11 Oct 2003 08:32:35 +0900 From: Norikatsu Shigemura To: Simon Barner Message-Id: <20031011083235.087ecfc9.nork@FreeBSD.org> In-Reply-To: <20031009174211.GA364@zi025.glhnet.mhn.de> References: <20031008033536.7f6099b5.nork@FreeBSD.org> <20031009174211.GA364@zi025.glhnet.mhn.de> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-hackers@FreeBSD.org cc: freebsd-stable@FreeBSD.org cc: freebsd-mozilla@FreeBSD.org cc: freebsd-gnome@FreeBSD.org Subject: Re: HEADS UP: pelase test /etc/libmap.conf feature on 4-stable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2003 23:32:36 -0000 On Thu, 9 Oct 2003 19:42:11 +0200 Simon Barner wrote: > I tested your patch, and it worked, but I had to modify the following > things: > Fetch libmapc. and libmap.h from the CVS repository (latest revisions). > Add libmap.c to SRC section in Makefile. Oops, sorry. I didn't notice > http://freebsd.rambler.ru/.... > > libstdc++-libc6.2-2.so.3 liblstdc++.so.3 > ^--- where is this file? I changed it to > libstdc++.so.3, and it worked > I performed some tests with mozilla, and I ended up with exactly the > same results as I pointed out in this email: Yes. You are right. Now I confirmed setting like following lines. for /etc/libmap.conf on 4-stable - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - #opera [/usr/X11R6/lib/browser_plugins/libflashplayer.so] libpthread.so.0 liblthread.so.2 libdl.so.2 pluginwrapper.so libz.so.1 libz.so.2 libstdc++-libc6.2-2.so.3 libstdc++.so.3 libm.so.6 libm.so.2 libc.so.6 pluginwrapper.so #opera [/usr/X11R6/share/opera/plugins/operamotifwrapper] libXm.so.1 libXm.so.3 # mozilla [/usr/local/lib/linux-flashplugin6/libflashplayer.so] libpthread.so.0 liblthread.so.2 libdl.so.2 pluginwrapper.so libz.so.1 libz.so.2 libstdc++-libc6.2-2.so.3 libstdc++.so.3 libm.so.6 libm.so.2 libc.so.6 pluginwrapper.so - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Another result is that mozilla locks up after successfully showing almost > any of the flash plugins I tried (I afraid I cannot offer more details on > this issue at the present, but I am investigating it). Now status... mozilla mozilla-firebird galeon epiphany konqueror opera 5-current OK OK OK OK UNKOWN NG 4-stable OK maybe maybe maybe UNKOWN OK TODO about only this port: 1. Check 'Is libmap.conf feature available?' on install. 2. Warning if ${LOCALBASE}/lib/libflashplayer.so.1 is available. 3. More adaptive for 4-stable. (update /etc/libmap.conf) 4. Add more working list. By the way, do anyone ask to opera's maker about operamotifwrapper like 'Where is libXm.so.1?'. I hope to link libXm.a:-). From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 17:40:30 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6BD816A4B3; Fri, 10 Oct 2003 17:40:30 -0700 (PDT) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92C0A43F3F; Fri, 10 Oct 2003 17:40:28 -0700 (PDT) (envelope-from kientzle@acm.org) Received: from acm.org ([66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id h9B0eJkX047883; Fri, 10 Oct 2003 17:40:19 -0700 (PDT) (envelope-from kientzle@acm.org) Message-ID: <3F875172.5010309@acm.org> Date: Fri, 10 Oct 2003 17:40:18 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce M Simpson References: <20031008083059.GA520@garage.freebsd.pl> <20031008114506.I63940@beagle.fokus.fraunhofer.de> <20031008101251.GG6524@saboteur.dek.spc.org> In-Reply-To: <20031008101251.GG6524@saboteur.dek.spc.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: rwatson@freebsd.org cc: hsu@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kientzle@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 00:40:31 -0000 Bruce M Simpson wrote: > On Wed, Oct 08, 2003 at 11:51:06AM +0200, Harti Brandt wrote: >>You need to lock when reading if you insist on consistent data. Even a >>simple read may be non-atomic (this should be the case for 64bit >>operations on all our platforms). > > Or keep a generation count to detect pre-emption (the devstat code does > this, amongst other things), and try again if you lost the race. Are you sure that code is right? I'm not at all convinced that the compiler is forbidden from simply optimizing away most of your generation count code. (Just because gcc doesn't do so today doesn't mean that icc or gcc 4 won't.) I'd be a lot more convinced by code that allocated a non-shared buffer, locked the mutex, copied the data into the buffer, unlocked, pushed the data out from the buffer, then released the buffer. Many attempts to avoid locking are foiled by compiler optimizations. Tim Kientzle From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 19:37:26 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 190E416A4BF for ; Fri, 10 Oct 2003 19:37:26 -0700 (PDT) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 028E043FBF for ; Fri, 10 Oct 2003 19:37:25 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 963975B66D; Fri, 10 Oct 2003 19:35:12 -0700 (PDT) From: Wes Peters Organization: Softweyr To: "C. Kukulies" , hackers@freebsd.org Date: Fri, 10 Oct 2003 19:37:23 -0700 User-Agent: KMail/1.5.4 References: <200310101417.h9AEHb4n025071@www.kukulies.org> In-Reply-To: <200310101417.h9AEHb4n025071@www.kukulies.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310101937.23785.wes@softweyr.com> Subject: Re: smallest piece of hardware that runs *BSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 02:37:26 -0000 On Friday 10 October 2003 07:17 am, C. Kukulies wrote: > 1990: In ten years, computers will just be bumps in cables. (Gordon > Bell) > > Remember that quote? > > Now, we are not far from that. I'm thinking of some CPU with TP > Ethernet and memory of size of an USB stick. Anyone knowing such or > having experience? Grab a copy of Embedded Systems Programming, there are ads for things like this all over near the back of the magazine. In particular, the chip in whatever USB stick you're looking at probably has an 8-bit CPU of some sort in it. -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 19:48:06 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F4E616A4B3; Fri, 10 Oct 2003 19:48:06 -0700 (PDT) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE50743FBF; Fri, 10 Oct 2003 19:48:04 -0700 (PDT) (envelope-from nork@FreeBSD.org) Received: from nd250009.gab.xdsl.ne.jp (nadesico.ninth-nine.com [192.168.36.3]) by sakura.ninth-nine.com (8.12.9p2/8.12.9/NinthNine) with SMTP id h9B2m3iR019297; Sat, 11 Oct 2003 11:48:03 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sat, 11 Oct 2003 11:48:03 +0900 (JST) Message-Id: <200310110248.h9B2m3iR019297@sakura.ninth-nine.com> From: Norikatsu Shigemura To: freebsd-hackers@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-mozilla@FreeBSD.org, freebsd-gnome@FreeBSD.org In-Reply-To: <20031011083235.087ecfc9.nork@FreeBSD.org> References: <20031008033536.7f6099b5.nork@FreeBSD.org> <20031009174211.GA364@zi025.glhnet.mhn.de> <20031011083235.087ecfc9.nork@FreeBSD.org> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: kde@FreeBSD.org Subject: Re: HEADS UP: pelase test /etc/libmap.conf feature on 4-stable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 02:48:06 -0000 On Sat, 11 Oct 2003 08:32:35 +0900 I wrote: > Now status... > mozilla mozilla-firebird galeon epiphany konqueror opera > 5-current OK OK OK OK UNKOWN NG > 4-stable OK maybe maybe maybe UNKOWN OK Konqueror on 5-current (maybe 4-stable) is OK. For konqueror. we will need to setup a new plugin directory which was decided by nspluginscan. nspluginscan contains following directories (according to strings /usr/local/bin/nspluginscan). $HOME/.netscape/plugins /usr/local/netscape/plugins /opt/mozilla/plugins /opt/netscape/plugins /usr/lib/netscape/plugins /usr/lib/mozilla/plugins $MOZILLA_HOME/plugins 1. (kde side) Anyone, would you please make a patch for nspluginscane to look /usr/X11R6/lib/browsers_plugins? or 2. (pluginwrapper side) If 1 is no, I'll install Flash6 plugin to /usr/local/netscape/plugins. > TODO about only this port: > 1. Check 'Is libmap.conf feature available?' on install. > 2. Warning if ${LOCALBASE}/lib/libflashplayer.so.1 is available. > 3. More adaptive for 4-stable. (update /etc/libmap.conf) > 4. Add more working list. > By the way, do anyone ask to opera's maker about operamotifwrapper > like 'Where is libXm.so.1?'. I hope to link libXm.a:-). And, do you know freebsd-kde mailling list? I know kde@ is, but I don't know public mailling list like freebsd-gnome@. (and, as possible as, freebsd-opera, too) From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 20:03:23 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5E5F16A4C0 for ; Fri, 10 Oct 2003 20:03:23 -0700 (PDT) Received: from c211-28-27-130.belrs2.nsw.optusnet.com.au (c211-28-27-130.belrs2.nsw.optusnet.com.au [211.28.27.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6E3443F75 for ; Fri, 10 Oct 2003 20:03:19 -0700 (PDT) (envelope-from peterjeremy@optushome.com.au) Received: from server.c211-28-27-130.belrs2.nsw.optusnet.com.au (localhost.c211-28-27-130.belrs2.nsw.optusnet.com.au [127.0.0.1]) ESMTP id h9B32pdb076494; Sat, 11 Oct 2003 13:02:51 +1000 (EST) peter@server.c211-28-27-130.belrs2.nsw.optusnet.com.au) Received: (from peter@localhost) (8.12.9p1/8.12.9/Submit) id h9B32p2K076493; Sat, 11 Oct 2003 13:02:51 +1000 (EST) (envelope-from peter) Date: Sat, 11 Oct 2003 13:02:51 +1000 From: Peter Jeremy To: ticso@cicely.de Message-ID: <20031011030251.GB75796@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> References: <20031008083059.GA520@garage.freebsd.pl> <20031008114506.I63940@beagle.fokus.fraunhofer.de> <20031009093741.GA69062@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> <20031009172414.GY13791@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031009172414.GY13791@cicely12.cicely.de> User-Agent: Mutt/1.4.1i cc: freebsd-hackers@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 03:03:23 -0000 On Thu, Oct 09, 2003 at 07:24:15PM +0200, Bernd Walter wrote: >> Note that, possibly contrary to expectations, 8-bit and 16-bit >> _writes_ are not atomic on many (all?) the 64-bit architectures. >> Small writes are generally done by doing a 64-bit read, insert >> under mask and 64-bit write. > >The mask case is true - e.g. on alpha <=ev5, but it's still atomic. >You write the 8 or 16 bit in a single step, but the other bits of the >same 32bit memory location are loaded into a register as well and >masked. True. I think I expressed myself badly referring to it as "not atomic". >Note that this is semanticaly in no way different from a CPU loading >a whole cacheline to change a single byte which is what every modern >system does. Which may or may not provide hardware interlocking to support multiple CPUs updating adjacent memory. The load/mask/store situation definitely needs explicit interlocks. Maybe what I should say is that in a threaded or multi-CPU environment, updating any variable without locks requires intimate knowledge of how your toolchain lays out storage and what the system coherency boundaries are. To explain further, say I have two variables: short foo, bar; If the toolchain happens to pack them into the same longword on an Alpha and doesn't use the BWL-extension instructions then I can't update 'foo' in one thread and 'bar' in a different thread without locks. OTOH, if 'foo' and 'bar' are in different cache lines, then you don't need locks in any architecture. Peter From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 20:58:41 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5ED216A4B3 for ; Fri, 10 Oct 2003 20:58:41 -0700 (PDT) Received: from c211-28-27-130.belrs2.nsw.optusnet.com.au (c211-28-27-130.belrs2.nsw.optusnet.com.au [211.28.27.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 436AE43F3F for ; Fri, 10 Oct 2003 20:58:40 -0700 (PDT) (envelope-from peterjeremy@optushome.com.au) Received: from server.c211-28-27-130.belrs2.nsw.optusnet.com.au (localhost.c211-28-27-130.belrs2.nsw.optusnet.com.au [127.0.0.1]) ESMTP id h9B3wTdb007825; Sat, 11 Oct 2003 13:58:29 +1000 (EST) peter@server.c211-28-27-130.belrs2.nsw.optusnet.com.au) Received: (from peter@localhost) (8.12.9p1/8.12.9/Submit) id h9B3wRYO007824; Sat, 11 Oct 2003 13:58:27 +1000 (EST) (envelope-from peter) Date: Sat, 11 Oct 2003 13:58:27 +1000 From: Peter Jeremy To: Andrew Gallatin Message-ID: <20031011035827.GD75796@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> References: <20031010103640.6F5A216A4BF@hub.freebsd.org> <20031010134400.GE803@saboteur.dek.spc.org> <16263.1019.939450.708832@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16263.1019.939450.708832@grasshopper.cs.duke.edu> User-Agent: Mutt/1.4.1i cc: freebsd-hackers@freebsd.org Subject: Re: Determining CPU features / cache organization from userland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 03:58:41 -0000 On Fri, Oct 10, 2003 at 03:09:47PM -0400, Andrew Gallatin wrote: > >Bruce M Simpson writes: > > I've been thinking we should definitely make the cache organization > > info available via sysctl. I am thinking we should do this to make > > the UMA_ALIGN_CACHE definition mean something... > >If you do this, it may make sense to use the same names as MacOSX. > >g51% sysctl hw | grep cache >hw.cachelinesize: 128 >hw.l1icachesize: 65536 >hw.l1dcachesize: 32768 >hw.l2cachesize: 524288 What if your hardware has different linesizes for different caches? Peter From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 22:02:02 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E1DB16A4B3 for ; Fri, 10 Oct 2003 22:02:02 -0700 (PDT) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9ABF043F93 for ; Fri, 10 Oct 2003 22:01:59 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: from freebsd1.cimlogic.com.au (localhost [127.0.0.1]) by cimlogic.com.au (8.12.9/8.12.9) with ESMTP id h9B56JgH070607; Sat, 11 Oct 2003 15:06:19 +1000 (EST) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by freebsd1.cimlogic.com.au (8.12.9/8.12.9/Submit) id h9B56IkM070606; Sat, 11 Oct 2003 15:06:18 +1000 (EST) Date: Sat, 11 Oct 2003 15:06:18 +1000 From: John Birrell To: "C. Kukulies" Message-ID: <20031011050618.GB61302@freebsd1.cimlogic.com.au> References: <200310101417.h9AEHb4n025071@www.kukulies.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310101417.h9AEHb4n025071@www.kukulies.org> User-Agent: Mutt/1.4.1i cc: hackers@freebsd.org Subject: Re: smallest piece of hardware that runs *BSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 05:02:02 -0000 On Fri, Oct 10, 2003 at 04:17:37PM +0200, C. Kukulies wrote: > Now, we are not far from that. I'm thinking of some CPU with TP Ethernet > and memory of size of an USB stick. Anyone knowing such or having > experience? Here's one the size of a credit card: . It's a lot bigger than a 'bump in a cable', but it runs FreeBSD. -- John Birrell From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 22:31:26 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFCDA16A4B3; Fri, 10 Oct 2003 22:31:26 -0700 (PDT) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D50DB43F93; Fri, 10 Oct 2003 22:31:25 -0700 (PDT) (envelope-from kientzle@acm.org) Received: from acm.org ([66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id h9B5VNkX048688; Fri, 10 Oct 2003 22:31:23 -0700 (PDT) (envelope-from kientzle@acm.org) Message-ID: <3F8795A9.5020409@acm.org> Date: Fri, 10 Oct 2003 22:31:21 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kientzle@acm.org References: <20031008083059.GA520@garage.freebsd.pl> <20031008114506.I63940@beagle.fokus.fraunhofer.de> <20031008101251.GG6524@saboteur.dek.spc.org> <3F875172.5010309@acm.org> In-Reply-To: <3F875172.5010309@acm.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: hsu@freebsd.org cc: rwatson@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kientzle@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 05:31:27 -0000 > Bruce M Simpson wrote: >> >> Or keep a generation count to detect pre-emption (the devstat code does >> this, amongst other things), and try again if you lost the race. On further inspection, I'm pretty sure that sys/kern/subr_devstat.c is not correct. In particular, sysctl_devstat writes out a node's data without holding the lock. (I believe this is the whole point of all the "generation count" machinery.) It seems possible for devstat_remove_entry to remove that entry, free the storage, and have that storage recycled just before it gets written out. In this particular case, it means random kernel data gets written out from the kernel to userspace. (Which in some circles would be considered a security problem, though it's hard to see how anyone could possibly exploit it.) Tim Kientzle From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 23:42:16 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C4F016A4B3; Fri, 10 Oct 2003 23:42:16 -0700 (PDT) Received: from ms-smtp-03.southeast.rr.com (ms-smtp-03.southeast.rr.com [24.93.67.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F11E43F75; Fri, 10 Oct 2003 23:42:14 -0700 (PDT) (envelope-from marcus@marcuscom.com) Received: from creme-brulee.marcuscom.com (rdu74-159-108.nc.rr.com [24.74.159.108])h9B6dgVx010353; Sat, 11 Oct 2003 02:39:42 -0400 (EDT) Received: from [192.168.1.4] (shumai.marcuscom.com [192.168.1.4]) h9B6fG1v064418; Sat, 11 Oct 2003 02:41:16 -0400 (EDT) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Michael Nottebrock In-Reply-To: <3F87A447.8020901@gmx.net> References: <20031008033536.7f6099b5.nork@FreeBSD.org> <20031009174211.GA364@zi025.glhnet.mhn.de> <20031011083235.087ecfc9.nork@FreeBSD.org> <200310110248.h9B2m3iR019297@sakura.ninth-nine.com> <3F87A447.8020901@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-X3NY99P38m8dw8s03f+s" Organization: MarcusCom, Inc. Message-Id: <1065854516.6166.71.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 11 Oct 2003 02:41:56 -0400 X-Spam-Status: No, hits=-0.8 required=5.0 tests=BAYES_00,SUBJ_HAS_SPACES autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on creme-brulee.marcuscom.com cc: kde@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-hackers@freebsd.org cc: freebsd-mozilla@freebsd.org cc: Norikatsu Shigemura cc: freebsd-stable@freebsd.org Subject: Re: [kde-freebsd] Re: HEADS UP: pelase test /etc/libmap.conffeature on 4-stable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 06:42:16 -0000 --=-X3NY99P38m8dw8s03f+s Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2003-10-11 at 02:33, Michael Nottebrock wrote: > Norikatsu Shigemura wrote: >=20 > >=20 > > 1. (kde side) Anyone, would you please make a patch for > > nspluginscane to look /usr/X11R6/lib/browsers_plugins? > > or > > 2. (pluginwrapper side) If 1 is no, I'll install Flash6 > > plugin to /usr/local/netscape/plugins. >=20 > Personally I'd like (2) better, /usr/X11/lib/browser_plugins isn't really= in=20 > the spirit of hier(7). Great to hear about this flashplugin-via-libmap=20 > project, can you provide some details? We'd like to put a HOWTO on=20 > kde-freebsd's homepage, etc. However, browser_plugins is what is being used for other plug-ins (e.g. mplayerplug-in), and this was decided on some time ago. It might be best to have Flash installed in just one place. Joe --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-X3NY99P38m8dw8s03f+s Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQA/h6Y0b2iPiv4Uz4cRAsdeAJ9E7JHWKntedQj8xxgejoG2cK97eQCfe6Bh wm09iv3S+Vd4CPnbUtk+mpo= =3t46 -----END PGP SIGNATURE----- --=-X3NY99P38m8dw8s03f+s-- From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 00:20:43 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B941316A4B3; Sat, 11 Oct 2003 00:20:43 -0700 (PDT) Received: from meitner.wh.uni-dortmund.de (meitner.wh.Uni-Dortmund.DE [129.217.129.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA86C43F75; Sat, 11 Oct 2003 00:20:38 -0700 (PDT) (envelope-from michaelnottebrock@gmx.net) Received: from lofi.dyndns.org (pc2-105.intern.meitner [10.3.12.105]) by meitner.wh.uni-dortmund.de (Postfix) with ESMTP id 0214A16768E; Sat, 11 Oct 2003 09:20:38 +0200 (CEST) Received: from gmx.net (kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.12.9p1/8.12.9) with ESMTP id h9B7Kaj4081143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Oct 2003 09:20:37 +0200 (CEST) (envelope-from michaelnottebrock@gmx.net) Message-ID: <3F87AF43.4070705@gmx.net> Date: Sat, 11 Oct 2003 09:20:35 +0200 From: Michael Nottebrock User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, de-de MIME-Version: 1.0 To: Joe Marcus Clarke References: <20031008033536.7f6099b5.nork@FreeBSD.org> <20031009174211.GA364@zi025.glhnet.mhn.de> <20031011083235.087ecfc9.nork@FreeBSD.org> <200310110248.h9B2m3iR019297@sakura.ninth-nine.com> <3F87A447.8020901@gmx.net> <1065854516.6166.71.camel@shumai.marcuscom.com> In-Reply-To: <1065854516.6166.71.camel@shumai.marcuscom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new cc: freebsd-stable@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-hackers@freebsd.org cc: freebsd-mozilla@freebsd.org cc: Norikatsu Shigemura cc: kde@freebsd.org Subject: Re: [kde-freebsd] Re: HEADS UP: pelase test/etc/libmap.conffeature on 4-stable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 07:20:44 -0000 Joe Marcus Clarke wrote: > On Sat, 2003-10-11 at 02:33, Michael Nottebrock wrote: > >>Norikatsu Shigemura wrote: >> >> >>> 1. (kde side) Anyone, would you please make a patch for >>> nspluginscane to look /usr/X11R6/lib/browsers_plugins? >>> or >>> 2. (pluginwrapper side) If 1 is no, I'll install Flash6 >>> plugin to /usr/local/netscape/plugins. >> >>Personally I'd like (2) better, /usr/X11/lib/browser_plugins isn't really in >>the spirit of hier(7). Great to hear about this flashplugin-via-libmap >>project, can you provide some details? We'd like to put a HOWTO on >>kde-freebsd's homepage, etc. > > > However, browser_plugins is what is being used for other plug-ins (e.g. > mplayerplug-in), and this was decided on some time ago. It's never too late to correct unfortunate decisions. :-) Anyway, the paths for konqueror's plugin-scanner are user-configurable through konqueror's settings dialog. We certainly can make a local patch to the defaults as well, and we can even try to get that patch merged upstream into KDE's sources. So, just go ahead with whatever path you feel comfortable with, we'll cope. -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 00:25:09 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0621E16A4B3; Sat, 11 Oct 2003 00:25:09 -0700 (PDT) Received: from ms-smtp-03.southeast.rr.com (ms-smtp-03.southeast.rr.com [24.93.67.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id A15ED43F93; Sat, 11 Oct 2003 00:25:07 -0700 (PDT) (envelope-from marcus@marcuscom.com) Received: from creme-brulee.marcuscom.com (rdu74-159-108.nc.rr.com [24.74.159.108])h9B7MkVx005535; Sat, 11 Oct 2003 03:22:46 -0400 (EDT) Received: from [192.168.1.4] (shumai.marcuscom.com [192.168.1.4]) h9B7OK1v064905; Sat, 11 Oct 2003 03:24:20 -0400 (EDT) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Michael Nottebrock In-Reply-To: <3F87AF43.4070705@gmx.net> References: <20031008033536.7f6099b5.nork@FreeBSD.org> <20031009174211.GA364@zi025.glhnet.mhn.de> <20031011083235.087ecfc9.nork@FreeBSD.org> <200310110248.h9B2m3iR019297@sakura.ninth-nine.com> <1065854516.6166.71.camel@shumai.marcuscom.com> <3F87AF43.4070705@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-goKde85eU46cIhCHTHv1" Organization: MarcusCom, Inc. Message-Id: <1065857100.6166.88.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 11 Oct 2003 03:25:00 -0400 X-Spam-Status: No, hits=-0.8 required=5.0 tests=BAYES_00,SUBJ_HAS_SPACES autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on creme-brulee.marcuscom.com cc: freebsd-stable@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-hackers@freebsd.org cc: freebsd-mozilla@freebsd.org cc: Norikatsu Shigemura cc: kde@freebsd.org Subject: Re: [kde-freebsd] Re: HEADS UP: pelase test /etc/libmap.conffeature on 4-stable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 07:25:09 -0000 --=-goKde85eU46cIhCHTHv1 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2003-10-11 at 03:20, Michael Nottebrock wrote: > Joe Marcus Clarke wrote: > > On Sat, 2003-10-11 at 02:33, Michael Nottebrock wrote: > >=20 > >>Norikatsu Shigemura wrote: > >> > >> > >>> 1. (kde side) Anyone, would you please make a patch for > >>> nspluginscane to look /usr/X11R6/lib/browsers_plugins? > >>> or > >>> 2. (pluginwrapper side) If 1 is no, I'll install Flash6 > >>> plugin to /usr/local/netscape/plugins. > >> > >>Personally I'd like (2) better, /usr/X11/lib/browser_plugins isn't real= ly in=20 > >>the spirit of hier(7). Great to hear about this flashplugin-via-libmap=20 > >>project, can you provide some details? We'd like to put a HOWTO on=20 > >>kde-freebsd's homepage, etc. > >=20 > >=20 > > However, browser_plugins is what is being used for other plug-ins (e.g. > > mplayerplug-in), and this was decided on some time ago. >=20 > It's never too late to correct unfortunate decisions. :-) What don't you agree with? Give me some better ideas. Give me some reasons why you don't like the current scheme. At the time, I thought it was better to do _something_ than kill the whole idea in a bikeshed. Joe >=20 > Anyway, the paths for konqueror's plugin-scanner are user-configurable th= rough=20 > konqueror's settings dialog. We certainly can make a local patch to the=20 > defaults as well, and we can even try to get that patch merged upstream i= nto=20 > KDE's sources. So, just go ahead with whatever path you feel comfortable = with,=20 > we'll cope. --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-goKde85eU46cIhCHTHv1 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQA/h7BMb2iPiv4Uz4cRAkzTAKCE5P90hkkCRFVNs61720wtqcdL7ACghMHC cQgCEUUp7JL8G7nv/9b+STM= =E0yy -----END PGP SIGNATURE----- --=-goKde85eU46cIhCHTHv1-- From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 01:18:31 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A105B16A4B3; Sat, 11 Oct 2003 01:18:31 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 645BF43FCB; Sat, 11 Oct 2003 01:18:30 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id CD0AD65495; Sat, 11 Oct 2003 09:18:27 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 90690-03; Sat, 11 Oct 2003 09:18:27 +0100 (BST) Received: from saboteur.dek.spc.org (lardystuffer.demon.co.uk [212.228.40.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id E30736549B; Sat, 11 Oct 2003 09:18:25 +0100 (BST) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id B060D35; Sat, 11 Oct 2003 09:18:22 +0100 (BST) Date: Sat, 11 Oct 2003 09:18:22 +0100 From: Bruce M Simpson To: Tim Kientzle Message-ID: <20031011081822.GA679@saboteur.dek.spc.org> Mail-Followup-To: Tim Kientzle , Bruce M Simpson , rwatson@freebsd.org, hsu@freebsd.org, freebsd-hackers@freebsd.org References: <20031008083059.GA520@garage.freebsd.pl> <20031008114506.I63940@beagle.fokus.fraunhofer.de> <20031008101251.GG6524@saboteur.dek.spc.org> <3F875172.5010309@acm.org> <3F8795A9.5020409@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F8795A9.5020409@acm.org> cc: hsu@freebsd.org cc: rwatson@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 08:18:31 -0000 On Fri, Oct 10, 2003 at 10:31:21PM -0700, Tim Kientzle wrote: > On further inspection, I'm pretty sure that sys/kern/subr_devstat.c > is not correct. OK. What about the shared page interface? Specifically the comment above devstat_end_transaction(). The generation count is used by the old sysctl interface. The shared page interface has a liberal sprinkling of atomic*() instructions. BMS From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 01:27:24 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 800A616A4B3 for ; Sat, 11 Oct 2003 01:27:24 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6468543F93 for ; Sat, 11 Oct 2003 01:27:21 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 9B981654BB; Sat, 11 Oct 2003 09:27:20 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 90690-04-2; Sat, 11 Oct 2003 09:27:20 +0100 (BST) Received: from saboteur.dek.spc.org (lardystuffer.demon.co.uk [212.228.40.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 34A07654B5; Sat, 11 Oct 2003 09:27:19 +0100 (BST) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 441FF35; Sat, 11 Oct 2003 09:27:11 +0100 (BST) Date: Sat, 11 Oct 2003 09:27:11 +0100 From: Bruce M Simpson To: Peter Jeremy Message-ID: <20031011082711.GB679@saboteur.dek.spc.org> Mail-Followup-To: Peter Jeremy , Andrew Gallatin , Bruce M Simpson , freebsd-hackers@freebsd.org References: <20031010103640.6F5A216A4BF@hub.freebsd.org> <20031010134400.GE803@saboteur.dek.spc.org> <16263.1019.939450.708832@grasshopper.cs.duke.edu> <20031011035827.GD75796@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031011035827.GD75796@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> cc: Andrew Gallatin cc: freebsd-hackers@freebsd.org Subject: Re: Determining CPU features / cache organization from userland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 08:27:24 -0000 X-List-Received-Date: Sat, 11 Oct 2003 08:27:24 -0000 On Sat, Oct 11, 2003 at 01:58:27PM +1000, Peter Jeremy wrote: > >If you do this, it may make sense to use the same names as MacOSX. > > What if your hardware has different linesizes for different caches? I noticed whilst peering in Apple Developer Notes that G5 has 128 byte cache line size, and this screws up mutexes bigtime. (!!) OS X definitions considered too PowerPC centric. I think the best way to handle all cases is thus:- - Support 3 levels of cache. - Each level may be unified or split between code and data not-quite-Von-Neumann-style. - Allow explicit retrieval of this info keyed on the cache you're interested in. This means: hw.cache.lN.(linesize|lines|sets) - Do similar for the TLB insofar as we can return information about the chip's TLB. I know for example from talking to peter@ that the Opteron is quite a different beast (ASNs, flush filter, etc). - Assume that all CPUs have identical characteristics in an SMP system. Trying to assume otherwise is pointless. People should be using matched chips anyway. BMS From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 01:27:50 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73CD416A4BF for ; Sat, 11 Oct 2003 01:27:50 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FCCA43FDD for ; Sat, 11 Oct 2003 01:27:48 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id AA37B654BD; Sat, 11 Oct 2003 09:27:47 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 90690-04-3; Sat, 11 Oct 2003 09:27:47 +0100 (BST) Received: from saboteur.dek.spc.org (lardystuffer.demon.co.uk [212.228.40.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id CFB48654B2; Sat, 11 Oct 2003 09:27:45 +0100 (BST) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 1B3F1D6; Sat, 11 Oct 2003 09:27:43 +0100 (BST) Date: Sat, 11 Oct 2003 09:27:43 +0100 From: Bruce M Simpson To: Wes Peters Message-ID: <20031011082743.GC679@saboteur.dek.spc.org> References: <200310101417.h9AEHb4n025071@www.kukulies.org> <200310101937.23785.wes@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310101937.23785.wes@softweyr.com> cc: "C. Kukulies" cc: hackers@freebsd.org Subject: Re: smallest piece of hardware that runs *BSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 08:27:50 -0000 On Fri, Oct 10, 2003 at 07:37:23PM -0700, Wes Peters wrote: > Grab a copy of Embedded Systems Programming, there are ads for things like > this all over near the back of the magazine. In particular, the chip in > whatever USB stick you're looking at probably has an 8-bit CPU of some > sort in it. I find Circuit Cellar is also a good periodical for stuff like this! BMS From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 03:12:44 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3170416A4B3 for ; Sat, 11 Oct 2003 03:12:44 -0700 (PDT) Received: from c211-28-27-130.belrs2.nsw.optusnet.com.au (c211-28-27-130.belrs2.nsw.optusnet.com.au [211.28.27.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E40E43FB1 for ; Sat, 11 Oct 2003 03:12:42 -0700 (PDT) (envelope-from peterjeremy@optushome.com.au) Received: from server.c211-28-27-130.belrs2.nsw.optusnet.com.au (localhost.c211-28-27-130.belrs2.nsw.optusnet.com.au [127.0.0.1]) ESMTP id h9BACWdb016390; Sat, 11 Oct 2003 20:12:32 +1000 (EST) peter@server.c211-28-27-130.belrs2.nsw.optusnet.com.au) Received: (from peter@localhost) (8.12.9p1/8.12.9/Submit) id h9BACVaf016389; Sat, 11 Oct 2003 20:12:31 +1000 (EST) (envelope-from peter) Date: Sat, 11 Oct 2003 20:12:31 +1000 From: Peter Jeremy To: Andrew Gallatin , Bruce M Simpson , freebsd-hackers@freebsd.org Message-ID: <20031011101231.GH75796@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> References: <20031010103640.6F5A216A4BF@hub.freebsd.org> <20031010134400.GE803@saboteur.dek.spc.org> <16263.1019.939450.708832@grasshopper.cs.duke.edu> <20031011035827.GD75796@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> <20031011082711.GB679@saboteur.dek.spc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031011082711.GB679@saboteur.dek.spc.org> User-Agent: Mutt/1.4.1i Subject: Re: Determining CPU features / cache organization from userland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 10:12:44 -0000 On Sat, Oct 11, 2003 at 09:27:11AM +0100, Bruce M Simpson wrote: >OS X definitions considered too PowerPC centric. I think the best way >to handle all cases is thus:- > > - Support 3 levels of cache. Out of interest, do any systems other than the big-iron Alpha's use L3 cache? A quick look at the code suggests that only L2 is coloured. > - Each level may be unified or split between code and data > not-quite-Von-Neumann-style. Do any systems use split L2 (or L3) caches? And how do you define the wierd micro-instruction cache used in the P4? > - Allow explicit retrieval of this info keyed on the cache you're > interested in. This means: hw.cache.lN.(linesize|lines|sets) How do you distinguish between a direct-mapped and fully-associative cache? (Do any current CPUs have fully-associative caches?) For set-associative caches, is it worth identifying and reporting the replacement algorithm (eg random, LRU or pseudo-LRU) > - Do similar for the TLB insofar as we can return information about > the chip's TLB. I know for example from talking to peter@ that > the Opteron is quite a different beast (ASNs, flush filter, etc). This is possibly more useful on the RISC CPUs where the TLB is managed in firmware (eg Alpha PALcode) so TLB misses are expensive. Note that at least the Alpha has multiple sets of TLB registers for different mapping types and sizes. The number of registers in each set varies between different AXP generations (though I think the sets remain the same). > - Assume that all CPUs have identical characteristics in an SMP system. > Trying to assume otherwise is pointless. People should be using matched > chips anyway. HP AlphaServer ES47 (and ES45 from memory) allow different speed CPUs in an SMP system. Some of the high-end SPARCservers probably do as well. This probably does make sense when you're talking about a system which might be expanded over its lifetime - and the slow CPUs that came with the system initially might no longer be available but you need more CPUs and can't justify replacing the existing ones. Whether FreeBSD wants to support this market is another issue. Peter From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 06:37:26 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F56316A4D9; Sat, 11 Oct 2003 06:37:26 -0700 (PDT) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id B416D43FBD; Sat, 11 Oct 2003 06:37:23 -0700 (PDT) (envelope-from nork@FreeBSD.org) Received: from pelsia.ninth-nine.com (pelsia.ninth-nine.com [219.127.74.123]) (authenticated bits=0) by sakura.ninth-nine.com (8.12.9p2/8.12.9/NinthNine) with ESMTP id h9BDbATo036327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Oct 2003 22:37:11 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sat, 11 Oct 2003 22:37:13 +0900 From: Norikatsu Shigemura To: Michael Nottebrock Message-Id: <20031011223713.11819206.nork@FreeBSD.org> In-Reply-To: <200310111000.46606.michaelnottebrock@gmx.net> References: <20031008033536.7f6099b5.nork@FreeBSD.org> <3F87AF43.4070705@gmx.net> <1065857100.6166.88.camel@shumai.marcuscom.com> <200310111000.46606.michaelnottebrock@gmx.net> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: kde-freebsd@lists.csociety.org cc: kde@FreeBSD.org cc: freebsd-gnome@FreeBSD.org cc: marcus@marcuscom.com cc: freebsd-hackers@FreeBSD.org cc: freebsd-mozilla@FreeBSD.org cc: freebsd-stable@FreeBSD.org Subject: Re: [kde-freebsd] Re: HEADS UP: pelase test /etc/libmap.conffeature on 4-stable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 13:37:26 -0000 On Sat, 11 Oct 2003 10:00:45 +0200 Michael Nottebrock wrote: > On Saturday 11 October 2003 09:25, Joe Marcus Clarke wrote: > > On Sat, 2003-10-11 at 03:20, Michael Nottebrock wrote: > > > Joe Marcus Clarke wrote: > > > > On Sat, 2003-10-11 at 02:33, Michael Nottebrock wrote: > > > >>Norikatsu Shigemura wrote: > > > >>> 1. (kde side) Anyone, would you please make a patch for > > > >>> nspluginscane to look /usr/X11R6/lib/browsers_plugins? > > > >>> or > > > >>> 2. (pluginwrapper side) If 1 is no, I'll install Flash6 > > > >>> plugin to /usr/local/netscape/plugins. > > > >>Personally I'd like (2) better, /usr/X11/lib/browser_plugins isn't > > > >> really in the spirit of hier(7). Great to hear about this > > > >> flashplugin-via-libmap project, can you provide some details? We'd > > > >> like to put a HOWTO on kde-freebsd's homepage, etc. > > > > However, browser_plugins is what is being used for other plug-ins (e.g. > > > > mplayerplug-in), and this was decided on some time ago. > > > It's never too late to correct unfortunate decisions. :-) > > What don't you agree with? > X11PREFIX. We really have to either stop cluttering /usr/X11R6 or rewrite > hier(7), it's as simple as that. I'd be happy either way (I mean, really. KDE > can move easily, FWIW), but I won't cut the occasional nagging earlier. :-) Humm.. I think Michael has a misunderstanding. This problem isn't installation (pkg-plist, hier(7)), but is nspluginscan looking up a (some?) plugin directory as ${X11BASE}/lib/browser_plugins. Therefore unbreak hier(7). > > Give me some better ideas. Give me some > > reasons why you don't like the current scheme. At the time, I thought > > it was better to do _something_ than kill the whole idea in a bikeshed. > I like the idea of pulling together all the ports-installed browser plugins > into one place. Even with the unfortunate prefix, I agree it's better than > just putting them all over the place. I hope that nspluginscan looks up ${X11BASE}/lib/brower_plugins like a /usr/local/netscape/plugins, /opt/mozilla/plugins. If this is OK, konqueror will be able to use Linux version Flash6 plugin with seamless by flashpluginwrapper and /etc/libmap.conf. Just like FreeBSD native version Flash6 plugin. From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 07:07:02 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FA4D16A4B3 for ; Sat, 11 Oct 2003 07:07:02 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2893B43F75 for ; Sat, 11 Oct 2003 07:07:00 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 95251654B4; Sat, 11 Oct 2003 15:06:58 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 93351-03; Sat, 11 Oct 2003 15:06:57 +0100 (BST) Received: from saboteur.dek.spc.org (lardystuffer.demon.co.uk [212.228.40.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id B72E0654C9; Sat, 11 Oct 2003 15:06:55 +0100 (BST) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 6405F31; Sat, 11 Oct 2003 15:06:51 +0100 (BST) Date: Sat, 11 Oct 2003 15:06:51 +0100 From: Bruce M Simpson To: Peter Jeremy Message-ID: <20031011140651.GA1739@saboteur.dek.spc.org> Mail-Followup-To: Peter Jeremy , Andrew Gallatin , Bruce M Simpson , freebsd-hackers@freebsd.org References: <20031010103640.6F5A216A4BF@hub.freebsd.org> <20031010134400.GE803@saboteur.dek.spc.org> <16263.1019.939450.708832@grasshopper.cs.duke.edu> <20031011035827.GD75796@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> <20031011082711.GB679@saboteur.dek.spc.org> <20031011101231.GH75796@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031011101231.GH75796@server.c211-28-27-130.belrs2.nsw.optusnet.com.au> cc: Andrew Gallatin cc: freebsd-hackers@freebsd.org Subject: Re: Determining CPU features / cache organization from userland X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 14:07:02 -0000 On Sat, Oct 11, 2003 at 08:12:31PM +1000, Peter Jeremy wrote: > Out of interest, do any systems other than the big-iron Alpha's use L3 > cache? A quick look at the code suggests that only L2 is coloured. L3 cache is present on many MIPS and Pentium Xeon systems, as well as PowerPC G4. > Do any systems use split L2 (or L3) caches? And how do you define the > wierd micro-instruction cache used in the P4? I believe certain models of MIPS may have split L2. Most L3 caches I believe will be unified. > How do you distinguish between a direct-mapped and fully-associative > cache? (Do any current CPUs have fully-associative caches?) For > set-associative caches, is it worth identifying and reporting the > replacement algorithm (eg random, LRU or pseudo-LRU) Add a sysctl type. enum cachetype { notpresent, direct, setassoc, fullyassoc }. Only look at sets if cache type set accordingly. [TLB] > This is possibly more useful on the RISC CPUs where the TLB is managed > in firmware (eg Alpha PALcode) so TLB misses are expensive. Note that > at least the Alpha has multiple sets of TLB registers for different > mapping types and sizes. The number of registers in each set varies > between different AXP generations (though I think the sets remain the > same). I know a number of individuals and organizations involved with FreeBSD pay very close attention to this, to the point of doing TLB profiling to ensure they don't churn too much in time-critical code, particulary on i386 derived platforms. I think knowledge of TLB geometry is valuable everywhere, but more so in the cases you point out. sparc64 has software-managed TLB. [on non-symmetric SMP processor clock-speeds and cache organisation] > Whether FreeBSD wants to support this market is another issue. We'll build that bridge when we come to it. BMS From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 07:24:04 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B02C116A4B3 for ; Sat, 11 Oct 2003 07:24:04 -0700 (PDT) Received: from lily.ezo.net (nsc.ezo.net [68.23.200.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5C8243FBF for ; Sat, 11 Oct 2003 07:24:03 -0700 (PDT) (envelope-from jflowers@ezo.net) Received: from www.ezo.net (peony.ezo.net [68.23.200.11]) by lily.ezo.net (8.12.6/8.12.6) with ESMTP id h9BEO6p6002713 for ; Sat, 11 Oct 2003 10:24:06 -0400 (EDT) (envelope-from jflowers@ezo.net) From: "Jim Flowers" To: freebsd-hackers@freebsd.org Date: Sat, 11 Oct 2003 10:24:04 -0500 Message-Id: <20031011141629.M11520@ezo.net> In-Reply-To: <200310101937.23785.wes@softweyr.com> References: <200310101417.h9AEHb4n025071@www.kukulies.org> <200310101937.23785.wes@softweyr.com> X-Mailer: Open WebMail 2.10 20031002 X-OriginatingIP: 24.93.231.122 (jflowers) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Subject: Re: smallest piece of hardware that runs *BSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 14:24:04 -0000 > Grab a copy of Embedded Systems Programming, there are ads for > things like this all over near the back of the magazine. In > particular, the chip in whatever USB stick you're looking at > probably has an 8-bit CPU of some sort in it. > Don't remember where I saw it but there is a product for embedded applications that is a complete webserver in a module about the size of an Ethernet socket (includes Ethernet socket) for about $50 with a $250 development system. If it could handle *BSD, it would certainly qualify for 'smallest'. From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 07:28:08 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54DA616A4B3; Sat, 11 Oct 2003 07:28:08 -0700 (PDT) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AA6E43F85; Sat, 11 Oct 2003 07:28:07 -0700 (PDT) (envelope-from nork@FreeBSD.org) Received: from pelsia.ninth-nine.com (pelsia.ninth-nine.com [219.127.74.123]) (authenticated bits=0) by sakura.ninth-nine.com (8.12.9p2/8.12.9/NinthNine) with ESMTP id h9BES5To037507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Oct 2003 23:28:06 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sat, 11 Oct 2003 23:28:09 +0900 From: Norikatsu Shigemura To: Michael Nottebrock Message-Id: <20031011232809.2c6a3e66.nork@FreeBSD.org> In-Reply-To: <3F87A447.8020901@gmx.net> References: <20031008033536.7f6099b5.nork@FreeBSD.org> <20031009174211.GA364@zi025.glhnet.mhn.de> <20031011083235.087ecfc9.nork@FreeBSD.org> <200310110248.h9B2m3iR019297@sakura.ninth-nine.com> <3F87A447.8020901@gmx.net> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i386-portbld-freebsd5.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-hackers@FreeBSD.org cc: kde@FreeBSD.org cc: freebsd-stable@FreeBSD.org cc: freebsd-mozilla@FreeBSD.org cc: freebsd-gnome@FreeBSD.org Subject: Re: [kde-freebsd] Re: HEADS UP: pelase test /etc/libmap.conf feature on 4-stable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 14:28:08 -0000 On Sat, 11 Oct 2003 08:33:43 +0200 Michael Nottebrock wrote: > the spirit of hier(7). Great to hear about this flashplugin-via-libmap > project, can you provide some details? We'd like to put a HOWTO on > kde-freebsd's homepage, etc. Thank you. Please, please. new Linux Plugin Wrapper(a.k.a. flashpluginwrapper) provides following feature. 1. FreeBSD native browers use Linux native Macromedia Flash6 Plugin with seamless. Just like FreeBSD native Flash6 Plugin. And in theory, we can use acrobat plugin, etc... 2. More safety and robust. No more LD_PRELOAD. Must not LD_PRELOAD. It doesn't intrude browesers's name space. 3. Browser independent. No need browser dependent setting. It provides seamless feature. 4. More extentional. For every plugin, it can set up libmap.conf. So conflicted setting(linkage?) coexistence with others. 5. I provided a new port, following URL (beta quality). http://tmp.ninth-nine.com/LinuxPluginWrapper/linuxpluginwrapper-20031006.tar.gz I'll upgrade www/flashpluginwrapper to www/linuxpluginwrapper. If you install this port and set /etc/libmap.conf, in this time, you can use Flash6 plugin on mozilla/firebird/galeon/ epiphany on 5-current. I have a setting for konqueror. I'll add it to example of libmap.conf. I'm afraid that we cann't use opera with Flash6. 6. I provided back port for 5-current's libmap.conf feature. http://tmp.ninth-nine.com/libmap_4/libmap_4stable.diff I hope MFC... By using it, on 4-stable, we can use this feature. I think mozilla/firebird/galeon/epiphany/konqueror/ opera is OK(in 5 case time, you can use mozillas). 7. FYI /etc/libmap.conf for 4-stable - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # /etc/libmap.conf for FreeBSD 4.x #[/usr/local/Acrobat5/Browsers/intellinux/nppdf.so] #libc.so.6 pluginwrapper.so # Opera [/usr/X11R6/lib/browser_plugins/libflashplayer.so] libpthread.so.0 liblthread.so.2 libdl.so.2 pluginwrapper.so libz.so.1 libz.so.2 libstdc++-libc6.2-2.so.3 libstdc++.so.3 libm.so.6 libm.so.2 libc.so.6 pluginwrapper.so [/usr/X11R6/share/opera/plugins/operamotifwrapper] libXm.so.1 libXm.so.3 # Konqueror (temporary setting) [/opt/mozilla/plugins/libflashplayer.so] libpthread.so.0 liblthread.so.2 libdl.so.2 pluginwrapper.so libz.so.1 libz.so.2 libstdc++-libc6.2-2.so.3 libstdc++.so.3 libm.so.6 libm.so.2 libc.so.6 pluginwrapper.so # Mozilla/Firebird/Galeon/Epiphany [/usr/local/lib/linux-flashplugin6/libflashplayer.so] libpthread.so.0 liblthread.so.2 libdl.so.2 pluginwrapper.so libz.so.1 libz.so.2 libstdc++-libc6.2-2.so.3 libstdc++.so.3 libm.so.6 libm.so.2 libc.so.6 pluginwrapper.so - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - /etc/libmap.conf for 5-current - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # /etc/libmap.conf for FreeBSD 5.x #[/usr/local/Acrobat5/Browsers/intellinux/nppdf.so] #libc.so.6 pluginwrapper.so # Opera is not avilable. # Konqueror (temporary setting) [/opt/mozilla/plugins/libflashplayer.so] libpthread.so.0 liblthread.so.3 libdl.so.2 pluginwrapper.so libz.so.1 libz.so.2 libstdc++-libc6.2-2.so.3 liblstdc++.so.4 libm.so.6 libm.so.2 libc.so.6 pluginwrapper.so # Mozilla/Firebird/Galeon/Epiphany [/usr/local/lib/linux-flashplugin6/libflashplayer.so] libpthread.so.0 liblthread.so.3 libdl.so.2 pluginwrapper.so libz.so.1 libz.so.2 libstdc++-libc6.2-2.so.3 liblstdc++.so.4 libm.so.6 libm.so.2 libc.so.6 pluginwrapper.so - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Working List - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - mozilla firebird galeon epiphany konqueror opera 4-stable OK OK OK OK OK NG 5-current OK maybe maybe maybe maybe OK - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > And, do you know freebsd-kde mailling list? I know kde@ is, > > but I don't know public mailling list like freebsd-gnome@. > > (and, as possible as, freebsd-opera, too) > kde@freebsd.org is the main public mailing list for KDE ports. There is an > additional mailing lists with a smaller audience (mostly consisting of > freebsd-ports- & KDE-developer people), kde-freebsd-devel@lists.csociety.org. Oops, sorry. I found it on http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources.html Thank you. From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 07:56:01 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E860116A4BF for ; Sat, 11 Oct 2003 07:56:01 -0700 (PDT) Received: from tenebras.com (dnscache.tenebras.com [66.92.188.165]) by mx1.FreeBSD.org (Postfix) with SMTP id B326343FAF for ; Sat, 11 Oct 2003 07:55:58 -0700 (PDT) (envelope-from kudzu@tenebras.com) Received: (qmail 10950 invoked from network); 11 Oct 2003 14:55:58 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (192.168.188.241) by laptop.tenebras.com with SMTP; 11 Oct 2003 14:55:58 -0000 Message-ID: <3F8819FE.7010605@tenebras.com> Date: Sat, 11 Oct 2003 07:55:58 -0700 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, zh-tw, zh-cn, fr, en, de-de MIME-Version: 1.0 References: <20031008033536.7f6099b5.nork@FreeBSD.org> <20031009174211.GA364@zi025.glhnet.mhn.de> <20031011083235.087ecfc9.nork@FreeBSD.org> <200310110248.h9B2m3iR019297@sakura.ninth-nine.com> <3F87A447.8020901@gmx.net> <1065854516.6166.71.camel@shumai.marcuscom.com> <3F87AF43.4070705@gmx.net> In-Reply-To: <3F87AF43.4070705@gmx.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org cc: freebsd-stable@freebsd.org cc: freebsd-mozilla@freebsd.org cc: freebsd-gnome@freebsd.org cc: kde@freebsd.org Subject: Re: [kde-freebsd] Re: HEADS UP: pelase test/etc/libmap.conffeature on 4-stable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 14:56:02 -0000 Michael Nottebrock wrote: > It's never too late to correct unfortunate decisions. :-) Such as putting packages in /usr/local/lib/ ? From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 08:21:18 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD2B216A4B3; Sat, 11 Oct 2003 08:21:18 -0700 (PDT) Received: from meitner.wh.uni-dortmund.de (meitner.wh.Uni-Dortmund.DE [129.217.129.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85B2E43F75; Sat, 11 Oct 2003 08:21:17 -0700 (PDT) (envelope-from michaelnottebrock@gmx.net) Received: from lofi.dyndns.org (pc2-105.intern.meitner [10.3.12.105]) by meitner.wh.uni-dortmund.de (Postfix) with ESMTP id F31AB167698; Sat, 11 Oct 2003 17:21:15 +0200 (CEST) Received: from gmx.net (kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.12.9p1/8.12.9) with ESMTP id h9BFLEj4039624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Oct 2003 17:21:15 +0200 (CEST) (envelope-from michaelnottebrock@gmx.net) Message-ID: <3F881FEA.8070301@gmx.net> Date: Sat, 11 Oct 2003 17:21:14 +0200 From: Michael Nottebrock User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, de-de MIME-Version: 1.0 To: Michael Sierchio References: <20031008033536.7f6099b5.nork@FreeBSD.org> <20031009174211.GA364@zi025.glhnet.mhn.de> <20031011083235.087ecfc9.nork@FreeBSD.org> <200310110248.h9B2m3iR019297@sakura.ninth-nine.com> <3F87A447.8020901@gmx.net> <1065854516.6166.71.camel@shumai.marcuscom.com> <3F87AF43.4070705@gmx.net> <3F8819FE.7010605@tenebras.com> In-Reply-To: <3F8819FE.7010605@tenebras.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new cc: freebsd-stable@FreeBSD.org cc: freebsd-mozilla@FreeBSD.org cc: kde@FreeBSD.org cc: freebsd-gnome@FreeBSD.org cc: freebsd-hackers@FreeBSD.org Subject: Re: [kde-freebsd] Re: HEADS UP: pelase test/etc/libmap.conffeature on 4-stable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 15:21:19 -0000 Michael Sierchio wrote: > Michael Nottebrock wrote: > >> It's never too late to correct unfortunate decisions. :-) > > > Such as putting packages in /usr/local/lib/ ? I don't get it. -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 08:23:11 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD3B216A4BF for ; Sat, 11 Oct 2003 08:23:11 -0700 (PDT) Received: from tenebras.com (dnscache.tenebras.com [66.92.188.165]) by mx1.FreeBSD.org (Postfix) with SMTP id 82C9343FDF for ; Sat, 11 Oct 2003 08:23:07 -0700 (PDT) (envelope-from kudzu@tenebras.com) Received: (qmail 11231 invoked from network); 11 Oct 2003 15:23:07 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (192.168.188.241) by laptop.tenebras.com with SMTP; 11 Oct 2003 15:23:07 -0000 Message-ID: <3F88205A.8080501@tenebras.com> Date: Sat, 11 Oct 2003 08:23:06 -0700 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, zh-tw, zh-cn, fr, en, de-de MIME-Version: 1.0 To: kde@FreeBSD.org References: <20031008033536.7f6099b5.nork@FreeBSD.org> <20031009174211.GA364@zi025.glhnet.mhn.de> <20031011083235.087ecfc9.nork@FreeBSD.org> <200310110248.h9B2m3iR019297@sakura.ninth-nine.com> <3F87A447.8020901@gmx.net> <1065854516.6166.71.camel@shumai.marcuscom.com> <3F87AF43.4070705@gmx.net> <3F8819FE.7010605@tenebras.com> <3F881FEA.8070301@gmx.net> In-Reply-To: <3F881FEA.8070301@gmx.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-stable@FreeBSD.org cc: freebsd-mozilla@FreeBSD.org cc: freebsd-gnome@FreeBSD.org cc: freebsd-hackers@FreeBSD.org Subject: Re: [kde-freebsd] Re: HEADS UP: pelase test/etc/libmap.conffeature on 4-stable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 15:23:11 -0000 Michael Nottebrock wrote: >> Such as putting packages in /usr/local/lib/ ? > > > I don't get it. Me neither -- the practice of putting entire packages in /usr/local/lib from the ports, such as Mozilla, etc. From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 08:32:51 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E23416A4B3 for ; Sat, 11 Oct 2003 08:32:51 -0700 (PDT) Received: from mig.mig-29.net (dsl-200-78-45-52.prodigy.net.mx [200.78.45.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A2DD43FB1 for ; Sat, 11 Oct 2003 08:32:48 -0700 (PDT) (envelope-from mig@mig-29.net) Received: from mig.mig-29.net (localhost.mig-29.net [127.0.0.1]) by mig.mig-29.net (8.12.8p1/8.12.8) with ESMTP id h9BFUbID016255; Sat, 11 Oct 2003 10:30:37 -0500 (CDT) (envelope-from mig@mig.mig-29.net) Received: (from mig@localhost) by mig.mig-29.net (8.12.8p1/8.12.8/Submit) id h9BFUZ0J016254; Sat, 11 Oct 2003 10:30:35 -0500 (CDT) (envelope-from mig) Date: Sat, 11 Oct 2003 10:30:34 -0500 From: Manuel Rabade To: alex@bsdcoders.org Message-ID: <20031011153034.GA16225@mig-29.net> References: <200310101417.h9AEHb4n025071@www.kukulies.org> <20031011050618.GB61302@freebsd1.cimlogic.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031011050618.GB61302@freebsd1.cimlogic.com.au> User-Agent: Mutt/1.4.1i URL: http://www.mig-29.net/ cc: "C. Kukulies" cc: hackers@freebsd.org Subject: Re: smallest piece of hardware that runs *BSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 15:32:51 -0000 On Sat, Oct 11, 2003 at 03:06:18PM +1000, John Birrell wrote: > On Fri, Oct 10, 2003 at 04:17:37PM +0200, C. Kukulies wrote: > > Now, we are not far from that. I'm thinking of some CPU with TP Ethernet > > and memory of size of an USB stick. Anyone knowing such or having > > experience? > > Here's one the size of a credit card: . > It's a lot bigger than a 'bump in a cable', but it runs FreeBSD. From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 08:38:31 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B223516A4B3; Sat, 11 Oct 2003 08:38:31 -0700 (PDT) Received: from meitner.wh.uni-dortmund.de (meitner.wh.Uni-Dortmund.DE [129.217.129.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDC1743F75; Sat, 11 Oct 2003 08:38:29 -0700 (PDT) (envelope-from michaelnottebrock@gmx.net) Received: from lofi.dyndns.org (pc2-105.intern.meitner [10.3.12.105]) by meitner.wh.uni-dortmund.de (Postfix) with ESMTP id 0D8EE167698; Sat, 11 Oct 2003 17:38:29 +0200 (CEST) Received: from gmx.net (kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.12.9p1/8.12.9) with ESMTP id h9BFcSj4058743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Oct 2003 17:38:28 +0200 (CEST) (envelope-from michaelnottebrock@gmx.net) Message-ID: <3F8823F4.50108@gmx.net> Date: Sat, 11 Oct 2003 17:38:28 +0200 From: Michael Nottebrock User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, de-de MIME-Version: 1.0 To: Michael Sierchio References: <20031008033536.7f6099b5.nork@FreeBSD.org> <20031009174211.GA364@zi025.glhnet.mhn.de> <20031011083235.087ecfc9.nork@FreeBSD.org> <200310110248.h9B2m3iR019297@sakura.ninth-nine.com> <3F87A447.8020901@gmx.net> <1065854516.6166.71.camel@shumai.marcuscom.com> <3F87AF43.4070705@gmx.net> <3F8819FE.7010605@tenebras.com> <3F881FEA.8070301@gmx.net> <3F88205A.8080501@tenebras.com> In-Reply-To: <3F88205A.8080501@tenebras.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new cc: freebsd-hackers@freebsd.org cc: freebsd-mozilla@freebsd.org cc: kde@freebsd.org cc: freebsd-stable@freebsd.org cc: freebsd-gnome@freebsd.org Subject: Re: [kde-freebsd] Re: HEADS UP: pelase test/etc/libmap.conffeature on 4-stable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 15:38:31 -0000 Michael Sierchio wrote: > Michael Nottebrock wrote: > >>> Such as putting packages in /usr/local/lib/ ? >> >> >> >> I don't get it. > > > Me neither -- the practice of putting entire packages in > /usr/local/lib from the ports, such as Mozilla, etc. Oh. Heh, well. I guess sometimes we could use some kind of /opt after all. -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 08:41:01 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 572F516A4B3 for ; Sat, 11 Oct 2003 08:41:01 -0700 (PDT) Received: from tenebras.com (dnscache.tenebras.com [66.92.188.165]) by mx1.FreeBSD.org (Postfix) with SMTP id 2F8AB43FBF for ; Sat, 11 Oct 2003 08:40:54 -0700 (PDT) (envelope-from kudzu@tenebras.com) Received: (qmail 11471 invoked from network); 11 Oct 2003 15:40:53 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (192.168.188.241) by laptop.tenebras.com with SMTP; 11 Oct 2003 15:40:53 -0000 Message-ID: <3F882485.9090503@tenebras.com> Date: Sat, 11 Oct 2003 08:40:53 -0700 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, zh-tw, zh-cn, fr, en, de-de MIME-Version: 1.0 To: Joe Marcus Clarke References: <20031008033536.7f6099b5.nork@FreeBSD.org> <20031009174211.GA364@zi025.glhnet.mhn.de> <20031011083235.087ecfc9.nork@FreeBSD.org> <200310110248.h9B2m3iR019297@sakura.ninth-nine.com> <3F87A447.8020901@gmx.net> <1065854516.6166.71.camel@shumai.marcuscom.com> <3F87AF43.4070705@gmx.net> <3F8819FE.7010605@tenebras.com> <3F881FEA.8070301@gmx.net> <3F88205A.8080501@tenebras.com> <1065886543.15210.9.camel@shumai.marcuscom.com> In-Reply-To: <1065886543.15210.9.camel@shumai.marcuscom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-stable@freebsd.org cc: kde@freebsd.org cc: freebsd-mozilla@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: [kde-freebsd] Re: HEADS UP: pelase test/etc/libmap.conffeature on 4-stable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 15:41:01 -0000 Joe Marcus Clarke wrote: > On Sat, 2003-10-11 at 11:23, Michael Sierchio wrote: > >>Michael Nottebrock wrote: >> >> >>>>Such as putting packages in /usr/local/lib/ ? >>> >>> >>>I don't get it. >> >>Me neither -- the practice of putting entire packages in >>/usr/local/lib from the ports, such as Mozilla, etc. > > > Mozilla doesn't go into /usr/local/lib. It installs into > /usr/X11R6/lib/mozilla. Not on my planet. linux-mozilla (the native version hasn't been very compatible with java or other plugins) gets put in /usr/local/lib But /usr/X11R6/lib is just as "busted" -- thanks for making my point for me! From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 08:46:07 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E07A16A4C0 for ; Sat, 11 Oct 2003 08:46:07 -0700 (PDT) Received: from tenebras.com (dnscache.tenebras.com [66.92.188.165]) by mx1.FreeBSD.org (Postfix) with SMTP id 022A443FBF for ; Sat, 11 Oct 2003 08:46:03 -0700 (PDT) (envelope-from kudzu@tenebras.com) Received: (qmail 11546 invoked from network); 11 Oct 2003 15:46:02 -0000 Received: from sapphire.tenebras.com (HELO tenebras.com) (192.168.188.241) by laptop.tenebras.com with SMTP; 11 Oct 2003 15:46:02 -0000 Message-ID: <3F8825BA.8000703@tenebras.com> Date: Sat, 11 Oct 2003 08:46:02 -0700 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, zh-tw, zh-cn, fr, en, de-de MIME-Version: 1.0 To: Joe Marcus Clarke References: <20031008033536.7f6099b5.nork@FreeBSD.org> <20031009174211.GA364@zi025.glhnet.mhn.de> <20031011083235.087ecfc9.nork@FreeBSD.org> <200310110248.h9B2m3iR019297@sakura.ninth-nine.com> <3F87A447.8020901@gmx.net> <1065854516.6166.71.camel@shumai.marcuscom.com> <3F87AF43.4070705@gmx.net> <3F8819FE.7010605@tenebras.com> <3F881FEA.8070301@gmx.net> <3F88205A.8080501@tenebras.com> <1065886543.15210.9.camel@shumai.marcuscom.com> <3F882485.9090503@tenebras.com> <1065886966.15210.12.camel@shumai.marcuscom.com> In-Reply-To: <1065886966.15210.12.camel@shumai.marcuscom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-stable@freebsd.org cc: kde@freebsd.org cc: freebsd-mozilla@freebsd.org cc: freebsd-gnome@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: [kde-freebsd] Re: HEADS UP: pelase test/etc/libmap.conffeature on 4-stable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 15:46:07 -0000 Joe Marcus Clarke wrote: > What point? Okay, new rule: if you're going to complain about > something, include some supporting details, and a suggestion on how to > make things better. Point (I'll sharpen it) -- ../lib is for *what*? Libraries? Putting entire packages and executables in lib directories is a horrible kludge, at least as far as my *NIX experience goes (only back to 1979). From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 09:33:05 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B77116A4B3 for ; Sat, 11 Oct 2003 09:33:05 -0700 (PDT) Received: from mig.mig-29.net (dsl-200-78-45-52.prodigy.net.mx [200.78.45.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFF5043F85 for ; Sat, 11 Oct 2003 09:33:03 -0700 (PDT) (envelope-from mig@mig-29.net) Received: from mig.mig-29.net (localhost.mig-29.net [127.0.0.1]) by mig.mig-29.net (8.12.8p1/8.12.8) with ESMTP id h9BGUtID016488; Sat, 11 Oct 2003 11:30:55 -0500 (CDT) (envelope-from mig@mig.mig-29.net) Received: (from mig@localhost) by mig.mig-29.net (8.12.8p1/8.12.8/Submit) id h9BGUtgW016487; Sat, 11 Oct 2003 11:30:55 -0500 (CDT) (envelope-from mig) Date: Sat, 11 Oct 2003 11:30:54 -0500 From: Manuel Rabade To: wada@mig-29.net Message-ID: <20031011163054.GA15813@mig-29.net> References: <200310101417.h9AEHb4n025071@www.kukulies.org> <20031011050618.GB61302@freebsd1.cimlogic.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031011050618.GB61302@freebsd1.cimlogic.com.au> User-Agent: Mutt/1.4.1i URL: http://www.mig-29.net/ cc: "C. Kukulies" cc: hackers@freebsd.org Subject: Re: smallest piece of hardware that runs *BSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 16:33:05 -0000 On Sat, Oct 11, 2003 at 03:06:18PM +1000, John Birrell wrote: > On Fri, Oct 10, 2003 at 04:17:37PM +0200, C. Kukulies wrote: > > Now, we are not far from that. I'm thinking of some CPU with TP Ethernet > > and memory of size of an USB stick. Anyone knowing such or having > > experience? > > Here's one the size of a credit card: . > It's a lot bigger than a 'bump in a cable', but it runs FreeBSD. From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 12:13:58 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3494F16A4B3 for ; Sat, 11 Oct 2003 12:13:58 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8868443FD7 for ; Sat, 11 Oct 2003 12:13:54 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) h9BJDft2045925 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sat, 11 Oct 2003 21:13:43 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id h9BJDdS8098684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Oct 2003 21:13:40 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.10/8.12.10) with ESMTP id h9BJDd2u053416; Sat, 11 Oct 2003 21:13:39 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.10/8.12.10/Submit) id h9BJDc3A053415; Sat, 11 Oct 2003 21:13:38 +0200 (CEST) (envelope-from ticso) Date: Sat, 11 Oct 2003 21:13:38 +0200 From: Bernd Walter To: Dan Nelson Message-ID: <20031011191337.GK13791@cicely12.cicely.de> References: <20031010181349.GG13791@cicely12.cicely.de> <20031010182633.GD77306@dan.emsphone.com> <20031010183346.GH13791@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031010183346.GH13791@cicely12.cicely.de> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-CURRENT alpha User-Agent: Mutt/1.5.4i cc: freebsd-hackers@freebsd.org cc: ticso@cicely.de Subject: Re: setting sio to even parity failed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 19:13:58 -0000 On Fri, Oct 10, 2003 at 08:33:46PM +0200, Bernd Walter wrote: > On Fri, Oct 10, 2003 at 01:26:33PM -0500, Dan Nelson wrote: > > In the last episode (Oct 10), Bernd Walter said: > > > buf.c_iflag |= IGNBRK; > > > buf.c_cflag &= ~(CSIZE | PARODD); > > > buf.c_cflag |= CS8 | CLOCAL | PARENB; > > > > Do you maybe want CS7 here? > > No I need 8e1, but the output still looks like 8n1. It was a programming fault on the receiver side. Receive errors were not handled so the result was identicaly to 8n1. Now things work fine for me. With the same constellation I noticed that sending bytes have an unreliable timing. It's a modbus RTU case were packet end is signaled with 1.5 data words idle time. Because of a programming error on the other site I only checked for 0.5 data words idle and this triggered about 50% within transmission of 8 bytes at 19200bps - it always happened after the 5th byte. Now with correct 1.5 handling everything seems to be OK, but that only says that I'm not far away from the edge. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 14:18:33 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F69716A4B3 for ; Sat, 11 Oct 2003 14:18:33 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC19443F3F for ; Sat, 11 Oct 2003 14:18:31 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9p2/8.12.9) with ESMTP id h9BLI9E7026644; Sat, 11 Oct 2003 15:18:09 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 11 Oct 2003 15:17:13 -0600 (MDT) Message-Id: <20031011.151713.93584643.imp@bsdimp.com> To: ticso@cicely.de, ticso@cicely12.cicely.de From: "M. Warner Losh" In-Reply-To: <20031010183346.GH13791@cicely12.cicely.de> References: <20031010181349.GG13791@cicely12.cicely.de> <20031010182633.GD77306@dan.emsphone.com> <20031010183346.GH13791@cicely12.cicely.de> X-Mailer: Mew version 2.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org cc: dnelson@allantgroup.com Subject: Re: setting sio to even parity failed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 21:18:33 -0000 In message: <20031010183346.GH13791@cicely12.cicely.de> Bernd Walter writes: : On Fri, Oct 10, 2003 at 01:26:33PM -0500, Dan Nelson wrote: : > In the last episode (Oct 10), Bernd Walter said: : > > buf.c_iflag |= IGNBRK; : > > buf.c_cflag &= ~(CSIZE | PARODD); : > > buf.c_cflag |= CS8 | CLOCAL | PARENB; : > : > Do you maybe want CS7 here? : : No I need 8e1, but the output still looks like 8n1. 8e1? You want 8 data bits plus a nineth parity bit? Warner From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 14:19:35 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0293616A4B3; Sat, 11 Oct 2003 14:19:35 -0700 (PDT) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 445A743FB1; Sat, 11 Oct 2003 14:19:33 -0700 (PDT) (envelope-from kientzle@acm.org) Received: from acm.org ([66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id h9BLJWkX053390; Sat, 11 Oct 2003 14:19:32 -0700 (PDT) (envelope-from kientzle@acm.org) Message-ID: <3F8873E3.1070403@acm.org> Date: Sat, 11 Oct 2003 14:19:31 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce M Simpson References: <20031008083059.GA520@garage.freebsd.pl> <20031008114506.I63940@beagle.fokus.fraunhofer.de> <20031008101251.GG6524@saboteur.dek.spc.org> <3F875172.5010309@acm.org> <3F8795A9.5020409@acm.org> <20031011081822.GA679@saboteur.dek.spc.org> In-Reply-To: <20031011081822.GA679@saboteur.dek.spc.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org cc: hsu@freebsd.org cc: rwatson@freebsd.org Subject: Re: Dynamic reads without locking. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kientzle@acm.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 21:19:35 -0000 Bruce M Simpson wrote: > On Fri, Oct 10, 2003 at 10:31:21PM -0700, Tim Kientzle wrote: > >>On further inspection, I'm pretty sure that sys/kern/subr_devstat.c >>is not correct. > > OK. What about the shared page interface? Specifically the comment > above devstat_end_transaction(). I'm not entirely happy about it, but maybe I just need to study it more. The atomic* operations here are implementing a partial lock. What's not entirely clear to me is whether it's sufficient or not. The fact that the transaction interface is using a different locking mechanism than the rest of the code is suspicious. > The generation count is used by > the old sysctl interface. The shared page interface has a liberal > sprinkling of atomic*() instructions. Back when I was following the Java threading mailing list, I saw a lot of "what about this" examples that I studied and lots of other people studied, and it often took a long time for someone to figure out why it was wrong. And, for as long as I was following the list, it was _always_ wrong. Every single trick for eliminating locks that someone came up with didn't work. Usually, the problem was some compiler optimization, processor optimization, or cache behavior that would break the code. Using generation counts in sysctl code makes perfect sense as a tool for notifying user space whether something has changed since they last checked. Using it as a tool to eliminate locking is another thing entirely. Tim From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 14:44:13 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FE6616A4B3 for ; Sat, 11 Oct 2003 14:44:13 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB2C24400D for ; Sat, 11 Oct 2003 14:43:51 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) h9BLhYt2047609 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sat, 11 Oct 2003 23:43:37 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id h9BLhWS8028319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Oct 2003 23:43:33 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.10/8.12.10) with ESMTP id h9BLhV2u053972; Sat, 11 Oct 2003 23:43:32 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.10/8.12.10/Submit) id h9BLhV8G053971; Sat, 11 Oct 2003 23:43:31 +0200 (CEST) (envelope-from ticso) Date: Sat, 11 Oct 2003 23:43:31 +0200 From: Bernd Walter To: "M. Warner Losh" Message-ID: <20031011214330.GL13791@cicely12.cicely.de> References: <20031010181349.GG13791@cicely12.cicely.de> <20031010182633.GD77306@dan.emsphone.com> <20031010183346.GH13791@cicely12.cicely.de> <20031011.151713.93584643.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031011.151713.93584643.imp@bsdimp.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-CURRENT alpha User-Agent: Mutt/1.5.4i cc: ticso@cicely12.cicely.de cc: freebsd-hackers@freebsd.org cc: dnelson@allantgroup.com cc: ticso@cicely.de Subject: Re: setting sio to even parity failed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 21:44:13 -0000 On Sat, Oct 11, 2003 at 03:17:13PM -0600, M. Warner Losh wrote: > In message: <20031010183346.GH13791@cicely12.cicely.de> > Bernd Walter writes: > : On Fri, Oct 10, 2003 at 01:26:33PM -0500, Dan Nelson wrote: > : > In the last episode (Oct 10), Bernd Walter said: > : > > buf.c_iflag |= IGNBRK; > : > > buf.c_cflag &= ~(CSIZE | PARODD); > : > > buf.c_cflag |= CS8 | CLOCAL | PARENB; > : > > : > Do you maybe want CS7 here? > : > : No I need 8e1, but the output still looks like 8n1. > > 8e1? You want 8 data bits plus a nineth parity bit? Exactly - 11 bit-times per dataword. But the problem is already identified and was not on the FreeBSD side as I wrote in another mail. Now I'm worried with the sending timing - maybe I should switch to uftdi based serials, because they have large fifos and also have a transmitter enable output for half-duplex operation. Currently I handle transmitter enabling via RTS line from userland, which leaves a potential for not having the transmitter disabled when the accessed slave answers. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 15:30:45 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63DC416A4B3 for ; Sat, 11 Oct 2003 15:30:45 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EBA843FBD for ; Sat, 11 Oct 2003 15:30:43 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) h9BMTnt2048160 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sun, 12 Oct 2003 00:29:58 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id h9BMTjS8042078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Oct 2003 00:29:45 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.10/8.12.10) with ESMTP id h9BMTj2u054164; Sun, 12 Oct 2003 00:29:45 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.10/8.12.10/Submit) id h9BMThQv054163; Sun, 12 Oct 2003 00:29:43 +0200 (CEST) (envelope-from ticso) Date: Sun, 12 Oct 2003 00:29:43 +0200 From: Bernd Walter To: John Birrell Message-ID: <20031011222942.GM13791@cicely12.cicely.de> References: <200310101417.h9AEHb4n025071@www.kukulies.org> <20031011050618.GB61302@freebsd1.cimlogic.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20031011050618.GB61302@freebsd1.cimlogic.com.au> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-CURRENT alpha User-Agent: Mutt/1.5.4i cc: "C. Kukulies" cc: hackers@freebsd.org Subject: Re: smallest piece of hardware that runs *BSD? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2003 22:30:45 -0000 On Sat, Oct 11, 2003 at 03:06:18PM +1000, John Birrell wrote: > On Fri, Oct 10, 2003 at 04:17:37PM +0200, C. Kukulies wrote: > > Now, we are not far from that. I'm thinking of some CPU with TP Ethernet > > and memory of size of an USB stick. Anyone knowing such or having > > experience? > > Here's one the size of a credit card: . > It's a lot bigger than a 'bump in a cable', but it runs FreeBSD. Leaves the question how much of the data on that page is correct. The elan chip is 486 class as we all know from soekris systems. At least it's smaller for shure. Unless you want to stick with FreeBSD you could also go NetBSD/ARM or embedded IP with a 8 bit µC. I asume the later could be done in the 30x30mm Range with Ethernet. Currently I do much smaller with slip. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 20:08:07 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 794AC16A4B3 for ; Sat, 11 Oct 2003 20:08:07 -0700 (PDT) Received: from doom.homeunix.org (8-075.dialup.comset.net [213.172.8.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8361343F3F for ; Sat, 11 Oct 2003 20:05:43 -0700 (PDT) (envelope-from igor@doom.homeunix.org) Received: from doom.homeunix.org (localhost [127.0.0.1]) by doom.homeunix.org (8.12.9p2/8.12.9) with ESMTP id h9C2w6Yg002189; Sun, 12 Oct 2003 07:00:17 +0400 (MSD) (envelope-from igor@doom.homeunix.org) Received: (from igor@localhost) by doom.homeunix.org (8.12.9p2/8.12.9/Submit) id h9C2uwgu002186; Sun, 12 Oct 2003 06:56:58 +0400 (MSD) (envelope-from igor) Date: Sun, 12 Oct 2003 06:56:58 +0400 From: Igor Pokrovsky To: Daniel Lang Message-ID: <20031012025658.GA1994@doom.homeunix.org> Mail-Followup-To: Daniel Lang , hackers@freebsd.org References: <20031009154030.GI2407@atrbg11.informatik.tu-muenchen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031009154030.GI2407@atrbg11.informatik.tu-muenchen.de> User-Agent: Mutt/1.4.1i X-Accept-Language: ru X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on doom.homeunix.org cc: hackers@freebsd.org Subject: Re: Matrox Parhelia XFree86 Busmastering kernel module? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Igor Pokrovsky List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2003 03:08:07 -0000 On Thu, Oct 09, 2003 at 05:40:30PM +0200, Daniel Lang wrote: > Hiho, > > There seems no freebsd-xfree list, but this is only XFree related, > it's rather kernel oriented. > > Matrox offers a RedHat-Linux driver for their Parhelia based boards > (Parhelia, P650, P750). The XFree86 driver module mtx_drv.o itself > is OS independent and works with FreeBSD, as successfully > tested on my desk, even with a multihead configuration. :) > > Alas, to use acceleration (2D xaa as well as 3D dri, OpenGL, > etc) it requires a kernel module to enable bus mastering on > the card. (I don't know if this is a common thing with Linux, > or with some graphic boards? I am not aware of bus mastering > is required for AGP boards, isn't AGP a dedicated bus anyway?) AFAIK, you can enable bus mastering using pciconf(8) by setting appropriate registers. Why do you need any additional kernel module? Or I'm completely missing the point? -ip -- Ask not for whom the telephone bell tolls ... if thou art in the bathtub, it tolls for thee. From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 20:44:59 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D254616A4C0 for ; Sat, 11 Oct 2003 20:44:59 -0700 (PDT) Received: from lewis.lclark.edu (lclark.edu [149.175.1.5]) by mx1.FreeBSD.org (Postfix) with SMTP id 0AE1543FB1 for ; Sat, 11 Oct 2003 20:44:59 -0700 (PDT) (envelope-from eta@lclark.edu) Received: from [149.175.34.250] ([149.175.34.250]) by lewis.lclark.edu (SAVSMTP 3.1.1.32) with SMTP id M2003101120445200501 ; Sat, 11 Oct 2003 20:44:52 -0700 From: Eric Anholt To: Igor Pokrovsky In-Reply-To: <20031012025658.GA1994@doom.homeunix.org> References: <20031009154030.GI2407@atrbg11.informatik.tu-muenchen.de> <20031012025658.GA1994@doom.homeunix.org> Content-Type: text/plain Message-Id: <1065930291.642.28.camel@leguin> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 11 Oct 2003 20:44:51 -0700 Content-Transfer-Encoding: 7bit cc: "hackers@FreeBSD.ORG" cc: Daniel Lang Subject: Re: Matrox Parhelia XFree86 Busmastering kernel module? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Oct 2003 03:44:59 -0000 On Sat, 2003-10-11 at 19:56, Igor Pokrovsky wrote: > On Thu, Oct 09, 2003 at 05:40:30PM +0200, Daniel Lang wrote: > > Hiho, > > > > There seems no freebsd-xfree list, but this is only XFree related, > > it's rather kernel oriented. > > > > Matrox offers a RedHat-Linux driver for their Parhelia based boards > > (Parhelia, P650, P750). The XFree86 driver module mtx_drv.o itself > > is OS independent and works with FreeBSD, as successfully > > tested on my desk, even with a multihead configuration. :) > > > > Alas, to use acceleration (2D xaa as well as 3D dri, OpenGL, > > etc) it requires a kernel module to enable bus mastering on > > the card. (I don't know if this is a common thing with Linux, > > or with some graphic boards? I am not aware of bus mastering > > is required for AGP boards, isn't AGP a dedicated bus anyway?) > > AFAIK, you can enable bus mastering using pciconf(8) by setting appropriate registers. > Why do you need any additional kernel module? Or I'm completely missing the point? > > -ip Busmastering is not an important part of kernel modules used for aiding accelerating graphics, if it is at all. Notably, XFree86 enables busmastering itself for all the cards it supports that need it (radeon, r128, mga, i8x0, etc.). What that module is more likely for is doing things that require kernel support, such as handling of interrupts to efficiently use the card's DMA support and sharing of resources between various competing direct-rendering clients. I'm not aware of anyone working on Matrox binary driver support. -- Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org