From owner-freebsd-hackers Sun Apr 23 1: 6: 6 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from corinth.bossig.com (mail.dohboys.com [208.26.253.10]) by hub.freebsd.org (Postfix) with ESMTP id 277F337B595 for ; Sun, 23 Apr 2000 01:06:02 -0700 (PDT) (envelope-from kstewart@3-cities.com) Received: from 3-cities.com (unverified [208.26.242.92]) by corinth.bossig.com (Rockliffe SMTPRA 4.2.1) with ESMTP id ; Sun, 23 Apr 2000 01:10:14 -0700 Message-ID: <3902AEE3.C4E64476@3-cities.com> Date: Sun, 23 Apr 2000 01:05:55 -0700 From: Kent Stewart Organization: Columbia Basin Virtual Community Project X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Michael Bacarella , Alfred Perlstein , Kevin Day , hackers@FreeBSD.ORG Subject: Re: Double buffered cp(1) References: <200004221736.KAA55484@apollo.backplane.com> <3901F277.66DDDDAF@3-cities.com> <200004222317.QAA56834@apollo.backplane.com> <39026874.F652A405@3-cities.com> <200004230625.XAA58076@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > > :You are right but that is because I haven't started keeping record on > :4.0-Stable and we were comparing apples and oranges. A buildworld of > :3.4-Stable required around 2000u seconds using gcc-2.8.2 on my system. > :Setiathome, which is running at a nice of 19, still consumed 90% of > :the cpu. A buildworld on 4.0-Stable required 3500u seconds using > :gcc-2.95.2 and setiathome didn't accrue any appreciable cpu time > :during the build. There were definitely some changes there :). > : > :Kent > : > :-- > :Kent Stewart > :Richland, WA > > Both 3.4 and 4.0 buildworlds are cpu-bound. If you are trying to test > buildworlds, then don't run setiathome (or anything else) while doing > the test... it will skew the results of your tests due to differences > between the 3.4 and 4.x schedulers (specifically, various scheduler > bugs were fixed in 4.x that effect niced cpu-bound background programs > such as setiathome, giving them way, way too much cpu). The bugs were fixed in 4.0? What I saw was far too much cpu going to setiathome on 3.4. Seti hardly ran on 4.0. I don't have quantities because I have only noticed the really large increase in cpu time required to build 4.0. The wall clock time on a buildworld hardly changed (55-60 minutes) whether I ran seti or not on 3.4. I can watch the wall clock time on some of my future builds and see how they are skewed by stopping seti before I being the buildworld. I just haven't got 4.0 to the capability I had with with 3.4 before I tried to upgrade to 4.0 and it died in the middle of creating the installkernel. The rest of the system was pretty much broken at that point and I used the opportunity to restructure everything. It has been a good check on some of the ports because I found a few that assumed you have things like Bison, automake, and autoconf installed and I didn't. > > It is simply impossible to fairly measure I/O performance in the > presence of unrelated background-running programs, especially under 3.x. > And even though 4.x does a better job of it, it will still skew the > results. I was looking at this as more of a real world setup simulation. Seti is almost pure cpu and the buildworld used everything else. I ran the build world from an x-term and from the command line. That didn't seem to matter much. The system also provided my dialup and nat'ing for my internal network. Seti was run from a script that was started from an login before I did my startx. It would chug along from one network problem at Berkeley until the next one with out any intervention on my part. The system was on a UPS and didn't go down on the occasional 1 or 2 second long power outages. Between the two codes, they mimic most of the types of calculations I've been associated with for many years. I have people that are using Windows 9x machines and I think they would be better off with something like FreeBSD. The programs were developed in unix environment. A lot of users are using Linux. Some are using PVM to combine systems into a single parallel virtual calculation. Lehey Fortran-90(77) running on Win9x with their protected mode interface setup has to be a terrible choice. The problem is proving it and providing an alternative :). A couple would run better on a scsi because of the queued read/write I/O that you identified. You can say anything is a POS but people won't listen unless you can show them a better way. I'm retired and no longer have a contract manager to answer to and can experiment. Cheers, Kent > > -Matt -- Kent Stewart Richland, WA mailto:kstewart@3-cities.com http://www.3-cities.com/~kstewart/index.html FreeBSD News http://daily.daemonnews.org/ SETI(Search for Extraterrestrial Intelligence) @ HOME http://setiathome.ssl.berkeley.edu/ Hunting Archibald Stewart, b 1802 in Ballymena, Antrim Co., NIR http://www.3-cities.com/~kstewart/genealogy/archibald_stewart.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 23 7:10:54 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from dc.ispro.net (c14pc21.dc.turkuamk.fi [193.166.135.246]) by hub.freebsd.org (Postfix) with ESMTP id 299CD37B8EE for ; Sun, 23 Apr 2000 07:10:41 -0700 (PDT) (envelope-from yurtesen@dc.ispro.net) Received: from localhost (yurtesen@localhost) by dc.ispro.net (8.9.3/8.9.3) with ESMTP id RAA95510 for ; Sun, 23 Apr 2000 17:10:35 +0300 (EEST) (envelope-from yurtesen@dc.ispro.net) Date: Sun, 23 Apr 2000 17:10:35 +0300 (EEST) From: Evren Yurtesen To: freebsd-hackers@freebsd.org Subject: bind and the limit of serial number ??? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, is the bind have 32 bit unsigned integer variable for the serial number part of the dns records? if yes, it means that we cant have a number bigger than 4294967296 right? what happens if we have a bigger number? then bind takes it like modulus 2^32? or it is forbidden to have a bigger number? Thanks! Evren Yurtesen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 23 9:25:50 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from eeyore.local.dohd.cx (d0030.dtk.chello.nl [213.46.0.30]) by hub.freebsd.org (Postfix) with ESMTP id D4F0437B5DB for ; Sun, 23 Apr 2000 09:25:45 -0700 (PDT) (envelope-from freebsd@dohd.cx) Received: from tiggr.local.dohd.cx (tiggr.local.dohd.cx [::ffff:10.0.0.10]) by eeyore.local.dohd.cx (Postfix+IPv6) with ESMTP id 9A118BAB3; Sun, 23 Apr 2000 18:25:29 +0200 (MET DST) Received: by tiggr.local.dohd.cx (Postfix, from userid 1008) id BDA235D45; Sun, 23 Apr 2000 18:25:28 +0200 (CEST) Date: Sun, 23 Apr 2000 18:25:28 +0200 From: Mark Huizer To: Greg Lehey Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Debugging kernel data Message-ID: <20000423182528.A58150@dohd.cx> References: <20000413132050.D43342@dohd.cx> <20000423114218.H4675@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.4i In-Reply-To: <20000423114218.H4675@freebie.lemis.com>; from grog@lemis.com on Sun, Apr 23, 2000 at 11:42:18AM +0930 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Apr 23, 2000 at 11:42:18AM +0930, Greg Lehey wrote: > On Thursday, 13 April 2000 at 13:20:50 +0200, Mark Huizer wrote: > > Hi > > > > I'm trying to debug a kernel that is not crashing but hanging, with all > > processes in 'inode' wchan. So I did a 'call panic()', and now I have > > the crashdump, but is there a way to get to the data structures of the > > kernel??? > > Sure. What are you looking for? Have you read the section on kernel > debugging in the handbook? > Yep, done that kind of stuff before, but never on non-crashing kernels :-( Problem is I want to get at the stacks of various running processes, and the syscalls they are making. I started using the vinum gdb macros, which got me a bit further, though not yet enough, I'm afraid. Mark -- Nice testing in little China... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 23 10:11:47 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from dc.ispro.net (c14pc21.dc.turkuamk.fi [193.166.135.246]) by hub.freebsd.org (Postfix) with ESMTP id B6AAE37B691 for ; Sun, 23 Apr 2000 10:11:43 -0700 (PDT) (envelope-from yurtesen@dc.ispro.net) Received: from localhost (yurtesen@localhost) by dc.ispro.net (8.9.3/8.9.3) with ESMTP id UAA95681; Sun, 23 Apr 2000 20:11:36 +0300 (EEST) (envelope-from yurtesen@dc.ispro.net) Date: Sun, 23 Apr 2000 20:11:36 +0300 (EEST) From: Evren Yurtesen To: Dave Dunaway Cc: freebsd-hackers@freebsd.org Subject: Re: bind and the limit of serial number ??? In-Reply-To: <20000423112259.A14653@nivek.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG well ours is still working fine ! thats why I asked this question, we did not realize that it went over 32 bit boundary how can I understand if there is a problem or not? Evren On Sun, 23 Apr 2000, Dave Dunaway wrote: > > Put a number bigger than 2^32 and it will overflows. > > > is the bind have 32 bit unsigned integer variable for the serial > > number part of the dns records? > > if yes, it means that we cant have a number bigger than > > 4294967296 right? what happens if we have a bigger number? > > then bind takes it like modulus 2^32? or it is forbidden to > > have a bigger number? > > -- > > Dave. > > > Dave Dunaway > bela@nivek.org > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 23 10:16:38 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.internet.dk (ns.internet.dk [194.19.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 182B737B9C0 for ; Sun, 23 Apr 2000 10:16:34 -0700 (PDT) (envelope-from leifn@neland.dk) Received: (from uucp@localhost) by ns.internet.dk (8.9.2/8.9.3) with UUCP id TAA26740; Sun, 23 Apr 2000 19:16:25 +0200 (CEST) (envelope-from leifn@neland.dk) Received: from localhost (localhost [127.0.0.1]) by arnold.neland.dk (8.9.3/8.9.3) with ESMTP id TAA20143; Sun, 23 Apr 2000 19:16:05 +0200 (CEST) (envelope-from leifn@neland.dk) Date: Sun, 23 Apr 2000 19:16:05 +0200 (CEST) From: Leif Neland To: Evren Yurtesen Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: bind and the limit of serial number ??? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 23 Apr 2000, Evren Yurtesen wrote: > Hello, > > is the bind have 32 bit unsigned integer variable for the serial > number part of the dns records? > if yes, it means that we cant have a number bigger than > 4294967296 right? Somewhere I read something like: "The format YYYYMMDDnn" is often used for the serial number. We know this wil break in the year 4294, but we are not worried about that." > what happens if we have a bigger number? > then bind takes it like modulus 2^32? I once put in an extra digit in the serial number. This made a secondary use a serial number, which was larger than mine, and could probably be the modulus 2^32. I had to call the hostmaster there (A "3.rd secondary" hosted at our uplink) to get the zonefile removed, so the right one would be reloaded. > or it is forbidden to > have a bigger number? Not only forbidden, impossible... Leif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 23 10:25:13 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 287B637B5DB for ; Sun, 23 Apr 2000 10:25:09 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id NAA05878; Sun, 23 Apr 2000 13:24:52 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Sun, 23 Apr 2000 13:24:51 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Bill Fenner Cc: dmlb@ragnet.demon.co.uk, freebsd-hackers@freebsd.org Subject: Re: Help with SIOCADDMULTI, IFF_ALLMULTI and IFF_PROMISC In-Reply-To: <200004212325.QAA24912@windsor.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 21 Apr 2000, Bill Fenner wrote: > >What should I do when I see ALLMULTI? > > You should go promiscuous to multicast. If the card doesn't support > that, you should go fully promiscuous and drop unicasts that aren't > to you. (Make sure you don't block packets that bpf is going to > want to see). Also, if you want bridging support, you have to bridge before doing the filtering. Really, the filtering on ``appropriateness'' should only occur when the packet is about to enter ether_input(). Speaking of which, I'd really like to see bridge support getting added to all new NIC drivers from now on. However, the current bridge interface leaves something to be desired... Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 23 10:37:25 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 9035F37B582 for ; Sun, 23 Apr 2000 10:37:22 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA62365; Sun, 23 Apr 2000 10:37:20 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Apr 2000 10:37:20 -0700 (PDT) From: Matthew Dillon Message-Id: <200004231737.KAA62365@apollo.backplane.com> To: Kent Stewart Cc: Michael Bacarella , Alfred Perlstein , Kevin Day , hackers@FreeBSD.ORG Subject: Re: Double buffered cp(1) References: <200004221736.KAA55484@apollo.backplane.com> <3901F277.66DDDDAF@3-cities.com> <200004222317.QAA56834@apollo.backplane.com> <39026874.F652A405@3-cities.com> <200004230625.XAA58076@apollo.backplane.com> <3902AEE3.C4E64476@3-cities.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :The bugs were fixed in 4.0? What I saw was far too much cpu going to :setiathome on 3.4. Seti hardly ran on 4.0. I don't have quantities :because I have only noticed the really large increase in cpu time :required to build 4.0. The wall clock time on a buildworld hardly :changed (55-60 minutes) whether I ran seti or not on 3.4. I can watch :the wall clock time on some of my future builds and see how they are I don't know what your setup is, Kent, but when I do a buildworld my system is 95% cpu bound, with virtual no idle time at all. It's all going to the buildworld. On both 3.x and 4.x. Try mounting /usr/obj with softupdates turned on, and if your /tmp is not a softupdates partition then make sure you are building with -pipe in /etc/make.conf: (For 3.x) CFLAGS= -O2 -pipe (For 4.x) CFLAGS= -Os -pipe :I was looking at this as more of a real world setup simulation. Seti :is almost pure cpu and the buildworld used everything else. I ran the :build world from an x-term and from the command line. That didn't seem :to matter much. The system also provided my dialup and nat'ing for my :internal network. Seti was run from a script that was started from an : login before I did my startx. It would chug along from one :network problem at Berkeley until the next one with out any Seti does almost no I/O, which means that in general it will have a much lower scheduling priority then even a cpu-bound buildworld. Most people run seti niced to +20, which means that it does not run at all if there are other 'normal' processes using the cpu. Under 3.x this was broken - seti got cpu when it shouldn't have. Under 4.x this is fixed. If you run a cpu-bound process niced to +20 it will get very little cpu in the face of other unniced cpu-bound processing. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 23 10:57:33 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.internet.dk (ns.internet.dk [194.19.140.1]) by hub.freebsd.org (Postfix) with ESMTP id A28DC37B9C2 for ; Sun, 23 Apr 2000 10:57:28 -0700 (PDT) (envelope-from leifn@neland.dk) Received: (from uucp@localhost) by ns.internet.dk (8.9.2/8.9.3) with UUCP id TAA27936; Sun, 23 Apr 2000 19:57:19 +0200 (CEST) (envelope-from leifn@neland.dk) Received: from localhost (localhost [127.0.0.1]) by arnold.neland.dk (8.9.3/8.9.3) with ESMTP id TAA33192; Sun, 23 Apr 2000 19:39:22 +0200 (CEST) (envelope-from leifn@neland.dk) Date: Sun, 23 Apr 2000 19:39:22 +0200 (CEST) From: Leif Neland To: Evren Yurtesen Cc: Dave Dunaway , freebsd-hackers@FreeBSD.ORG Subject: Re: bind and the limit of serial number ??? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG You can not be sure your secondary dns servers are picking up your zonefile, when you update the primary. On Sun, 23 Apr 2000, Evren Yurtesen wrote: > well ours is still working fine ! > thats why I asked this question, we did not realize that it went over 32 > bit boundary > how can I understand if there is a problem or not? > Evren > > On Sun, 23 Apr 2000, Dave Dunaway wrote: > > > > > Put a number bigger than 2^32 and it will overflows. > > > > > is the bind have 32 bit unsigned integer variable for the serial > > > number part of the dns records? > > > if yes, it means that we cant have a number bigger than > > > 4294967296 right? what happens if we have a bigger number? > > > then bind takes it like modulus 2^32? or it is forbidden to > > > have a bigger number? > > > > -- > > > > Dave. > > > > > > Dave Dunaway > > bela@nivek.org > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 23 11: 5:45 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 28BF037B9C2 for ; Sun, 23 Apr 2000 11:05:43 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA62689; Sun, 23 Apr 2000 11:05:33 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Apr 2000 11:05:33 -0700 (PDT) From: Matthew Dillon Message-Id: <200004231805.LAA62689@apollo.backplane.com> To: Leif Neland Cc: Evren Yurtesen , Dave Dunaway , freebsd-hackers@FreeBSD.ORG Subject: Re: bind and the limit of serial number ??? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :You can not be sure your secondary dns servers are picking up your :zonefile, when you update the primary. : You can 'reset' (roll-over) the serial number, but when you do so you have to realize that the secondaries may continue to cache the 'old' version of the zone file all the way up to the expiration time of the zone in the SOA (normally 3-days to a week). For manual updates of the zone file, I recommend using yyyymmdd rather then yyyymmddhhmm, and if you modify it twice in one day just increment the day (and hopefully real time will catch up to it again). For automatic updates (i.e. scripts that update zone files), I recommend simply starting the serial number at 1 and incrementing it on every update. Trying to make the serial number into a date for viewing ease is overrated. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 23 11:32:51 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.targetnet.com (mail.targetnet.com [207.245.246.3]) by hub.freebsd.org (Postfix) with ESMTP id 6A22F37B58F for ; Sun, 23 Apr 2000 11:32:44 -0700 (PDT) (envelope-from james@targetnet.com) Received: from james by mail.targetnet.com with local (Exim 3.02 #1) id 12jRBA-000DSI-00; Sun, 23 Apr 2000 14:32:24 -0400 Date: Sun, 23 Apr 2000 14:32:24 -0400 From: James FitzGibbon To: Leif Neland Cc: Evren Yurtesen , freebsd-hackers@FreeBSD.ORG Subject: Re: bind and the limit of serial number ??? Message-ID: <20000423143224.C26932@targetnet.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre1i In-Reply-To: Organization: Targetnet.com Inc. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Leif Neland (leifn@neland.dk) [000423 13:17]: > I once put in an extra digit in the serial number. > This made a secondary use a serial number, which was larger than mine, and > could probably be the modulus 2^32. > I had to call the hostmaster there (A "3.rd secondary" hosted at our > uplink) to get the zonefile removed, so the right one would be reloaded. Just FYI: if you make the serial number of a zone '0', secondary servers (bind at least) will *always* grab the zone from the master. It's intended to fix just the situation you had; set the serial to 0, leave it that way until all the slaves have picked up the new zone, then start using the proper numbering scheme again. It wastes bandwidth for a while if you have a large number of secondaries and/or a low refresh time, but it lets you fix a type without human intervention. -- j. James FitzGibbon james@targetnet.com Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 23 12:43: 8 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id BCC6037B674 for ; Sun, 23 Apr 2000 12:42:55 -0700 (PDT) (envelope-from sthaug@nethelp.no) Received: (qmail 58855 invoked by uid 1001); 23 Apr 2000 19:42:53 +0000 (GMT) To: james@targetnet.com Cc: leifn@neland.dk, yurtesen@dc.ispro.net, freebsd-hackers@FreeBSD.ORG Subject: Re: bind and the limit of serial number ??? From: sthaug@nethelp.no In-Reply-To: Your message of "Sun, 23 Apr 2000 14:32:24 -0400" References: <20000423143224.C26932@targetnet.com> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sun, 23 Apr 2000 21:42:53 +0200 Message-ID: <58853.956518973@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I once put in an extra digit in the serial number. > > This made a secondary use a serial number, which was larger than mine, and > > could probably be the modulus 2^32. > > I had to call the hostmaster there (A "3.rd secondary" hosted at our > > uplink) to get the zonefile removed, so the right one would be reloaded. > > Just FYI: if you make the serial number of a zone '0', secondary servers > (bind at least) will *always* grab the zone from the master. It's intended > to fix just the situation you had; set the serial to 0, leave it that way > until all the slaves have picked up the new zone, then start using the > proper numbering scheme again. It wastes bandwidth for a while if you have > a large number of secondaries and/or a low refresh time, but it lets you fix > a type without human intervention. This is a BIND feature, and should not be relied on. From RFC 1982: Caution should also be exercised before causing the serial number to be set to the value zero. While this value is not in any way special in serial number arithmetic, or to the DNS SOA serial number, many DNS implementations have incorrectly treated zero as a special case, with special properties, and unusual behaviour may be expected if zero is used as a DNS SOA serial number. There are better methods if you need to lower the serial number. The standard method, which is guaranteed to work, is to increase the serial number by 2^31-1 on the primary (largest increase allowed by serial number arithmetic, se RFC 1982), wait one refresh period (then the slave will have picked up the new serial number), and *then* set it to the desired value. Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 23 13: 0:18 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from corinth.bossig.com (corinth.bossig.com [208.26.239.66]) by hub.freebsd.org (Postfix) with ESMTP id F27B937B59E for ; Sun, 23 Apr 2000 13:00:14 -0700 (PDT) (envelope-from kstewart@3-cities.com) Received: from 3-cities.com (unverified [208.26.241.252]) by corinth.bossig.com (Rockliffe SMTPRA 4.2.1) with ESMTP id ; Sun, 23 Apr 2000 13:04:18 -0700 Message-ID: <3903563C.6453A9E2@3-cities.com> Date: Sun, 23 Apr 2000 12:59:56 -0700 From: Kent Stewart Organization: Columbia Basin Virtual Community Project X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Michael Bacarella , Alfred Perlstein , Kevin Day , hackers@FreeBSD.ORG Subject: Re: Double buffered cp(1) References: <200004221736.KAA55484@apollo.backplane.com> <3901F277.66DDDDAF@3-cities.com> <200004222317.QAA56834@apollo.backplane.com> <39026874.F652A405@3-cities.com> <200004230625.XAA58076@apollo.backplane.com> <3902AEE3.C4E64476@3-cities.com> <200004231737.KAA62365@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > > :The bugs were fixed in 4.0? What I saw was far too much cpu going to > :setiathome on 3.4. Seti hardly ran on 4.0. I don't have quantities > :because I have only noticed the really large increase in cpu time > :required to build 4.0. The wall clock time on a buildworld hardly > :changed (55-60 minutes) whether I ran seti or not on 3.4. I can watch > :the wall clock time on some of my future builds and see how they are > > I don't know what your setup is, Kent, but when I do a buildworld > my system is 95% cpu bound, with virtual no idle time at all. It's > all going to the buildworld. On both 3.x and 4.x. It is on 4.x but it wasn't on 3.4. At least, seti was taking time that it shouldn't have been getting. > > Try mounting /usr/obj with softupdates turned on, and if your /tmp > is not a softupdates partition then make sure you are building with > -pipe in /etc/make.conf: > > (For 3.x) > > CFLAGS= -O2 -pipe > > (For 4.x) > > CFLAGS= -Os -pipe I am trying this right now. I thought that optimizing this way was dangerous for the kernel. The problem for the new people is what works and when. You have to understand that Murphy sits on my shoulder. If there are 2+ bugs in a product, I will eventually end up seeing one of them :). I have been going to turn on softupdates but haven't got there yet. I want to link /usr/obj to the scsi drive first. Then, I think I will try softupdates. Try the worst combo's first and then add features but write the times down when you try the different arrangements. If 50% of my Cray throughput was write behind caching, then softupdates could be an equal share on FreeBSD. A benchmark that ran in four hours versus eight hours is a big change. I don't have a good batch system but the speed of my FreeBSD systems have a lot going for them clock wise. The Cray had 16MW (128MB) of memory and that is pretty much a starter system now days. Kent -- Kent Stewart Richland, WA mailto:kstewart@3-cities.com http://www.3-cities.com/~kstewart/index.html FreeBSD News http://daily.daemonnews.org/ SETI(Search for Extraterrestrial Intelligence) @ HOME http://setiathome.ssl.berkeley.edu/ Hunting Archibald Stewart, b 1802 in Ballymena, Antrim Co., NIR http://www.3-cities.com/~kstewart/genealogy/archibald_stewart.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 23 13:22:34 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id C711E37B66B for ; Sun, 23 Apr 2000 13:22:28 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA64183; Sun, 23 Apr 2000 13:22:27 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Apr 2000 13:22:27 -0700 (PDT) From: Matthew Dillon Message-Id: <200004232022.NAA64183@apollo.backplane.com> To: Kent Stewart Cc: Michael Bacarella , Alfred Perlstein , Kevin Day , hackers@FreeBSD.ORG Subject: Re: Double buffered cp(1) References: <200004221736.KAA55484@apollo.backplane.com> <3901F277.66DDDDAF@3-cities.com> <200004222317.QAA56834@apollo.backplane.com> <39026874.F652A405@3-cities.com> <200004230625.XAA58076@apollo.backplane.com> <3902AEE3.C4E64476@3-cities.com> <200004231737.KAA62365@apollo.backplane.com> <3903563C.6453A9E2@3-cities.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :> I don't know what your setup is, Kent, but when I do a buildworld :> my system is 95% cpu bound, with virtual no idle time at all. It's :> all going to the buildworld. On both 3.x and 4.x. : :It is on 4.x but it wasn't on 3.4. At least, seti was taking time that :it shouldn't have been getting. Right. I think we're in agreement, it's just getting lost somewhere :-) :> (For 3.x) :> :> CFLAGS= -O2 -pipe :> :> (For 4.x) :> :> CFLAGS= -Os -pipe : :I am trying this right now. I thought that optimizing this way was :dangerous for the kernel. The problem for the new people is what works :and when. You have to understand that Murphy sits on my shoulder. If :there are 2+ bugs in a product, I will eventually end up seeing one of :them :). -O2 and -Os are 'safe'. Other optimization levels (-O3 for example) are *NOT* safe. Most machine-specific optimizations (-m options) should generally be considered NOT safe. :I have been going to turn on softupdates but haven't got there yet. I :want to link /usr/obj to the scsi drive first. Then, I think I will :try softupdates. Try the worst combo's first and then add features but :write the times down when you try the different arrangements. :... :Kent I also turn off atime updates ('noatime' mount option in /etc/fstab) on /usr/src, since buildworlds do a lot of file scanning and there is simply no reason to update every single file's inode with a new atime. I doubt it makes much of a difference but it does leave more clean buffer cache buffers available for other things. -pipe makes a significant difference since without it every source file being compiled creates several files in /tmp. Softupdates makes a significant difference in its ability to asynchronize file creation and meta-data updates (which helps /tmp as well as /usr/obj, though /tmp is helped even more by using -pipe). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 23 15:30:54 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by hub.freebsd.org (Postfix) with ESMTP id A253737B960 for ; Sun, 23 Apr 2000 15:30:47 -0700 (PDT) (envelope-from daemon@bigeye.rhein-neckar.de) Received: from bigeye.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id AAA08215 for freebsd-hackers@freebsd.org; Mon, 24 Apr 2000 00:30:44 +0200 (CEST) (envelope-from daemon@bigeye.rhein-neckar.de) Received: (from daemon@localhost) by bigeye.rhein-neckar.de (8.9.3/8.9.3) id AAA55227 for freebsd-hackers@freebsd.org; Mon, 24 Apr 2000 00:08:13 +0200 (CEST) (envelope-from daemon) From: naddy@mips.rhein-neckar.de (Christian Weisgerber) Subject: Re: Double buffered cp(1) Date: 24 Apr 2000 00:08:12 +0200 Message-ID: <8dvs8c$1ltd$1@bigeye.rhein-neckar.de> References: <200004231737.KAA62365@apollo.backplane.com> <3903563C.6453A9E2@3-cities.com> <200004232022.NAA64183@apollo.backplane.com> To: freebsd-hackers@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > -pipe makes a significant difference since without it every source > file being compiled creates several files in /tmp. Hasn't O'Brien recently said that in fact "-pipe" is already the default for our cc, so explicitly specifying the option doesn't do anything? -- Christian "naddy" Weisgerber naddy@mips.rhein-neckar.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 23 15:51:26 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 16E3437B57C for ; Sun, 23 Apr 2000 15:51:19 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Sun, 23 Apr 2000 18:51:16 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: hackers@FreeBSD.org Subject: commit MAKE_SHELL? Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-333593351-956530276=:46547" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-333593351-956530276=:46547 Content-Type: TEXT/PLAIN; charset=US-ASCII Some weeks ago, I made a small modification to make(1) so that it could be built to use a different shell for its work. It already seemed to have the idea at least partially thought out and in the code, so it was a naturally easy thing to finish implementing. The code will remain exactly the same unless you set the following (e.g. in make.conf): MAKE_SHELL=ksh Well, it's been sitting in my tree for a while now, and there have been 0 problems with it. I use the ports and build worlds extensively, not to mention having built everything which uses make(1) with this. The pdksh is more than sufficiently Bourne (or shall I say compatible? It's just a superset...) to support every single thing I've thrown at it. Of course, it would be possible to use the real ksh with this patch, or whatever ksh you want named "/bin/ksh". I certainly don't mind adding more shells to the ${MAKE_SHELL} logic, but so far have only done ksh because using pdksh as the ${MAKE_SHELL} does, for me, result in about 10% faster make world time, and speeds port building enormously (though port building speed has gotten faster with some reason optimizations made to the Mk/bsd.port*.mk files). I'd like to get public opinion on this change to see if many others will find it useful. Note that the change also allows you to use "/bin/csh" with MAKE_SHELL=csh, but you might not want to shoot yourself in the foot like that :) Let me know if you find it useful to you; if people do find it useful enough to have these make(1) speed increases, I'll commit it to 5.0 and 4.0. It should also apply to 3.4, but I haven't tried it yet, as my machines run -CURRENT. Let me know what kind of results you have :) I'm interested in results with the real Korn shell, zsh, or bash, as well; I'll specifically add those to the logic if people have good results there. Thanks for any feedback! -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' --0-333593351-956530276=:46547 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="MAKE_SHELL.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="MAKE_SHELL.patch" SW5kZXg6IE1ha2VmaWxlDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1Mg ZmlsZTogL3VzcjIvbmN2cy9zcmMvdXNyLmJpbi9tYWtlL01ha2VmaWxlLHYN CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xMw0KZGlmZiAtdSAtcjEuMTMgTWFr ZWZpbGUNCi0tLSBNYWtlZmlsZQkxOTk5LzExLzE1IDE3OjA3OjQ1CTEuMTMN CisrKyBNYWtlZmlsZQkyMDAwLzAyLzA0IDA1OjM0OjM3DQpAQCAtMTIsNCAr MTIsMjAgQEANCiAJbHN0TWVtYmVyLmMgbHN0TmV4dC5jIGxzdE9wZW4uYyBs c3RSZW1vdmUuYyBsc3RSZXBsYWNlLmMgbHN0U3VjYy5jDQogLlBBVEg6CSR7 LkNVUkRJUn0vbHN0LmxpYg0KIA0KKyMgU2V0IHRoZSBzaGVsbCB3aGljaCBt YWtlKDEpIHVzZXMuICBCb3VybmUgaXMgdGhlIGRlZmF1bHQsIGJ1dCBhIGRl Y2VudA0KKyMgS29ybiBzaGVsbCB3b3JrcyBmaW5lLCBhbmQgbXVjaCBmYXN0 ZXIuICBVc2luZyB0aGUgQyBzaGVsbCBmb3IgdGhpcw0KKyMgd2lsbCBhbG1v c3QgY2VydGFpbmx5IGJyZWFrIGV2ZXJ5dGhpbmcsIGJ1dCBpdCdzIFVuaXgg dHJhZGl0aW9uIHRvDQorIyBhbGxvdyB5b3UgdG8gc2hvb3QgeW91cnNlbGYg aW4gdGhlIGZvb3QgaWYgeW91IHdhbnQgdG8gOi0pDQorDQorTUFLRV9TSEVM TD89CXNoDQorLmlmICR7TUFLRV9TSEVMTH0gPT0gImNzaCINCitDRkxBR1Mr PQktRERFRlNIRUxMPTANCisuZWxpZiAke01BS0VfU0hFTEx9ID09ICJzaCIN CitDRkxBR1MrPQktRERFRlNIRUxMPTENCisuZWxpZiAke01BS0VfU0hFTEx9 ID09ICJrc2giDQorQ0ZMQUdTKz0JLURERUZTSEVMTD0yDQorLmVsc2UNCisu ZXJyb3IgIk1BS0VfU0hFTEwgbXVzdCBiZSBzZXQgdG8gb25lIG9mIFwiY3No XCIsIFwic2hcIiBvciBcImtzaFwiLiINCisuZW5kaWYNCisNCiAuaW5jbHVk ZSA8YnNkLnByb2cubWs+DQpJbmRleDogY29uZmlnLmgNCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0NClJDUyBmaWxlOiAvdXNyMi9uY3ZzL3NyYy91c3IuYmlu L21ha2UvY29uZmlnLmgsdg0KcmV0cmlldmluZyByZXZpc2lvbiAxLjkNCmRp ZmYgLXUgLXIxLjkgY29uZmlnLmgNCi0tLSBjb25maWcuaAkxOTk5LzA5LzEw IDIwOjUxOjU5CTEuOQ0KKysrIGNvbmZpZy5oCTIwMDAvMDIvMDQgMDU6MjM6 NTINCkBAIC0zOSw4ICszOSw2IEBADQogICogJEZyZWVCU0Q6IHNyYy91c3Iu YmluL21ha2UvY29uZmlnLmgsdiAxLjkgMTk5OS8wOS8xMCAyMDo1MTo1OSBq dWxpYW4gRXhwICQNCiAgKi8NCiANCi0jZGVmaW5lCURFRlNIRUxMCTEJCQkv KiBCb3VybmUgc2hlbGwgKi8NCi0NCiAvKg0KICAqIERFRk1BWEpPQlMNCiAg KiBERUZNQVhMT0NBTA0KSW5kZXg6IGpvYi5jDQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09DQpSQ1MgZmlsZTogL3VzcjIvbmN2cy9zcmMvdXNyLmJpbi9tYWtl L2pvYi5jLHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS4xNw0KZGlmZiAtdSAt cjEuMTcgam9iLmMNCi0tLSBqb2IuYwkyMDAwLzAxLzE3IDA2OjQzOjQwCTEu MTcNCisrKyBqb2IuYwkyMDAwLzAyLzAzIDIzOjI0OjM1DQpAQCAtMTkxLDYg KzE5MSwxNiBAQA0KICAgICAidiIsICJlIiwNCiB9LA0KICAgICAvKg0KKyAg ICAgKiBLU0ggZGVzY3JpcHRpb24uIFRoZSBLb3JuIHNoZWxsIGhhcyBhIHN1 cGVyc2V0IG9mDQorICAgICAqIHRoZSBCb3VybmUgc2hlbGwncyBmdW5jdGlv bmFsaXR5Lg0KKyAgICAgKi8NCit7DQorICAgICJrc2giLA0KKyAgICBUUlVF LCAic2V0IC0iLCAic2V0IC12IiwgInNldCAtIiwgNSwNCisgICAgVFJVRSwg InNldCAtZSIsICJzZXQgK2UiLA0KKyAgICAidiIsICJlIiwNCit9LA0KKyAg ICAvKg0KICAgICAgKiBVTktOT1dOLg0KICAgICAgKi8NCiB7DQpJbmRleDog bWFpbi5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpSQ1MgZmlsZTogL3Vz cjIvbmN2cy9zcmMvdXNyLmJpbi9tYWtlL21haW4uYyx2DQpyZXRyaWV2aW5n IHJldmlzaW9uIDEuMzUNCmRpZmYgLXUgLXIxLjM1IG1haW4uYw0KLS0tIG1h aW4uYwkxOTk5LzExLzIzIDEwOjM1OjI0CTEuMzUNCisrKyBtYWluLmMJMjAw MC8wMy8yNSAyMDowMjo1NA0KQEAgLTQ4Myw2ICs0ODMsMTMgQEANCiAJCQkJ CS8qIGF2b2lkIGZhdWx0cyBvbiByZWFkLW9ubHkgc3RyaW5ncyAqLw0KIAlz dGF0aWMgY2hhciBzeXNwYXRoW10gPSBfUEFUSF9ERUZTWVNQQVRIOw0KIA0K KyNpZiBERUZTSEVMTCA9PSAyDQorCS8qDQorCSAqIFR1cm4gb2ZmIEVOViB0 byBtYWtlIGtzaCBoYXBwaWVyLg0KKwkgKi8NCisJdW5zZXRlbnYoIkVOViIp Ow0KKyNlbmRpZg0KKw0KICNpZmRlZiBSTElNSVRfTk9GSUxFDQogCS8qDQog CSAqIGdldCByaWQgb2YgcmVzb3VyY2UgbGltaXQgb24gZmlsZSBkZXNjcmlw dG9ycw0KQEAgLTEwMDUsNyArMTAxMiwxMyBAQA0KIAkodm9pZCkgZHVwMihm ZHNbMV0sIDEpOw0KIAkodm9pZCkgY2xvc2UoZmRzWzFdKTsNCiANCisjaWYg REVGU0hFTEwgPT0gMQ0KIAkodm9pZCkgZXhlY3YoIi9iaW4vc2giLCBhcmdz KTsNCisjZWxpZiBERUZTSEVMTCA9PSAyDQorCSh2b2lkKSBleGVjdigiL2Jp bi9rc2giLCBhcmdzKTsNCisjZWxzZQ0KKyNlcnJvciAiREVGU0hFTEwgbXVz dCBiZSAxIG9yIDIuIg0KKyNlbmRpZg0KIAlfZXhpdCgxKTsNCiAJLypOT1RS RUFDSEVEKi8NCiANCg== --0-333593351-956530276=:46547-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 23 15:55:52 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 656B437B5D1; Sun, 23 Apr 2000 15:55:47 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.2) id PAA20746; Sun, 23 Apr 2000 15:55:45 -0700 (PDT) From: Archie Cobbs Message-Id: <200004232255.PAA20746@bubba.whistle.com> Subject: Re: Help with SIOCADDMULTI, IFF_ALLMULTI and IFF_PROMISC In-Reply-To: from Robert Watson at "Apr 23, 2000 01:24:51 pm" To: rwatson@FreeBSD.ORG (Robert Watson) Date: Sun, 23 Apr 2000 15:55:45 -0700 (PDT) Cc: fenner@research.att.com (Bill Fenner), dmlb@ragnet.demon.co.uk, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Robert Watson writes: > > You should go promiscuous to multicast. If the card doesn't support > > that, you should go fully promiscuous and drop unicasts that aren't > > to you. (Make sure you don't block packets that bpf is going to > > want to see). > > Also, if you want bridging support, you have to bridge before doing the > filtering. > > Really, the filtering on ``appropriateness'' should only occur when the > packet is about to enter ether_input(). > > Speaking of which, I'd really like to see bridge support getting added to > all new NIC drivers from now on. However, the current bridge interface > leaves something to be desired... I'm working on fixing this.. see discussion on freebsd-net. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 23 16: 5: 5 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by hub.freebsd.org (Postfix) with ESMTP id D8CB037B57C for ; Sun, 23 Apr 2000 16:04:51 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id IAA12318; Mon, 24 Apr 2000 08:34:48 +0930 (CST) Date: Mon, 24 Apr 2000 08:34:48 +0930 From: Greg Lehey To: Mark Huizer Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Debugging kernel data Message-ID: <20000424083448.A12170@freebie.lemis.com> References: <20000413132050.D43342@dohd.cx> <20000423114218.H4675@freebie.lemis.com> <20000423182528.A58150@dohd.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20000423182528.A58150@dohd.cx> Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sunday, 23 April 2000 at 18:25:28 +0200, Mark Huizer wrote: > On Sun, Apr 23, 2000 at 11:42:18AM +0930, Greg Lehey wrote: >> On Thursday, 13 April 2000 at 13:20:50 +0200, Mark Huizer wrote: >>> Hi >>> >>> I'm trying to debug a kernel that is not crashing but hanging, with all >>> processes in 'inode' wchan. So I did a 'call panic()', and now I have >>> the crashdump, but is there a way to get to the data structures of the >>> kernel??? >> >> Sure. What are you looking for? Have you read the section on kernel >> debugging in the handbook? > > Yep, done that kind of stuff before, but never on non-crashing kernels > :-( Problem is I want to get at the stacks of various running processes, > and the syscalls they are making. > I started using the vinum gdb macros, which got me a bit further, > though not yet enough, I'm afraid. What are you missing? You can get a stack trace, but you'll have to go looking for the variables yourself. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 23 16:39:55 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 5A42A37B97E; Sun, 23 Apr 2000 16:39:50 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id TAA07746; Sun, 23 Apr 2000 19:40:03 -0400 (EDT) (envelope-from chuckr@picnic.mat.net) Date: Sun, 23 Apr 2000 19:40:03 -0400 (EDT) From: Chuck Robey To: Brian Fundakowski Feldman Cc: hackers@FreeBSD.ORG Subject: Re: commit MAKE_SHELL? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 23 Apr 2000, Brian Fundakowski Feldman wrote: > Some weeks ago, I made a small modification to make(1) so that it could > be built to use a different shell for its work. It already seemed to > have the idea at least partially thought out and in the code, so it was > a naturally easy thing to finish implementing. The code will remain > exactly the same unless you set the following (e.g. in make.conf): > > MAKE_SHELL=ksh [some eliding] in general, it's a good idea, but the problem, is, it gives a lot more freedom without any real gain. It only allows one to write Makefiles that use your private choice of shell, and you can do anything you want, I think, as it is now. Your next paragraph, where you give "csh" as an example, it (I think) a perfect counter-example, because (as we all know) csh is a horrible scripting language, but I bet it gets used. Not only that, but one will end up having hav have 15 different shells installed on machines, just to build things that require odd shells. Just so you don't have to use sh. The idea of being able to use your own shell is great, until you think about how you're opening the door to abuse of it. > I'd like to get public opinion on this change to see if many others will > find it useful. Note that the change also allows you to use "/bin/csh" > with MAKE_SHELL=csh, but you might not want to shoot yourself in the foot > like that :) Let me know if you find it useful to you; if people do find > it useful enough to have these make(1) speed increases, I'll commit it > to 5.0 and 4.0. It should also apply to 3.4, but I haven't tried it yet, > as my machines run -CURRENT. > > Let me know what kind of results you have :) I'm interested in results > with the real Korn shell, zsh, or bash, as well; I'll specifically add > those to the logic if people have good results there. > > Thanks for any feedback! > > -- > Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / > green@FreeBSD.org `------------------------------' > ---------------------------------------------------------------------------- Chuck Robey | Interests include C & Java programming, FreeBSD, chuckr@picnic.mat.net | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 23 18:16:52 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mailgw1.netvision.net.il (mailgw1.netvision.net.il [194.90.1.14]) by hub.freebsd.org (Postfix) with ESMTP id 1C82737B55B for ; Sun, 23 Apr 2000 18:16:40 -0700 (PDT) (envelope-from ak@freenet.co.uk) Received: from freenet.co.uk (RAS3-p79.rlz.netvision.net.il [62.0.169.81]) by mailgw1.netvision.net.il (8.9.3/8.9.3) with ESMTP id EAA17885 for ; Mon, 24 Apr 2000 04:16:30 +0300 (IDT) Message-ID: <3903AEA6.FA7CBBAB@freenet.co.uk> Date: Mon, 24 Apr 2000 05:17:10 +0300 From: A G F Keahan X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Multithreaded server performance Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am currently porting a multithreaded TCP server from NT (yech!) to UNIX using pthreads. The server has a fairly straightforward design -- it opens a thread for each connection, and each thread spends most of its life blocked in a call to read() from a socket. As soon as it receives enough of a request, it does quite a bit of processing and sends something back to the client. How would FreeBSD 4.0 perform in such a scenario? We are talking hundreds, maybe thousands of threads, a lot of them doing blocking reads and writes. Is the standard pthreads library adequate for the task, or would "Linuxthreads" be a better choice? What is the main difference between the standard FreeBSD pthreads and "Linuxthreads" -- it seems both are implemented using a version of clone(). The hardware is probably going to be UP at first -- a fast Pentium III (733MHz?), an Intel 820 board, an Adaptec U2W SCSI controller, and a couple of U2W LVD SCA disks to go with it. The operating system has yet to be chosen. I have tried Solaris 7 on similar hardware, and it seems so much slower than FreeBSD -- and so bloody unresponsive when doing I/O that even NT seems faster. On the other hand, Solaris's threads implementation is supposedly better than anything else out there. I'm not even considering Linux -- or should I? Is it safe to use FreeBSD 4.0-S on a production server? So far I've had nothing but positive experience with it. Any advice will be much appreciated. Alex Keahan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 23 19:17: 2 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id C43EB37BAAA; Sun, 23 Apr 2000 19:16:55 -0700 (PDT) (envelope-from rmuir@looksharp.net) Received: from localhost (rmuir@localhost) by turtle.looksharp.net (8.9.3/8.9.3) with ESMTP id WAA19601; Sun, 23 Apr 2000 22:17:12 -0400 (EDT) (envelope-from rmuir@looksharp.net) Date: Sun, 23 Apr 2000 22:17:12 -0400 (EDT) From: Robert Muir To: Brian Fundakowski Feldman Cc: hackers@FreeBSD.ORG Subject: Re: commit MAKE_SHELL? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have been using it as well (with pdksh) for quite some time. I haven't compared speed, but it certainly hasn't broken anything. Robert Muir rmuir@looksharp.net On Sun, 23 Apr 2000, Brian Fundakowski Feldman wrote: > Some weeks ago, I made a small modification to make(1) so that it could > be built to use a different shell for its work. It already seemed to > have the idea at least partially thought out and in the code, so it was > a naturally easy thing to finish implementing. The code will remain > exactly the same unless you set the following (e.g. in make.conf): > > MAKE_SHELL=ksh > > Well, it's been sitting in my tree for a while now, and there have been > 0 problems with it. I use the ports and build worlds extensively, not > to mention having built everything which uses make(1) with this. The > pdksh is more than sufficiently Bourne (or shall I say compatible? It's > just a superset...) to support every single thing I've thrown at it. > Of course, it would be possible to use the real ksh with this patch, or > whatever ksh you want named "/bin/ksh". > > I certainly don't mind adding more shells to the ${MAKE_SHELL} logic, but > so far have only done ksh because using pdksh as the ${MAKE_SHELL} does, > for me, result in about 10% faster make world time, and speeds port > building enormously (though port building speed has gotten faster with > some reason optimizations made to the Mk/bsd.port*.mk files). > > I'd like to get public opinion on this change to see if many others will > find it useful. Note that the change also allows you to use "/bin/csh" > with MAKE_SHELL=csh, but you might not want to shoot yourself in the foot > like that :) Let me know if you find it useful to you; if people do find > it useful enough to have these make(1) speed increases, I'll commit it > to 5.0 and 4.0. It should also apply to 3.4, but I haven't tried it yet, > as my machines run -CURRENT. > > Let me know what kind of results you have :) I'm interested in results > with the real Korn shell, zsh, or bash, as well; I'll specifically add > those to the logic if people have good results there. > > Thanks for any feedback! > > -- > Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / > green@FreeBSD.org `------------------------------' > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 23 20:48:26 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 6F15F37B800; Sun, 23 Apr 2000 20:48:20 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Sun, 23 Apr 2000 23:48:18 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Chuck Robey Cc: hackers@FreeBSD.ORG Subject: Re: commit MAKE_SHELL? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 23 Apr 2000, Chuck Robey wrote: > in general, it's a good idea, but the problem, is, it gives a lot more > freedom without any real gain. It only allows one to write Makefiles that > use your private choice of shell, and you can do anything you want, I > think, as it is now. That's not the purpouse, though. Yes, anyone can do that now, as they're perfectly free to modify the source as they please. And, yes, csh was in the source already (!) which is only why I put it there. > Your next paragraph, where you give "csh" as an example, it (I think) a > perfect counter-example, because (as we all know) csh is a horrible > scripting language, but I bet it gets used. Not only that, but one will > end up having hav have 15 different shells installed on machines, just to > build things that require odd shells. > > Just so you don't have to use sh. This is more than about freedom of shells for make(1). Noone is going to write proprietary Makefiles simply because noone is going to accept the heat for trying to make people recompile their make(1) just to build their program. Don't put the idea off because of this, as I really feel that this is unrealistic. > The idea of being able to use your own shell is great, until you think > about how you're opening the door to abuse of it. The door's already open. Go to src/usr.bin/make. for i in *.[ch]; do perl -pi 's:/bin/sh:/bin/bash:g' $i; done And you can rebuild make(1) to use bash. It's extremely simple to make it use the shell of the day. The idea here is that our /bin/sh is not nearly as fast for many things as other Bourne shells. There should be the option to allow a user to enable a faster shell. I can easily disable the csh logic, and anyone can easily reenable it. What do you have against enabling people to use another Bourne-compatible shell if it makes things faster? I'm only criticizing the logic that it will make people want to use various shells to make Makefiles nonstandard. There's GNU make for that, anyway. > ---------------------------------------------------------------------------- > Chuck Robey | Interests include C & Java programming, FreeBSD, > chuckr@picnic.mat.net | electronics, communications, and signal processing. > > New Year's Resolution: I will not sphroxify gullible people into looking up > fictitious words in the dictionary. > ---------------------------------------------------------------------------- -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 23 20:56:45 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id CDAA037B9BD; Sun, 23 Apr 2000 20:56:40 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id XAA08380; Sun, 23 Apr 2000 23:56:52 -0400 (EDT) (envelope-from chuckr@picnic.mat.net) Date: Sun, 23 Apr 2000 23:56:52 -0400 (EDT) From: Chuck Robey To: Brian Fundakowski Feldman Cc: hackers@FreeBSD.org Subject: Re: commit MAKE_SHELL? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 23 Apr 2000, Brian Fundakowski Feldman wrote: > On Sun, 23 Apr 2000, Chuck Robey wrote: > > > in general, it's a good idea, but the problem, is, it gives a lot more > > freedom without any real gain. It only allows one to write Makefiles that > > use your private choice of shell, and you can do anything you want, I > > think, as it is now. [some deletions] > The door's already open. Go to src/usr.bin/make. I didn't say what you asked for was hard, I was against making the addition of lots of extra complications in Makefiles too easy. To tell you the truth, I would find your idea really neat as a programmer, UNTIL I had to maintain some of the inevitable garbage that it generated among some of the less disciplined minds. That said, I'm not dead set against it, I was just giving my take. I think, overall, it's going to hugely complicate makefile maintenance, but if you get approval, go for it! > There's GNU make for that, anyway. Guess why I don't like Gmake? ---------------------------------------------------------------------------- Chuck Robey | Interests include C & Java programming, FreeBSD, chuckr@picnic.mat.net | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 23 21:15:19 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13]) by hub.freebsd.org (Postfix) with ESMTP id 8774337B68B; Sun, 23 Apr 2000 21:15:15 -0700 (PDT) (envelope-from ben@scientia.demon.co.uk) Received: from strontium.scientia.demon.co.uk ([192.168.91.36] ident=exim) by scientia.demon.co.uk with esmtp (Exim 3.12 #1) id 12jXGl-0005Ut-00; Mon, 24 Apr 2000 02:02:35 +0100 Received: (from ben) by strontium.scientia.demon.co.uk (Exim 3.12 #7) id 12jXGl-000FgU-00; Mon, 24 Apr 2000 02:02:35 +0100 Date: Mon, 24 Apr 2000 02:02:35 +0100 From: Ben Smithurst To: Brian Fundakowski Feldman Cc: hackers@FreeBSD.org Subject: Re: commit MAKE_SHELL? Message-ID: <20000424020235.C86507@strontium.scientia.demon.co.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian Fundakowski Feldman wrote: > +.if ${MAKE_SHELL} == "csh" > +CFLAGS+= -DDEFSHELL=0 ... > +#if DEFSHELL == 1 > (void) execv("/bin/sh", args); > +#elif DEFSHELL == 2 > + (void) execv("/bin/ksh", args); > +#else > +#error "DEFSHELL must be 1 or 2." > +#endif why allow csh in the Makefile when the setting of DEFSHELL it results in will not compile? Have I missed something? -- Ben Smithurst / ben@scientia.demon.co.uk / PGP: 0x99392F7D To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 23 21:30: 4 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from canonware.com (canonware.com [199.181.107.39]) by hub.freebsd.org (Postfix) with SMTP id 8015537BAAC for ; Sun, 23 Apr 2000 21:29:55 -0700 (PDT) (envelope-from jasone@canonware.com) Received: (qmail 36215 invoked by uid 1001); 24 Apr 2000 04:21:15 -0000 Date: Sun, 23 Apr 2000 21:21:15 -0700 From: Jason Evans To: A G F Keahan Cc: freebsd-hackers@freebsd.org Subject: Re: Multithreaded server performance Message-ID: <20000423212115.E31925@sturm.canonware.com> References: <3903AEA6.FA7CBBAB@freenet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3903AEA6.FA7CBBAB@freenet.co.uk>; from ak@freenet.co.uk on Mon, Apr 24, 2000 at 05:17:10AM +0300 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 24, 2000 at 05:17:10AM +0300, A G F Keahan wrote: > I am currently porting a multithreaded TCP server from NT (yech!) to > UNIX using pthreads. The server has a fairly straightforward design -- > it opens a thread for each connection, and each thread spends most of > its life blocked in a call to read() from a socket. As soon as it > receives enough of a request, it does quite a bit of processing and > sends something back to the client. This design isn't ideal on any OS, but the fact that you do significant processing every time a request arrives on a socket probably hides most of the inefficiency due to thread switching and lack of cache locality due to many thread stacks. > How would FreeBSD 4.0 perform in such a scenario? We are talking > hundreds, maybe thousands of threads, a lot of them doing blocking reads > and writes. Is the standard pthreads library adequate for the task, or > would "Linuxthreads" be a better choice? What is the main difference > between the standard FreeBSD pthreads and "Linuxthreads" -- it seems > both are implemented using a version of clone(). FreeBSD's threads should perform adequately given the design of your program and the hardware you listed. Actually trying it on the various operating systems would be a good exercise, but I have found that FreeBSD's threads perform at least as well as Solaris's for such an application. LinuxThreads will definitely bog down with so many threads because the kernel scheduler has to deal with so many clone()d processes. FreeBSD's libc_r does not use clone() or anything similar. Instead, it is a userland call conversion library that multiplexes threads in a single process. This style of threads library should perform well for the type of application you are dealing with. Note that there is also ports/devel/linuxthreads, which is based on rfork(), which can be made to behave like Linux's clone(). Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 23 22:20:49 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 80E9E37BAE7; Sun, 23 Apr 2000 22:20:46 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Mon, 24 Apr 2000 01:20:45 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Ben Smithurst Cc: hackers@FreeBSD.org Subject: Re: commit MAKE_SHELL? In-Reply-To: <20000424020235.C86507@strontium.scientia.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, Ben Smithurst wrote: > why allow csh in the Makefile when the setting of DEFSHELL it results in > will not compile? Have I missed something? It's there to allow you attempt to shoot yourself in the foot more safely. Too much shooting, still? > -- > Ben Smithurst / ben@scientia.demon.co.uk / PGP: 0x99392F7D -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Apr 23 22:56:15 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 4C5A837B9AB for ; Sun, 23 Apr 2000 22:56:13 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id WAA66144; Sun, 23 Apr 2000 22:56:08 -0700 (PDT) (envelope-from dillon) Date: Sun, 23 Apr 2000 22:56:08 -0700 (PDT) From: Matthew Dillon Message-Id: <200004240556.WAA66144@apollo.backplane.com> To: naddy@mips.rhein-neckar.de (Christian Weisgerber) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Double buffered cp(1) References: <200004231737.KAA62365@apollo.backplane.com> <3903563C.6453A9E2@3-cities.com> <200004232022.NAA64183@apollo.backplane.com> <8dvs8c$1ltd$1@bigeye.rhein-neckar.de> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Matthew Dillon wrote: : :> -pipe makes a significant difference since without it every source :> file being compiled creates several files in /tmp. : :Hasn't O'Brien recently said that in fact "-pipe" is already the :default for our cc, so explicitly specifying the option doesn't do :anything? : :-- :Christian "naddy" Weisgerber naddy@mips.rhein-neckar.de I don't recall him saying anything like that. There was an argument over making the -pipe the default a few months ago, but I was under the impression that it didn't happen because some people were concerned about the memory requirements nixing compiles on machines with small amounts of memory (since cpp, cc1, AND as wind up all running simultaniously). The documentation doesn't indicate that -pipe is turned on by default. If I ktrace a cc command it sure looks like it uses /tmp files when -pipe is not specified! So I would say that -pipe is NOT the default. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 0: 7:36 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 5167D37B698 for ; Mon, 24 Apr 2000 00:07:32 -0700 (PDT) (envelope-from bp@butya.kz) Received: from bp (helo=localhost) by relay.butya.kz with local-esmtp (Exim 3.13 #1) id 12jcxs-0000kc-00 for freebsd-hackers@freebsd.org; Mon, 24 Apr 2000 14:07:28 +0700 Date: Mon, 24 Apr 2000 14:07:28 +0700 (ALMST) From: Boris Popov To: freebsd-hackers@freebsd.org Subject: Request for the major device number Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, in the near future I'm going to release beta version of native, kernel side SMB/CIFS filesytem for FreeBSD. It uses device /dev/net/nsmbX for the userland <-> kernel interaction. Currently it uses major number assigned to the 'joystick' device which can make some peoples unhappy :). -- Boris Popov To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 0:53:43 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rdc1.sfba.home.com (ha1.rdc1.sfba.home.com [24.0.0.66]) by hub.freebsd.org (Postfix) with ESMTP id 36D2337B67D for ; Mon, 24 Apr 2000 00:53:41 -0700 (PDT) (envelope-from boshea@ricochet.net) Received: from beastie.localdomain ([24.19.158.41]) by mail.rdc1.sfba.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000424075340.JWRN12856.mail.rdc1.sfba.home.com@beastie.localdomain>; Mon, 24 Apr 2000 00:53:40 -0700 Received: (from brian@localhost) by beastie.localdomain (8.9.3/8.8.7) id BAA21633; Mon, 24 Apr 2000 01:03:15 -0700 (PDT) (envelope-from brian) Date: Mon, 24 Apr 2000 01:03:15 -0700 From: "Brian O'Shea" To: Jason Evans Cc: A G F Keahan , freebsd-hackers@FreeBSD.ORG Subject: Re: Multithreaded server performance Message-ID: <20000424010315.U337@beastie.localdomain> Reply-To: boshea@ricochet.net Mail-Followup-To: Jason Evans , A G F Keahan , freebsd-hackers@FreeBSD.ORG References: <3903AEA6.FA7CBBAB@freenet.co.uk> <20000423212115.E31925@sturm.canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <20000423212115.E31925@sturm.canonware.com>; from Jason Evans on Sun, Apr 23, 2000 at 09:21:15PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Apr 23, 2000 at 09:21:15PM -0700, Jason Evans wrote: > > FreeBSD's libc_r does not use clone() or anything similar. Instead, it is > a userland call conversion library that multiplexes threads in a single > process. This style of threads library should perform well for the type of > application you are dealing with. I was under the impression that, because user thread scheduling is done in user mode, a thread that goes to sleep calling a blocking read() system call will put the entire process to sleep until that read() returns (and so all user threads in the process will also be blocked). Is this correct? If it is, it sounds like a user thread implementation would be bad for Mr. Keahan's application, and something like the LinuxThreads port might be more appropriate. > > Note that there is also ports/devel/linuxthreads, which is based on > rfork(), which can be made to behave like Linux's clone(). > > Jason Please correct me if I am wrong. Thanks, -brian -- Brian O'Shea boshea@ricochet.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 1: 8:31 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 6E2FA37B93D for ; Mon, 24 Apr 2000 01:08:30 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id BAA12407; Mon, 24 Apr 2000 01:09:33 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Boris Popov Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Request for the major device number In-reply-to: Your message of "Mon, 24 Apr 2000 14:07:28 +0700." Date: Mon, 24 Apr 2000 01:09:33 -0700 Message-ID: <12404.956563773@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > in the near future I'm going to release beta version of native, > kernel side SMB/CIFS filesytem for FreeBSD. It uses device /dev/net/nsmbX You're a committer, just grab an available one. :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 1:19:15 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 514F837B65E for ; Mon, 24 Apr 2000 01:19:03 -0700 (PDT) (envelope-from julian@elischer.org) Received: from gothic.iinet.net.au (gothic.iinet.net.au [203.59.24.252]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id QAA19678; Mon, 24 Apr 2000 16:18:56 +0800 Received: from jules.elischer.org (reggae-01-187.nv.iinet.net.au [203.59.62.187]) by gothic.iinet.net.au (8.8.5/8.8.5) with SMTP id QAA25465; Mon, 24 Apr 2000 16:18:53 +0800 Message-ID: <390402D3.41C67EA6@elischer.org> Date: Mon, 24 Apr 2000 01:16:19 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Boris Popov Cc: freebsd-hackers@freebsd.org Subject: Re: Request for the major device number References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Boris Popov wrote: > > Hello, > > in the near future I'm going to release beta > version of native, > kernel side SMB/CIFS filesytem for FreeBSD. It uses > device /dev/net/nsmbX > for the userland <-> kernel interaction. Currently it uses > major number > assigned to the 'joystick' device which can make some > peoples unhappy :). Can you explain a little more, what interaction there is between the userland and kernel that requires the device? (I am truely curious, and not trying be difficult) -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 2: 9:25 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 3D89837B900 for ; Mon, 24 Apr 2000 02:09:14 -0700 (PDT) (envelope-from bp@butya.kz) Received: from bp (helo=localhost) by relay.butya.kz with local-esmtp (Exim 3.13 #1) id 12jerU-0000xt-00; Mon, 24 Apr 2000 16:09:00 +0700 Date: Mon, 24 Apr 2000 16:09:00 +0700 (ALMST) From: Boris Popov To: Julian Elischer Cc: freebsd-hackers@freebsd.org Subject: Re: Request for the major device number In-Reply-To: <390402D3.41C67EA6@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, Julian Elischer wrote: > > in the near future I'm going to release beta > > version of native, > > kernel side SMB/CIFS filesytem for FreeBSD. It uses > > device /dev/net/nsmbX > > for the userland <-> kernel interaction. Currently it uses > > major number > > assigned to the 'joystick' device which can make some > > peoples unhappy :). > > > Can you explain a little more, what interaction there is between > the userland and kernel that requires the device? > (I am truely curious, and not trying be difficult) Sure. smbfs actually consists of two major parts - SMB requester and filesystem itself. SMB requester handles all protocol details and gives clear interface like 'connect to server', 'connect to share', 'send request' etc. An opened device used as a handle for above primitives and this saves some code which should track these handles. For example: any new connection established by userland process should be dropped when the process-owner is terminated. This can be done via at_exit handler and set of syscalls, but why to reinvent the wheel ? Kernel already does this job and does it well. (at_exit technique used in the netncp code and I don't like it much :) Of course, said above doesn't mean that mount_smbfs will hang as a daemon. The only disadvantage is the necessity to create N nsmb devices, but this should gone when device clones will be available (in fact, clones are implemented, but there is some unnegotiated conventions with Poul-Henning and lack of spare time). -- Boris Popov To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 2:21:50 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from urban.iinet.net.au (urban.iinet.net.au [203.59.24.231]) by hub.freebsd.org (Postfix) with ESMTP id 3A35137B5D0 for ; Mon, 24 Apr 2000 02:21:46 -0700 (PDT) (envelope-from julian@elischer.org) Received: from gothic.iinet.net.au (gothic.iinet.net.au [203.59.24.252]) by urban.iinet.net.au (8.8.7/8.8.7) with ESMTP id RAA31625; Mon, 24 Apr 2000 17:21:43 +0800 Received: from jules.elischer.org (reggae-01-187.nv.iinet.net.au [203.59.62.187]) by gothic.iinet.net.au (8.8.5/8.8.5) with SMTP id RAA27301; Mon, 24 Apr 2000 17:21:38 +0800 Message-ID: <3904118B.446B9B3D@elischer.org> Date: Mon, 24 Apr 2000 02:19:07 -0700 From: Julian Elischer X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 5.0-CURRENT i386) MIME-Version: 1.0 To: Boris Popov Cc: freebsd-hackers@freebsd.org Subject: Re: Request for the major device number References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Boris Popov wrote: > > On Mon, 24 Apr 2000, Julian Elischer wrote: > > Sure. smbfs actually consists of two major parts - SMB requester > and filesystem itself. SMB requester handles all protocol details and > gives clear interface like 'connect to server', 'connect to share', 'send > request' etc. An opened device used as a handle for above primitives and > this saves some code which should track these handles. if I'm understanding this right, then a particular process has it's own session to the server? Does the filesystem not just get mounted? how does a process that is unaware of the smbfs open a session? (I think I'm missing something here) > > For example: any new connection established by userland process > should be dropped when the process-owner is terminated. This can be done > via at_exit handler and set of syscalls, but why to reinvent the wheel ? > Kernel already does this job and does it well. (at_exit technique > used in the netncp code and I don't like it much :) what is the 'userland process'? The process that wants to read the data, or some daemon that is doing work to maintain the session? > > Of course, said above doesn't mean that mount_smbfs will hang as a > daemon. > > The only disadvantage is the necessity to create N nsmb devices, > but this should gone when device clones will be available (in fact, > clones are implemented, but there is some unnegotiated conventions with > Poul-Henning and lack of spare time). it would be nice of these convensions were shared with the rest of us :-) > > -- > Boris Popov -- __--_|\ Julian Elischer / \ julian@elischer.org ( OZ ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 3: 0:34 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id DE51C37B955 for ; Mon, 24 Apr 2000 03:00:23 -0700 (PDT) (envelope-from bp@butya.kz) Received: from bp (helo=localhost) by relay.butya.kz with local-esmtp (Exim 3.13 #1) id 12jfev-00014A-00; Mon, 24 Apr 2000 17:00:05 +0700 Date: Mon, 24 Apr 2000 17:00:05 +0700 (ALMST) From: Boris Popov To: Julian Elischer Cc: freebsd-hackers@freebsd.org Subject: Re: Request for the major device number In-Reply-To: <3904118B.446B9B3D@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, Julian Elischer wrote: > > Sure. smbfs actually consists of two major parts - SMB requester > > and filesystem itself. SMB requester handles all protocol details and > > gives clear interface like 'connect to server', 'connect to share', 'send > > request' etc. An opened device used as a handle for above primitives and > > this saves some code which should track these handles. > > if I'm understanding this right, then a particular process has it's > own session to the server? Does the filesystem not just get mounted? > how does a process that is unaware of the smbfs open a session? > (I think I'm missing something here) No, it doesn't (unless it want to establish its own session to server). smbfs by itself doesn't require any special treating and looks as plain network filesystem. It uses its own connection to SMB share (which may (or may not) have separate TCP connection to server). SMB requester by itself can be used for tasks like sending jobs to remote printer. smbprint command can use its own session (or use already established one) and may require user to authenticate, etc.. > > For example: any new connection established by userland process > > should be dropped when the process-owner is terminated. This can be done > > via at_exit handler and set of syscalls, but why to reinvent the wheel ? > > Kernel already does this job and does it well. (at_exit technique > > used in the netncp code and I don't like it much :) > > what is the 'userland process'? The process that wants to read the data, > or some daemon that is doing work to maintain the session? No, there is no need in any daemon to maintain session. All such things handled by kernel-side code. A simple example - the mount_smbfs command need to setup session to the server. It opens device, passes parameters (user name, share name, password etc) and establish session. Next, it passes device handle to smbfs code and closes the device (but session keept opened because smbfs code keeps reference to it). Another example is a smbprint command which also setups session but performs SMB requests from userland and releases handle when it coredumps or exit normally. SMB requester handles all connections and different programs can use the same connection to server (unlike Samba client which always establishes new connection/VC/session to server). Permanent connections can be created with smblogin command and this process doesn't involve smbfs code. > > The only disadvantage is the necessity to create N nsmb devices, > > but this should gone when device clones will be available (in fact, > > clones are implemented, but there is some unnegotiated conventions with > > Poul-Henning and lack of spare time). > > it would be nice of these convensions were shared with the rest of us > :-) Let me finish this task and then move to another :) -- Boris Popov To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 3:14:13 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 8D09B37B998 for ; Mon, 24 Apr 2000 03:14:10 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id GAA07817; Mon, 24 Apr 2000 06:13:53 -0400 (EDT) Date: Mon, 24 Apr 2000 06:13:53 -0400 (EDT) From: Daniel Eischen To: "Brian O'Shea" Cc: Jason Evans , A G F Keahan , freebsd-hackers@FreeBSD.ORG Subject: Re: Multithreaded server performance In-Reply-To: <20000424010315.U337@beastie.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, Brian O'Shea wrote: > On Sun, Apr 23, 2000 at 09:21:15PM -0700, Jason Evans wrote: > > > > FreeBSD's libc_r does not use clone() or anything similar. Instead, it is > > a userland call conversion library that multiplexes threads in a single > > process. This style of threads library should perform well for the type of > > application you are dealing with. > > I was under the impression that, because user thread scheduling is done > in user mode, a thread that goes to sleep calling a blocking read() > system call will put the entire process to sleep until that read() > returns (and so all user threads in the process will also be blocked). > Is this correct? 1. You are mistaken. > If it is, it sounds like a user thread implementation would be bad for > Mr. Keahan's application, and something like the LinuxThreads port might > be more appropriate. > > > > > Note that there is also ports/devel/linuxthreads, which is based on > > rfork(), which can be made to behave like Linux's clone(). > > > > Jason > > Please correct me if I am wrong. Go To 1. ;-) -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 3:24:49 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 00D3237B649; Mon, 24 Apr 2000 03:24:47 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id MAA15240; Mon, 24 Apr 2000 12:25:52 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200004241025.MAA15240@info.iet.unipi.it> Subject: Re: Help with SIOCADDMULTI, IFF_ALLMULTI and IFF_PROMISC In-Reply-To: from Robert Watson at "Apr 23, 2000 01:24:51 pm" To: Robert Watson Date: Mon, 24 Apr 2000 12:25:52 +0200 (CEST) Cc: Bill Fenner , dmlb@ragnet.demon.co.uk, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Speaking of which, I'd really like to see bridge support getting added to > all new NIC drivers from now on. However, the current bridge interface > leaves something to be desired... hopefully things will improve if someone finds the time to extend ether_input() as suggested by archie Cobbs and possibly many others. (BTW suggestions for a better interface welcome...) cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 3:57:46 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from fort.wn.net.ua (fort.wn.net.ua [207.241.164.249]) by hub.freebsd.org (Postfix) with ESMTP id 82DBA37B6A2; Mon, 24 Apr 2000 03:57:24 -0700 (PDT) (envelope-from romik@base.wn.net.ua) Received: from base.wn.net.ua (base.wn.net.ua [207.241.169.17]) by fort.wn.net.ua (8.9.3/8.9.3) with ESMTP id NAA14805; Mon, 24 Apr 2000 13:59:10 +0300 (EEST) Received: (from romik@localhost) by base.wn.net.ua (8.9.3/8.9.3) id NAA07047; Mon, 24 Apr 2000 13:59:09 +0300 (EEST) (envelope-from romik) Date: Mon, 24 Apr 2000 13:59:02 +0300 From: "Roman N. Dmitrik" To: freebsd-questions@FreeBSD.ORG Cc: freebsd-hackers@FreeBSD.ORG Subject: IA-300 PCI ADSL Modem Message-ID: <20000424135902.A6808@WN.NET.UA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Operating-System: FreeBSD base.wn.net.ua 3.2-RELEASE FreeBSD 3.2-RELEASE Organization: WN Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, We bought IA-300 PCI ADSL Modem( chipsets i901889F/i90135F ITeX) and have trouble with installing it in FreeBSD 3.4. Does FreeBSD support this device if yes were we can read about this problem ? Please help -- Regards, Roman D. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 4:21: 0 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.uninet.ee (ns.uninet.ee [194.204.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 9215737B636; Mon, 24 Apr 2000 04:20:49 -0700 (PDT) (envelope-from taavi@uninet.ee) Received: by ns.uninet.ee (Postfix, from userid 1001) id 8184B2580C; Mon, 24 Apr 2000 13:20:40 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by ns.uninet.ee (Postfix) with SMTP id 7D2CB14A22; Mon, 24 Apr 2000 13:20:40 +0200 (EET) Date: Mon, 24 Apr 2000 13:20:40 +0200 (EET) From: Taavi Talvik To: "Roman N. Dmitrik" Cc: freebsd-questions@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: IA-300 PCI ADSL Modem In-Reply-To: <20000424135902.A6808@WN.NET.UA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 24 Apr 2000, Roman N. Dmitrik wrote: > We bought IA-300 PCI ADSL Modem( chipsets i901889F/i90135F ITeX) > and have trouble with installing it in FreeBSD 3.4. > Does FreeBSD support this device if yes were we can read about this problem ? No, FreeBSD doesn't support any ADSL chipset. Currently you can use only external ethernet attached ADSL modems. best regards, taavi ----------------------------------------------------------- Taavi Talvik | Internet: taavi@uninet.ee Unineti Andmeside AS | phone: +372 6405150 Ravala pst. 10 | fax: +372 6405151 Tallinn 10143, Estonia | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 6:14:30 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from rmx04.globecomm.net (rmx04.iname.net [165.251.8.202]) by hub.freebsd.org (Postfix) with ESMTP id 97A2437BABD for ; Mon, 24 Apr 2000 06:14:25 -0700 (PDT) (envelope-from hamidreza@mail.com) Received: from web431-mc.mail.com by rmx04.globecomm.net (8.9.1/8.8.0) with SMTP id JAA00771 ; Mon, 24 Apr 2000 09:13:05 -0400 (EDT) Message-ID: <380857435.956581985438.JavaMail.root@web431-mc.mail.com> Date: Mon, 24 Apr 2000 09:13:05 -0400 (EDT) From: Hamid Moghadam To: hackers@freebsd.org Subject: TCP maximum data lenght Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: mail.com X-Originating-IP: 195.200.226.110 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dear folks Recently, I have notice a problem. When I send or receive data blocks <= 4096 with READ or WRITE system calls, everything work well, when I increase the block size, syscalls return the correct value but the network throughput falls down %80. I have increased the socket rcv/snd buffer size and there is no changes. Sys: 3.4R on a PIII with two 3C905B nics working 100M full-duplex Comments will be appretiated. TIA - HM ______________________________________________ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 7:25:39 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13]) by hub.freebsd.org (Postfix) with ESMTP id 376B737B5CD; Mon, 24 Apr 2000 07:25:36 -0700 (PDT) (envelope-from ben@scientia.demon.co.uk) Received: from strontium.scientia.demon.co.uk ([192.168.91.36] ident=exim) by scientia.demon.co.uk with esmtp (Exim 3.12 #1) id 12jjnQ-0000cp-00; Mon, 24 Apr 2000 15:25:08 +0100 Received: (from ben) by strontium.scientia.demon.co.uk (Exim 3.12 #7) id 12jjnP-000Aav-00; Mon, 24 Apr 2000 15:25:07 +0100 Date: Mon, 24 Apr 2000 15:25:07 +0100 From: Ben Smithurst To: Brian Fundakowski Feldman Cc: hackers@FreeBSD.org Subject: Re: commit MAKE_SHELL? Message-ID: <20000424152507.F86507@strontium.scientia.demon.co.uk> References: <20000424020235.C86507@strontium.scientia.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian Fundakowski Feldman wrote: > On Mon, 24 Apr 2000, Ben Smithurst wrote: > >> why allow csh in the Makefile when the setting of DEFSHELL it results in >> will not compile? Have I missed something? > > It's there to allow you attempt to shoot yourself in the foot more safely. > Too much shooting, still? I think so, but I won't argue if someone else disagrees, it doesn't bother me that much. It just seems a bit odd to have an option which will produce code which doesn't compile. -- Ben Smithurst / ben@scientia.demon.co.uk / PGP: 0x99392F7D To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 8:13:52 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from njord.bart.nl (njord.bart.nl [194.158.170.15]) by hub.freebsd.org (Postfix) with ESMTP id 5D2CB37B635 for ; Mon, 24 Apr 2000 08:13:45 -0700 (PDT) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org (abaddon@lucifer.is.an.elder.of.the.ninth-circle.org [195.38.216.226]) by njord.bart.nl (8.9.3/8.9.2) with ESMTP id RAA86077; Mon, 24 Apr 2000 17:13:35 +0200 (CEST) Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id QAA03085; Mon, 24 Apr 2000 16:39:43 +0200 (CEST) (envelope-from asmodai) Date: Mon, 24 Apr 2000 16:39:43 +0200 From: Jeroen Ruigrok/Asmodai To: Arun Sharma Cc: freebsd-hackers@freebsd.org Subject: Re: Fwd: socket.h and _POSIX_SOURCE Message-ID: <20000424163942.E1842@daemon.ninth-circle.org> References: <200004201604.JAA10995@sharmas.dhs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200004201604.JAA10995@sharmas.dhs.org>; from adsharma@sharmas.dhs.org on Thu, Apr 20, 2000 at 09:04:06AM -0700 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20000420 20:02], Arun Sharma (adsharma@sharmas.dhs.org) wrote: >Comments ? > >$ cat test.c >#include >#include >$ cc -D_POSIX_SOURCE -c test.c >In file included from test.c:2: >/usr/include/sys/socket.h:47: syntax error before `sa_family_t' >/usr/include/sys/socket.h:47: warning: data definition has no type or storage > class sys/socket.h declares sa_family_t as a u_char. If we look at sys/types.h we see: #ifndef _POSIX_SOURCE typedef unsigned char u_char; [snip] #endif Which combined with D_POSIX_SOURCE causes [logical] problems. -- Jeroen Ruigrok vd Werven/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best The BSD Programmer's Documentation Project Who looks under the surface does so at his own risk... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 13:26: 0 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from viking.sophos.com (viking.sophos.com [193.82.145.128]) by hub.freebsd.org (Postfix) with ESMTP id 5E42937BBF1 for ; Mon, 24 Apr 2000 13:25:56 -0700 (PDT) (envelope-from gjvc@sophos.com) Received: from trafalgar.sophos.com (trafalgar.sophos.com [193.82.145.143]) by viking.sophos.com (MAILER-DAEMON) with ESMTP id CAC3A45C28 for ; Mon, 24 Apr 2000 20:25:54 +0000 (GMT) Received: by trafalgar.sophos.com (Postfix, from userid 1010) id A967C1F2F; Mon, 24 Apr 2000 21:25:54 +0100 (BST) Date: Mon, 24 Apr 2000 21:25:54 +0100 From: George Cox To: freebsd-hackers@freebsd.org Subject: Re: Double buffered cp(1) Message-ID: <20000424212554.A80998@trafalgar.sophos.com> References: <200004231737.KAA62365@apollo.backplane.com> <3903563C.6453A9E2@3-cities.com> <200004232022.NAA64183@apollo.backplane.com> <8dvs8c$1ltd$1@bigeye.rhein-neckar.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i In-Reply-To: <8dvs8c$1ltd$1@bigeye.rhein-neckar.de>; from naddy@mips.rhein-neckar.de on Mon, Apr 24, 2000 at 12:08:12AM +0200 X-Operating-System: FreeBSD 5.0-CURRENT (i386) X-EICAR: X5O!P%@AP[4PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!+H* X-Sophos: You betcha Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 24/04 00:08, Christian Weisgerber wrote: > Hasn't O'Brien recently said that in fact "-pipe" is already the default > for our cc, so explicitly specifying the option doesn't do anything? Try compiling a 'hello world' program with and without the '-pipe' option but with '-v' switched on in both cases and compare the difference in the messages. best; gjvc -- George Cox Tel +44 1235 544 127 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 13:50:46 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from corinth.bossig.com (corinth.bossig.com [208.26.239.66]) by hub.freebsd.org (Postfix) with ESMTP id 72EA337BAED for ; Mon, 24 Apr 2000 13:50:39 -0700 (PDT) (envelope-from kstewart@3-cities.com) Received: from 3-cities.com (unverified [208.26.242.50]) by corinth.bossig.com (Rockliffe SMTPRA 4.2.1) with ESMTP id ; Mon, 24 Apr 2000 13:54:55 -0700 Message-ID: <3904B391.D72E8D0E@3-cities.com> Date: Mon, 24 Apr 2000 13:50:25 -0700 From: Kent Stewart Organization: Columbia Basin Virtual Community Project X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: George Cox Cc: freebsd-hackers@freebsd.org Subject: Re: Double buffered cp(1) References: <200004231737.KAA62365@apollo.backplane.com> <3903563C.6453A9E2@3-cities.com> <200004232022.NAA64183@apollo.backplane.com> <8dvs8c$1ltd$1@bigeye.rhein-neckar.de> <20000424212554.A80998@trafalgar.sophos.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG George Cox wrote: > > On 24/04 00:08, Christian Weisgerber wrote: > > > Hasn't O'Brien recently said that in fact "-pipe" is already the default > > for our cc, so explicitly specifying the option doesn't do anything? > > Try compiling a 'hello world' program with and without the '-pipe' option > but with '-v' switched on in both cases and compare the difference in the > messages. This is what I see on a buildworld with 4.0-Stable Modified /etc/make.conf and commented out CFLAGS= -Os -pipe 3707.4u 799.6s 1:35:52.46 78.3% 1374+1477k 56974+173232io 2337pf+0w 3693.9u 800.5s 1:29:45.73 83.4% 1375+1477k 55201+173224io 2160pf+0w Modified /etc/make.conf and added CFLAGS= -pipe 3559.2u 807.2s 1:28:00.05 82.6% 1608+1286k 56499+174033io 2516pf+0w Kent > > best; > > gjvc > > -- > George Cox > Tel +44 1235 544 127 > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- Kent Stewart Richland, WA mailto:kstewart@3-cities.com http://www.3-cities.com/~kstewart/index.html FreeBSD News http://daily.daemonnews.org/ SETI(Search for Extraterrestrial Intelligence) @ HOME http://setiathome.ssl.berkeley.edu/ Hunting Archibald Stewart, b 1802 in Ballymena, Antrim Co., NIR http://www.3-cities.com/~kstewart/genealogy/archibald_stewart.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 14:10:26 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rdc1.sfba.home.com (ha1.rdc1.sfba.home.com [24.0.0.66]) by hub.freebsd.org (Postfix) with ESMTP id 895DA37BBDD for ; Mon, 24 Apr 2000 14:10:22 -0700 (PDT) (envelope-from boshea@ricochet.net) Received: from beastie.localdomain ([24.19.158.41]) by mail.rdc1.sfba.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000424211021.YUID12856.mail.rdc1.sfba.home.com@beastie.localdomain>; Mon, 24 Apr 2000 14:10:21 -0700 Received: (from brian@localhost) by beastie.localdomain (8.9.3/8.8.7) id OAA22873; Mon, 24 Apr 2000 14:19:57 -0700 (PDT) (envelope-from brian) Date: Mon, 24 Apr 2000 14:19:57 -0700 From: "Brian O'Shea" To: Daniel Eischen Cc: "Brian O'Shea" , Jason Evans , A G F Keahan , freebsd-hackers@FreeBSD.ORG Subject: Re: Multithreaded server performance Message-ID: <20000424141957.W337@beastie.localdomain> Reply-To: boshea@ricochet.net Mail-Followup-To: Daniel Eischen , Brian O'Shea , Jason Evans , A G F Keahan , freebsd-hackers@FreeBSD.ORG References: <20000424010315.U337@beastie.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Daniel Eischen on Mon, Apr 24, 2000 at 06:13:53AM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 24, 2000 at 06:13:53AM -0400, Daniel Eischen wrote: > On Mon, 24 Apr 2000, Brian O'Shea wrote: > > > > I was under the impression that, because user thread scheduling is done > > in user mode, a thread that goes to sleep calling a blocking read() > > system call will put the entire process to sleep until that read() > > returns (and so all user threads in the process will also be blocked). > > Is this correct? > > 1. You are mistaken. Could you elaborate? The text that I am using [1] warns about blocking system calls putting the process (and thus all user threads) to sleep. This book has no FreeBSD specific information, so anything specific to FreeBSD would be really interesting to hear. > > > > Please correct me if I am wrong. > > Go To 1. ;-) > > -- > Dan Eischen > Thanks, -brian 1. Norton, Scott J., "Thread Time", p.24, Hewlett-Packard Professional Books, ISBN 0-13-190067-6 -- Brian O'Shea boshea@ricochet.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 14:44:24 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from test.tar.com (test.tar.com [204.95.187.4]) by hub.freebsd.org (Postfix) with ESMTP id 3D9E337BC5C for ; Mon, 24 Apr 2000 14:44:18 -0700 (PDT) (envelope-from dick@test.tar.com) Received: (from dick@localhost) by test.tar.com (8.9.3/8.9.3) id QAA37117; Mon, 24 Apr 2000 16:44:05 -0500 (CDT) (envelope-from dick) Date: Mon, 24 Apr 2000 16:44:05 -0500 From: "Richard Seaman, Jr." To: Jason Evans Cc: A G F Keahan , freebsd-hackers@FreeBSD.ORG Subject: Re: Multithreaded server performance Message-ID: <20000424164405.G370@seaman.org> References: <3903AEA6.FA7CBBAB@freenet.co.uk> <20000423212115.E31925@sturm.canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000423212115.E31925@sturm.canonware.com>; from jasone@canonware.com on Sun, Apr 23, 2000 at 09:21:15PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Apr 23, 2000 at 09:21:15PM -0700, Jason Evans wrote: > On Mon, Apr 24, 2000 at 05:17:10AM +0300, A G F Keahan wrote: > > I am currently porting a multithreaded TCP server from NT (yech!) to > > UNIX using pthreads. The server has a fairly straightforward design -- > > it opens a thread for each connection, and each thread spends most of > > its life blocked in a call to read() from a socket. As soon as it > > receives enough of a request, it does quite a bit of processing and > > sends something back to the client. > > This design isn't ideal on any OS, but the fact that you do significant > processing every time a request arrives on a socket probably hides most of > the inefficiency due to thread switching and lack of cache locality due to > many thread stacks. > > > How would FreeBSD 4.0 perform in such a scenario? We are talking > > hundreds, maybe thousands of threads, a lot of them doing blocking reads > > and writes. Is the standard pthreads library adequate for the task, or > > would "Linuxthreads" be a better choice? What is the main difference > > between the standard FreeBSD pthreads and "Linuxthreads" -- it seems > > both are implemented using a version of clone(). > > FreeBSD's threads should perform adequately given the design of your program > and the hardware you listed. Actually trying it on the various operating > systems would be a good exercise, but I have found that FreeBSD's threads > perform at least as well as Solaris's for such an application. Interesting. I would have thought Solaris would be much superior. > LinuxThreads will definitely bog down with so many threads because the > kernel scheduler has to deal with so many clone()d processes. Somewhat. But its nothing compared to the slowdown in the libc_r scheduler, in my experience. Each context switch (or each time the libc_r scheduler examines its state to consider a context switch), it executes a poll call to examine the state of *each* file descriptor that is considered "blocked" (of course its not really blocked in the kernel -- libc_r converts all i/o calls to non-blocking and polls their status to determined when i/o can be done). If you have hundreds/thousands of threads and each has an open file descriptor that has to be polled, linuxthreads is much faster, at least for the tests I've run. However, linuxthreads will consume a lot more kernel resources, so this only holds if you can tolerate the load on your resources. That said, if you want more than 1022 threads using linuxthreads (either in the FreeBSD port or in linux emulation, or in native linux) you will have to tweak the linuxthreads pthread library. It has a default limit of 1024 threads including the "main" thread and the thread manager thread. You have to raise the limit, and fiddle with the default thread stack spacing, if I recall. (I think the default stack spacing is 2MB. This doesn't work too well when you have "thousands" of threads :)) > FreeBSD's libc_r does not use clone() or anything similar. Instead, it is > a userland call conversion library that multiplexes threads in a single > process. This style of threads library should perform well for the type of > application you are dealing with. Perhaps. The proposed "new" threads model that I understand you are working on should be *much* superior in this kind of application to either libc_r or linuxthreads, I would think. -- Richard Seaman, Jr. email: dick@seaman.org 5182 N. Maple Lane phone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 15: 9:52 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mta2.rcsntx.swbell.net (mta2.rcsntx.swbell.net [151.164.30.26]) by hub.freebsd.org (Postfix) with ESMTP id D795837B5AA for ; Mon, 24 Apr 2000 15:09:49 -0700 (PDT) (envelope-from chris@holly.calldei.com) Received: from holly.calldei.com ([208.191.155.7]) by mta2.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FTJ00IP8K3Q4R@mta2.rcsntx.swbell.net> for freebsd-hackers@FreeBSD.ORG; Mon, 24 Apr 2000 17:07:02 -0500 (CDT) Received: (from chris@localhost) by holly.calldei.com (8.9.3/8.9.3) id RAA15195; Mon, 24 Apr 2000 17:07:01 -0500 (CDT envelope-from chris) Date: Mon, 24 Apr 2000 17:07:00 -0500 From: Chris Costello Subject: Re: Multithreaded server performance In-reply-to: <20000424141957.W337@beastie.localdomain> To: Brian O'Shea Cc: Daniel Eischen , Jason Evans , A G F Keahan , freebsd-hackers@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <20000424170700.A14783@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i References: <20000424010315.U337@beastie.localdomain> <20000424141957.W337@beastie.localdomain> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, April 24, 2000, Brian O'Shea wrote: > On Mon, Apr 24, 2000 at 06:13:53AM -0400, Daniel Eischen wrote: > > On Mon, 24 Apr 2000, Brian O'Shea wrote: > > > > > > I was under the impression that, because user thread scheduling is done > > > in user mode, a thread that goes to sleep calling a blocking read() > > > system call will put the entire process to sleep until that read() > > > returns (and so all user threads in the process will also be blocked). > > > Is this correct? > > > > 1. You are mistaken. > > Could you elaborate? The text that I am using [1] warns about blocking > system calls putting the process (and thus all user threads) to sleep. > This book has no FreeBSD specific information, so anything specific to > FreeBSD would be really interesting to hear. FreeBSD's threads implement has its own read() function which will make a non-blocking read() call (using the _real_ syscall) for the specified amount of bytes. Now a non-blocking read() call fails unless all the data in nbytes can be read into buf. So our implementation will continue to do a non-blocking read until all the data can be copied and then allows the thread continue, thus blocking only the calling thread. At least that's what the source code tells me. -- |Chris Costello |I smell a wumpus. `---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 15:10:58 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from canonware.com (canonware.com [199.181.107.39]) by hub.freebsd.org (Postfix) with SMTP id 58E5937B5F2 for ; Mon, 24 Apr 2000 15:10:56 -0700 (PDT) (envelope-from jasone@canonware.com) Received: (qmail 39107 invoked by uid 1001); 24 Apr 2000 22:00:52 -0000 Date: Mon, 24 Apr 2000 15:00:52 -0700 From: Jason Evans To: "Richard Seaman, Jr." Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Multithreaded server performance Message-ID: <20000424150052.J31925@sturm.canonware.com> References: <3903AEA6.FA7CBBAB@freenet.co.uk> <20000423212115.E31925@sturm.canonware.com> <20000424164405.G370@seaman.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000424164405.G370@seaman.org>; from dick@seaman.org on Mon, Apr 24, 2000 at 04:44:05PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 24, 2000 at 04:44:05PM -0500, Richard Seaman, Jr. wrote: > On Sun, Apr 23, 2000 at 09:21:15PM -0700, Jason Evans wrote: > > FreeBSD's threads should perform adequately given the design of your program > > and the hardware you listed. Actually trying it on the various operating > > systems would be a good exercise, but I have found that FreeBSD's threads > > perform at least as well as Solaris's for such an application. > > Interesting. I would have thought Solaris would be much superior. > > > LinuxThreads will definitely bog down with so many threads because the > > kernel scheduler has to deal with so many clone()d processes. > > Somewhat. But its nothing compared to the slowdown in the libc_r scheduler, > in my experience. Each context switch (or each time the libc_r scheduler > examines its state to consider a context switch), it executes a poll call > to examine the state of *each* file descriptor that is considered "blocked" > (of course its not really blocked in the kernel -- libc_r converts all > i/o calls to non-blocking and polls their status to determined when i/o > can be done). If you have hundreds/thousands of threads and each has an > open file descriptor that has to be polled, linuxthreads is much faster, > at least for the tests I've run. However, linuxthreads will consume a > lot more kernel resources, so this only holds if you can tolerate the load > on your resources. Interesting. Unfortunately, when I was developing the server I referred to, I was never able to get past about 100 connections on FreeBSD without crashing the kernel, because of the static buffer limits in the kernel (yes, I manually specified very large mbuf limits). As a result, I never experienced the scaling problems you mention. =) Linux runs into problems at less than 4000 threads because of a limit on the total number of processes, even if the thread stack size is decreased. I have run threaded tests on Solaris with over 30,000 connections without problems, other than kernel deadlock due to resource starvation when stuffing too many kernel-side socket buffers with data. > > FreeBSD's libc_r does not use clone() or anything similar. Instead, it is > > a userland call conversion library that multiplexes threads in a single > > process. This style of threads library should perform well for the type of > > application you are dealing with. > > Perhaps. The proposed "new" threads model that I understand you are working > on should be *much* superior in this kind of application to either libc_r or > linuxthreads, I would think. I hope so, because it's going to be a bit of work. =) Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 15:15:15 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rdc1.sfba.home.com (ha1.rdc1.sfba.home.com [24.0.0.66]) by hub.freebsd.org (Postfix) with ESMTP id 2AFE537B5E7 for ; Mon, 24 Apr 2000 15:15:13 -0700 (PDT) (envelope-from boshea@ricochet.net) Received: from beastie.localdomain ([24.19.158.41]) by mail.rdc1.sfba.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000424221507.MPL12856.mail.rdc1.sfba.home.com@beastie.localdomain>; Mon, 24 Apr 2000 15:15:07 -0700 Received: (from brian@localhost) by beastie.localdomain (8.9.3/8.8.7) id PAA22992; Mon, 24 Apr 2000 15:24:43 -0700 (PDT) (envelope-from brian) Date: Mon, 24 Apr 2000 15:24:43 -0700 From: "Brian O'Shea" To: Jason Evans Cc: Daniel Eischen , "Brian O'Shea" , A G F Keahan , freebsd-hackers@FreeBSD.ORG Subject: Re: Multithreaded server performance Message-ID: <20000424152443.X337@beastie.localdomain> Reply-To: boshea@ricochet.net Mail-Followup-To: Jason Evans , Daniel Eischen , Brian O'Shea , A G F Keahan , freebsd-hackers@FreeBSD.ORG References: <20000424010315.U337@beastie.localdomain> <20000424141957.W337@beastie.localdomain> <20000424141111.H31925@sturm.canonware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <20000424141111.H31925@sturm.canonware.com>; from Jason Evans on Mon, Apr 24, 2000 at 02:11:11PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 24, 2000 at 02:11:11PM -0700, Jason Evans wrote: > > Could you elaborate? The text that I am using [1] warns about blocking > > system calls putting the process (and thus all user threads) to sleep. > > This book has no FreeBSD specific information, so anything specific to > > FreeBSD would be really interesting to hear. > > > > 1. Norton, Scott J., "Thread Time", p.24, Hewlett-Packard Professional > > Books, ISBN 0-13-190067-6 > > Read page 25 as well. Call conversion (referred to as wrappers) is > discussed there. Call conversion works very well for sockets. Wow, a page reference to the same book that I am reading. Kind of embarrassing that the answer to my question was on the page after the one that I mentioned. Thanks, that's exactly what I was looking for. -brian > > Jason > -- Brian O'Shea boshea@ricochet.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 15:39: 2 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.nyct.net (bsd4.nyct.net [204.141.86.6]) by hub.freebsd.org (Postfix) with ESMTP id 3FDEC37B737 for ; Mon, 24 Apr 2000 15:38:58 -0700 (PDT) (envelope-from mbac@nyct.net) Received: from bsd1.nyct.net (root@bsd1.nyct.net [204.141.86.3]) by mail.nyct.net (8.9.3/8.8.7) with ESMTP id SAA36540; Mon, 24 Apr 2000 18:40:06 -0400 (EDT) (envelope-from mbac@nyct.net) Received: from localhost (mbac@localhost) by bsd1.nyct.net (8.9.3/8.9.3) with ESMTP id SAA85098; Mon, 24 Apr 2000 18:38:07 -0400 (EDT) (envelope-from mbac@nyct.net) X-Authentication-Warning: bsd1.nyct.net: mbac owned process doing -bs Date: Mon, 24 Apr 2000 18:38:07 -0400 (EDT) From: Michael Bacarella To: Jason Evans Cc: "Richard Seaman, Jr." , freebsd-hackers@FreeBSD.ORG Subject: Re: Multithreaded server performance In-Reply-To: <20000424150052.J31925@sturm.canonware.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Linux runs into problems at less than 4000 threads because of a limit on > the total number of processes, even if the thread stack size is decreased. I believe this restriction was eliminated in the 2.2.x series. -MB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 18: 2:18 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from kronos.networkrichmond.com (kronos.networkrichmond.com [63.69.28.22]) by hub.freebsd.org (Postfix) with ESMTP id 43C4337B67C for ; Mon, 24 Apr 2000 18:02:16 -0700 (PDT) (envelope-from kbyanc@posi.net) X-Provider: Network Richmond, LLC. http://www.networkrichmond.com/ Received: from localhost (kbyanc@localhost) by kronos.networkrichmond.com (8.9.3/8.9.3/antispam) with ESMTP id UAA47862 for ; Mon, 24 Apr 2000 20:53:44 -0400 (EDT) Date: Mon, 24 Apr 2000 20:53:44 -0400 (EDT) From: Kelly Yancey X-Sender: kbyanc@kronos.networkrichmond.com To: hackers@freebsd.org Subject: PR kern/15251 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Now that the 4.0 branch split is well behind us, would someone with commit privs mind taking a look at the kern/15251? Thanks, Kelly -- Kelly Yancey - kbyanc@posi.net - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSD http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 18:51:32 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from alpha.netvision.net.il (alpha.netvision.net.il [194.90.1.13]) by hub.freebsd.org (Postfix) with ESMTP id 9710A37BC75 for ; Mon, 24 Apr 2000 18:51:23 -0700 (PDT) (envelope-from ak@freenet.co.uk) Received: from freenet.co.uk (RAS1-p120.rlz.netvision.net.il [62.0.168.122]) by alpha.netvision.net.il (8.9.3/8.8.6) with ESMTP id EAA23699; Tue, 25 Apr 2000 04:21:48 +0300 (IDT) Message-ID: <390501AB.D185646E@freenet.co.uk> Date: Tue, 25 Apr 2000 05:23:39 +0300 From: A G F Keahan X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: "Richard Seaman, Jr." Cc: Jason Evans , freebsd-hackers@FreeBSD.ORG Subject: Re: Multithreaded server performance References: <3903AEA6.FA7CBBAB@freenet.co.uk> <20000423212115.E31925@sturm.canonware.com> <20000424164405.G370@seaman.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jason and Richard, thank you very much for your explanations of libc_r and LinuxThreads. Due to the significant processing time of each request (typically between 50-800ms, averaging 100ms), I doubt that FreeBSD's threads would perform any worse than if I forked a separate process for each connection (memory usage would go sky high), or even if I had a single process and called poll() myself to check each descriptor for being readable/writable. What worries me though is that by design client connections are kept alive (although the server is allowed to disconnect a client after a period of inactivity), hence after a while there will be a lot of idle descriptors, and continuously polling them might slow down the processing of the active ones. I have to experiment to find out what's best -- the goal is to do better than NT (which surprisingly does quite a good job when it comes to processing lots of threads). Solaris's threads are pretty darn good too, but I dislike all things SystemV-ish, and Solaris/x86 isn't all that hot either (compared with the version for the UltraSPARC). > On Sun, Apr 23, 2000 at 09:21:15PM -0700, Jason Evans wrote: > > On Mon, Apr 24, 2000 at 05:17:10AM +0300, A G F Keahan wrote: > > > I am currently porting a multithreaded TCP server from NT (yech!) to > > > UNIX using pthreads. The server has a fairly straightforward design -- > > > it opens a thread for each connection, and each thread spends most of > > > its life blocked in a call to read() from a socket. As soon as it > > > receives enough of a request, it does quite a bit of processing and > > > sends something back to the client. > > > > This design isn't ideal on any OS, but the fact that you do significant > > processing every time a request arrives on a socket probably hides most of > > the inefficiency due to thread switching and lack of cache locality due to > > many thread stacks. Can you suggest a better design for this type of server application under FreeBSD? Perhaps a combination of forking (or pre-forking) and threads? > > > How would FreeBSD 4.0 perform in such a scenario? We are talking > > > hundreds, maybe thousands of threads, a lot of them doing blocking reads > > > and writes. Is the standard pthreads library adequate for the task, or > > > would "Linuxthreads" be a better choice? What is the main difference > > > between the standard FreeBSD pthreads and "Linuxthreads" -- it seems > > > both are implemented using a version of clone(). > > > > FreeBSD's threads should perform adequately given the design of your program > > and the hardware you listed. Actually trying it on the various operating > > systems would be a good exercise, but I have found that FreeBSD's threads > > perform at least as well as Solaris's for such an application. > > Interesting. I would have thought Solaris would be much superior. I would have thought so too... we'll see. Thanks again Alex Keahan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 19:34:32 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rdc1.ct.home.com (ha1.rdc1.ct.home.com [24.2.0.66]) by hub.freebsd.org (Postfix) with ESMTP id 011DB37B54C for ; Mon, 24 Apr 2000 19:34:25 -0700 (PDT) (envelope-from tsikora@home.com) Received: from home.com ([24.2.168.186]) by mail.rdc1.ct.home.com (InterMail vM.4.01.02.00 201-229-116) with ESMTP id <20000425023116.YTR18096.mail.rdc1.ct.home.com@home.com> for ; Mon, 24 Apr 2000 19:31:16 -0700 Message-ID: <39050339.3E668A7E@home.com> Date: Mon, 24 Apr 2000 22:30:17 -0400 From: Ted Sikora Reply-To: tsikora@powerusersbbs.com Organization: Jtl Development X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.15pre17 i686) X-Accept-Language: en-US,en-GB MIME-Version: 1.0 To: "freebsd-hackers@FreeBSD.ORG" Subject: StarOffice source to be released. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I received the following from SUN Microsystems: -------------------Susan Grabau Thanks for your note. Here's a bit of an update. We are planning on making the StarOffice source code available in the next few months. This will enable OS/2 users and organizations to migrate later versions of StarOffice to OS/2. Of course this strategy will also enable interested parties to deploy StarOffice on any operating system platform not supported by Sun. Best regards, Susan Grabau -------------------Susan Grabau Regards, -- Ted Sikora Jtl Development Group tsikora@powerusersbbs.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 19:45: 6 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtprelay2.adelphia.net (smtprelay2.adelphia.net [64.8.25.7]) by hub.freebsd.org (Postfix) with ESMTP id DCB1E37BBB4 for ; Mon, 24 Apr 2000 19:44:48 -0700 (PDT) (envelope-from pvlad@bigfoot.com) Received: from baikal ([24.48.151.39]) by smtprelay2.adelphia.net (Netscape Messaging Server 4.15) with SMTP id FTJX0X00.7RM; Mon, 24 Apr 2000 22:46:09 -0400 From: Vladik To: A G F Keahan Subject: Re: Multithreaded server performance Date: Mon, 24 Apr 2000 17:46:51 -0500 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain Cc: freebsd-hackers@freebsd.org References: <3903AEA6.FA7CBBAB@freenet.co.uk> <20000424164405.G370@seaman.org> <390501AB.D185646E@freenet.co.uk> In-Reply-To: <390501AB.D185646E@freenet.co.uk> MIME-Version: 1.0 Message-Id: <00042417473901.01311@baikal> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, I would like to suggest to read the following articles at http://www.cs.wustl.edu/~schmidt/report-doc.html (he has there a ps doc for each article) -------------------------------- 13.Comparing Alternative Programming Techniques for Multi-threaded Servers -- the Thread-per-Session Concurrency Model, SIGS, Vol 8. No 7. July 1996. This column examines and evaluates three techniques for developing multi-threaded servers using the ``thread-per-session'' concurrency model. These techniques include using the socket network programming interface, using C++ wrappers for sockets, and using multi-threaded Orbix. 14.Comparing Alternative Programming Techniques for Multi-threaded Servers -- the Thread-Pool Concurrency Model, SIGS, Vol 8. No 4. April 1996. This column examines and evaluates three techniques for developing multi-threaded servers using the ``thread-pool'' concurrency model. These techniques include using the socket network programming interface, using C++ wrappers for sockets, and using multi-threaded Orbix. 15.Comparing Alternative Programming Techniques for Multi-threaded Servers -- the Thread-per-Request Concurrency Model, SIGS, Vol 8. No 2. February 1996. This column examines and evaluates four techniques for developing multi-threaded servers using the ``thread-per-request'' concurrency model. These techniques include using the socket network programming interface, using C++ wrappers for sockets, and using two multi-threaded versions of CORBA (Orbix and HP ORB Plus). ------------------------------------------------------------------------ I hope those papers will help you to decide what thread model to use for your particular application. Most of the models, I think, are implemented in the ACE C++ toolkit, but I am not 100% sure (but for sure you do not need to be concerned with any CORBA's if you just want to use the described thread models) I found that for applications that use any OS or other resources that are expensive to tear down (like database connection, sockets, etc) thread pool models work the best, because there a programmer has control over what resources to can be bound to the items in the pool. Regards, Vladislav On Mon, 24 Apr 2000, A G F Keahan wrote: > Jason and Richard, > > thank you very much for your explanations of libc_r and > LinuxThreads. Due to the significant processing time of each request > (typically between 50-800ms, averaging 100ms), I doubt that FreeBSD's > threads would perform any worse than if I forked a separate process for > each connection (memory usage would go sky high), or even if I had a > single process and called poll() myself to check each descriptor for > being readable/writable. What worries me though is that by design > client connections are kept alive (although the server is allowed to > disconnect a client after a period of inactivity), hence after a while > there will be a lot of idle descriptors, and continuously polling them > might slow down the processing of the active ones. I have to > experiment to find out what's best -- the goal is to do better than NT > (which surprisingly does quite a good job when it comes to processing > lots of threads). Solaris's threads are pretty darn good too, but I > dislike all things SystemV-ish, and Solaris/x86 isn't all that hot > either (compared with the version for the UltraSPARC). > > > > > On Sun, Apr 23, 2000 at 09:21:15PM -0700, Jason Evans wrote: > > > On Mon, Apr 24, 2000 at 05:17:10AM +0300, A G F Keahan wrote: > > > > I am currently porting a multithreaded TCP server from NT (yech!) to > > > > UNIX using pthreads. The server has a fairly straightforward design -- > > > > it opens a thread for each connection, and each thread spends most of > > > > its life blocked in a call to read() from a socket. As soon as it > > > > receives enough of a request, it does quite a bit of processing and > > > > sends something back to the client. > > > > > > This design isn't ideal on any OS, but the fact that you do significant > > > processing every time a request arrives on a socket probably hides most of > > > the inefficiency due to thread switching and lack of cache locality due to > > > many thread stacks. > > > Can you suggest a better design for this type of server application > under FreeBSD? Perhaps a combination of forking (or pre-forking) and > threads? > > > > > > > How would FreeBSD 4.0 perform in such a scenario? We are talking > > > > hundreds, maybe thousands of threads, a lot of them doing blocking reads > > > > and writes. Is the standard pthreads library adequate for the task, or > > > > would "Linuxthreads" be a better choice? What is the main difference > > > > between the standard FreeBSD pthreads and "Linuxthreads" -- it seems > > > > both are implemented using a version of clone(). > > > > > > FreeBSD's threads should perform adequately given the design of your program > > > and the hardware you listed. Actually trying it on the various operating > > > systems would be a good exercise, but I have found that FreeBSD's threads > > > perform at least as well as Solaris's for such an application. > > > > Interesting. I would have thought Solaris would be much superior. > > > I would have thought so too... we'll see. > > Thanks again > > Alex Keahan > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- .. -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 19:54:23 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rdc1.sfba.home.com (ha1.rdc1.sfba.home.com [24.0.0.66]) by hub.freebsd.org (Postfix) with ESMTP id DEFAF37BD8F for ; Mon, 24 Apr 2000 19:54:15 -0700 (PDT) (envelope-from boshea@ricochet.net) Received: from beastie.localdomain ([24.19.158.41]) by mail.rdc1.sfba.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000425025415.IBCE12856.mail.rdc1.sfba.home.com@beastie.localdomain>; Mon, 24 Apr 2000 19:54:15 -0700 Received: (from brian@localhost) by beastie.localdomain (8.9.3/8.8.7) id UAA23675; Mon, 24 Apr 2000 20:03:51 -0700 (PDT) (envelope-from brian) Date: Mon, 24 Apr 2000 20:03:51 -0700 From: "Brian O'Shea" To: Chris Costello Cc: "Brian O'Shea" , Daniel Eischen , Jason Evans , A G F Keahan , freebsd-hackers@FreeBSD.ORG Subject: Re: Multithreaded server performance Message-ID: <20000424200351.Y337@beastie.localdomain> Reply-To: boshea@ricochet.net Mail-Followup-To: Chris Costello , Brian O'Shea , Daniel Eischen , Jason Evans , A G F Keahan , freebsd-hackers@FreeBSD.ORG References: <20000424010315.U337@beastie.localdomain> <20000424141957.W337@beastie.localdomain> <20000424170700.A14783@holly.calldei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <20000424170700.A14783@holly.calldei.com>; from Chris Costello on Mon, Apr 24, 2000 at 05:07:00PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 24, 2000 at 05:07:00PM -0500, Chris Costello wrote: > FreeBSD's threads implement has its own read() function which > will make a non-blocking read() call (using the _real_ syscall) > for the specified amount of bytes. Now a non-blocking read() > call fails unless all the data in nbytes can be read into buf. > So our implementation will continue to do a non-blocking read > until all the data can be copied and then allows the thread > continue, thus blocking only the calling thread. > > At least that's what the source code tells me. Yea, I took a look at lib/libc_r/uthread/uthread_read.c too, but it didn't paint the whole picture for me. Specifically, I couldn't find the definition for the _thread_sys_read() function. It looks like the polling magic to which Jason Evans referred occurs in some interesting code in uthread_kern.c, though. Thanks, -brian -- Brian O'Shea boshea@ricochet.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 19:59:23 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by hub.freebsd.org (Postfix) with ESMTP id 95CCD37BD8F for ; Mon, 24 Apr 2000 19:59:21 -0700 (PDT) (envelope-from chris@holly.calldei.com) Received: from holly.calldei.com ([208.191.155.7]) by mta4.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FTJ00A6FXM3E4@mta4.rcsntx.swbell.net> for freebsd-hackers@FreeBSD.ORG; Mon, 24 Apr 2000 21:58:53 -0500 (CDT) Received: (from chris@localhost) by holly.calldei.com (8.9.3/8.9.3) id VAA16662; Mon, 24 Apr 2000 21:58:50 -0500 (CDT envelope-from chris) Date: Mon, 24 Apr 2000 21:58:49 -0500 From: Chris Costello Subject: Re: Multithreaded server performance In-reply-to: <20000424200351.Y337@beastie.localdomain> To: Brian O'Shea , Daniel Eischen , Jason Evans , A G F Keahan , freebsd-hackers@FreeBSD.ORG Reply-To: chris@calldei.com Message-id: <20000424215849.B14783@holly.calldei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.4i References: <20000424010315.U337@beastie.localdomain> <20000424141957.W337@beastie.localdomain> <20000424170700.A14783@holly.calldei.com> <20000424200351.Y337@beastie.localdomain> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Monday, April 24, 2000, Brian O'Shea wrote: > Yea, I took a look at lib/libc_r/uthread/uthread_read.c too, but it > didn't paint the whole picture for me. Specifically, I couldn't find > the definition for the _thread_sys_read() function. It looks like the > polling magic to which Jason Evans referred occurs in some interesting > code in uthread_kern.c, though. _thread_sys_read() is the real read(2) syscall. They're renamed to ``_thread_sys_SYSCALL()'' for the purpose of reimplementing them in a thread-friendly manner, as you see with read() there. -- |Chris Costello |Do something unusual today. Accomplish work on the computer. `------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 20:20:37 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rdc1.sfba.home.com (ha1.rdc1.sfba.home.com [24.0.0.66]) by hub.freebsd.org (Postfix) with ESMTP id 10C1837C00B for ; Mon, 24 Apr 2000 20:20:32 -0700 (PDT) (envelope-from boshea@ricochet.net) Received: from beastie.localdomain ([24.19.158.41]) by mail.rdc1.sfba.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <20000425032022.IRXD12856.mail.rdc1.sfba.home.com@beastie.localdomain>; Mon, 24 Apr 2000 20:20:22 -0700 Received: (from brian@localhost) by beastie.localdomain (8.9.3/8.8.7) id UAA23805; Mon, 24 Apr 2000 20:29:54 -0700 (PDT) (envelope-from brian) Date: Mon, 24 Apr 2000 20:29:54 -0700 From: "Brian O'Shea" To: Chris Costello Cc: "Brian O'Shea" , freebsd-hackers@FreeBSD.ORG Subject: Re: Multithreaded server performance Message-ID: <20000424202954.Z337@beastie.localdomain> Reply-To: boshea@ricochet.net Mail-Followup-To: Chris Costello , Brian O'Shea , freebsd-hackers@FreeBSD.ORG References: <20000424010315.U337@beastie.localdomain> <20000424141957.W337@beastie.localdomain> <20000424170700.A14783@holly.calldei.com> <20000424200351.Y337@beastie.localdomain> <20000424215849.B14783@holly.calldei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <20000424215849.B14783@holly.calldei.com>; from Chris Costello on Mon, Apr 24, 2000 at 09:58:49PM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 24, 2000 at 09:58:49PM -0500, Chris Costello wrote: > On Monday, April 24, 2000, Brian O'Shea wrote: > > Yea, I took a look at lib/libc_r/uthread/uthread_read.c too, but it > > didn't paint the whole picture for me. Specifically, I couldn't find > > the definition for the _thread_sys_read() function. It looks like the > > polling magic to which Jason Evans referred occurs in some interesting > > code in uthread_kern.c, though. > > _thread_sys_read() is the real read(2) syscall. They're > renamed to ``_thread_sys_SYSCALL()'' for the purpose of > reimplementing them in a thread-friendly manner, as you see with > read() there. > Well that explains it, then! There is actually a note about this in the read(2) man page which was confusing me before, but now I understand what it is talking about: IMPLEMENTATION NOTES In the non-threaded library read() is implemented as the read syscall. In the threaded library, the read syscall is assembled to _thread_sys_read() and read() is implemented as a function which locks d for read, then calls _thread_sys_read(). If the call to _thread_sys_read() would block, a context switch is performed. Before re- turning, read() unlocks d. Thanks, -brian -- Brian O'Shea boshea@ricochet.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 20:27:27 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by hub.freebsd.org (Postfix) with ESMTP id 6D83137B513; Mon, 24 Apr 2000 20:27:22 -0700 (PDT) (envelope-from jacobson@pobox.com) Received: from 216-164-201-145.s526.tnt6.atn.pa.dialup.rcn.com ([216.164.201.145] helo=home.my.domain) by smtp02.mrf.mail.rcn.net with esmtp (Exim 2.12 #3) id 12jsHO-0006KX-00; Mon, 24 Apr 2000 19:28:38 -0400 Received: from home (joe@localhost [127.0.0.1]) by home.my.domain (8.9.3/8.9.3) with ESMTP id TAA07013; Mon, 24 Apr 2000 19:28:32 -0400 (EDT) (envelope-from jacobson@pobox.com) Message-Id: <200004242328.TAA07013@home.my.domain> To: Nik Clayton Cc: hackers@FreeBSD.ORG From: Joseph Jacobson Subject: Re: No route for 127/8 to lo0 (?) In-Reply-To: Your message of "Fri, 21 Apr 2000 20:02:01 BST." <20000421200201.A34984@catkin.nothing-going-on.org> Date: Mon, 24 Apr 2000 19:28:32 -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG See RFC1122, section 3.2.1.3, available at http://www.cis.ohio-state.edu/htbin/rfc/rfc1122.html http://www.faqs.org/rfcs/rfc1122.html > On Fri, Mar 31, 2000 at 12:57:40PM +0100, Nik Clayton wrote: [...] > > I thought that 127/8 was the "local net", and that packets sent to any of > > those addresses would go via the loopback interface. That seems to be > > how Linux and Windows 98 do things (the only systems I can check this on > > at the moment). Assuming that's the case, why does FreeBSD only add a > > a host route to 127.0.0.1, and not a network route for 127/8? Various > > other people have confirmed that they only have a 127.0.0.1 host route > > as well, so I don't believe this is a misconfiguration of my system. > > No one's actually been able to answer this, save a few comments that the > loopback interface is special-cased to do this in the code, and that the > code in question is quite old. [...] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 20:51:35 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from CS.MsState.Edu (walt.cs.msstate.edu [130.18.208.30]) by hub.freebsd.org (Postfix) with ESMTP id 955A437B509 for ; Mon, 24 Apr 2000 20:51:30 -0700 (PDT) (envelope-from pdh@CS.MsState.EDU) Received: from nora.cs.msstate.edu (nora.cs.msstate.edu [130.18.208.178]); by CS.MsState.Edu (8.9.3/8.9.3/MsState-CS/evision: 1.3 $) with ESMTP; id WAA26828 for ; Mon, 24 Apr 2000 22:51:27 -0500 (CDT) Received: from localhost (pdh@localhost) by nora.cs.msstate.edu (8.9.3/8.9.3/MsState/solaris/1.9c) with ESMTP id WAA06160 for ; Mon, 24 Apr 2000 22:51:27 -0500 (CDT) X-Authentication-Warning: nora.cs.msstate.edu: pdh owned process doing -bs Date: Mon, 24 Apr 2000 22:51:27 -0500 (CDT) From: Dehui Peng X-Sender: pdh@nora.cs.msstate.edu To: freebsd-hackers@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi All- I want to be a part of your team and do something for freeBSD. Could somebody tell me how to start? Thanks a lot. Best Regards, Dehui Peng To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 23:43: 1 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from main.piter.net (main.piter.net [195.201.22.10]) by hub.freebsd.org (Postfix) with ESMTP id 6A66237BC4F for ; Mon, 24 Apr 2000 23:42:57 -0700 (PDT) (envelope-from cyril@main.piter.net) Received: (from cyril@localhost) by main.piter.net (8.9.3/8.5.2/sply) id KAA10775; Tue, 25 Apr 2000 10:51:45 +0400 (MSD) Date: Tue, 25 Apr 2000 10:51:45 +0400 (MSD) From: "Cyril A. Vechera" Message-Id: <200004250651.KAA10775@main.piter.net> To: ak@freenet.co.uk, dick@seaman.org Subject: Re: Multithreaded server performance Cc: freebsd-hackers@FreeBSD.ORG, jasone@canonware.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 25 06:02:09 2000 > Date: Tue, 25 Apr 2000 05:23:39 +0300 > From: A G F Keahan > To: "Richard Seaman, Jr." > Cc: Jason Evans , freebsd-hackers@FreeBSD.ORG > Subject: Re: Multithreaded server performance > > Jason and Richard, > > thank you very much for your explanations of libc_r and > LinuxThreads. Due to the significant processing time of each request > (typically between 50-800ms, averaging 100ms), I doubt that FreeBSD's > threads would perform any worse than if I forked a separate process for > each connection (memory usage would go sky high), or even if I had a > single process and called poll() myself to check each descriptor for > being readable/writable. What worries me though is that by design > client connections are kept alive (although the server is allowed to > disconnect a client after a period of inactivity), hence after a while > there will be a lot of idle descriptors, and continuously polling them > might slow down the processing of the active ones. I have to There is a way to save from slowing down on lot of connections. If we assume that response time is not consired to be too fast, for example, 500-5000 msec, we can poll() not all sockets, but just delay inserting some sockets in polling set. Look how it works: 1. we've made socket action (accept, read etc) 2. insert socket into poll/select waiting set after N msec 3. if socket has any activity within M msec, go to 1. 4. delay socket insertion on L msec If some of connections require most interactivity, they must use its own L,M,N. Only overhead we have is supporting two queues of active and frozen sockets. So, by variation L,M,N we have array of only 32 descriptors for poll() and really work with about 1000 sockets, working in single process without treads and forks. Sincerely your, Cyril A. Vechera To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Apr 24 23:45: 5 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from rye.elite.net (rye.elite.net [205.199.220.6]) by hub.freebsd.org (Postfix) with ESMTP id 3FB5737B92A; Mon, 24 Apr 2000 23:45:00 -0700 (PDT) (envelope-from nate@elite.net) Received: from almond.elite.net (root@almond.elite.net [205.199.220.5]) by rye.elite.net (8.9.3/8.9.3) with ESMTP id XAA90633; Mon, 24 Apr 2000 23:44:59 -0700 (PDT) Received: (nate@localhost) by almond.elite.net (8.8.3/8.6.12) id XAA13414; Mon, 24 Apr 2000 23:44:59 -0700 (PDT) Date: Mon, 24 Apr 2000 23:44:59 -0700 (PDT) From: Nate Lawson To: freebsd-hackers@freebsd.org Cc: freebsd-ports@freebsd.org, davidm@hpl.hp.com Subject: Re: floating point exceptions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am running FreeBSD 4.0-RELEASE on x86 with gcc 2.95.2 and the httperf-0.6 port gives a SIGFPE and dumps core when run against a system that has no web server running. (The default behavior is to measure localhost when no arguments are specified). It seems this is caused by a divide by zero error since the delta between connections ends up being zero. The author suggest that the divide should return a defined value, Inf, according to the IEEE floating point standard. FreeBSD generates SIGFPE. I temporarily patched the code locally to check for a delta of zero and arbitrarily set it to 1.0 so that the divide succeeds and everything comes out ok without crashing. Is FreeBSD's behavior correct? Why or why not? You can use the included code snippet to verify that this occurs. Thanks, Nate ---------- Forwarded message ---------- Date: Mon, 24 Apr 2000 15:54:38 -0700 (PDT) From: David Mosberger To: Nate Lawson Subject: Re: patch to httperf-0.6 >>>>> On Mon, 24 Apr 2000 15:37:21 -0700 (PDT), Nate Lawson said: Nate> On x86. Your code generates SIGFPE, not SIGBUS sorry. Here Nate> is a code snippet which generates SIGFPE as well. Nate> main() { float a, b, c; Nate> a = 1.0; b = 0.0; c = a/b; } Nate> This seems to be correct behavior. No, IEEE says that the exceptions should be disabled by default. You should get Inf instead of SIGFPE. --david To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 25 0: 5:38 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from orion.ac.hmc.edu (Orion.AC.HMC.Edu [134.173.32.20]) by hub.freebsd.org (Postfix) with ESMTP id 8DC6137BCC0; Tue, 25 Apr 2000 00:05:29 -0700 (PDT) (envelope-from brdavis@orion.ac.hmc.edu) Received: (from brdavis@localhost) by orion.ac.hmc.edu (8.8.8/8.8.8) id AAA20157; Tue, 25 Apr 2000 00:05:23 -0700 (PDT) Date: Tue, 25 Apr 2000 00:05:23 -0700 From: Brooks Davis To: Nate Lawson Cc: freebsd-hackers@FreeBSD.ORG, freebsd-ports@FreeBSD.ORG, davidm@hpl.hp.com Subject: Re: floating point exceptions Message-ID: <20000425000523.A17224@orion.ac.hmc.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i In-Reply-To: ; from nate@elite.net on Mon, Apr 24, 2000 at 11:44:59PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 24, 2000 at 11:44:59PM -0700, Nate Lawson wrote: > I am running FreeBSD 4.0-RELEASE on x86 with gcc 2.95.2 and the > httperf-0.6 port gives a SIGFPE and dumps core when run against a system > that has no web server running. (The default behavior is to measure > localhost when no arguments are specified). > > It seems this is caused by a divide by zero error since the delta between > connections ends up being zero. The author suggest that the divide > should return a defined value, Inf, according to the IEEE floating point > standard. FreeBSD generates SIGFPE. I temporarily patched the code > locally to check for a delta of zero and arbitrarily set it to 1.0 so > that the divide succeeds and everything comes out ok without crashing. > > Is FreeBSD's behavior correct? Why or why not? You can use the included > code snippet to verify that this occurs. FreeBSD has traditionaly violated the IEEE FP standard in this regard. This is fixed in 5.0 and I think in 4.0-STABLE (though I can't remember what file this is in so I can't check.) If upgrading to -stable isn't an option you can add a call to fpsetmask(3) in the application as follows (this will work on Solaris and Irix as well): #include <...> main() { fpsetmask(0); <...> } -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 25 7:11:20 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from happy.checkpoint.com (happy.checkpoint.com [199.203.156.41]) by hub.freebsd.org (Postfix) with ESMTP id BEB6D37BD8B; Tue, 25 Apr 2000 07:11:04 -0700 (PDT) (envelope-from mellon@pobox.com) Received: (from mellon@localhost) by happy.checkpoint.com (8.9.3/8.9.3) id RAA29452; Tue, 25 Apr 2000 17:09:52 GMT (envelope-from mellon@pobox.com) Date: Tue, 25 Apr 2000 17:09:52 +0000 From: Anatoly Vorobey To: Brian Fundakowski Feldman Cc: hackers@FreeBSD.ORG Subject: Re: commit MAKE_SHELL? Message-ID: <20000425170951.A29390@happy.checkpoint.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from green@FreeBSD.ORG on Sun, Apr 23, 2000 at 06:51:16PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Apr 23, 2000 at 06:51:16PM -0400, Brian Fundakowski Feldman wrote: > I certainly don't mind adding more shells to the ${MAKE_SHELL} logic, but > so far have only done ksh because using pdksh as the ${MAKE_SHELL} does, > for me, result in about 10% faster make world time, and speeds port > building enormously Do you have any guesses about what causes this speed increase? What does our shell suck at, in terms of speed? Maybe we could try and speed it up. (this is not meant to counter your proposal). -- Anatoly Vorobey, mellon@pobox.com http://pobox.com/~mellon/ "Angels can fly because they take themselves lightly" - G.K.Chesterton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 25 7:47:21 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from hplms26.hpl.hp.com (hplms26.hpl.hp.com [15.255.168.31]) by hub.freebsd.org (Postfix) with ESMTP id C119837B7D4; Tue, 25 Apr 2000 07:47:14 -0700 (PDT) (envelope-from davidm@hpl.hp.com) Received: from mlhub26.hpl.hp.com (root@mlhub26.hpl.hp.com [15.9.144.132]) by hplms26.hpl.hp.com (8.9.3 (PHNE_18979)/HPL-PA Relay) with ESMTP id HAA23009; Tue, 25 Apr 2000 07:47:03 -0700 (PDT) Received: from napali.hpl.hp.com (napali.hpl.hp.com [15.4.89.123]) by mlhub26.hpl.hp.com (8.9.3 (PHNE_18979)/8.9.3 HPL-PA Hub) with ESMTP id HAA21383; Tue, 25 Apr 2000 07:47:01 -0700 (PDT) Received: (from davidm@localhost) by napali.hpl.hp.com (8.9.3/8.9.3) id HAA22117; Tue, 25 Apr 2000 07:47:01 -0700 From: David Mosberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14597.45029.383712.138944@napali.hpl.hp.com> Date: Tue, 25 Apr 2000 07:47:01 -0700 (PDT) To: Brooks Davis Cc: Nate Lawson , freebsd-hackers@FreeBSD.ORG, freebsd-ports@FreeBSD.ORG, davidm@hpl.hp.com Subject: Re: floating point exceptions In-Reply-To: <20000425000523.A17224@orion.ac.hmc.edu> References: <20000425000523.A17224@orion.ac.hmc.edu> X-Mailer: VM 6.75 under Emacs 20.4.1 Reply-To: davidm@hpl.hp.com X-URL: http://www.hpl.hp.com/personal/David_Mosberger/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG OK, having to call fpsetmask(0) is an acceptable workaround. So if I do: #ifdef __freebsd___ fpsetmask(0); #endif Then this should work on all versions of freebsd? --david >>>>> On Tue, 25 Apr 2000 00:05:23 -0700, Brooks Davis said: Brooks> On Mon, Apr 24, 2000 at 11:44:59PM -0700, Nate Lawson wrote: >> I am running FreeBSD 4.0-RELEASE on x86 with gcc 2.95.2 and the >> httperf-0.6 port gives a SIGFPE and dumps core when run against a >> system that has no web server running. (The default behavior is >> to measure localhost when no arguments are specified). >> >> It seems this is caused by a divide by zero error since the delta >> between connections ends up being zero. The author suggest that >> the divide should return a defined value, Inf, according to the >> IEEE floating point standard. FreeBSD generates SIGFPE. I >> temporarily patched the code locally to check for a delta of zero >> and arbitrarily set it to 1.0 so that the divide succeeds and >> everything comes out ok without crashing. >> >> Is FreeBSD's behavior correct? Why or why not? You can use the >> included code snippet to verify that this occurs. Brooks> FreeBSD has traditionaly violated the IEEE FP standard in Brooks> this regard. This is fixed in 5.0 and I think in 4.0-STABLE Brooks> (though I can't remember what file this is in so I can't Brooks> check.) If upgrading to -stable isn't an option you can add Brooks> a call to fpsetmask(3) in the application as follows (this Brooks> will work on Solaris and Irix as well): Brooks> #include <...> main() { Brooks> fpsetmask(0); <...> } Brooks> -- Brooks Brooks> -- Any statement of the form "X is the one, true Y" is Brooks> FALSE. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 25 8:14:15 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from rock.ghis.net (rock.ghis.net [209.222.164.7]) by hub.freebsd.org (Postfix) with ESMTP id 7E91937BD48; Tue, 25 Apr 2000 08:14:11 -0700 (PDT) (envelope-from will@blackdawn.com) Received: from argon.blackdawn.com (deepspace9.dcds.edu [207.231.151.2]) by rock.ghis.net (8.9.3/8.9.3) with ESMTP id IAA07562; Tue, 25 Apr 2000 08:14:08 -0700 (PDT) Received: by argon.blackdawn.com (Postfix, from userid 1000) id BD1B1192C; Tue, 25 Apr 2000 11:13:21 -0400 (EDT) Date: Tue, 25 Apr 2000 11:13:21 -0400 From: Will Andrews To: David Mosberger Cc: Brooks Davis , Nate Lawson , freebsd-hackers@FreeBSD.ORG, freebsd-ports@FreeBSD.ORG Subject: Re: floating point exceptions Message-ID: <20000425111321.A363@argon.blackdawn.com> References: <20000425000523.A17224@orion.ac.hmc.edu> <14597.45029.383712.138944@napali.hpl.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <14597.45029.383712.138944@napali.hpl.hp.com>; from davidm@hpl.hp.com on Tue, Apr 25, 2000 at 07:47:01AM -0700 X-Operating-System: FreeBSD 5.0-CURRENT i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Apr 25, 2000 at 07:47:01AM -0700, David Mosberger wrote: > OK, having to call fpsetmask(0) is an acceptable workaround. So if I > do: > > #ifdef __freebsd___ > fpsetmask(0); > #endif > > Then this should work on all versions of freebsd? #ifdef __FreeBSD__ fpsetmask(0); #endif BTW: if you update httperf, let me know so I can update the port (I'm the maintainer for the httperf port). -- Will Andrews GCS/E/S @d- s+:+>+:- a--->+++ C++ UB++++ 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? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 25 8:28:24 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from karon.dynas.se (karon.dynas.se [192.71.43.4]) by hub.freebsd.org (Postfix) with SMTP id A98ED37BD61 for ; Tue, 25 Apr 2000 08:28:12 -0700 (PDT) (envelope-from mikko@m2.dynas.se) Received: (qmail 58555 invoked from network); 25 Apr 2000 15:28:10 -0000 Received: from spirit.sto.dynas.se (HELO spirit.dynas.se) (172.16.1.10) by karon.sto.dynas.se with SMTP; 25 Apr 2000 15:28:10 -0000 Received: (qmail 10506 invoked from network); 25 Apr 2000 15:28:14 -0000 Received: from m2.dynas.se (172.16.1.168) by spirit.dynas.se with SMTP; 25 Apr 2000 15:28:14 -0000 Received: (from mikko@localhost) by m2.dynas.se (8.9.3/8.9.3) id RAA29727; Tue, 25 Apr 2000 17:28:37 +0200 (CEST) (envelope-from mikko) Date: Tue, 25 Apr 2000 17:28:37 +0200 (CEST) From: Mikko T Message-Id: <200004251528.RAA29727@m2.dynas.se> To: freebsd-hackers@FreeBSD.ORG Subject: Re: commit MAKE_SHELL? Newsgroups: local.freebsd-hackers References: ; from green@FreeBSD.ORG on Sun, Apr 23, 2000 at 06:51:16PM -0400 <20000425170951.A29390@happy.checkpoint.com> X-Newsreader: NN version 6.5.6 (NOV) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Anatoly Vorobey: >On Sun, Apr 23, 2000 at 06:51:16PM -0400, Brian Fundakowski Feldman wrote: >> I certainly don't mind adding more shells to the ${MAKE_SHELL} logic, but >> so far have only done ksh because using pdksh as the ${MAKE_SHELL} does, >> for me, result in about 10% faster make world time, and speeds port >> building enormously >Do you have any guesses about what causes this speed increase? What does >our shell suck at, in terms of speed? Maybe we could try and speed it up. I compared some complex shell scripts on different platforms, albeit quite a while back (FreeBSD 2.something, I think). FreeBSD didn't do too well, speedwise, mainly due to not having a built-in "test", thus having to execute "/bin/test" (or "/bin/[") a lot. $.02, /Mikko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 25 8:54:50 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from kweetal.tue.nl (kweetal.tue.nl [131.155.2.7]) by hub.freebsd.org (Postfix) with ESMTP id 7B34537BD62 for ; Tue, 25 Apr 2000 08:54:47 -0700 (PDT) (envelope-from marcov@toad.stack.nl) Received: from hermes.tue.nl [131.155.2.46] by kweetal.tue.nl (8.9.3) for id RAA14120 (ESMTP); Tue, 25 Apr 2000 17:54:45 +0200 (MDT) Received: from deathstar (n140.dial.tue.nl [131.155.209.139]) by hermes.tue.nl (Postfix) with ESMTP id CF2542E805 for ; Tue, 25 Apr 2000 17:54:43 +0200 (CEST) From: "Marco van de Voort" To: freebsd-hackers@FreeBSD.ORG Date: Tue, 25 Apr 2000 17:52:36 +0100 Subject: Re: Multithreaded server performance In-reply-to: <20000424150052.J31925@sturm.canonware.com> References: <20000424164405.G370@seaman.org>; from dick@seaman.org on Mon, Apr 24, 2000 at 04:44:05PM -0500 X-mailer: Pegasus Mail for Win32 (v3.12b) Message-Id: <20000425155443.CF2542E805@hermes.tue.nl> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Linux runs into problems at less than 4000 threads because of a limit on > the total number of processes, even if the thread stack size is decreased. 16xxx if you use a 2.3.99pre-x kernel? At least I thought that that was being mentioned as one of the major new things in 2.4.x kernels. Marco van de Voort (MarcoV@Stack.nl) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 25 9: 1:39 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from sharmas.dhs.org (c62443-a.frmt1.sfba.home.com [24.0.69.165]) by hub.freebsd.org (Postfix) with ESMTP id E3A9437B7D4 for ; Tue, 25 Apr 2000 09:01:35 -0700 (PDT) (envelope-from adsharma@sharmas.dhs.org) Received: (from adsharma@localhost) by sharmas.dhs.org (8.9.3/8.9.3) id JAA09763; Tue, 25 Apr 2000 09:01:06 -0700 Date: Tue, 25 Apr 2000 09:01:06 -0700 From: Arun Sharma To: Jeroen Ruigrok/Asmodai Cc: freebsd-hackers@freebsd.org Subject: Re: Fwd: socket.h and _POSIX_SOURCE Message-ID: <20000425090106.A9742@sharmas.dhs.org> References: <200004201604.JAA10995@sharmas.dhs.org> <20000424163942.E1842@daemon.ninth-circle.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <20000424163942.E1842@daemon.ninth-circle.org>; from Jeroen Ruigrok/Asmodai on Mon, Apr 24, 2000 at 04:39:43PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 24, 2000 at 04:39:43PM +0200, Jeroen Ruigrok/Asmodai wrote: > -On [20000420 20:02], Arun Sharma (adsharma@sharmas.dhs.org) wrote: > >Comments ? > > > >$ cat test.c > >#include > >#include > >$ cc -D_POSIX_SOURCE -c test.c > >In file included from test.c:2: > >/usr/include/sys/socket.h:47: syntax error before `sa_family_t' > >/usr/include/sys/socket.h:47: warning: data definition has no type or storage > > class > > sys/socket.h declares sa_family_t as a u_char. > > If we look at sys/types.h we see: > > #ifndef _POSIX_SOURCE > typedef unsigned char u_char; > [snip] > #endif > > Which combined with D_POSIX_SOURCE causes [logical] problems. Would it be fair to say this is a (POSIX non-compliance) bug in the header files ? -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 25 11:51:39 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.internet.dk (ns.internet.dk [194.19.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 74E7837B5C3 for ; Tue, 25 Apr 2000 11:51:33 -0700 (PDT) (envelope-from leifn@neland.dk) Received: (from uucp@localhost) by ns.internet.dk (8.9.2/8.9.3) with UUCP id UAA51701 for freebsd-hackers@FreeBSD.ORG; Tue, 25 Apr 2000 20:51:30 +0200 (CEST) (envelope-from leifn@neland.dk) Received: from gina (gina.neland.dk [192.168.0.14]) by arnold.neland.dk (8.9.3/8.9.3) with SMTP id UAA99943 for ; Tue, 25 Apr 2000 20:50:58 +0200 (CEST) (envelope-from leifn@neland.dk) Message-ID: <00b901bfaee7$55da1fe0$0e00a8c0@neland.dk> Reply-To: "Leif Neland" From: "Leif Neland" To: Subject: Turning on a relay. Date: Tue, 25 Apr 2000 20:51:14 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'd like to turn on a relay to the power for my laserprinter 3 rooms away where the server is located. I have an i/o board with a 8255 24 bit i/o port.(IIRC) So I wrote a simple userland program to do inb/outb, but it dumped core with BUSERR, I presume because userland is not supposed to do i/o to the hardware. I guess I have these options: A: write a driver/kernel module to access the port. B: use an extra parallel port. (I use 2 at the moment) C: use a serial port; I have 3-4 available. What would be the simplest to interface from a shellscript, i.e. the spooler to turn on and off the printer? (The relay has a turn-off delay, so I don't have to worry about turning off the power after everything has been sent, but the printer not finished, or turning off/on between printjobs) Leif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 25 11:58: 8 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from staff.accessus.net (staff.accessus.net [209.145.151.3]) by hub.freebsd.org (Postfix) with ESMTP id E9AF637BDF2 for ; Tue, 25 Apr 2000 11:58:03 -0700 (PDT) (envelope-from jyoung@accessus.net) Received: by staff.accessus.net with Internet Mail Service (5.5.2650.21) id ; Tue, 25 Apr 2000 13:57:52 -0500 Message-ID: From: Jason Young To: 'Leif Neland' , freebsd-hackers@FreeBSD.ORG Subject: RE: Turning on a relay. Date: Tue, 25 Apr 2000 13:57:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I think you need to have a fd open on /dev/io to do inb/outb. Jason Young Access US(tm) Chief Network Engineer > -----Original Message----- > From: Leif Neland [mailto:leifn@neland.dk] > Sent: Tuesday, April 25, 2000 1:51 PM > To: freebsd-hackers@FreeBSD.ORG > Subject: Turning on a relay. > > > I'd like to turn on a relay to the power for my laserprinter > 3 rooms away > where the server is located. > > I have an i/o board with a 8255 24 bit i/o port.(IIRC) > > So I wrote a simple userland program to do inb/outb, but it > dumped core with > BUSERR, I presume because userland is not supposed to do i/o to the > hardware. > > I guess I have these options: > A: write a driver/kernel module to access the port. > B: use an extra parallel port. (I use 2 at the moment) > C: use a serial port; I have 3-4 available. > > What would be the simplest to interface from a shellscript, > i.e. the spooler > to turn on and off the printer? (The relay has a turn-off > delay, so I don't > have to worry about turning off the power after everything > has been sent, > but the printer not finished, or turning off/on between printjobs) > > Leif > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 25 12: 0: 4 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ada.eu.org (marvin.enst.fr [137.194.161.2]) by hub.freebsd.org (Postfix) with ESMTP id D336237BD6E for ; Tue, 25 Apr 2000 11:59:58 -0700 (PDT) (envelope-from sam@inf.enst.fr) Received: from trillian.enst.fr (antinea.enst.fr [137.194.160.145]) by ada.eu.org (Postfix) with ESMTP id 2E9081905C; Tue, 25 Apr 2000 20:59:57 +0200 (CEST) Received: by trillian.enst.fr (Postfix, from userid 1000) id BE565A7; Tue, 25 Apr 2000 20:59:55 +0200 (CEST) Date: Tue, 25 Apr 2000 20:59:54 +0200 To: Leif Neland Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Turning on a relay. References: <00b901bfaee7$55da1fe0$0e00a8c0@neland.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <00b901bfaee7$55da1fe0$0e00a8c0@neland.dk>; from leifn@neland.dk on Tue, Apr 25, 2000 at 08:51:14PM +0200 From: Samuel Tardieu Organization: Ecole Nationale Superieure des Telecommunications Reply-To: Samuel Tardieu Content-Transfer-Encoding: 8bit X-WWW: http://www.inf.enst.fr/~tardieu/ X-Mail-Processing: Sam's procmail tools X-ICQ: 21547599 Message-Id: <2000-04-25-20-59-55+trackit+sam@inf.enst.fr> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 25/04, Leif Neland wrote: | I guess I have these options: | A: write a driver/kernel module to access the port. | B: use an extra parallel port. (I use 2 at the moment) | C: use a serial port; I have 3-4 available. D: use i386_set_ioperm to get access to the I/O port space To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 25 12: 1:18 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 2327137B7E4 for ; Tue, 25 Apr 2000 12:01:15 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e3PJUL915936; Tue, 25 Apr 2000 12:30:21 -0700 (PDT) Date: Tue, 25 Apr 2000 12:30:21 -0700 From: Alfred Perlstein To: Leif Neland Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Turning on a relay. Message-ID: <20000425123021.F9754@fw.wintelcom.net> References: <00b901bfaee7$55da1fe0$0e00a8c0@neland.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <00b901bfaee7$55da1fe0$0e00a8c0@neland.dk>; from leifn@neland.dk on Tue, Apr 25, 2000 at 08:51:14PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Leif Neland [000425 12:24] wrote: > I'd like to turn on a relay to the power for my laserprinter 3 rooms away > where the server is located. > > I have an i/o board with a 8255 24 bit i/o port.(IIRC) > > So I wrote a simple userland program to do inb/outb, but it dumped core with > BUSERR, I presume because userland is not supposed to do i/o to the > hardware. > > I guess I have these options: > A: write a driver/kernel module to access the port. > B: use an extra parallel port. (I use 2 at the moment) > C: use a serial port; I have 3-4 available. D: open(/dev/io) -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 25 13:21:12 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from hurricane.columbus.rr.com (m5.columbus.rr.com [204.210.252.249]) by hub.freebsd.org (Postfix) with ESMTP id EFBA037BDC0 for ; Tue, 25 Apr 2000 13:21:03 -0700 (PDT) (envelope-from caa@columbus.rr.com) Received: from columbus.rr.com ([24.95.63.210]) by hurricane.columbus.rr.com (Post.Office MTA v3.5.3 release 223 ID# 0-53939U80000L80000S0V35) with ESMTP id com; Tue, 25 Apr 2000 16:21:14 -0400 Received: (from caa@localhost) by columbus.rr.com (8.9.3/8.9.3) id QAA56534; Tue, 25 Apr 2000 16:21:01 -0400 (EDT) (envelope-from caa) Date: Tue, 25 Apr 2000 16:21:01 -0400 From: "Charles Anderson" To: Alfred Perlstein Cc: Leif Neland , freebsd-hackers@FreeBSD.ORG Subject: Re: Turning on a relay. Message-ID: <20000425162101.D51324@midgard.dhs.org> References: <00b901bfaee7$55da1fe0$0e00a8c0@neland.dk> <20000425123021.F9754@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000425123021.F9754@fw.wintelcom.net>; from bright@wintelcom.net on Tue, Apr 25, 2000 at 12:30:21PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Yet another way. I used #include ... io_fd = open("/dev/console", O_RDWR, 0); ioctl(io_fd, KDENABIO, 0); and ioctl(io_fd, KDDISABIO, 0); to turn it off again. Is there a "right" way of doing it? Linux has a iopl call that sets the i/o privilege level, it seems much easier and at least better documented. (I was porting glx code, that was using iopl) -Charlie On Tue, Apr 25, 2000 at 12:30:21PM -0700, Alfred Perlstein wrote: > * Leif Neland [000425 12:24] wrote: > > I'd like to turn on a relay to the power for my laserprinter 3 rooms away > > where the server is located. > > > > I have an i/o board with a 8255 24 bit i/o port.(IIRC) > > > > So I wrote a simple userland program to do inb/outb, but it dumped core with > > BUSERR, I presume because userland is not supposed to do i/o to the > > hardware. > > > > I guess I have these options: > > A: write a driver/kernel module to access the port. > > B: use an extra parallel port. (I use 2 at the moment) > > C: use a serial port; I have 3-4 available. > > D: open(/dev/io) > > -Alfred > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- Charles Anderson caa@columbus.rr.com No quote, no nothin' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 25 13:26:20 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from happy.checkpoint.com (happy.checkpoint.com [199.203.156.41]) by hub.freebsd.org (Postfix) with ESMTP id 0CCC337BD89 for ; Tue, 25 Apr 2000 13:26:16 -0700 (PDT) (envelope-from mellon@pobox.com) Received: (from mellon@localhost) by happy.checkpoint.com (8.9.3/8.9.3) id XAA32583; Tue, 25 Apr 2000 23:24:47 GMT (envelope-from mellon@pobox.com) Date: Tue, 25 Apr 2000 23:24:47 +0000 From: Anatoly Vorobey To: Mikko T Cc: hackers@freebsd.org Subject: Re: commit MAKE_SHELL? Message-ID: <20000425232447.A32567@happy.checkpoint.com> References: ; <20000425170951.A29390@happy.checkpoint.com> <200004251528.RAA29727@m2.dynas.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004251528.RAA29727@m2.dynas.se>; from mikko@dynas.se on Tue, Apr 25, 2000 at 05:28:37PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Apr 25, 2000 at 05:28:37PM +0200, Mikko T wrote: > >Anatoly Vorobey: > > >On Sun, Apr 23, 2000 at 06:51:16PM -0400, Brian Fundakowski Feldman wrote: > > >> I certainly don't mind adding more shells to the ${MAKE_SHELL} logic, but > >> so far have only done ksh because using pdksh as the ${MAKE_SHELL} does, > >> for me, result in about 10% faster make world time, and speeds port > >> building enormously > > >Do you have any guesses about what causes this speed increase? What does > >our shell suck at, in terms of speed? Maybe we could try and speed it up. > > I compared some complex shell scripts on different platforms, albeit > quite a while back (FreeBSD 2.something, I think). FreeBSD didn't do > too well, speedwise, mainly due to not having a built-in "test", thus > having to execute "/bin/test" (or "/bin/[") a lot. Well, *should* we have a built-in "test"? I gather the original ash didn't have it due to the KIS principle. But if it speeds things up considerably, it's not much of a bloat, is it? I'd volunteer to write it. -- Anatoly Vorobey, mellon@pobox.com http://pobox.com/~mellon/ "Angels can fly because they take themselves lightly" - G.K.Chesterton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 25 14: 9:50 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail4.kscable.com (fe4.rdc-kc.rr.com [24.94.163.51]) by hub.freebsd.org (Postfix) with ESMTP id AF12137B5B2 for ; Tue, 25 Apr 2000 14:09:35 -0700 (PDT) (envelope-from rklosh@rkl.org) Received: from stimpy ([24.29.188.83]) by mail4.kscable.com with Microsoft SMTPSVC(5.5.1877.357.35); Tue, 25 Apr 2000 16:09:31 -0500 Received: from rklosh by stimpy with local (Exim 3.12 #1 (Debian)) id 12kCa2-0003b6-00 for ; Tue, 25 Apr 2000 16:09:14 -0500 Subject: Broken Kernel?? To: hackers@freebsd.org Date: Tue, 25 Apr 2000 16:09:14 -0500 (CDT) X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Ryan Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner thinks he may have broken the kernel in his last few commits. If so, the fix is to replicate card_if.m line in conf/files & change pccard to card... (Warner was on vacation when he called me and asked me to post this e-mail for him...He appologizes for the mistake, and said he'll be back in 2-3 days...) Ryan rklosh@rkl.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 25 17:45:23 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail2.rdc3.on.home.com (mail2.rdc3.on.home.com [24.2.9.41]) by hub.freebsd.org (Postfix) with ESMTP id 8DBAA37B872 for ; Tue, 25 Apr 2000 17:45:16 -0700 (PDT) (envelope-from cwass99@home.com) Received: from tristan.net ([24.114.108.234]) by mail2.rdc3.on.home.com (InterMail vM.4.01.02.00 201-229-116) with ESMTP id <20000426004515.TOIP910.mail2.rdc3.on.home.com@tristan.net>; Tue, 25 Apr 2000 17:45:15 -0700 Content-Length: 922 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200004231805.LAA62689@apollo.backplane.com> Date: Tue, 25 Apr 2000 20:39:20 -0400 (EDT) From: Colin To: Matthew Dillon Subject: Re: bind and the limit of serial number ??? Cc: freebsd-hackers@FreeBSD.ORG, Dave Dunaway , Evren Yurtesen , Leif Neland Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The generally accepted method (AFAIR) is yyyymmddxx, where xx starts at 00 and is incremented for each change during that day. This allows for multiple updates in a single day without causing problems for situations such as 3 updates today followed by one update each day for the next 4 days ... Of course, if you never manually update the zone file, this isn't really an issue ;) On 23-Apr-00 Matthew Dillon wrote: > > For manual updates of the zone file, I recommend using yyyymmdd rather > then yyyymmddhhmm, and if you modify it twice in one day just increment > the day (and hopefully real time will catch up to it again). > > For automatic updates (i.e. scripts that update zone files), I recommend > simply starting the serial number at 1 and incrementing it on every > update. Trying to make the serial number into a date for viewing ease > is overrated. > Cheers, Colin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Apr 25 23: 0:38 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from dt051n0b.san.rr.com (dt051n0b.san.rr.com [204.210.32.11]) by hub.freebsd.org (Postfix) with ESMTP id B133C37B7E6 for ; Tue, 25 Apr 2000 23:00:33 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (doug@master [10.0.0.2]) by dt051n0b.san.rr.com (8.9.3/8.9.3) with ESMTP id XAA44447; Tue, 25 Apr 2000 23:00:07 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <390685E7.986C2EBA@gorean.org> Date: Tue, 25 Apr 2000 23:00:07 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.72 [en] (X11; U; FreeBSD 5.0-CURRENT-0422 i386) X-Accept-Language: en MIME-Version: 1.0 To: Anatoly Vorobey Cc: Mikko T , hackers@freebsd.org Subject: Re: commit MAKE_SHELL? References: ; <20000425170951.A29390@happy.checkpoint.com> <200004251528.RAA29727@m2.dynas.se> <20000425232447.A32567@happy.checkpoint.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Anatoly Vorobey wrote: > Well, *should* we have a built-in "test"? I gather the original ash didn't > have it due to the KIS principle. But if it speeds things up considerably, > it's not much of a bloat, is it? I'd volunteer to write it. Unfortunately, the only way to tell for sure would be to do a couple make worlds with the current sh, then do some with super-sh with the built in 'test'. Doug -- Excess on occasion is exhilarating. It prevents moderation from acquiring the deadening effect of a habit. -- W. Somerset Maugham To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 4: 2:36 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 809EB37B8B2 for ; Wed, 26 Apr 2000 04:02:33 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.13 #1) id 12kPa9-00065L-00; Wed, 26 Apr 2000 13:02:13 +0200 From: Sheldon Hearn To: Brian Somers Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Shell games In-reply-to: Your message of "Tue, 18 Apr 2000 22:53:22 +0100." <200004182153.WAA00650@hak.lan.Awfulhak.org> Date: Wed, 26 Apr 2000 13:02:13 +0200 Message-ID: <23394.956746933@axl.ops.uunet.co.za> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 18 Apr 2000 22:53:22 +0100, Brian Somers wrote: > I'm not sure why sanity won here though. I guess it'll be done the > next time it comes up.... Reason won in the Bourne shell case because ours is actively maintained. Until ours is no longer actively maintained by a responsive, cluefull and FreeBSD-friendly person or group of people, someone's going to have to come up with _new_ arguments for any other shell. Thus far, nothing compelling has emerged, though not for want of noise. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 5:30:36 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 4ADB437B88F; Wed, 26 Apr 2000 05:30:31 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.13 #1) id 12kQx6-0006Ix-00; Wed, 26 Apr 2000 14:30:00 +0200 From: Sheldon Hearn To: Brooks Davis Cc: Nate Lawson , freebsd-hackers@FreeBSD.ORG, freebsd-ports@FreeBSD.ORG, davidm@hpl.hp.com Subject: Re: floating point exceptions In-reply-to: Your message of "Tue, 25 Apr 2000 00:05:23 MST." <20000425000523.A17224@orion.ac.hmc.edu> Date: Wed, 26 Apr 2000 14:30:00 +0200 Message-ID: <24238.956752200@axl.ops.uunet.co.za> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000 00:05:23 MST, Brooks Davis wrote: > > Is FreeBSD's behavior correct? Why or why not? You can use the included > > code snippet to verify that this occurs. > > FreeBSD has traditionaly violated the IEEE FP standard in this regard. > This is fixed in 5.0 and I think in 4.0-STABLE (though I can't remember > what file this is in so I can't check.) Huh? I'm pretty sure you've got this backwards. FreeBSD has traditionally upheld the standard and we only recently decided to go with the flow in 5.0. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 6:54:31 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (Postfix) with ESMTP id E91F737BB76 for ; Wed, 26 Apr 2000 06:54:28 -0700 (PDT) (envelope-from dennis@etinc.com) Received: from dbsys (dbsys.etinc.com [207.252.1.18]) by etinc.com (8.9.3/8.9.3) with SMTP id JAA16855 for ; Wed, 26 Apr 2000 09:59:05 -0400 (EDT) Message-Id: <200004261359.JAA16855@etinc.com> X-Sender: dennis@etinc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 26 Apr 2000 09:54:06 -0400 To: hackers@freebsd.org From: Dennis Subject: Large mbufs? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is there support for large mbufs in v4.0? (that is, allocations of any size?) Dennis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 7:49:26 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id DE7F837BDA7 for ; Wed, 26 Apr 2000 07:49:22 -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.9.3/8.9.3) with ESMTP id KAA26767; Wed, 26 Apr 2000 10:49:21 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id KAA29394; Wed, 26 Apr 2000 10:49:20 -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 Date: Wed, 26 Apr 2000 10:49:20 -0400 (EDT) To: Dennis Cc: hackers@freebsd.org Subject: Re: Large mbufs? In-Reply-To: <200004261359.JAA16855@etinc.com> References: <200004261359.JAA16855@etinc.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14598.65443.725745.6119@grasshopper.cs.duke.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dennis writes: > Is there support for large mbufs in v4.0? (that is, allocations of any size?) > There are 2 ways to use large mbufs: o options MCLSHIFT=XXXX in your kernel config file. Where XXX is 1 << XXX bytes. Eg, MCLSHIFT=12 is 4K mbuf clusters, MCLSHIFT=13 is 8k clusters, etc. config will complain, but it will work. There are several drawbacks to this method. The most glaring is that you'll probably be wasting an awfully large amount of space. o allocate & manage them yourself, using m_ext mbufs, within the subsystem you feel needs them. See the Tigon (sys/pci/if_ti.c) driver's management of jumbo frame receive buffers for an example of how this is done. Hope this helps, Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 7:57: 7 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by hub.freebsd.org (Postfix) with ESMTP id 901B037BD6B for ; Wed, 26 Apr 2000 07:57:00 -0700 (PDT) (envelope-from narvi@haldjas.folklore.ee) Received: from localhost (narvi@localhost) by haldjas.folklore.ee (8.9.3/8.9.3) with SMTP id QAA16309; Wed, 26 Apr 2000 16:55:58 +0200 (EET) (envelope-from narvi@haldjas.folklore.ee) Date: Wed, 26 Apr 2000 16:55:58 +0200 (EET) From: Narvi To: Matthew Dillon Cc: Michael Bacarella , Alfred Perlstein , Kevin Day , hackers@FreeBSD.ORG Subject: Re: Double buffered cp(1) In-Reply-To: <200004221736.KAA55484@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 22 Apr 2000, Matthew Dillon wrote: [snip] > disk itself is probably the bottleneck. Disk writes tend to be > somewhat slower then disk reads and the seeking alone (between source > file and destination file), even when using a large block size, > will reduce performance drastically verses simply reading or writing > a single file linearly. Double buffering may help a disk-to-disk > file copy, but I doubt it will help a disk-to-same-disk file copy. > Wouldn't coping the file to another disk and then back to the original one than just a simple copy in some cases be faster then? After all, you are saving a lot of head seeks. > -Matt > Matthew Dillon > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 8:29:45 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from bilby.prth.tensor.pgs.com (bilby.prth.tensor.pgs.com [157.147.232.237]) by hub.freebsd.org (Postfix) with ESMTP id C16AD37B895; Wed, 26 Apr 2000 08:29:34 -0700 (PDT) (envelope-from shocking@prth.pgs.com) Received: from bandicoot.prth.tensor.pgs.com (bandicoot.prth.tensor.pgs.com [157.147.224.1]) by bilby.prth.tensor.pgs.com (8.9.3/8.8.8) with ESMTP id XAA08781; Wed, 26 Apr 2000 23:27:16 +0800 (WST) Received: from bleep.craftncomp.com (dialin20 [157.147.225.220]) by bandicoot.prth.tensor.pgs.com (8.9.3/8.9.3) with ESMTP id XAA20787; Wed, 26 Apr 2000 23:29:30 +0800 (WST) Received: from bloop.craftncomp.com (bloop.prth.tensor.pgs.com [202.12.111.1]) by bleep.craftncomp.com (8.9.3/8.9.3) with ESMTP id XAA01526; Wed, 26 Apr 2000 23:28:53 +0800 (WST) (envelope-from shocking@prth.pgs.com) Received: from bloop.craftncomp.com (localhost [127.0.0.1]) by bloop.craftncomp.com (8.9.3/8.9.3) with ESMTP id XAA12560; Wed, 26 Apr 2000 23:28:48 +0800 (WST) (envelope-from shocking@bloop.craftncomp.com) Message-Id: <200004261528.XAA12560@bloop.craftncomp.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: msmith@freebsd.org, hackers@freebsd.org Subject: Using the boot loader to set maximum memory size? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Apr 2000 23:28:48 +0800 From: Stephen Hocking Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is there any chance of extending the loader so that it can set the memory size, rather than hard coding it into the kernel config file? This would be quite useful for testing things which like a large amount of memory set aside exclusively for hardware's use (I'm thinking of Utah-GLX's DMA buffers for G400 cards here). Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true." Robert Wilensky, University of California To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 8:33:57 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from quack.kfu.com (quack.kfu.com [170.1.70.2]) by hub.freebsd.org (Postfix) with ESMTP id 0504537BD57 for ; Wed, 26 Apr 2000 08:33:54 -0700 (PDT) (envelope-from nsayer@quack.kfu.com) Received: from icarus.kfu.com (icarus.kfu.com [170.1.70.28]) by quack.kfu.com (8.9.2/8.9.3) with ESMTP id IAA45623 for ; Wed, 26 Apr 2000 08:33:42 -0700 (PDT) (envelope-from nsayer@quack.kfu.com) Received: from quack.kfu.com by icarus.kfu.com with ESMTP (8.9.3//ident-1.0) id IAA02821; Wed, 26 Apr 2000 08:33:10 -0700 (PDT) Message-ID: <39070C36.93C9118F@quack.kfu.com> Date: Wed, 26 Apr 2000 08:33:10 -0700 From: Nick Sayer X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: IPv4->IPv6 conversion suite? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have just set up IPv6 on my network at home, and there was much rejoicing. :-) Now the problem is that legacy apps don't have v6 support. One idea I have floating around in my head is the idea of a socks-like combination of libc support and faith to allow IPv6-only networks to participate in ipv4 using faith as a proxy. Such a library would merely need a single input -- an IPV4PREFIX. It would take the socket(), connect(), etc calls for the AF_INET domain and turn them into AF_INET6 calls with the address being made out of the IPv4 input address and the IPV4PREFIX. With this in place, entire IPv6 networks could "hide" behind a single IPv4 address with which they could conduct IPv4 business, while using IPv6 natively. IMHO common deployment would speed the retirement of IPv4. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 8:57: 1 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 2B31A37B78A; Wed, 26 Apr 2000 08:56:59 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e3QGQ8N22052; Wed, 26 Apr 2000 09:26:08 -0700 (PDT) Date: Wed, 26 Apr 2000 09:26:08 -0700 From: Alfred Perlstein To: Stephen Hocking Cc: msmith@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Using the boot loader to set maximum memory size? Message-ID: <20000426092607.L9754@fw.wintelcom.net> References: <200004261528.XAA12560@bloop.craftncomp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004261528.XAA12560@bloop.craftncomp.com>; from shocking@prth.pgs.com on Wed, Apr 26, 2000 at 11:28:48PM +0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Stephen Hocking [000426 09:23] wrote: > Is there any chance of extending the loader so that it can set the memory > size, rather than hard coding it into the kernel config file? This would be > quite useful for testing things which like a large amount of memory set aside > exclusively for hardware's use (I'm thinking of Utah-GLX's DMA buffers for > G400 cards here). Use the undocumented hw.physmem variable in the loader. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 9: 4:19 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 0E79A37BC89; Wed, 26 Apr 2000 09:04:11 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.9.3/8.9.3) id LAA24991; Wed, 26 Apr 2000 11:03:45 -0500 (CDT) (envelope-from dan) Date: Wed, 26 Apr 2000 11:03:45 -0500 From: Dan Nelson To: Sheldon Hearn Cc: Brooks Davis , Nate Lawson , freebsd-hackers@FreeBSD.ORG, freebsd-ports@FreeBSD.ORG, davidm@hpl.hp.com Subject: Re: floating point exceptions Message-ID: <20000426110345.A13173@dan.emsphone.com> References: <20000425000523.A17224@orion.ac.hmc.edu> <24238.956752200@axl.ops.uunet.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.9i In-Reply-To: <24238.956752200@axl.ops.uunet.co.za>; from "Sheldon Hearn" on Wed Apr 26 14:30:00 GMT 2000 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Apr 26), Sheldon Hearn said: > On Tue, 25 Apr 2000 00:05:23 MST, Brooks Davis wrote: > > > Is FreeBSD's behavior correct? Why or why not? You can use the > > > included code snippet to verify that this occurs. > > > > FreeBSD has traditionaly violated the IEEE FP standard in this > > regard. This is fixed in 5.0 and I think in 4.0-STABLE (though I > > can't remember what file this is in so I can't check.) > > Huh? I'm pretty sure you've got this backwards. FreeBSD has > traditionally upheld the standard and we only recently decided to go > with the flow in 5.0. No; we held our moral ground against IEEE, until 5.0 when we gave in. The IEEE standard says "trap nothing". For most programs, this is the wrong thing to do, since they are not signal-processing apps or numerical analysis programs and a divide by zero is a coding error. I'd rather have my program die on an unexpected divide by zero than continue with invalid data. Why should we treat (1.0/0.0) any differently from (1/0)? -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 9: 5: 1 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id C290437BE5F; Wed, 26 Apr 2000 09:04:36 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p51-dn01kiryunisiki.gunma.ocn.ne.jp [211.0.245.52]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id BAA00102; Thu, 27 Apr 2000 01:04:18 +0900 (JST) Message-ID: <390713D9.28C779DF@newsguy.com> Date: Thu, 27 Apr 2000 01:05:45 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: Alfred Perlstein Cc: Stephen Hocking , msmith@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Using the boot loader to set maximum memory size? References: <200004261528.XAA12560@bloop.craftncomp.com> <20000426092607.L9754@fw.wintelcom.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > > * Stephen Hocking [000426 09:23] wrote: > > Is there any chance of extending the loader so that it can set the memory > > size, rather than hard coding it into the kernel config file? This would be > > quite useful for testing things which like a large amount of memory set aside > > exclusively for hardware's use (I'm thinking of Utah-GLX's DMA buffers for > > G400 cards here). > > Use the undocumented hw.physmem variable in the loader. Patches for both /boot/help and loader.8 are accepted, of course. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org dcs@there.is.no.such.thing.as.a.bsdconspiracy.net GPL certainly doesn't meet Janis Joplin's definition of freedom: "Freedom is just another word for nothing left to lose." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 9:17: 1 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from jade.chc-chimes.com (jade.chc-chimes.com [216.28.46.6]) by hub.freebsd.org (Postfix) with ESMTP id 34C7237BA78; Wed, 26 Apr 2000 09:16:53 -0700 (PDT) (envelope-from billf@jade.chc-chimes.com) Received: by jade.chc-chimes.com (Postfix, from userid 1001) id C71551C4A; Wed, 26 Apr 2000 12:16:51 -0400 (EDT) Date: Wed, 26 Apr 2000 12:16:51 -0400 From: Bill Fumerola To: Dan Nelson Cc: Sheldon Hearn , Brooks Davis , Nate Lawson , freebsd-hackers@FreeBSD.ORG, freebsd-ports@FreeBSD.ORG, davidm@hpl.hp.com Subject: Re: floating point exceptions Message-ID: <20000426121651.M40387@jade.chc-chimes.com> References: <20000425000523.A17224@orion.ac.hmc.edu> <24238.956752200@axl.ops.uunet.co.za> <20000426110345.A13173@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000426110345.A13173@dan.emsphone.com>; from dnelson@emsphone.com on Wed, Apr 26, 2000 at 11:03:45AM -0500 X-Operating-System: FreeBSD 3.3-STABLE i386 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Apr 26, 2000 at 11:03:45AM -0500, Dan Nelson wrote: > Why should we treat (1.0/0.0) any differently from (1/0)? Because Linux has the uncanny ability to both divide by zero and produce the shittiest coders the world has ever seen. -- Bill Fumerola - Network Architect Computer Horizons Corp - CVM e-mail: billf@chc-chimes.com / billf@FreeBSD.org Office: 800-252-2421 x128 / Cell: 248-761-7272 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 9:21:59 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from corinth.bossig.com (corinth.bossig.com [208.26.239.66]) by hub.freebsd.org (Postfix) with ESMTP id 627AF37C123 for ; Wed, 26 Apr 2000 09:21:51 -0700 (PDT) (envelope-from kstewart@3-cities.com) Received: from 3-cities.com (unverified [208.26.241.99]) by corinth.bossig.com (Rockliffe SMTPRA 4.2.1) with ESMTP id ; Wed, 26 Apr 2000 09:26:06 -0700 Message-ID: <3907177C.5CFEC69A@3-cities.com> Date: Wed, 26 Apr 2000 09:21:16 -0700 From: Kent Stewart Organization: Columbia Basin Virtual Community Project X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Narvi Cc: Matthew Dillon , Michael Bacarella , Alfred Perlstein , Kevin Day , hackers@FreeBSD.ORG Subject: Re: Double buffered cp(1) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Narvi wrote: > > On Sat, 22 Apr 2000, Matthew Dillon wrote: > > [snip] > > > disk itself is probably the bottleneck. Disk writes tend to be > > somewhat slower then disk reads and the seeking alone (between source > > file and destination file), even when using a large block size, > > will reduce performance drastically verses simply reading or writing > > a single file linearly. Double buffering may help a disk-to-disk > > file copy, but I doubt it will help a disk-to-same-disk file copy. > > > > Wouldn't coping the file to another disk and then back to the original one > than just a simple copy in some cases be faster then? > > After all, you are saving a lot of head seeks. The problem is that if they are on the same data channel then you have conflicts for access to the data bus. Some products like SCSI are better suited for that environment but data still only flows one direction at a time. On the old ISA bus, you could just about watch data flow with an analyzer plugged on to a new interface card. We had one interface card that the data ready went true before the data was stored into the on_card memory. The cpu was fast enough that I could watch the bits in the memory change. I couldn't get good data until memory had stablized. Cray's were really good at handling data in 1988 because they had 100MB/s + 1000MB/s data channels. I'm not sure how wide the data channels were. It seems like the 100MB/s was 16 bytes wide and the 1000 MB/s was 32 bytes wide. Their high speed disks were striped to provide 20MB/s continuous transfers. Getting data off of the disk was far more important to throughput than writing the data. The queued read/write ability of the scsi drives made life better but the disk was still the bottle neck to high speed data. The PCI bus probably shares that honor on the modern PC. It is only 4 bytes wide and relatively slow. The new 64bit PCI bus will help but that is a long way from the 256 bit or 512 bit wide Cray data channels that Cray was using in 1988. A while back I was given some parameters that could change the time required for a 4.0-Stable buildworld. The only option that improved my buildworld time was "CFLAGS= -pipe". It saved about 140u seconds. The option "-Os" made a buildworld take 1/3 longer. I also did an installworld (and kernel) of a -Os system and that really didn't change the times. The jump for version 4.0 on a Celeron 433a was 3560u + 800s to 4950u + 800s. There are still some options to try but "softupdates" didn't help. The buildworld using an UW scsi for /usr/obj was actually a little bit longer than using a UDMA66 ATA HD. The scsi was flat out at 8MB/s where as the UDMA HD was capable of 12-14MB/s. The Maxtor UDMA drive had a 2MB cache and the IBM uw was much smaller. Kent -- Kent Stewart Richland, WA mailto:kstewart@3-cities.com http://www.3-cities.com/~kstewart/index.html FreeBSD News http://daily.daemonnews.org/ SETI(Search for Extraterrestrial Intelligence) @ HOME http://setiathome.ssl.berkeley.edu/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 9:57:45 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from happy.checkpoint.com (happy.checkpoint.com [199.203.156.41]) by hub.freebsd.org (Postfix) with ESMTP id 2815537B802 for ; Wed, 26 Apr 2000 09:57:40 -0700 (PDT) (envelope-from mellon@pobox.com) Received: (from mellon@localhost) by happy.checkpoint.com (8.9.3/8.9.3) id TAA02057; Wed, 26 Apr 2000 19:55:19 GMT (envelope-from mellon@pobox.com) Date: Wed, 26 Apr 2000 19:55:19 +0000 From: Anatoly Vorobey To: Doug Barton Cc: hackers@freebsd.org Subject: Re: commit MAKE_SHELL? Message-ID: <20000426195519.A2022@happy.checkpoint.com> References: ; <20000425170951.A29390@happy.checkpoint.com> <200004251528.RAA29727@m2.dynas.se> <20000425232447.A32567@happy.checkpoint.com> <390685E7.986C2EBA@gorean.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <390685E7.986C2EBA@gorean.org>; from Doug@gorean.org on Tue, Apr 25, 2000 at 11:00:07PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Apr 25, 2000 at 11:00:07PM -0700, Doug Barton wrote: > Anatoly Vorobey wrote: > > > Well, *should* we have a built-in "test"? I gather the original ash didn't > > have it due to the KIS principle. But if it speeds things up considerably, > > it's not much of a bloat, is it? I'd volunteer to write it. > > Unfortunately, the only way to tell for sure would be to do a couple > make worlds with the current sh, then do some with super-sh with the > built in 'test'. You are right. I will do it, and report the results. -- Anatoly Vorobey, mellon@pobox.com http://pobox.com/~mellon/ "Angels can fly because they take themselves lightly" - G.K.Chesterton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 9:59:43 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (adsl-63-202-176-132.dsl.snfc21.pacbell.net [63.202.176.132]) by hub.freebsd.org (Postfix) with ESMTP id 1157537BAB0; Wed, 26 Apr 2000 09:59:40 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id KAA03050; Wed, 26 Apr 2000 10:07:08 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200004261707.KAA03050@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Stephen Hocking Cc: msmith@freebsd.org, hackers@freebsd.org Subject: Re: Using the boot loader to set maximum memory size? In-reply-to: Your message of "Wed, 26 Apr 2000 23:28:48 +0800." <200004261528.XAA12560@bloop.craftncomp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Apr 2000 10:07:08 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Is there any chance of extending the loader so that it can set the memory > size, rather than hard coding it into the kernel config file? This would be > quite useful for testing things which like a large amount of memory set aside > exclusively for hardware's use (I'm thinking of Utah-GLX's DMA buffers for > G400 cards here). There are better ways to achieve that, but you can use: set hw.physmem= MAXMEM (i386 only) Limits the amount of physical memory space available to the system to bytes. may have a k, M or G suffix to indicate kilobytes, megabytes and gigabytes respectively. Note that the current i386 architecture limits this value to 4GB. On systems where memory cannot be accurately probed, this option provides a hint as to the actual size of system memory (which will be tested before use). -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 10: 0:28 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (adsl-63-202-176-132.dsl.snfc21.pacbell.net [63.202.176.132]) by hub.freebsd.org (Postfix) with ESMTP id A74E537BEA3 for ; Wed, 26 Apr 2000 10:00:24 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id KAA03066; Wed, 26 Apr 2000 10:08:01 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200004261708.KAA03066@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Alfred Perlstein Cc: Stephen Hocking , hackers@FreeBSD.ORG Subject: Re: Using the boot loader to set maximum memory size? In-reply-to: Your message of "Wed, 26 Apr 2000 09:26:08 PDT." <20000426092607.L9754@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Apr 2000 10:08:01 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > * Stephen Hocking [000426 09:23] wrote: > > Is there any chance of extending the loader so that it can set the memory > > size, rather than hard coding it into the kernel config file? This would be > > quite useful for testing things which like a large amount of memory set aside > > exclusively for hardware's use (I'm thinking of Utah-GLX's DMA buffers for > > G400 cards here). > > Use the undocumented hw.physmem variable in the loader. There isn't an "undocumented hw.physmem" variable, there's only a "documented hw.physmem" variable. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 10:22:45 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 398CE37B8BE; Wed, 26 Apr 2000 10:22:42 -0700 (PDT) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e3QHq2K24657; Wed, 26 Apr 2000 10:52:02 -0700 (PDT) Date: Wed, 26 Apr 2000 10:52:02 -0700 From: Alfred Perlstein To: Mike Smith Cc: Stephen Hocking , hackers@FreeBSD.ORG Subject: Re: Using the boot loader to set maximum memory size? Message-ID: <20000426105201.M9754@fw.wintelcom.net> References: <20000426092607.L9754@fw.wintelcom.net> <200004261708.KAA03066@mass.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004261708.KAA03066@mass.cdrom.com>; from msmith@FreeBSD.ORG on Wed, Apr 26, 2000 at 10:08:01AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Mike Smith [000426 10:46] wrote: > > * Stephen Hocking [000426 09:23] wrote: > > > Is there any chance of extending the loader so that it can set the memory > > > size, rather than hard coding it into the kernel config file? This would be > > > quite useful for testing things which like a large amount of memory set aside > > > exclusively for hardware's use (I'm thinking of Utah-GLX's DMA buffers for > > > G400 cards here). > > > > Use the undocumented hw.physmem variable in the loader. > > There isn't an "undocumented hw.physmem" variable, there's only a > "documented hw.physmem" variable. Ah, it's in loader.help, but not the manpage, I'll patch it asap. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 10:23:10 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from relay02.chello.nl (relay02.chello.nl [212.83.68.146]) by hub.freebsd.org (Postfix) with ESMTP id EA5BF37BF1A; Wed, 26 Apr 2000 10:22:56 -0700 (PDT) (envelope-from wkb@chello.nl) Received: from chello.nl ([213.46.78.184]) by relay02.chello.nl (InterMail vK.4.02.00.00 201-232-116 license 99c8f334c649856e3f2cdadc4054e412) with ESMTP id <20000426172249.PMQG22628.relay02@chello.nl>; Wed, 26 Apr 2000 19:22:49 +0200 Received: (from wkb@localhost) by chello.nl (8.9.3/8.9.3) id TAA01294; Wed, 26 Apr 2000 19:22:54 +0200 (CEST) (envelope-from wkb) Date: Wed, 26 Apr 2000 19:22:54 +0200 From: Wilko Bulte To: Bill Fumerola Cc: Dan Nelson , Sheldon Hearn , Brooks Davis , Nate Lawson , freebsd-hackers@FreeBSD.ORG, freebsd-ports@FreeBSD.ORG, davidm@hpl.hp.com Subject: Re: floating point exceptions Message-ID: <20000426192254.E1021@yedi.wbnet> Reply-To: wc.bulte@chello.nl References: <20000425000523.A17224@orion.ac.hmc.edu> <24238.956752200@axl.ops.uunet.co.za> <20000426110345.A13173@dan.emsphone.com> <20000426121651.M40387@jade.chc-chimes.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000426121651.M40387@jade.chc-chimes.com>; from billf@chc-chimes.com on Wed, Apr 26, 2000 at 12:16:51PM -0400 X-OS: FreeBSD 3.4-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Apr 26, 2000 at 12:16:51PM -0400, Bill Fumerola wrote: > On Wed, Apr 26, 2000 at 11:03:45AM -0500, Dan Nelson wrote: > > > Why should we treat (1.0/0.0) any differently from (1/0)? > > Because Linux has the uncanny ability to both divide by zero and produce > the shittiest coders the world has ever seen. Which brings me to the inevitable question: 'can NT divide by zero' ? ;-) -- Wilko Bulte Powered by FreeBSD http://www.freebsd.org http://www.tcja.nl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 10:51:11 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 9EEA937B78A for ; Wed, 26 Apr 2000 10:51:07 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA96154; Wed, 26 Apr 2000 10:51:02 -0700 (PDT) (envelope-from dillon) Date: Wed, 26 Apr 2000 10:51:02 -0700 (PDT) From: Matthew Dillon Message-Id: <200004261751.KAA96154@apollo.backplane.com> To: Kent Stewart Cc: Narvi , Michael Bacarella , Alfred Perlstein , Kevin Day , hackers@FreeBSD.ORG Subject: Re: Double buffered cp(1) References: <3907177C.5CFEC69A@3-cities.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The standard PCI bus can do 130 MBytes/sec. Even with overhead issues (setup for a DMA burst) it can still do 100 MBytes/sec. A standard SCSI controller can do 40, 80, and now even 160 MBytes/sec over the wire - standard copper cabling w/ LVD connectors (example below). A modern hard disk can do 10-30 MBytes/sec to/from the platter, assuming no seeks. But the moment it needs to seek the performance drops drastically ... generally down to 1-5 MBytes/sec. So in the case of a file copy over a SCSI bus, the physical disk is almost always going to be the limiting factor. -Matt da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled ^^^^ da0: 4340MB (8888924 512 byte sectors: 255H 63S/T 553C) da1 at ahc2 bus 0 target 0 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) da2 at ahc2 bus 0 target 1 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da2: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) Mounting root from ufs:/dev/da0s1a To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 11:33:27 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from corinth.bossig.com (corinth.bossig.com [208.26.239.66]) by hub.freebsd.org (Postfix) with ESMTP id 5873A37B95C for ; Wed, 26 Apr 2000 11:33:22 -0700 (PDT) (envelope-from kstewart@3-cities.com) Received: from 3-cities.com (unverified [208.26.241.99]) by corinth.bossig.com (Rockliffe SMTPRA 4.2.1) with ESMTP id ; Wed, 26 Apr 2000 11:37:41 -0700 Message-ID: <39073655.56A70C00@3-cities.com> Date: Wed, 26 Apr 2000 11:32:53 -0700 From: Kent Stewart Organization: Columbia Basin Virtual Community Project X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: Narvi , Michael Bacarella , Alfred Perlstein , Kevin Day , hackers@FreeBSD.ORG Subject: Re: Double buffered cp(1) References: <3907177C.5CFEC69A@3-cities.com> <200004261751.KAA96154@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > > The standard PCI bus can do 130 MBytes/sec. Even with overhead issues > (setup for a DMA burst) it can still do 100 MBytes/sec. But that depends on what is also going on at the same time. There are three other cards in my PCI bus. You can eliminate one because I wasn't using the sound card :). > > A standard SCSI controller can do 40, 80, and now even 160 MBytes/sec > over the wire - standard copper cabling w/ LVD connectors (example > below). This is where the cache size on the HD becomes important. It also acts like a hardware double buffering. > > A modern hard disk can do 10-30 MBytes/sec to/from the platter, assuming > no seeks. But the moment it needs to seek the performance drops > drastically ... generally down to 1-5 MBytes/sec. I haven't seen any 30MB/s. The 10K LVD IBM's were just about the fastest at 20MB/s continuous. The drop for UDMA drives is to even lower rates. > > So in the case of a file copy over a SCSI bus, the physical disk is > almost always going to be the limiting factor. I just noticed that mine isn't showing "Tagged Queueing Enabled" is that something I can set? The adapter is an Adaptec 2940uw. da0 at ahc0 bus 0 target 4 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) Kent -- Kent Stewart Richland, WA mailto:kstewart@3-cities.com http://www.3-cities.com/~kstewart/index.html FreeBSD News http://daily.daemonnews.org/ SETI(Search for Extraterrestrial Intelligence) @ HOME http://setiathome.ssl.berkeley.edu/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 11:51:40 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id F3EC337B970 for ; Wed, 26 Apr 2000 11:51:35 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.9.3/8.9.3) id NAA21930; Wed, 26 Apr 2000 13:51:11 -0500 (CDT) (envelope-from dan) Date: Wed, 26 Apr 2000 13:51:11 -0500 From: Dan Nelson To: Kent Stewart Cc: Matthew Dillon , Narvi , Michael Bacarella , Alfred Perlstein , Kevin Day , hackers@FreeBSD.ORG Subject: Re: Double buffered cp(1) Message-ID: <20000426135111.A21368@dan.emsphone.com> References: <3907177C.5CFEC69A@3-cities.com> <200004261751.KAA96154@apollo.backplane.com> <39073655.56A70C00@3-cities.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.9i In-Reply-To: <39073655.56A70C00@3-cities.com>; from "Kent Stewart" on Wed Apr 26 11:32:53 GMT 2000 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Apr 26), Kent Stewart said: > I just noticed that mine isn't showing "Tagged Queueing Enabled" is > that something I can set? The adapter is an Adaptec 2940uw. > > da0 at ahc0 bus 0 target 4 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) > da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) The CAM code has a quirk entry for IBM DCAS drives that turns it off; check out /sys/cam/cam_xpt.c, line 320. I suggest benchmarking with and without the quirk entry, and if it's faster with tagged queueing, update PR kern/10398. -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 11:58:11 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 5E9B937BDC0 for ; Wed, 26 Apr 2000 11:58:07 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA96849; Wed, 26 Apr 2000 11:58:00 -0700 (PDT) (envelope-from dillon) Date: Wed, 26 Apr 2000 11:58:00 -0700 (PDT) From: Matthew Dillon Message-Id: <200004261858.LAA96849@apollo.backplane.com> To: Dan Nelson Cc: Kent Stewart , Narvi , Michael Bacarella , Alfred Perlstein , Kevin Day , hackers@FreeBSD.ORG Subject: Re: Double buffered cp(1) References: <3907177C.5CFEC69A@3-cities.com> <200004261751.KAA96154@apollo.backplane.com> <39073655.56A70C00@3-cities.com> <20000426135111.A21368@dan.emsphone.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :In the last episode (Apr 26), Kent Stewart said: :> I just noticed that mine isn't showing "Tagged Queueing Enabled" is :> that something I can set? The adapter is an Adaptec 2940uw. :> :> da0 at ahc0 bus 0 target 4 lun 0 :> da0: Fixed Direct Access SCSI-2 device :> da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) :> da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) : :The CAM code has a quirk entry for IBM DCAS drives that turns it off; :check out /sys/cam/cam_xpt.c, line 320. I suggest benchmarking with :and without the quirk entry, and if it's faster with tagged queueing, :update PR kern/10398. : :-- : Dan Nelson : dnelson@emsphone.com I seem to remember a discussion last year about tagged commands being a lot slower on IBM drives being the reason why tagged queueing was turned off. I wonder if IBM has fixed the problem in their later drives? Note that tagging is different from disconnection. Tagging allows you to queue multiple commands (e.g. multiple reads & writes) to the drive. Disconnection is a bus-level protocol which allows the SCSI bus to be freed up after sending a command (e.g. like a read) so other SCSI devices can use the bus while the drive is seeking. Disconnection is more important. Tagging is nice in that it can absorb command queueing overheads and allows the drive to prioritize the transactions based on the characteristics of the media, but tagging is not going to make much of a difference when you only have one or two processes banging on the drive. Tagging shows its suds on more heavily loaded systems, when dozens of processes are banging on the disks. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 12: 9:26 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id E15E037B970 for ; Wed, 26 Apr 2000 12:09:06 -0700 (PDT) (envelope-from sthaug@nethelp.no) Received: (qmail 19284 invoked by uid 1001); 26 Apr 2000 18:58:38 +0000 (GMT) To: kstewart@3-cities.com Cc: dillon@apollo.backplane.com, narvi@haldjas.folklore.ee, mbac@nyct.net, bright@wintelcom.net, toasty@dragondata.com, hackers@FreeBSD.ORG Subject: Re: Double buffered cp(1) From: sthaug@nethelp.no In-Reply-To: Your message of "Wed, 26 Apr 2000 11:32:53 -0700" References: <39073655.56A70C00@3-cities.com> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Wed, 26 Apr 2000 20:58:38 +0200 Message-ID: <19282.956775518@verdi.nethelp.no> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > A modern hard disk can do 10-30 MBytes/sec to/from the platter, assuming > > no seeks. But the moment it needs to seek the performance drops > > drastically ... generally down to 1-5 MBytes/sec. > > I haven't seen any 30MB/s. The 10K LVD IBM's were just about the > fastest at 20MB/s continuous. The drop for UDMA drives is to even > lower rates. The IBM DPTA-372730 will do 23 MB/s continuous - this is a 7200 RPM IDE drive with very high bit density. There are IDE drives that do more, and I certainly expect the new 36 GB 1" 10K drives to do more. > I just noticed that mine isn't showing "Tagged Queueing Enabled" is > that something I can set? The adapter is an Adaptec 2940uw. > > da0 at ahc0 bus 0 target 4 lun 0 > da0: Fixed Direct Access SCSI-2 device > da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) > da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) The DCAS-34330 is quirked out - which may not always be sensible. See /sys/cam/cam_xpt.c. Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 13:19:50 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 3579637B64B for ; Wed, 26 Apr 2000 13:19:46 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA97309; Wed, 26 Apr 2000 13:19:44 -0700 (PDT) (envelope-from dillon) Date: Wed, 26 Apr 2000 13:19:44 -0700 (PDT) From: Matthew Dillon Message-Id: <200004262019.NAA97309@apollo.backplane.com> To: freebsd-hackers@freebsd.org Subject: Removing synchronizing instruction from MP unlock References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I had added a synchronizing instruction to the MP unlock code in November after the issue was brought up in the lists and linux folks thought there might be a synchronization issue. It turns out that there is no issue. This was refered to me by Mike Silbersack: http://kernelnotes.org/lnxlists/linux-kernel/lk_0004_04/msg00332.html I have decided to remove the synchronizing instruction from the MP unlock code. There are three cases: * single cpu using the MP lock. - 200 nS faster with the synchronizing instruction removed. * two cpu's using the MP lock, in contention (one holds it while the other is trying to get it) - 700 nS SLOWER with the synchronizing instruction removed. * two cpu's using the MP lock, NOT in contention (one holds it and releases it, then sometime later the other holds it and releases it). - 400 ns FASTER. Since our goal is to reduce lock contention in the first place by removing the MP lock, and since the most common instance of MP use eats some user time and does not result in billions of short-term MP locks being simultaniously contended for by more then one cpu (this is different from long-term contention, where 700 nS doesn't matter anyway), I have decided to remove the synchronizing instruction from the unlock code for FreeBSD. Linus has indicated (if you follow the thread in the above URL), that he will be doing the same thing for the Linux MP unlock code as well. This is just a head's up. No review is necessary. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 13:31:52 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ns1.sunesi.net (ns1.sunesi.net [196.15.192.194]) by hub.freebsd.org (Postfix) with ESMTP id 969A237B904 for ; Wed, 26 Apr 2000 13:31:47 -0700 (PDT) (envelope-from nbm@sunesi.net) Received: from nbm by ns1.sunesi.net with local (Exim 3.03 #1) id 12kYT1-0005FB-00; Wed, 26 Apr 2000 22:31:27 +0200 Date: Wed, 26 Apr 2000 22:31:27 +0200 From: Neil Blakey-Milner To: Doug Barton Cc: freebsd-hackers@freebsd.org, adrian@creative.net.au Subject: Re: Safe sourcing of rc files Message-ID: <20000426223127.A20023@mithrandr.moria.org> References: <38F17E7A.5892318A@gorean.org> <20000419165123.A59794@mithrandr.moria.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000419165123.A59794@mithrandr.moria.org>; from nbm@mithrandr.moria.org on Wed, Apr 19, 2000 at 04:51:24PM +0200 Organization: Sunesi Clinical Systems X-Operating-System: FreeBSD 3.3-RELEASE i386 X-URL: http://rucus.ru.ac.za/~nbm/ Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed 2000-04-19 (16:51), Neil Blakey-Milner wrote: > I have another idea: We make a sh script named "rcsource" or whatever, > which we source when we want to have the rc environment, stealing your > code maliciously: > > /-- > sourcercs_sourced_files= > sourcercs ( ) { > local rc_conf_files > for i in $*; do > case "${sourcercs_sourced_files}" in > *:$i:*) > ;; > *) > sourcercs_sourced_files="${sourcercs_sourced_files}:$i:" > echo $i > if [ -r $i ]; then > . $i > sourcercs ${rc_conf_files} > fi > ;; > esac > done > } > sourcercs /etc/defaults/rc.conf > \-- Unless someone comes back with negative feedback, I'll be pushing for a commit for this (and all that depend on this change) on the weekend. Consider this a request for review and comment. Neil -- Neil Blakey-Milner Hacker In Chief, Sunesi Clinical Systems nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 13:44:43 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from corinth.bossig.com (mail.dohboys.com [208.26.253.10]) by hub.freebsd.org (Postfix) with ESMTP id 12D2137B781 for ; Wed, 26 Apr 2000 13:44:39 -0700 (PDT) (envelope-from kstewart@3-cities.com) Received: from 3-cities.com (unverified [208.26.241.59]) by corinth.bossig.com (Rockliffe SMTPRA 4.2.1) with ESMTP id ; Wed, 26 Apr 2000 13:48:59 -0700 Message-ID: <39075519.B6085190@3-cities.com> Date: Wed, 26 Apr 2000 13:44:09 -0700 From: Kent Stewart Organization: Columbia Basin Virtual Community Project X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dan Nelson Cc: Matthew Dillon , Narvi , Michael Bacarella , Alfred Perlstein , Kevin Day , hackers@FreeBSD.ORG Subject: Re: Double buffered cp(1) References: <3907177C.5CFEC69A@3-cities.com> <200004261751.KAA96154@apollo.backplane.com> <39073655.56A70C00@3-cities.com> <20000426135111.A21368@dan.emsphone.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dan Nelson wrote: > > In the last episode (Apr 26), Kent Stewart said: > > I just noticed that mine isn't showing "Tagged Queueing Enabled" is > > that something I can set? The adapter is an Adaptec 2940uw. > > > > da0 at ahc0 bus 0 target 4 lun 0 > > da0: Fixed Direct Access SCSI-2 device > > da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit) > > da0: 4134MB (8467200 512 byte sectors: 255H 63S/T 527C) > > The CAM code has a quirk entry for IBM DCAS drives that turns it off; > check out /sys/cam/cam_xpt.c, line 320. I suggest benchmarking with > and without the quirk entry, and if it's faster with tagged queueing, > update PR kern/10398. What would you suggest. Do you remove the entry or just change the tags field? It has mintags=0 and maxtags=0. The other entries have mintags=24 and maxtags=32. I 've have about 6 hours of buildworlds on it right now. Plus some other benchmarking. Kent > > -- > Dan Nelson > dnelson@emsphone.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- Kent Stewart Richland, WA mailto:kstewart@3-cities.com http://www.3-cities.com/~kstewart/index.html FreeBSD News http://daily.daemonnews.org/ SETI(Search for Extraterrestrial Intelligence) @ HOME http://setiathome.ssl.berkeley.edu/ Hunting Archibald Stewart, b 1802 in Ballymena, Antrim Co., NIR http://www.3-cities.com/~kstewart/genealogy/archibald_stewart.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 14:29: 8 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from happy.checkpoint.com (happy.checkpoint.com [199.203.156.41]) by hub.freebsd.org (Postfix) with ESMTP id 09EF537B974 for ; Wed, 26 Apr 2000 14:28:59 -0700 (PDT) (envelope-from mellon@pobox.com) Received: (from mellon@localhost) by happy.checkpoint.com (8.9.3/8.9.3) id AAA92211; Thu, 27 Apr 2000 00:29:00 GMT (envelope-from mellon@pobox.com) Date: Thu, 27 Apr 2000 00:29:00 +0000 From: Anatoly Vorobey To: Doug Barton Cc: hackers@FreeBSD.ORG Subject: Re: commit MAKE_SHELL? Message-ID: <20000427002859.A78245@happy.checkpoint.com> References: ; <20000425170951.A29390@happy.checkpoint.com> <200004251528.RAA29727@m2.dynas.se> <20000425232447.A32567@happy.checkpoint.com> <390685E7.986C2EBA@gorean.org> <20000426195519.A2022@happy.checkpoint.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000426195519.A2022@happy.checkpoint.com>; from mellon@pobox.com on Wed, Apr 26, 2000 at 07:55:19PM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Apr 26, 2000 at 07:55:19PM +0000, Anatoly Vorobey wrote: > > Unfortunately, the only way to tell for sure would be to do a couple > > make worlds with the current sh, then do some with super-sh with the > > built in 'test'. > > You are right. I will do it, and report the results. Reporting back ;) Adding built-in "test" turns out to be frightfully easy, by compiling into the shell the real test(1) code (builtin printf works this way, too). I have broken world right now so I can't test it, but on running several configure scripts from ports I generally save from 9% to 18% of time. Maybe someone would like to test/review/comment on this? Patches below. In test(1), errx() calls had to be changed into warnx() calls because the latter are #define'd to be something else when compiling within the shell, in order to capture the output when necessary. To test, 'sh /usr/src/bin/test/TEST.sh', run configures, build worlds, etc. ;) Index: test.c =================================================================== RCS file: /freebsd/cvs/src/bin/test/test.c,v retrieving revision 1.29 diff -u -r1.29 test.c --- test.c 1999/12/28 09:34:57 1.29 +++ test.c 2000/04/26 22:30:13 @@ -10,10 +10,12 @@ * This program is in the Public Domain. */ +#if !defined(SHELL) #ifndef lint static const char rcsid[] = "$FreeBSD: src/bin/test/test.c,v 1.29 1999/12/28 09:34:57 sheldonh Exp $"; #endif /* not lint */ +#endif /* not a sh builtin */ #include #include @@ -26,6 +28,11 @@ #include #include +#ifdef SHELL +#define main testcmd +#include "bltin/bltin.h" +#endif + /* test(1) accepts the following grammar: oexpr ::= aexpr | aexpr "-o" oexpr ; aexpr ::= nexpr | nexpr "-a" aexpr ; @@ -171,7 +178,7 @@ p++; if (strcmp(p, "[") == 0) { if (strcmp(argv[--argc], "]")) - errx(2, "missing ]"); + return( (warnx("missing ]") , 2) ); argv[argc] = NULL; } @@ -195,9 +202,9 @@ { if (op && *op) - errx(2, "%s: %s", op, msg); + exit( (warnx("%s: %s", op, msg), 2) ); else - errx(2, "%s", msg); + exit( (warnx("%s", msg), 2) ); } static int Index: Makefile =================================================================== RCS file: /freebsd/cvs/src/bin/sh/Makefile,v retrieving revision 1.30 diff -u -r1.30 Makefile --- Makefile 1999/09/08 15:40:43 1.30 +++ Makefile 2000/04/27 00:24:55 @@ -5,7 +5,7 @@ SHSRCS= alias.c arith.y arith_lex.l cd.c echo.c error.c eval.c exec.c expand.c \ histedit.c input.c jobs.c mail.c main.c memalloc.c miscbltin.c \ mystring.c options.c output.c parser.c printf.c redir.c show.c \ - trap.c var.c + test.c trap.c var.c GENSRCS= builtins.c init.c nodes.c syntax.c GENHDRS= builtins.h nodes.h syntax.h token.h y.tab.h SRCS= ${SHSRCS} ${GENSRCS} ${GENHDRS} y.tab.h @@ -22,7 +22,7 @@ # for debug: # CFLAGS+= -g -DDEBUG=2 -.PATH: ${.CURDIR}/bltin ${.CURDIR}/../../usr.bin/printf +.PATH: ${.CURDIR}/bltin ${.CURDIR}/../../usr.bin/printf ${.CURDIR}/../test CLEANFILES+= mkinit mkinit.o mknodes mknodes.o \ mksyntax mksyntax.o Index: builtins.def =================================================================== RCS file: /freebsd/cvs/src/bin/sh/builtins.def,v retrieving revision 1.7 diff -u -r1.7 builtins.def --- builtins.def 1999/08/27 23:15:08 1.7 +++ builtins.def 2000/04/27 00:25:08 @@ -80,6 +80,7 @@ setcmd set setvarcmd setvar shiftcmd shift +testcmd test [ trapcmd trap truecmd : true typecmd type -- Anatoly Vorobey, mellon@pobox.com http://pobox.com/~mellon/ "Angels can fly because they take themselves lightly" - G.K.Chesterton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 14:30:15 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mauibuilt.com (mauibuilt.com [205.166.249.50]) by hub.freebsd.org (Postfix) with ESMTP id DD8E737BCD4 for ; Wed, 26 Apr 2000 14:30:11 -0700 (PDT) (envelope-from freebsd@mauibuilt.com) Received: (from freebsd@localhost) by mauibuilt.com (8.9.3/8.9.3) id LAA27954 for freebsd-hackers@freebsd.org; Wed, 26 Apr 2000 11:41:25 -1000 (HST) (envelope-from freebsd) From: FreeBSD MAIL Message-Id: <200004262141.LAA27954@mauibuilt.com> Subject: xe driver To: freebsd-hackers@freebsd.org Date: Wed, 26 Apr 2000 11:41:25 -1000 (HST) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG FYI I tried the xe driver in 4.0-Stable and could not get it to work. I have a 16bit Xircomn RE-10 ethernet adaptor. here is what I tried /etc/pccard.conf # Xircom CreditCard Ethernet 10/100 + modem (Ethernet part) card "Xircom" "Ethernet Adapter" config auto "xe1" 9 insert logger -t pccard:$device -s Xircom CreditCard Modem inserted insert /etc/pccard_ether $device remove logger -t pccard:$device -s Xircom CreditCard Modem removed remove /sbin/ifconfig $device delete also tried config 0x1, 0x27 ,0x15 and "xe0" cruft from insert... Apr 27 06:24:33 ricoh /kernel: pccard: card inserted, slot 1 Apr 27 06:24:38 ricoh pccardd[409]: Card "Xircom"("Ethernet Adapter") matched "Xircom" ("Ethernet Adapter") Apr 27 06:24:38 ricoh pccardd[409]: Card "Xircom"("Ethernet Adapter") matched "Xircom" ("Ethernet Adapter") Apr 27 06:24:44 ricoh /kernel: xe1: xe: Probing Apr 27 06:24:44 ricoh /kernel: xe1: xe: Probing Apr 27 06:24:44 ricoh /kernel: xe1: Can't map in cis Apr 27 06:24:44 ricoh /kernel: xe1: Can't map in cis Apr 27 06:24:44 ricoh pccardd[409]: driver allocation failed for Xircom(Ethernet Adapter): Device not configured Apr 27 06:24:44 ricoh pccardd[409]: driver allocation failed for Xircom(Ethernet Adapter): Device not configured Ill keep trying as soon as I hear about updates... RP puga@mauibuilt.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 17:17:51 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from nothing-going-on.demon.co.uk (nothing-going-on.demon.co.uk [193.237.89.66]) by hub.freebsd.org (Postfix) with ESMTP id 0A45337BDB4; Wed, 26 Apr 2000 17:17:46 -0700 (PDT) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.9.3/8.9.3) id BAA68409; Thu, 27 Apr 2000 01:07:55 +0100 (BST) (envelope-from nik) Date: Thu, 27 Apr 2000 01:07:55 +0100 From: Nik Clayton To: Joseph Jacobson Cc: Nik Clayton , hackers@FreeBSD.ORG Subject: Re: No route for 127/8 to lo0 (?) Message-ID: <20000427010755.A67291@catkin.nothing-going-on.org> References: <20000421200201.A34984@catkin.nothing-going-on.org> <200004242328.TAA07013@home.my.domain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004242328.TAA07013@home.my.domain>; from jacobson@pobox.com on Mon, Apr 24, 2000 at 07:28:32PM -0400 Organization: FreeBSD Project Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Apr 24, 2000 at 07:28:32PM -0400, Joseph Jacobson wrote: > See RFC1122, section 3.2.1.3, available at > http://www.cis.ohio-state.edu/htbin/rfc/rfc1122.html > http://www.faqs.org/rfcs/rfc1122.html Right. Assuming we're looking at the same section, it says: [...] (g) { 127, } Internal host loopback address. Addresses of this form MUST NOT appear outside a host. [...] which is the only discussion of 127/8 I see in that document. The behaviour I'm seeing is that packets to 127.255.255.255 (i.e., broadcasts on the 127/8 net) are being sent out the default route, because on FreeBSD (at least, FreeBSD 3-stable), there's only a host route for 127.0.0.1, not a network route. Per the RFC, that's incorrect behaviour, right? The RFC also says: For most purposes, a datagram addressed to a broadcast or multicast destination is processed as if it had been addressed to one of the host's IP addresses; Is there some special-case for 127/8 that's covered by the "For most purposes" line? Cheers, N -- Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. Telephone line, $24.95 a month. Software, free. USENET transmission, hundreds if not thousands of dollars. Thinking before posting, priceless. Somethings in life you can't buy. For everything else, there's MasterCard. -- Graham Reed, in the Scary Devil Monastery To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 17:24:39 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by hub.freebsd.org (Postfix) with ESMTP id 895B637BD63; Wed, 26 Apr 2000 17:24:35 -0700 (PDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.9.3/8.9.3) id TAA08864; Wed, 26 Apr 2000 19:24:16 -0500 (CDT) (envelope-from dan) Date: Wed, 26 Apr 2000 19:24:16 -0500 From: Dan Nelson To: Andrew Reilly Cc: Sheldon Hearn , Brooks Davis , Nate Lawson , freebsd-hackers@FreeBSD.ORG, freebsd-ports@FreeBSD.ORG, davidm@hpl.hp.com Subject: Re: floating point exceptions Message-ID: <20000426192416.A8019@dan.emsphone.com> References: <20000425000523.A17224@orion.ac.hmc.edu> <24238.956752200@axl.ops.uunet.co.za> <20000426110345.A13173@dan.emsphone.com> <20000427093434.A81401@gurney.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.9i In-Reply-To: <20000427093434.A81401@gurney.reilly.home>; from "Andrew Reilly" on Thu Apr 27 09:34:34 GMT 2000 X-OS: FreeBSD 5.0-CURRENT Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In the last episode (Apr 27), Andrew Reilly said: > > Because 0.0 might be the closest approximation to whatever > number you were really trying to divide by that the hardware can > manage. 0 is never an approximation to 1 or -1. Aaah, but that assumes you're not also trapping on underflow :) -- Dan Nelson dnelson@emsphone.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 20:16:42 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 3759C37B8ED for ; Wed, 26 Apr 2000 20:16:39 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com (p29-dn01kiryunisiki.gunma.ocn.ne.jp [211.0.245.30]) by peach.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id MAA18100; Thu, 27 Apr 2000 12:16:34 +0900 (JST) Message-ID: <3907B179.6D05FAB2@newsguy.com> Date: Thu, 27 Apr 2000 12:18:17 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,pt-BR,ja MIME-Version: 1.0 To: George Cox Cc: freebsd-hackers@freebsd.org Subject: Re: How about building modules along with the kernel? References: <3906C526.A9F3EF02@newsguy.com> <20000426185707.A361@trafalgar.sophos.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [cc'ing to hackers, to get this archived] George Cox wrote: > > On 26/04 19:29, Daniel C. Sobral wrote: > > > BTW, loader reads FAT just fine too, thank you. > > I have a related question :-) > > Is there any way I can put a FreeBSD kernel on a DOS partition, and load > it, specifying the root device (different from the DOS partition device) > that I want it to use? Sure. There are many variations that you can try. For example, you can put something like kernel="disk1s1:/kernel" in /boot/loader.conf, which will cause the loader to get the kernel from said disk/slice. Now, assume FreeBSD is on disk2 or disk1s2, for example, and you tell booteasy (boot0) to boot from said disk. The root device will be the one you asked booteasy to boot FreeBSD from (and where loader will be loaded from), while the kernel will be coming from the other disk. Alternatively, there is the variable rootdev you can use to specify an alternate root device. See loader(8) for more information, as well as "help" from the loader prompt. :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org dcs@there.is.no.such.thing.as.a.bsdconspiracy.net GPL certainly doesn't meet Janis Joplin's definition of freedom: "Freedom is just another word for nothing left to lose." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 20:27:37 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 4DDC037BE47 for ; Wed, 26 Apr 2000 20:27:24 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Wed, 26 Apr 2000 23:27:11 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: hackers@FreeBSD.org Subject: lock-ups due to the scheduler Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I dropped hints that there may be issues about 3 weeks ago, as my machine had locked up for apparently no reason, and I had no idea why until recently. It seems that it has everything to do with running things that use lots of CPU at a very high priority (I use -20). I've been struggling for a few days with this... and what happens is that the kernel never executes any user processes (or does so so very rarely that I really can't detect it at all, in any application, the execution). I'm not really sure what's happening, but it definitely is with the scheduler: if I cap the scheduler's priority computation on the lower end to keep user processes from not executing with a p_priority < PUSER, the system can get slightly unresponsive, but it does not lock up. The modifications I made to allow prevention of this follow my signature. This is a deadlock-type situation, and I can reproduce it at will, so I'll try to explain the steps I can reproduce it with. 1. start XMMS at -20 priority, and play something 2. XMMS is decoding audio and other random things, nothing huge, but at about 15-20% CPU. XMMS sends decoded mp3 (archives of CDs I own) to the EsounD daemon (esd), which takes 2-3% cpu or so, and XFree86 itself takes a good 5-10% cpu. 3. Start a "Visualization" plugin, which basically takes XMMS to full CPU usage (as much as it can get), and things lock up. XMMS is the curproc for every single time I've polled it (using DDB, for example), and I stop hearing audio. XFree86 would be doing the X11 servering, and esd would mostly be writing to the audio device or reading from its socket, so usually in PRIBIO or PSOCK. At this point, the system is really locked up, and there's nothing I can do. I can, however, get a coredump and have the entire system state at this point. I'm certain that that other people here will be able to try the same tests, of course on 5.0-CURRENT, and possibly reproduce them exactly the same as it happens for me. I can grovel in a coredump to get information about the system as it was running at the time, so if anyone can provide hints as to where to check for what happened that makes things lock up nowadays, I'll be grateful, and I'll be able to try almost anything to get this fixed. If you're familiar with the scheduler area of the system, please help. I have noone's arm to twist or anything of the sort, so I'm really going out on a limb hoping someone will be able to try to help me fix this. Note that I've taken my HZ=1000 line out of my kernel config, so I'm running at a standard hz = 100 and a kern.quantum of 20000. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' Index: kern_synch.c =================================================================== RCS file: /usr2/ncvs/src/sys/kern/kern_synch.c,v retrieving revision 1.89 diff -u -u -r1.89 kern_synch.c --- kern_synch.c 2000/03/28 18:06:42 1.89 +++ kern_synch.c 2000/04/27 00:55:21 @@ -903,6 +903,10 @@ maybe_resched(p); } +static int priority_lower_cap = 0; +SYSCTL_INT(_debug, OID_AUTO, enable_priority_lower_cap, CTLFLAG_RW, + &priority_lower_cap, 0, ""); + /* * Compute the priority of a process when running in user mode. * Arrange to reschedule if the resulting priority is better @@ -917,6 +921,12 @@ if (p->p_rtprio.type == RTP_PRIO_NORMAL) { newpriority = PUSER + p->p_estcpu / INVERSE_ESTCPU_WEIGHT + NICE_WEIGHT * p->p_nice; + if (priority_lower_cap && newpriority < PUSER) { + if (p == curproc) + uprintf("kernel: tried to use priority %d\n", + newpriority); + newpriority = PUSER; + } newpriority = min(newpriority, MAXPRI); p->p_usrpri = newpriority; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 20:35:49 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from alcanet.com.au (mail.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id EB69337B670 for ; Wed, 26 Apr 2000 20:35:44 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <115207>; Thu, 27 Apr 2000 13:36:11 +1000 Content-return: prohibited From: Peter Jeremy Subject: Re: commit MAKE_SHELL? To: hackers@FreeBSD.ORG Message-Id: <00Apr27.133611est.115207@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii Date: Thu, 27 Apr 2000 13:36:11 +1000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000 23:00:07 -0700, Doug Barton wrote: >Anatoly Vorobey wrote: > >> Well, *should* we have a built-in "test"? I gather the original ash didn't >> have it due to the KIS principle. But if it speeds things up considerably, >> it's not much of a bloat, is it? I'd volunteer to write it. > > Unfortunately, the only way to tell for sure would be to do a couple >make worlds with the current sh, then do some with super-sh with the >built in 'test'. A somewhat quicker (though not quite as accurate) check is to do a make buildworld with accounting on. Based on this, the most-executed (>1000) commands (after merging aliases) are: 23743 cpp 23912 sh sh* 17060 cc 15583 as 13689 cc1 17934 test [ 12544 ld 11725 mv 7366 make 4904 rm 2999 ln 2160 sed 2102 gzip 1454 mkdir (There was some other system activity, but I don't think it would affect the results). This suggests that making test/[ a builtin would probably help, but probably not nearly as much as reducing the number of shells exec'd (ie making make(1) a bit smarter). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Apr 26 22:47:46 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id 3C44C37B933; Wed, 26 Apr 2000 22:47:42 -0700 (PDT) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.10.1/8.10.1) id e3R5lfi24004; Thu, 27 Apr 2000 01:47:41 -0400 (EDT) Date: Thu, 27 Apr 2000 01:47:41 -0400 (EDT) From: Luoqi Chen Message-Id: <200004270547.e3R5lfi24004@lor.watermarkgroup.com> To: green@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: lock-ups due to the scheduler Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is quite interesting. I'm no scheduler expert, but my understanding is priority < PUSER won't degrade and is only set in kernel mode after waking up from a sleep. In user mode, processes should always have priority p_usrpri >= PUSER, it is obviously not true for a negative nice value: > newpriority = PUSER + p->p_estcpu / INVERSE_ESTCPU_WEIGHT + > NICE_WEIGHT * p->p_nice; We should probably offset p->p_nice by PRIO_MIN, > newpriority = PUSER + p->p_estcpu / INVERSE_ESTCPU_WEIGHT + > NICE_WEIGHT * (p->p_nice - PRIO_MIN); To fully utilize the 20 out of 32 run queues for user priorities, we might want to change NICE_WEIGHT from 2 to 1, and upper limit of p_estcpu to #define ESTCPULIM(e) \ min((e), INVERSE_ESTCPU_WEIGHT * (NICE_WEIGHT * (PRIO_MAX - PRIO_MIN) - PPQ) + \ INVERSE_ESTCPU_WEIGHT - 1) so that a cpu hog at nice 0 would have about the same priority as a low cpu usage nice +20 process. -lq > I dropped hints that there may be issues about 3 weeks ago, as my machine > had locked up for apparently no reason, and I had no idea why until > recently. It seems that it has everything to do with running things that > use lots of CPU at a very high priority (I use -20). > > I've been struggling for a few days with this... and what happens is that > the kernel never executes any user processes (or does so so very rarely > that I really can't detect it at all, in any application, the execution). > > I'm not really sure what's happening, but it definitely is with the > scheduler: if I cap the scheduler's priority computation on the lower > end to keep user processes from not executing with a p_priority < PUSER, > the system can get slightly unresponsive, but it does not lock up. > The modifications I made to allow prevention of this follow my signature. > > This is a deadlock-type situation, and I can reproduce it at will, so I'll > try to explain the steps I can reproduce it with. > > 1. start XMMS at -20 priority, and play something > 2. XMMS is decoding audio and other random things, nothing huge, but at > about 15-20% CPU. XMMS sends decoded mp3 (archives of CDs I own) to > the EsounD daemon (esd), which takes 2-3% cpu or so, and XFree86 > itself takes a good 5-10% cpu. > 3. Start a "Visualization" plugin, which basically takes XMMS to full > CPU usage (as much as it can get), and things lock up. XMMS is the > curproc for every single time I've polled it (using DDB, for example), > and I stop hearing audio. XFree86 would be doing the X11 servering, > and esd would mostly be writing to the audio device or reading from its > socket, so usually in PRIBIO or PSOCK. > > At this point, the system is really locked up, and there's nothing I can > do. I can, however, get a coredump and have the entire system state at > this point. I'm certain that that other people here will be able to try > the same tests, of course on 5.0-CURRENT, and possibly reproduce them > exactly the same as it happens for me. I can grovel in a coredump to > get information about the system as it was running at the time, so if > anyone can provide hints as to where to check for what happened that > makes things lock up nowadays, I'll be grateful, and I'll be able to > try almost anything to get this fixed. > > If you're familiar with the scheduler area of the system, please help. > I have noone's arm to twist or anything of the sort, so I'm really > going out on a limb hoping someone will be able to try to help me fix > this. Note that I've taken my HZ=1000 line out of my kernel config, > so I'm running at a standard hz = 100 and a kern.quantum of 20000. > > -- > Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / > green@FreeBSD.org `------------------------------' > > Index: kern_synch.c > =================================================================== > RCS file: /usr2/ncvs/src/sys/kern/kern_synch.c,v > retrieving revision 1.89 > diff -u -u -r1.89 kern_synch.c > --- kern_synch.c 2000/03/28 18:06:42 1.89 > +++ kern_synch.c 2000/04/27 00:55:21 > @@ -903,6 +903,10 @@ > maybe_resched(p); > } > > +static int priority_lower_cap = 0; > +SYSCTL_INT(_debug, OID_AUTO, enable_priority_lower_cap, CTLFLAG_RW, > + &priority_lower_cap, 0, ""); > + > /* > * Compute the priority of a process when running in user mode. > * Arrange to reschedule if the resulting priority is better > @@ -917,6 +921,12 @@ > if (p->p_rtprio.type == RTP_PRIO_NORMAL) { > newpriority = PUSER + p->p_estcpu / INVERSE_ESTCPU_WEIGHT + > NICE_WEIGHT * p->p_nice; > + if (priority_lower_cap && newpriority < PUSER) { > + if (p == curproc) > + uprintf("kernel: tried to use priority %d\n", > + newpriority); > + newpriority = PUSER; > + } > newpriority = min(newpriority, MAXPRI); > p->p_usrpri = newpriority; > } > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 0:13:23 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from sr14.nsw-remote.bigpond.net.au (sr14.nsw-remote.bigpond.net.au [24.192.3.29]) by hub.freebsd.org (Postfix) with ESMTP id 0617837B933 for ; Thu, 27 Apr 2000 00:13:15 -0700 (PDT) (envelope-from areilly@nsw.bigpond.net.au) Received: from areilly.bpc-users.org (CPE-144-132-171-71.nsw.bigpond.net.au [144.132.171.71]) by sr14.nsw-remote.bigpond.net.au (Pro-8.9.3/8.9.3) with SMTP id JAA04951 for ; Thu, 27 Apr 2000 09:34:35 +1000 (EST) Received: (qmail 82165 invoked by uid 1000); 26 Apr 2000 23:34:34 -0000 From: "Andrew Reilly" Date: Thu, 27 Apr 2000 09:34:34 +1000 To: Dan Nelson Cc: Sheldon Hearn , Brooks Davis , Nate Lawson , freebsd-hackers@FreeBSD.ORG, freebsd-ports@FreeBSD.ORG, davidm@hpl.hp.com Subject: Re: floating point exceptions Message-ID: <20000427093434.A81401@gurney.reilly.home> References: <20000425000523.A17224@orion.ac.hmc.edu> <24238.956752200@axl.ops.uunet.co.za> <20000426110345.A13173@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20000426110345.A13173@dan.emsphone.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Apr 26, 2000 at 11:03:45AM -0500, Dan Nelson wrote: > In the last episode (Apr 26), Sheldon Hearn said: > > On Tue, 25 Apr 2000 00:05:23 MST, Brooks Davis wrote: > > > > Is FreeBSD's behavior correct? Why or why not? You can use the > > > > included code snippet to verify that this occurs. > > > > > > FreeBSD has traditionaly violated the IEEE FP standard in this > > > regard. This is fixed in 5.0 and I think in 4.0-STABLE (though I > > > can't remember what file this is in so I can't check.) > > > > Huh? I'm pretty sure you've got this backwards. FreeBSD has > > traditionally upheld the standard and we only recently decided to go > > with the flow in 5.0. > > No; we held our moral ground against IEEE, until 5.0 when we gave in. > The IEEE standard says "trap nothing". For most programs, this is the > wrong thing to do, since they are not signal-processing apps or > numerical analysis programs and a divide by zero is a coding error. > I'd rather have my program die on an unexpected divide by zero than > continue with invalid data. > > Why should we treat (1.0/0.0) any differently from (1/0)? Because 0.0 might be the closest approximation to whatever number you were really trying to divide by that the hardware can manage. 0 is never an approximation to 1 or -1. Dividing is for wimps, anyway. :-) -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 0:43:38 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from dt051n0b.san.rr.com (dt051n0b.san.rr.com [204.210.32.11]) by hub.freebsd.org (Postfix) with ESMTP id B3E7937B5BD for ; Thu, 27 Apr 2000 00:43:35 -0700 (PDT) (envelope-from DougB@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt051n0b.san.rr.com (8.9.3/8.9.3) with ESMTP id AAA54514; Thu, 27 Apr 2000 00:43:23 -0700 (PDT) (envelope-from DougB@gorean.org) Message-ID: <3907EFA1.3D31D221@gorean.org> Date: Thu, 27 Apr 2000 00:43:29 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Neil Blakey-Milner Cc: Doug Barton , freebsd-hackers@freebsd.org, adrian@creative.net.au Subject: Re: Safe sourcing of rc files References: <38F17E7A.5892318A@gorean.org> <20000419165123.A59794@mithrandr.moria.org> <20000426223127.A20023@mithrandr.moria.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Neil Blakey-Milner wrote: > > On Wed 2000-04-19 (16:51), Neil Blakey-Milner wrote: > > I have another idea: We make a sh script named "rcsource" or whatever, > > which we source when we want to have the rc environment, stealing your > > code maliciously: > > > > /-- > > sourcercs_sourced_files= > > sourcercs ( ) { > > local rc_conf_files > > for i in $*; do > > case "${sourcercs_sourced_files}" in > > *:$i:*) > > ;; > > *) > > sourcercs_sourced_files="${sourcercs_sourced_files}:$i:" > > echo $i > > if [ -r $i ]; then > > . $i > > sourcercs ${rc_conf_files} > > fi > > ;; > > esac > > done > > } > > sourcercs /etc/defaults/rc.conf > > \-- > > Unless someone comes back with negative feedback, I'll be pushing for a > commit for this (and all that depend on this change) on the weekend. Please don't take this the wrong way, but commit what exactly? All you've described is an idea. Before anyone could even test your idea, you'd have to have much more concrete work to share. Have you done any actual testing of your concept? Do you have a patchset that others can test in varying conditions? I haven't commented further on your idea because without some solid implementation details it's impossible to discuss further. I think there are some holes in your concept of being able to redefine $rc_conf_files for one thing. Keep in mind that you have to source /etc/defaults/rc.conf first, then do whatever gymnastics you want to do with the other files. Can you demonstrate a mechanism that accomplishes this? As for comments in general, I do not see the value in making a seperate script file out of the bit that does the sourcing of the rc.conf files for the current implementation. I have heard several vague plans for some future uses of rc.conf, but those are hard to evaluate in the absence of detail as well. :) Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 1: 4:24 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id A486337B598 for ; Thu, 27 Apr 2000 01:04:17 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.13 #1) id 12kjGq-000L2Z-00; Thu, 27 Apr 2000 10:03:36 +0200 From: Sheldon Hearn To: Neil Blakey-Milner Cc: Doug Barton , freebsd-hackers@freebsd.org, adrian@creative.net.au Subject: Re: Safe sourcing of rc files In-reply-to: Your message of "Wed, 26 Apr 2000 22:31:27 +0200." <20000426223127.A20023@mithrandr.moria.org> Date: Thu, 27 Apr 2000 10:03:36 +0200 Message-ID: <80882.956822616@axl.ops.uunet.co.za> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 26 Apr 2000 22:31:27 +0200, Neil Blakey-Milner wrote: > Unless someone comes back with negative feedback, I'll be pushing for a > commit for this (and all that depend on this change) on the weekend. > > Consider this a request for review and comment. My intention is to commit the patches Doug sent to -hackers. We know they work, and we know they work well. They're not going to make it difficult for you to implement the self-contained sourcing script idea, so I don't believe I'll be stepping on your (or Adrian's) toes with this. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 1:23: 2 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ewok.creative.net.au (ewok.creative.net.au [203.30.44.82]) by hub.freebsd.org (Postfix) with SMTP id 18E1A37B5CB for ; Thu, 27 Apr 2000 01:22:57 -0700 (PDT) (envelope-from adrian@creative.net.au) Received: (qmail 31246 invoked by uid 1001); 27 Apr 2000 08:21:56 -0000 Date: Thu, 27 Apr 2000 16:21:56 +0800 From: Adrian Chadd To: Sheldon Hearn Cc: Neil Blakey-Milner , Doug Barton , freebsd-hackers@freebsd.org, adrian@creative.net.au Subject: Re: Safe sourcing of rc files Message-ID: <20000427162155.M27215@ewok.creative.net.au> References: <20000426223127.A20023@mithrandr.moria.org> <80882.956822616@axl.ops.uunet.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <80882.956822616@axl.ops.uunet.co.za>; from Sheldon Hearn on Thu, Apr 27, 2000 at 10:03:36AM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, Apr 27, 2000, Sheldon Hearn wrote: > > > On Wed, 26 Apr 2000 22:31:27 +0200, Neil Blakey-Milner wrote: > > > Unless someone comes back with negative feedback, I'll be pushing for a > > commit for this (and all that depend on this change) on the weekend. > > > > Consider this a request for review and comment. > > My intention is to commit the patches Doug sent to -hackers. We know > they work, and we know they work well. They're not going to make it > difficult for you to implement the self-contained sourcing script idea, > so I don't believe I'll be stepping on your (or Adrian's) toes with > this. > > Ciao, > Sheldon. Nope, feel free and go ahead to commit something. I don't mind either way. Adrian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 1:48:47 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from axl.ops.uunet.co.za (axl.ops.uunet.co.za [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 2A26B37B51F for ; Thu, 27 Apr 2000 01:48:43 -0700 (PDT) (envelope-from sheldonh@axl.ops.uunet.co.za) Received: from sheldonh (helo=axl.ops.uunet.co.za) by axl.ops.uunet.co.za with local-esmtp (Exim 3.13 #1) id 12kjxk-000L9r-00; Thu, 27 Apr 2000 10:47:56 +0200 From: Sheldon Hearn To: Adrian Chadd Cc: Neil Blakey-Milner , Doug Barton , freebsd-hackers@freebsd.org Subject: Re: Safe sourcing of rc files In-reply-to: Your message of "Thu, 27 Apr 2000 16:21:56 +0800." <20000427162155.M27215@ewok.creative.net.au> Date: Thu, 27 Apr 2000 10:47:56 +0200 Message-ID: <81334.956825276@axl.ops.uunet.co.za> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 27 Apr 2000 16:21:56 +0800, Adrian Chadd wrote: > Nope, feel free and go ahead to commit something. I don't mind either > way. Excellent. I've committed the function to defaults/rc.conf and the calls to it from the various rc scripts. I realize that this is something we want backported, but given the recent discussions around premature MFC's, I'd like to hold off on an MFC for a month so that we can rest assured that this has been done properly. If Neil or anyone else breaks this function out into its own script without affecting its usefulness before this is merged, then we know it was prudent to wait. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 9:19:28 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from hotmail.com (f126.law8.hotmail.com [216.33.241.126]) by hub.freebsd.org (Postfix) with SMTP id AC50A37B573 for ; Thu, 27 Apr 2000 09:19:24 -0700 (PDT) (envelope-from jmd526@hotmail.com) Received: (qmail 35175 invoked by uid 0); 27 Apr 2000 16:19:24 -0000 Message-ID: <20000427161924.35174.qmail@hotmail.com> Received: from 209.220.228.2 by www.hotmail.com with HTTP; Thu, 27 Apr 2000 09:19:24 PDT X-Originating-IP: [209.220.228.2] From: "John Daniels" To: freebsd-hackers@freebsd.org, freebsd-advocacy@freebsd.org, advocacy@netbsd.org Subject: Please support Java port to *BSD Date: Thu, 27 Apr 2000 12:19:24 EDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi: In November 1999 a request for enhancement (RFE) was opened at Sun's Java Developer's Connection titled: Port jdk 1.2.x to FreeBSD (bug id: 4288745). Members of the Java Developer's Connection help prioritize bug fixes and RFE's by voting for the one's that they believe are needed most. The FreeBSD port RFE is currently the #1 request by far with 2953 votes vs. 819 for the #2 request. Even with this wide lead, Sun has no obligation to make an official port of Java to FreeBSD or *BSD, or to be helpful to the *BSD efforts to port Java (see www.freebsd.org/java). The larger the number of votes for our RFE, however, the more difficult it is for Sun to ignore. And the more that we can widen the lead between our #1 RFE and #2, the more dramatic a statement we (collectively) make. An official Java JDK port to FreeBSD would likely mean that all BSD's would benefit either by being able to use the FreeBSD port or by being much closer to a port of their own. In fact, many who have voted for the RFE have left comments supporting a port to *BSD, not just FreeBSD. As you may know, Sun recently teamed with Inprise to create an official port of Java to Linux (building on the work of Blackdown). The *BSD's, with a large and loyal base of developers, also deserve an official native version of Java. Please support the Java on *BSD effort by voting for the RFE at: http://developer.java.sun.com/developer/bugParade/bugs/4288745.html If you are not already a member of Sun's Java Developers Connection, you will need to register before voting (membership is free). Your support is greatly appreciated. Thank you. John PS Please forward this message to any person, list, or organization that may want to support this effort. ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 10:50: 5 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from relay2.mail.uk.psi.net (relay2.mail.uk.psi.net [154.32.107.6]) by hub.freebsd.org (Postfix) with ESMTP id 8CD3E37B933; Thu, 27 Apr 2000 10:49:57 -0700 (PDT) (envelope-from sdobson@allstor-sw.com) Received: from mail.plasmon.co.uk ([193.115.5.217]) by relay2.mail.uk.psi.net with smtp (Exim 2.12 #2) id 12ksQF-0003Qp-00; Thu, 27 Apr 2000 18:49:56 +0100 Received: from virgo.software.plasmon ([193.115.4.42]) by mail.plasmon.co.uk (Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) with SMTP id 802568CE.0061FAFA; Thu, 27 Apr 2000 18:50:12 +0100 Received: from mail by virgo.software.plasmon with local-esmtp (Exim 2.12 #1) id 12ksMB-000MLR-00 (FreeBSD); Thu, 27 Apr 2000 18:45:43 +0100 Received: from dobbo by penfold.software.plasmon with local (Exim 3.12 #1) id 12ksMA-0005NS-00 (Debian); Thu, 27 Apr 2000 18:45:42 +0100 Date: Thu, 27 Apr 2000 18:45:42 +0100 From: Steve Dobson To: freebsd-ports@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: pthreads and ORBacus Message-ID: <20000427184542.A20642@penfold.software.plasmon> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Sorry to anyone who reads both the hackers and ports mail lists as this is cross posted. I am trying to build ORBacus's JTC and ORB on FreeBSD 4.0-RELEASE. I know that there is an ORBacus port, but it is the single threaded version and I need the event service (which needs JTC which needs pthreads). Is any work being done to get JTC to build on FreeBSD? Thanks for any help Steve -- Steve Dobson E-mail: sdobson@allstor-sw.com Unix Architect Tel (Direct): +44 1763 264441 Allstor Software Ltd. (R'tion): +44 1763 262963 Whiting Way Fax: +44 1763 264444 Melbourn, Herts, UK SG8 6EN To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 10:54:29 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from obie.softweyr.com (obie.softweyr.com [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id E4D2D37B573; Thu, 27 Apr 2000 10:53:57 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (Foolstrustidentd@obie.softweyr.com [204.68.178.33]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id LAA15567; Thu, 27 Apr 2000 11:53:09 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <39087EA5.34E6F2D2@softweyr.com> Date: Thu, 27 Apr 2000 11:53:41 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: wc.bulte@chello.nl Cc: Bill Fumerola , Dan Nelson , Sheldon Hearn , Brooks Davis , Nate Lawson , freebsd-hackers@FreeBSD.ORG, freebsd-ports@FreeBSD.ORG, davidm@hpl.hp.com Subject: Re: floating point exceptions References: <20000425000523.A17224@orion.ac.hmc.edu> <24238.956752200@axl.ops.uunet.co.za> <20000426110345.A13173@dan.emsphone.com> <20000426121651.M40387@jade.chc-chimes.com> <20000426192254.E1021@yedi.wbnet> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wilko Bulte wrote: > > On Wed, Apr 26, 2000 at 12:16:51PM -0400, Bill Fumerola wrote: > > On Wed, Apr 26, 2000 at 11:03:45AM -0500, Dan Nelson wrote: > > > > > Why should we treat (1.0/0.0) any differently from (1/0)? > > > > Because Linux has the uncanny ability to both divide by zero and produce > > the shittiest coders the world has ever seen. > > Which brings me to the inevitable question: 'can NT divide by zero' ? ;-) No, at least not in US Navy installations. It also cannot recover from divide by zero errors, leading a brand new US warship to be towed in from sea trials. The NT-powered nuclear navy. Be afraid. Be very afraid. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 11: 5:18 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ms.tokyo.jcom.ne.jp (ms.tokyo.jcom.ne.jp [210.234.123.18]) by hub.freebsd.org (Postfix) with ESMTP id 86C6337B585; Thu, 27 Apr 2000 11:05:13 -0700 (PDT) (envelope-from knu@idaemons.org) Received: from daemon.local.idaemons.org (203-165-77-40.sugnm1.kt.home.ne.jp [203.165.77.40]) by ms.tokyo.jcom.ne.jp (8.9.3/3.7W 04/27/00) with ESMTP id DAA16866; Fri, 28 Apr 2000 03:05:12 +0900 (JST) Received: by daemon.local.idaemons.org (8.9.3/3.7W) id DAA22118; Fri, 28 Apr 2000 03:04:41 +0900 (JST) Date: Fri, 28 Apr 2000 03:04:40 +0900 Message-ID: <86aeifzah3.wl@localhost.local.idaemons.org> From: "Akinori -Aki- MUSHA" To: freebsd-hackers@FreeBSD.org, freebsd-ports@FreeBSD.org Subject: Help me complete the FreeBSD specific zsh completions! User-Agent: Wanderlust/1.1.1 (Purple Rain) EMIKO/1.13.12 (Euglena sociabilis) FLIM/1.13.2 (Kasanui) APEL/10.2 MULE XEmacs/21.1 (patch 9) (Canyonlands) (i386--freebsd) Organization: Associated I. Daemons X-PGP-Public-Key: finger knu@FreeBSD.org X-PGP-Fingerprint: 1BEF D9B2 BABD 25D7 659A FD08 89C2 F3BE E981 4E16 MIME-Version: 1.0 (generated by EMIKO 1.13.12 - "Euglena sociabilis") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi! This is continued from my previous call re the zsh compdef's. I've had a contact with zsh-workers and one of the zsh developers, Sven Wischnowsky. He kindly improved the completions I'd handed in and sent me back the following work. (How kind of him!) http://people.freebsd.org/~knu/etc/zsh/functions/devel/ Now, we FreeBSD users must do due feedback to get them into 3.1.7 release of zsh. So, I'd like some of you to help me with the following tasks: - Write other completions that are kind of FreeBSD specific. o send-pr command (low) o *control commands (low) o etc. (low) - Fix some standard completions to conform to FreeBSD environments. o mount and umount commands (high) o etc. (low) - Test them hard. (medium) Someone help! -- / /__ __ / ) ) ) ) / Akinori -Aki- MUSHA aka / (_ / ( (__( @ idaemons.org / FreeBSD.org "We're only at home when we're on the run, on the wing, on the fly" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 11:41:35 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from web804.mail.yahoo.com (web804.mail.yahoo.com [128.11.23.64]) by hub.freebsd.org (Postfix) with SMTP id 53C7637B70A for ; Thu, 27 Apr 2000 11:41:33 -0700 (PDT) (envelope-from raysonlogin@yahoo.com) Received: (qmail 2158 invoked by uid 60001); 27 Apr 2000 18:41:27 -0000 Message-ID: <20000427184127.2157.qmail@web804.mail.yahoo.com> Received: from [128.100.13.59] by web804.mail.yahoo.com; Thu, 27 Apr 2000 11:41:27 PDT Date: Thu, 27 Apr 2000 11:41:27 -0700 (PDT) From: Rayson Ho Subject: Re: Multithreaded server performance To: A G F Keahan , "Richard Seaman, Jr." Cc: Jason Evans , freebsd-hackers@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Both Solaris and NT have good thread implementations: http://www.usenix.org/publications/library/proceedings/usenix-nt98/zabatta.html Read this paper -- There is something about NT threads implementation which has never been released in any books! > the goal is to > do better than NT > (which surprisingly does quite a good job when it > comes to processing > lots of threads). Solaris's threads are pretty > darn good too, but I > dislike all things SystemV-ish, and Solaris/x86 > isn't all that hot > either (compared with the version for the > UltraSPARC). __________________________________________________ Do You Yahoo!? Talk to your friends online and get email alerts with Yahoo! Messenger. http://im.yahoo.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 11:45:59 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from Samizdat.uucom.com (samizdat.uucom.com [198.202.217.54]) by hub.freebsd.org (Postfix) with ESMTP id B8DF937B685 for ; Thu, 27 Apr 2000 11:45:57 -0700 (PDT) (envelope-from cshenton@uucom.com) Received: (from cshenton@localhost) by Samizdat.uucom.com (8.9.3/8.9.3) id OAA02398; Thu, 27 Apr 2000 14:45:56 -0400 (EDT) To: hackers@freebsd.org Subject: 4.0-RELEASE ASUS K7V floppy boot fails -- register dump From: Chris Shenton Date: 27 Apr 2000 14:45:55 -0400 Message-ID: Lines: 28 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Got a new ASUS K7V with AMD K7 700Mhz processor trying to install FreeBSD-4.0 from the kern.flp on ftp.freebsd.org. It dumps the registers immediately after saying /boot.config: -P Keyboard: yes / [spin icon just twitches once or somethign] Here's what the 4.0-RELEASE kern.flp dumps before halting; I'm supressing the leading zeros so I can typie this: int=d err=0 efl=30002 eip=56af eax=208 ebx=0 ecx=c0010010 edx=100 esi=b edi=5 ebp=3f4 esp=3c4 cs=f000 ds=ec00 es=1000 fs=0 gs=0 ss=9e75 cs: eip=0f 32 66 0d 00 00 08 00-0f 30 c3 66 b9 10 00 01 ss: esp=12 57 03 01 00 00 00 01-00 00 8d 1d 00 ec ba 1d System Halted I've also tried this with the 3.4-RELEASE floppy and it fails similarly, tho dumps the registers twice for some reason. BTW: Solaris-x86-beta does boot from floppy. Any hints? I'd really prefer not to go to (ehem) another operating system. Thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 12: 0:15 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id DA96437BF58 for ; Thu, 27 Apr 2000 12:00:11 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) Received: from localhost (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id MAA00752; Thu, 27 Apr 2000 12:02:14 -0700 (PDT) (envelope-from jkh@zippy.cdrom.com) To: Chris Shenton Cc: hackers@FreeBSD.ORG Subject: Re: 4.0-RELEASE ASUS K7V floppy boot fails -- register dump In-reply-to: Your message of "27 Apr 2000 14:45:55 EDT." Date: Thu, 27 Apr 2000 12:02:14 -0700 Message-ID: <749.956862134@localhost> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Got a new ASUS K7V with AMD K7 700Mhz processor trying to install > FreeBSD-4.0 from the kern.flp on ftp.freebsd.org. It dumps the > registers immediately after saying Mount the kern floppy on another FreeBSD box and do some surgery on it along the following lines: mount /dev/fd0 /mnt rm /mnt/boot.config umount /mnt That should keep the -P flag out of your boot line and ensure that the keyboard is properly detected. I think our use of -P was over-eager since there are motherboards which don't play nice with it, like this one. - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 13:23: 6 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from Samizdat.uucom.com (samizdat.uucom.com [198.202.217.54]) by hub.freebsd.org (Postfix) with ESMTP id AA5F737C0D6 for ; Thu, 27 Apr 2000 13:23:03 -0700 (PDT) (envelope-from cshenton@uucom.com) Received: (from cshenton@localhost) by Samizdat.uucom.com (8.9.3/8.9.3) id QAA03763; Thu, 27 Apr 2000 16:22:57 -0400 (EDT) To: "Jordan K. Hubbard" Cc: hackers@FreeBSD.ORG Subject: Re: 4.0-RELEASE ASUS K7V floppy boot fails -- register dump References: <749.956862134@localhost> From: Chris Shenton Date: 27 Apr 2000 16:22:57 -0400 In-Reply-To: "Jordan K. Hubbard"'s message of "Thu, 27 Apr 2000 12:02:14 -0700" Message-ID: Lines: 22 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 27 Apr 2000 12:02:14 -0700, "Jordan K. Hubbard" said: Jordan> Mount the kern floppy on another FreeBSD box and do some Jordan> surgery on it along the following lines: Jordan> mount /dev/fd0 /mnt Jordon> rm /mnt/boot.config Jordon> umount /mnt Jordan> That should keep the -P flag out of your boot line and ensure Jordan> that the keyboard is properly detected. I think our use of -P Jordan> was over-eager since there are motherboards which don't play Jordan> nice with it, like this one. Just tried it, and as expected it didn't do the "-P" thing this time. Unfortunately: no joy -- same exact register dump. :-( It doesn't seem to be the keyboard finding problem others have written about (with NumLock hack workarounds) since the scan found the keyboard originally (keyboard: yes). Other suggestions welcome. Thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 14:19:23 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184]) by hub.freebsd.org (Postfix) with ESMTP id E39DF37B551 for ; Thu, 27 Apr 2000 14:19:19 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id OAA00656; Thu, 27 Apr 2000 14:26:13 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200004272126.OAA00656@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Chris Shenton Cc: hackers@freebsd.org Subject: Re: 4.0-RELEASE ASUS K7V floppy boot fails -- register dump In-reply-to: Your message of "27 Apr 2000 14:45:55 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Apr 2000 14:26:13 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'm seeing this too. Try booting without the floppy installed, then when it bitches, insert said floppy and hit enter. Actually, I'm having all manner of insane problems with this board, and I'm about to throw it out and go back to a FIC SD-11. > Got a new ASUS K7V with AMD K7 700Mhz processor trying to install > FreeBSD-4.0 from the kern.flp on ftp.freebsd.org. It dumps the > registers immediately after saying > > /boot.config: -P > Keyboard: yes > / [spin icon just twitches once or somethign] > > Here's what the 4.0-RELEASE kern.flp dumps before halting; I'm > supressing the leading zeros so I can typie this: > > int=d err=0 efl=30002 eip=56af > eax=208 ebx=0 ecx=c0010010 edx=100 > esi=b edi=5 ebp=3f4 esp=3c4 > cs=f000 ds=ec00 es=1000 fs=0 gs=0 ss=9e75 > cs: eip=0f 32 66 0d 00 00 08 00-0f 30 c3 66 b9 10 00 01 > ss: esp=12 57 03 01 00 00 00 01-00 00 8d 1d 00 ec ba 1d > System Halted > > > I've also tried this with the 3.4-RELEASE floppy and it fails > similarly, tho dumps the registers twice for some reason. > > BTW: Solaris-x86-beta does boot from floppy. > > Any hints? I'd really prefer not to go to (ehem) another operating system. > > Thanks. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 14:21:46 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184]) by hub.freebsd.org (Postfix) with ESMTP id ECE0F37B540 for ; Thu, 27 Apr 2000 14:21:42 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id OAA00669; Thu, 27 Apr 2000 14:28:05 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200004272128.OAA00669@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Jordan K. Hubbard" Cc: Chris Shenton , hackers@FreeBSD.ORG Subject: Re: 4.0-RELEASE ASUS K7V floppy boot fails -- register dump In-reply-to: Your message of "Thu, 27 Apr 2000 12:02:14 PDT." <749.956862134@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Apr 2000 14:28:05 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Got a new ASUS K7V with AMD K7 700Mhz processor trying to install > > FreeBSD-4.0 from the kern.flp on ftp.freebsd.org. It dumps the > > registers immediately after saying > > Mount the kern floppy on another FreeBSD box and do some surgery on > it along the following lines: > > mount /dev/fd0 /mnt > rm /mnt/boot.config > umount /mnt > > That should keep the -P flag out of your boot line and ensure that the > keyboard is properly detected. I think our use of -P was over-eager > since there are motherboards which don't play nice with it, like this > one. Actually, this is entirely irrelevant. The keyboard detection code is passive, and simply reads a flag in low memory (which this board is setting correctly). I don't have a good idea of what's going wrong here, but it's the current spanner in getting your build box out of my hair. 8( -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 14:58:56 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from Quote.Twiddle.COM (mail.twiddle.nl [212.83.214.2]) by hub.freebsd.org (Postfix) with ESMTP id 16F4B37BAC9 for ; Thu, 27 Apr 2000 14:58:48 -0700 (PDT) (envelope-from jh@efmsoftware.com) Received: from dc2-isdn2051.dial.xs4all.nl ([194.109.156.3] helo=EFMSoftware.COM) by Quote.Twiddle.COM with esmtp (Exim 3.02 #4) id 12kvgH-0004Y8-00 for hackers@FreeBSD.ORG; Thu, 27 Apr 2000 23:18:42 +0200 Message-ID: <3909FF8B.E8224960@EFMSoftware.COM> Date: Fri, 28 Apr 2000 23:15:55 +0200 From: Jeroen Hogeveen Organization: EFM Software B.V. X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: hackers@FreeBSD.ORG Subject: Asus K7V boot failure Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hey Chris and Jordan, I've got one too, you should however disable your boot virus protection in the bios setup! This will fix the problem you described. Maybe something to mention in the FAQ, if it is not yet there. Regards, jh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 15: 5:27 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from phoenix.aye.net (phoenix.aye.net [198.7.192.5]) by hub.freebsd.org (Postfix) with SMTP id CE9D137BD2C for ; Thu, 27 Apr 2000 15:05:23 -0700 (PDT) (envelope-from barrett@aye.net) Received: (qmail 9066 invoked by uid 1000); 27 Apr 2000 22:05:22 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 27 Apr 2000 22:05:22 -0000 Date: Thu, 27 Apr 2000 18:05:22 -0400 (EDT) From: Barrett Richardson To: freebsd-hackers@freebsd.org Subject: immutable flag strangeness Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have attached a file to /dev/vn0 and built a file system on it. I have set the "system immutable" flag because I want to store some sensitive stuff on it. # ls -lo /home/afile -rw-r--r-- 1 root wheel schg 16777216 Apr 27 17:36 /home/afile # But... if I mount it vnconfig -c /dev/vn0 /home/afile mount /dev/vn0c /mnt And create a file on it... cd /mnt ps -agx > afile It creates a file and the time stamp on the file updates # ls -lo /home/afile -rw-r--r-- 1 root wheel schg 16777216 Apr 27 17:40 /home/afile # schg flag broken on 3.3? I've tried to test it on 3.4 but have been unable to get the disk label edited. - Barrett Richardson (my name) barrett@aye.net (my email address) main(){} (my program) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 15:13: 5 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.beattie-home.net (148.129.249.209.fastpoint.net [209.249.129.148]) by hub.freebsd.org (Postfix) with ESMTP id 072D637B96E; Thu, 27 Apr 2000 15:13:02 -0700 (PDT) (envelope-from beattie@beattie-home.net) Received: from raven.pdx.beattie-home.net (raven.pdx.beattie-home.net [192.168.0.1]) by mail.beattie-home.net (Postfix) with ESMTP id 1C278A974; Thu, 27 Apr 2000 15:14:43 -0700 (PDT) Date: Thu, 27 Apr 2000 15:13:26 -0700 (PDT) From: Brian Beattie X-Sender: beattie@raven.pdx.beattie-home.net To: Mike Smith Cc: "Jordan K. Hubbard" , Chris Shenton , hackers@FreeBSD.ORG Subject: Re: 4.0-RELEASE ASUS K7V floppy boot fails -- register dump In-Reply-To: <200004272128.OAA00669@mass.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 27 Apr 2000, Mike Smith wrote: > > > Got a new ASUS K7V with AMD K7 700Mhz processor trying to install > > > FreeBSD-4.0 from the kern.flp on ftp.freebsd.org. It dumps the > > > registers immediately after saying > > > > Mount the kern floppy on another FreeBSD box and do some surgery on > > it along the following lines: > > > > mount /dev/fd0 /mnt > > rm /mnt/boot.config > > umount /mnt > > > > That should keep the -P flag out of your boot line and ensure that the > > keyboard is properly detected. I think our use of -P was over-eager > > since there are motherboards which don't play nice with it, like this > > one. > > Actually, this is entirely irrelevant. The keyboard detection code is > passive, and simply reads a flag in low memory (which this board is > setting correctly). I don't have a good idea of what's going wrong here, > but it's the current spanner in getting your build box out of my hair. 8( > I would have to say that my experience indicates a flaw in your analysis. I do not know what is doing it, but since the boot process started checking for an extended keyboard, I can not use my compact keyboard in boot, or, I think, single user. It still works fine in multi-user (may be an artifact of X). This keyboard is not an extended keyboard, but I do not have te -P flag set. The keyboard produces garbage. I can understand the keyboard not be recognized, but if I do not do a -P it should still work fine, but does not. Last time I mentioned this, I got pretty much tge same answer you give here. Well you may be right, it coule be an entirely passive operation, but something changed, no matter what you think. I gave up and went back to a regulat keyboard, since nobody seemed interested in listening, to myself and others. > -- > \\ Give a man a fish, and you feed him for a day. \\ Mike Smith > \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org > \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Beattie | This email was produced using professional quality, beattie@aracnet.com | standards based software. Users of Microsoft beattie@aracnet.com | products or other substandard software should www.aracnet.com/~beattie | contact the author about receiving a Free upgrade to | FreeBSD or Linux. "FreeBSD: The power to serve" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 15:17:56 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184]) by hub.freebsd.org (Postfix) with ESMTP id 748F937BF3A for ; Thu, 27 Apr 2000 15:17:53 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id PAA01245; Thu, 27 Apr 2000 15:25:40 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200004272225.PAA01245@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Brian Beattie Cc: hackers@FreeBSD.ORG Subject: Re: 4.0-RELEASE ASUS K7V floppy boot fails -- register dump In-reply-to: Your message of "Thu, 27 Apr 2000 15:13:26 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Apr 2000 15:25:40 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Mount the kern floppy on another FreeBSD box and do some surgery on > > > it along the following lines: > > > > > > mount /dev/fd0 /mnt > > > rm /mnt/boot.config > > > umount /mnt > > > > > > That should keep the -P flag out of your boot line and ensure that the > > > keyboard is properly detected. I think our use of -P was over-eager > > > since there are motherboards which don't play nice with it, like this > > > one. > > > > Actually, this is entirely irrelevant. The keyboard detection code is > > passive, and simply reads a flag in low memory (which this board is > > setting correctly). I don't have a good idea of what's going wrong here, > > but it's the current spanner in getting your build box out of my hair. 8( > > I would have to say that my experience indicates a flaw in your > analysis. I do not know what is doing it, but since the boot process > started checking for an extended keyboard, I can not use my compact > keyboard in boot, or, I think, single user. You're welcome to read the code in boot2, and explain to me how the testing of a single bit in low memory might cause the symptoms that you describe. I'm afraid that, in this case, it is *your* analysis that is faulty, and you are being misled by an irrelevant aside. > I gave up and went back to a regulat keyboard, since nobody seemed > interested in listening, to myself and others. I'm certainly not interested in being insulted, no. You're welcome to help work out what's really going on, since you're the one with the symptoms, and until you decide to do so, nothing's going to get fixed. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 15:29:53 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from Samizdat.uucom.com (samizdat.uucom.com [198.202.217.54]) by hub.freebsd.org (Postfix) with ESMTP id CD32837B6CB; Thu, 27 Apr 2000 15:29:49 -0700 (PDT) (envelope-from cshenton@uucom.com) Received: (from cshenton@localhost) by Samizdat.uucom.com (8.9.3/8.9.3) id SAA13940; Thu, 27 Apr 2000 18:29:48 -0400 (EDT) To: Mike Smith Cc: hackers@freebsd.org Subject: Re: 4.0-RELEASE ASUS K7V floppy boot fails -- register dump References: <200004272126.OAA00656@mass.cdrom.com> From: Chris Shenton Date: 27 Apr 2000 18:29:48 -0400 In-Reply-To: Mike Smith's message of "Thu, 27 Apr 2000 14:26:13 -0700" Message-ID: Lines: 16 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 27 Apr 2000 14:26:13 -0700, Mike Smith said: Mike> I'm seeing this too. Try booting without the floppy installed, Mike> then when it bitches, insert said floppy and hit enter. ROFL, it worked. I'm pulling the install down the wire now. Many thanks! Mike> Actually, I'm having all manner of insane problems with this Mike> board, and I'm about to throw it out and go back to a FIC SD-11. What kind of problems? A friend has the slightly older ASUS K7M board and seems happy with it -- no problems reported. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 15:46:32 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184]) by hub.freebsd.org (Postfix) with ESMTP id DA97737BCDA; Thu, 27 Apr 2000 15:46:29 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id PAA01503; Thu, 27 Apr 2000 15:54:19 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200004272254.PAA01503@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Chris Shenton Cc: Mike Smith , hackers@freebsd.org Subject: Re: 4.0-RELEASE ASUS K7V floppy boot fails -- register dump In-reply-to: Your message of "27 Apr 2000 18:29:48 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Apr 2000 15:54:19 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Mike> Actually, I'm having all manner of insane problems with this > Mike> board, and I'm about to throw it out and go back to a FIC SD-11. > > What kind of problems? A friend has the slightly older ASUS K7M board > and seems happy with it -- no problems reported. The system shipped (nonfunctional) with 512MB of ECC SDRAM. If you enable ECC in the BIOS and reboot, it locks up. I've also been thwarted long and hard by what's turned out to be an unrelated problem, but which I'd been unable to pin down more closely. With the suggestion that it's actually the bootsector virus detector, I'm going back to the K7V to give it another go. I'll lick this bastard yet! -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 15:49:40 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from obie.softweyr.com (obie.softweyr.com [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id 7921837BC96 for ; Thu, 27 Apr 2000 15:49:36 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (Foolstrustidentd@obie.softweyr.com [204.68.178.33]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id QAA16222; Thu, 27 Apr 2000 16:49:04 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <3908C3FE.ABD80977@softweyr.com> Date: Thu, 27 Apr 2000 16:49:34 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: A G F Keahan Cc: "Richard Seaman, Jr." , Jason Evans , freebsd-hackers@FreeBSD.ORG Subject: Re: Multithreaded server performance References: <3903AEA6.FA7CBBAB@freenet.co.uk> <20000423212115.E31925@sturm.canonware.com> <20000424164405.G370@seaman.org> <390501AB.D185646E@freenet.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG A G F Keahan wrote: > > > On Sun, Apr 23, 2000 at 09:21:15PM -0700, Jason Evans wrote: > > > > > > This design isn't ideal on any OS, but the fact that you do significant > > > processing every time a request arrives on a socket probably hides most of > > > the inefficiency due to thread switching and lack of cache locality due to > > > many thread stacks. > > Can you suggest a better design for this type of server application > under FreeBSD? Perhaps a combination of forking (or pre-forking) and > threads? Preallocate a number of threads that yeilds adequate peformance and feed work to the threads via IPC mechanisms. When the thread finishes its work, rather than exiting, it just waits for another work unit. A simple way to do this is via a queue, or via a shared memory pool for each thread and a "go" semaphore. This avoids the overhead of thread startup and shutdown for every client connection. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 15:57:20 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.beattie-home.net (148.129.249.209.fastpoint.net [209.249.129.148]) by hub.freebsd.org (Postfix) with ESMTP id B40F937BB41; Thu, 27 Apr 2000 15:57:16 -0700 (PDT) (envelope-from beattie@beattie-home.net) Received: from raven.pdx.beattie-home.net (raven.pdx.beattie-home.net [192.168.0.1]) by mail.beattie-home.net (Postfix) with ESMTP id 36930A974; Thu, 27 Apr 2000 15:58:56 -0700 (PDT) Date: Thu, 27 Apr 2000 15:57:39 -0700 (PDT) From: Brian Beattie X-Sender: beattie@raven.pdx.beattie-home.net To: Mike Smith Cc: hackers@FreeBSD.ORG Subject: Re: 4.0-RELEASE ASUS K7V floppy boot fails -- register dump In-Reply-To: <200004272225.PAA01245@mass.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 27 Apr 2000, Mike Smith wrote: > > I'm afraid that, in this case, it is *your* analysis that is faulty, and > you are being misled by an irrelevant aside. > Hardware that used to work, that still works in other situations, stopped working when the boot procedure changed. The people who worked on that code tell me I'm wrong, nothing they did could have done that. Ok fine, I don't care that much, I have other hardware that will let me work around this. BTW, I did not say that the testing od the bit causes the problem, I said that something related to testing for an extended keyboard SEEMS to have caused this change in behaviour. More so because the keyboard has problems only when you DON'T test for an extended keyboard, because then it fails, correctly, to read the keyboard. As to insults, I do not see how disagreeing with you analysis is insulting. Brian Beattie | This email was produced using professional quality, beattie@aracnet.com | standards based software. Users of Microsoft beattie@aracnet.com | products or other substandard software should www.aracnet.com/~beattie | contact the author about receiving a Free upgrade to | FreeBSD or Linux. "FreeBSD: The power to serve" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 16:10:12 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from server.baldwin.cx (jobaldwi.campus.vt.edu [198.82.67.146]) by hub.freebsd.org (Postfix) with ESMTP id CCFB737BB5A for ; Thu, 27 Apr 2000 16:09:58 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from john.baldwin.cx (john [10.0.0.2]) by server.baldwin.cx (8.9.3/8.9.3) with ESMTP id TAA01034; Thu, 27 Apr 2000 19:09:40 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-Id: <200004272309.TAA01034@server.baldwin.cx> X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 27 Apr 2000 19:09:40 -0400 (EDT) From: John Baldwin To: Chris Shenton Subject: RE: 4.0-RELEASE ASUS K7V floppy boot fails -- register dump Cc: hackers@FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 27-Apr-00 Chris Shenton wrote: > Got a new ASUS K7V with AMD K7 700Mhz processor trying to install > FreeBSD-4.0 from the kern.flp on ftp.freebsd.org. It dumps the > registers immediately after saying > > /boot.config: -P > Keyboard: yes > / [spin icon just twitches once or somethign] > > Here's what the 4.0-RELEASE kern.flp dumps before halting; I'm > supressing the leading zeros so I can typie this: > > int=d err=0 efl=30002 eip=56af > eax=208 ebx=0 ecx=c0010010 edx=100 > esi=b edi=5 ebp=3f4 esp=3c4 > cs=f000 ds=ec00 es=1000 fs=0 gs=0 ss=9e75 > cs: eip=0f 32 66 0d 00 00 08 00-0f 30 c3 66 b9 10 00 01 > ss: esp=12 57 03 01 00 00 00 01-00 00 8d 1d 00 ec ba 1d > System Halted It appears to be some weird BIOS problem (cs=f000 is the BIOS code segment): 00000000 0F32 rdmsr 00000002 660D00000800 or eax,0x80000 00000008 F1 int1 00000009 30C3 xor bl,al 0000000B 66B910000101 mov ecx,0x1010010 It's trying to read a Machine Status Register, specifically MSR[0xc0010010] (%ecx) into %edx:%eax. It then is setting a bit in the value it read, and executing an undocumented/ invalid instruction. *sigh*, why must hardware manufacturers be so difficult? The real problem is that the rdmsr instruction can't be executed in virtual 86 mode, which we use to make BIOS calls once boot2 has started up. When the machine fails to boot the first time, it probably ends up running this BIOS hook in real mode, where it succeeds, and supposing it is a once-only init type of thing, the second time around it sees that it's already done this and doesn't bother executing the instruction, thus not faulting. Now, it could be that or at some point we are wondering off into lala land and executing random code, but I really doubt it, especially since the processor is in vm86 mode (most likely) when it executes this instruction, and we are only in vm86 mode when we call the BIOS. > I've also tried this with the 3.4-RELEASE floppy and it fails > similarly, tho dumps the registers twice for some reason. Probably another little buglet I accidentally introduced in 3.4 that causes the fault handler to execute an invalid instruction since it doesn't leave protected mode when it tries to exit after the first fault. :P > BTW: Solaris-x86-beta does boot from floppy. It may not be running in protected mode as early as we are, thus not tripping a General Protection Fault like we do. > Any hints? I'd really prefer not to go to (ehem) another operating system. Well, we're looking into it. :) We'll let you know when we have more info. > Thanks. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 17: 3:45 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mass.cdrom.com (mass.cdrom.com [204.216.28.184]) by hub.freebsd.org (Postfix) with ESMTP id 7B7D137B97C for ; Thu, 27 Apr 2000 17:03:42 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id RAA02152; Thu, 27 Apr 2000 17:11:02 -0700 (PDT) (envelope-from msmith@mass.cdrom.com) Message-Id: <200004280011.RAA02152@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Jeroen Hogeveen Cc: hackers@FreeBSD.ORG Subject: Re: Asus K7V boot failure In-reply-to: Your message of "Fri, 28 Apr 2000 23:15:55 +0200." <3909FF8B.E8224960@EFMSoftware.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Apr 2000 17:11:02 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hey Chris and Jordan, > > I've got one too, you should however disable your boot virus protection > in the bios setup! > > This will fix the problem you described. > > Maybe something to mention in the FAQ, if it is not yet there. Thanks; this has indeed fixed things. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 17:54:38 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rdc2.bc.home.com (ha1.rdc2.bc.wave.home.com [24.2.10.68]) by hub.freebsd.org (Postfix) with ESMTP id C8D0437BB73 for ; Thu, 27 Apr 2000 17:54:34 -0700 (PDT) (envelope-from dr@dursec.com) Received: from kyxbot.zorg ([24.113.134.64]) by mail.rdc2.bc.home.com (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20000428005430.DHQG11154.mail.rdc2.bc.home.com@kyxbot.zorg> for ; Thu, 27 Apr 2000 17:54:30 -0700 From: Dragos Ruiu Organization: kyx.net To: hackers@FreeBSD.ORG Subject: Mouse Sync Problems with KVM Date: Thu, 27 Apr 2000 17:50:17 -0700 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <0004271752300E.00332@kyxbot.zorg> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I'll try asking here now.... I have a freebsd system(3.4S) on a KVM.... and every time the monitored system is switched, the mouse driver gets fuxored, and when you switch back to the system the driver starts outputting oodles of the following messages to syslog every time the mouse is moved: Apr 26 18:49:45 kyxbot /kernel: psmintr: out of sync (00c8 != 0008). Apr 26 18:49:45 kyxbot /kernel: psmintr: out of sync (0000 != 0008). mouse type is PS/2 Has anyone seen this before? Or do I have to get down and dirty with the driver? This may be an issue with the KVM switch because it does this on two different 3.4 systems on different KVMs, both KVM brands are identical(masterview)... But the KVM works with Wintendo/NT, Linux and OpenBSD just fine... on the same HW. thank you, --dr -- dursec.com / kyx.net - we're from the future http://www.dursec.com learn kanga-foo from security experts: CanSecWest - May 10-12 Vancouver Speakers: Ron Gula/NSW, Ken Williams/E&Y, Marty Roesch/Hiverworld, Fyodor/insecure.org, RainForestPuppy/wiretrip.net, Theo de Raadt/OpenBSD Lance Spitzner/Sun, Fyodor Yarochkin/KALUG, Max Vision/whitehats.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 18:16:50 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id BFCED37BB73; Thu, 27 Apr 2000 18:16:43 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Thu, 27 Apr 2000 21:16:40 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: Luoqi Chen Cc: hackers@FreeBSD.ORG Subject: Re: lock-ups due to the scheduler In-Reply-To: <200004270547.e3R5lfi24004@lor.watermarkgroup.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 27 Apr 2000, Luoqi Chen wrote: > This is quite interesting. I'm no scheduler expert, but my understanding > is priority < PUSER won't degrade and is only set in kernel mode after > waking up from a sleep. In user mode, processes should always have priority > p_usrpri >= PUSER, it is obviously not true for a negative nice value: That was my take on it. There were multiple tests for <= PUSER which were really tests for whether or not the process was in SRUN. However, changing these tests to SRUN tests didn't prevent lockups, so the problem seems to be deeper than that. And they definitely keep p_priority < PUSER processes from updating their p_priority to their newly calculated p_usrpri, a very large bug. The deeper problem seems to be that for whatever the process does, it never accrues enough estcpu to classify it as hoggy, as a process I start with a niceness of -20 cycles through priorities 10 (in the very beginning) and 27 at the very highest. This _shouldn't_ be too much of a problem, but it never gets to 50 and thus never gets rescheduled properly... and this seems to be most of what's causing the lockups. > > newpriority = PUSER + p->p_estcpu / INVERSE_ESTCPU_WEIGHT + > > NICE_WEIGHT * p->p_nice; > We should probably offset p->p_nice by PRIO_MIN, > > newpriority = PUSER + p->p_estcpu / INVERSE_ESTCPU_WEIGHT + > > NICE_WEIGHT * (p->p_nice - PRIO_MIN); > > To fully utilize the 20 out of 32 run queues for user priorities, we might > want to change NICE_WEIGHT from 2 to 1, and upper limit of p_estcpu to > #define ESTCPULIM(e) \ > min((e), > INVERSE_ESTCPU_WEIGHT * (NICE_WEIGHT * (PRIO_MAX - PRIO_MIN) - PPQ) + \ > INVERSE_ESTCPU_WEIGHT - 1) > so that a cpu hog at nice 0 would have about the same priority as a low > cpu usage nice +20 process. Yes, this seems right. It seems that the niceness making the priority dip below 50 is a bad idea. I think that if we make that modification (which is another thing I tried) of niceness values subtracting PRIO_MIN to prevent any values less than PUSER, this would fix the bugs we have. I missed, when I did it, changing ESTCPULIM, so that probably explains why things didn't (I believe) lock up, but (I believe) seemed veerrry bad... Also, decreasing NICE_WEIGHT would be a good idea, so I'll try all of this out, and report later. > -lq -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 19: 3:10 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id CE55437B97C; Thu, 27 Apr 2000 19:03:05 -0700 (PDT) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.10.1/8.10.1) id e3S234X10756; Thu, 27 Apr 2000 22:03:04 -0400 (EDT) Date: Thu, 27 Apr 2000 22:03:04 -0400 (EDT) From: Luoqi Chen Message-Id: <200004280203.e3S234X10756@lor.watermarkgroup.com> To: green@FreeBSD.org Subject: Re: lock-ups due to the scheduler Cc: hackers@FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The deeper problem seems to be that for whatever the process does, it > never accrues enough estcpu to classify it as hoggy, as a process I > start with a niceness of -20 cycles through priorities 10 (in the > very beginning) and 27 at the very highest. This _shouldn't_ be too > much of a problem, but it never gets to 50 and thus never gets > rescheduled properly... and this seems to be most of what's causing the > lockups. > Even with max estcpu, the process will have a priority of PUSER - 4, which puts it at least one run queue higher than all user mode processes, therefore no user mode processes get a chance to run and the system is locked up. > > > newpriority = PUSER + p->p_estcpu / INVERSE_ESTCPU_WEIGHT + > > > NICE_WEIGHT * p->p_nice; > > We should probably offset p->p_nice by PRIO_MIN, > > > newpriority = PUSER + p->p_estcpu / INVERSE_ESTCPU_WEIGHT + > > > NICE_WEIGHT * (p->p_nice - PRIO_MIN); > > > > To fully utilize the 20 out of 32 run queues for user priorities, we might > > want to change NICE_WEIGHT from 2 to 1, and upper limit of p_estcpu to > > #define ESTCPULIM(e) \ > > min((e), > > INVERSE_ESTCPU_WEIGHT * (NICE_WEIGHT * (PRIO_MAX - PRIO_MIN) - PPQ) + \ > > INVERSE_ESTCPU_WEIGHT - 1) > > so that a cpu hog at nice 0 would have about the same priority as a low > > cpu usage nice +20 process. > > Yes, this seems right. It seems that the niceness making the priority dip > below 50 is a bad idea. I think that if we make that modification (which > is another thing I tried) of niceness values subtracting PRIO_MIN to > prevent any values less than PUSER, this would fix the bugs we have. > I missed, when I did it, changing ESTCPULIM, so that probably explains > why things didn't (I believe) lock up, but (I believe) seemed veerrry > bad... Also, decreasing NICE_WEIGHT would be a good idea, so I'll try > all of this out, and report later. > Would you try the patch below? I have shown it to Bruce and he approved it in principle. If it solves your problem, I will probably commit it sometime tomorrow. -lq Index: kern/kern_synch.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_synch.c,v retrieving revision 1.89 diff -u -r1.89 kern_synch.c --- kern/kern_synch.c 2000/03/28 18:06:42 1.89 +++ kern/kern_synch.c 2000/04/27 20:01:19 @@ -916,7 +916,7 @@ if (p->p_rtprio.type == RTP_PRIO_NORMAL) { newpriority = PUSER + p->p_estcpu / INVERSE_ESTCPU_WEIGHT + - NICE_WEIGHT * p->p_nice; + NICE_WEIGHT * (p->p_nice - PRIO_MIN); newpriority = min(newpriority, MAXPRI); p->p_usrpri = newpriority; } Index: sys/param.h =================================================================== RCS file: /home/ncvs/src/sys/sys/param.h,v retrieving revision 1.63 diff -u -r1.63 param.h --- sys/param.h 2000/03/27 21:29:33 1.63 +++ sys/param.h 2000/04/27 19:19:59 @@ -111,7 +111,7 @@ #define PCONFIG 32 #define PLOCK 36 #define PPAUSE 40 -#define PUSER 50 +#define PUSER 46 #define MAXPRI 127 /* Priorities range from 0 through MAXPRI. */ #define PRIMASK 0x0ff Index: sys/proc.h =================================================================== RCS file: /home/ncvs/src/sys/sys/proc.h,v retrieving revision 1.102 diff -u -r1.102 proc.h --- sys/proc.h 2000/04/16 18:53:29 1.102 +++ sys/proc.h 2000/04/27 14:33:23 @@ -405,10 +405,10 @@ * the range 100-256 Hz (approximately). */ #define ESTCPULIM(e) \ - min((e), INVERSE_ESTCPU_WEIGHT * (NICE_WEIGHT * PRIO_MAX - PPQ) + \ + min((e), INVERSE_ESTCPU_WEIGHT * (NICE_WEIGHT * (PRIO_MAX - PRIO_MIN)) + \ INVERSE_ESTCPU_WEIGHT - 1) #define INVERSE_ESTCPU_WEIGHT 8 /* 1 / (priorities per estcpu level) */ -#define NICE_WEIGHT 2 /* priorities per nice level */ +#define NICE_WEIGHT 1 /* priorities per nice level */ #define PPQ (128 / NQS) /* priorities per queue */ extern u_long ps_arg_cache_limit; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 19:17:30 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from outmail.utsunomiya-u.ac.jp (outmail.utsunomiya-u.ac.jp [160.12.196.3]) by hub.freebsd.org (Postfix) with ESMTP id 29CB937BDAE for ; Thu, 27 Apr 2000 19:17:22 -0700 (PDT) (envelope-from yokota@zodiac.mech.utsunomiya-u.ac.jp) Received: from zodiac.mech.utsunomiya-u.ac.jp (IDENT:02wY97S8SKGJ/6EOFbnw7ozFms8itbbS@zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by outmail.utsunomiya-u.ac.jp (8.9.3/3.7Wpl2) with ESMTP id LAA16261; Fri, 28 Apr 2000 11:17:14 +0900 (JST) Received: from zodiac.mech.utsunomiya-u.ac.jp (zodiac.mech.utsunomiya-u.ac.jp [160.12.42.1]) by zodiac.mech.utsunomiya-u.ac.jp (8.7.6+2.6Wbeta7/3.4W/zodiac-May96) with ESMTP id LAA04611; Fri, 28 Apr 2000 11:23:53 +0900 (JST) Message-Id: <200004280223.LAA04611@zodiac.mech.utsunomiya-u.ac.jp> To: Dragos Ruiu Cc: hackers@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp Subject: Re: Mouse Sync Problems with KVM In-reply-to: Your message of "Thu, 27 Apr 2000 17:50:17 MST." <0004271752300E.00332@kyxbot.zorg> References: <0004271752300E.00332@kyxbot.zorg> Date: Fri, 28 Apr 2000 11:23:53 +0900 From: Kazutaka YOKOTA Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >I have a freebsd system(3.4S) on a KVM.... and every time the monitored >system is switched, the mouse driver gets fuxored, and when you switch >back to the system the driver starts outputting oodles of the following >messages to syslog every time the mouse is moved: > >Apr 26 18:49:45 kyxbot /kernel: psmintr: out of sync (00c8 != 0008). >Apr 26 18:49:45 kyxbot /kernel: psmintr: out of sync (0000 != 0008). > >mouse type is PS/2 Which model is it? I suspect it is one of those mice with the "wheel". >Has anyone seen this before? Or do I have to get down and dirty with >the driver? This may be an issue with the KVM switch because it >does this on two different 3.4 systems on different KVMs, both KVM >brands are identical(masterview)... KVMs have presented so many headaches to us... Well, if the mouse works fine when you directly connect the mouse to the host computer, but it doesn't work as expected when you use a KVM, I would say the KVM is not compatible enough and is the cause of the problem.... I would like to see /var/run/dmesg.boot when you directly connect the mouse to your computer and reboot. I also like to compare it with /var/run/dmesg.boot obtained when you are using the KVM. Some KVMs are simple switch boxes which may momentarily cut power to the mouse when you switch between computers. Your mouse will loose internal settings if the power is cut. This will lead to mismatch of protocol between the host and the mouse. Some other KVMs are said to be smart enough to remember settings or understand wheel mouse protocols, and are free from such problem. But, the fact is, it appears that the firmware in many KVMs knows very limited number of various protocols (IntelliMouse protocol is not the only wheel mouse protocol in the market, you know), and can be easily confused and is not able to forward mouse data properly in a timely manner to the host computer. I wonder how many KVM products can handle dual-wheel mice from A4 Tech, IBM ScrollPoint mouse, and Logitech wheel mice when their proprietary drivers are installed in W*ndows95/98... >But the KVM works with Wintendo/NT, >Linux and OpenBSD just fine... on the same HW. If your mouse is a wheel mouse, do you have its driver installed on NT? If it isn't, the mouse is just acting as the standard 2 button mouse without wheel's functionality. That's why you don't see any problem with NT. The PS/2 mouse drivers in Linux and OpenBSD do not detect and initialize the wheel mouse. XFree86 servers try to activate the wheel, if you specify an appropriate wheel mouse protocol in XF86Config. I suspect you will see the mouse cursor go crazy if you switch KVM away from and back to the Linux/OpenBSD box while running the X server in this case. You can force FreeBSD to use the mouse as the standard PS/2 mouse by specifying the flags 0x200 to the psm driver. This way, the mouse should always work. But, you cannot use the wheel. Kazu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 19:36:29 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rdc2.bc.home.com (ha1.rdc2.bc.wave.home.com [24.2.10.68]) by hub.freebsd.org (Postfix) with ESMTP id B9DE737B957 for ; Thu, 27 Apr 2000 19:36:25 -0700 (PDT) (envelope-from dr@dursec.com) Received: from kyxbot.zorg ([24.113.134.64]) by mail.rdc2.bc.home.com (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20000428023623.TSF5540.mail.rdc2.bc.home.com@kyxbot.zorg>; Thu, 27 Apr 2000 19:36:23 -0700 From: Dragos Ruiu Organization: kyx.net To: Kazutaka YOKOTA Subject: Re: Mouse Sync Problems with KVM Date: Thu, 27 Apr 2000 19:19:11 -0700 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain Cc: hackers@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp, fygrave@scorpions.net References: <0004271752300E.00332@kyxbot.zorg> <200004280223.LAA04611@zodiac.mech.utsunomiya-u.ac.jp> In-Reply-To: <200004280223.LAA04611@zodiac.mech.utsunomiya-u.ac.jp> MIME-Version: 1.0 Message-Id: <00042719342207.00575@kyxbot.zorg> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 27 Apr 2000, Kazutaka YOKOTA wrote: > >I have a freebsd system(3.4S) on a KVM.... and every time the monitored > >system is switched, the mouse driver gets fuxored, and when you switch > >back to the system the driver starts outputting oodles of the following > >messages to syslog every time the mouse is moved: > Which model is it? I suspect it is one of those mice with the "wheel". Yep, Logitech TrackBall... love them because they are optical and easy to clean. Yep, it has the stupid wheel .... I hate it.... But no-one sells the old model without it. (I find it uncomfortable and long for the simple old middle button) > Well, if the mouse works fine when you directly connect the mouse to > the host computer, but it doesn't work as expected when you use a KVM, > I would say the KVM is not compatible enough and is the cause of the > problem.... > Some other KVMs are said to be smart enough to remember settings or > understand wheel mouse protocols, and are free from such problem. > But, the fact is, it appears that the firmware in many KVMs knows very > limited number of various protocols (IntelliMouse protocol is not the > only wheel mouse protocol in the market, you know), and can be easily > confused and is not able to forward mouse data properly in a timely > manner to the host computer. Mouse works fine until you switch.... Yes, KVM is a smart one that spoofs monitor/mouse... but it you hit it on the nose when you said that it doesn't recognize anything beyond a simple set of drivers... as a matter of fact it makes the wheel inoperative even on Wintendo with the special Logitech drivers. > I wonder how many KVM products can handle dual-wheel mice from A4 > Tech, IBM ScrollPoint mouse, and Logitech wheel mice when their > proprietary drivers are installed in W*ndows95/98... None that I've found :-( > >But the KVM works with Wintendo/NT, > >Linux and OpenBSD just fine... on the same HW. > If your mouse is a wheel mouse, do you have its driver installed on > NT? If it isn't, the mouse is just acting as the standard 2 button > mouse without wheel's functionality. That's why you don't see any > problem with NT. > > The PS/2 mouse drivers in Linux and OpenBSD do not detect and > initialize the wheel mouse. XFree86 servers try to activate the > wheel, if you specify an appropriate wheel mouse protocol in > XF86Config. I suspect you will see the mouse cursor go crazy if you > switch KVM away from and back to the Linux/OpenBSD box while running > the X server in this case. > Doesn't go crazy... just starts to lose button input, and movements quickly saturate syslog with a zillion alternating (different dammit so the duplicate entry logic doesn't even kick in!) lines. > You can force FreeBSD to use the mouse as the standard PS/2 mouse by > specifying the flags 0x200 to the psm driver. This way, the mouse > should always work. But, you cannot use the wheel. I really couldn't give a damn about the pesky wheel. I will try this. Where are the flags set? Kernel Config? boot manager? Where is that handbook again... :-) I'll report back if this is succesfull. BTW this sounds very promising.... MANY THANKS. cheers, --dr -- dursec.com / kyx.net - we're from the future http://www.dursec.com learn kanga-foo from security experts: CanSecWest - May 10-12 Vancouver Speakers: Ron Gula/NSW, Ken Williams/E&Y, Marty Roesch/Hiverworld, Fyodor/insecure.org, RainForestPuppy/wiretrip.net, Theo de Raadt/OpenBSD Lance Spitzner/Sun, Fyodor Yarochkin/KALUG, Max Vision/whitehats.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 19:44:25 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp02.teb1.iconnet.net (smtp02.teb1.iconnet.net [209.3.218.43]) by hub.freebsd.org (Postfix) with ESMTP id 4E23737BB5A for ; Thu, 27 Apr 2000 19:44:22 -0700 (PDT) (envelope-from babkin@bellatlantic.net) Received: from bellatlantic.net (client-151-198-135-42.bellatlantic.net [151.198.135.42]) by smtp02.teb1.iconnet.net (8.9.1/8.9.1) with ESMTP id WAA05559; Thu, 27 Apr 2000 22:43:36 -0400 (EDT) Message-ID: <3908FCA1.C8A4D7A7@bellatlantic.net> Date: Thu, 27 Apr 2000 22:51:13 -0400 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.0-19990626-CURRENT i386) X-Accept-Language: ru, en MIME-Version: 1.0 To: Dragos Ruiu Cc: hackers@FreeBSD.ORG Subject: Re: Mouse Sync Problems with KVM References: <0004271752300E.00332@kyxbot.zorg> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dragos Ruiu wrote: > > I'll try asking here now.... > > I have a freebsd system(3.4S) on a KVM.... and every time the monitored > system is switched, the mouse driver gets fuxored, and when you switch > back to the system the driver starts outputting oodles of the following > messages to syslog every time the mouse is moved: ... > brands are identical(masterview)... But the KVM works with Wintendo/NT, > Linux and OpenBSD just fine... on the same HW. Possibly the problem is with the exact mode of the keyboard/mouse controller. I can give an example: I have a KVM (Connectpro BA-12P, can't remember the name of OEM now) installed with UnixWare machines which mostly works but when I exit from KDB (the UW kernel debugger) the keyboard hangs. Disconnecting and re-connecting the physical keyboard fixes the problem. My guess is that the KVM handles properly only a subset of the commands that may be set to and from the keyboard, so if some unsupported command passes through it all the kinds of weird effects start happening. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Apr 27 20:38:51 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rdc2.bc.home.com (ha1.rdc2.bc.wave.home.com [24.2.10.68]) by hub.freebsd.org (Postfix) with ESMTP id 84B7337B93B for ; Thu, 27 Apr 2000 20:38:48 -0700 (PDT) (envelope-from dr@dursec.com) Received: from kyxbot.zorg ([24.113.134.64]) by mail.rdc2.bc.home.com (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20000428033848.CWSC5540.mail.rdc2.bc.home.com@kyxbot.zorg>; Thu, 27 Apr 2000 20:38:48 -0700 From: Dragos Ruiu Organization: kyx.net To: Kazutaka YOKOTA Subject: Re: Mouse Sync Problems with KVM Date: Thu, 27 Apr 2000 20:34:31 -0700 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain Cc: hackers@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp, fygrave@scorpions.net References: <0004271752300E.00332@kyxbot.zorg> <200004280223.LAA04611@zodiac.mech.utsunomiya-u.ac.jp> <00042719342207.00575@kyxbot.zorg> In-Reply-To: <00042719342207.00575@kyxbot.zorg> MIME-Version: 1.0 Message-Id: <00042720364901.00334@kyxbot.zorg> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 27 Apr 2000, Dragos Ruiu wrote: > On Thu, 27 Apr 2000, Kazutaka YOKOTA wrote: > > >I have a freebsd system(3.4S) on a KVM.... and every time the monitored > > >system is switched, the mouse driver gets fuxored, and when you switch > > >back to the system the driver starts outputting oodles of the following > > >messages to syslog every time the mouse is moved: > > You can force FreeBSD to use the mouse as the standard PS/2 mouse by > > specifying the flags 0x200 to the psm driver. This way, the mouse > > should always work. But, you cannot use the wheel. Problem Solved... Flags of 0x100 from psm(4) look promising too to get it working with the wheel, but I couldn't care less about the friggin wheelie thing... so my system is happy. Many thanks, --dr -- dursec.com / kyx.net - we're from the future http://www.dursec.com learn kanga-foo from security experts: CanSecWest - May 10-12 Vancouver Speakers: Ron Gula/NSW, Ken Williams/E&Y, Marty Roesch/Hiverworld, Fyodor/insecure.org, RainForestPuppy/wiretrip.net, Theo de Raadt/OpenBSD Lance Spitzner/Sun, Fyodor Yarochkin/KALUG, Max Vision/whitehats.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 28 0:48:35 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ns3.khmere.com (216-59-86-175.usa2.flashcom.net [216.59.86.175]) by hub.freebsd.org (Postfix) with ESMTP id 9C45737B6E2 for ; Fri, 28 Apr 2000 00:48:32 -0700 (PDT) (envelope-from nathan@khmere.com) Received: from khmere.com (ns2.khmere.com [216.59.86.176]) by ns3.khmere.com (8.9.3/8.8.7) with ESMTP id AAA61053 for ; Fri, 28 Apr 2000 00:49:37 -0700 (PDT) Message-ID: <3909424D.7B57AECD@khmere.com> Date: Fri, 28 Apr 2000 00:48:29 -0700 From: nathan@khmere.com X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i586) X-Accept-Language: en MIME-Version: 1.0 To: "hackers@FreeBSD.ORG" Subject: FreeBSD 4.0 installation for Laptops ?? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I tried to Install the 4.0 on my laptop but it dosent seem to find the ethernet card ? I have a Sager NP8620 Cirrus Logic CL-PD6729-QC-B its on 0x3000 and irq 7 Now when it boots the kernel it finds the controller and initializes it, the link light comes on and I hear a beep but when I try to select a device installation it does not list my ethernet ? It was supported under 3.3 and 3.2 (with PAO) has thier been changes ? or is thier something special i need to do ? Please any help ? Sorry for spelling........ thank you nathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 28 3:33: 1 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from cairo.anu.edu.au (cairo.anu.edu.au [150.203.224.11]) by hub.freebsd.org (Postfix) with ESMTP id 1299737B918 for ; Fri, 28 Apr 2000 03:32:56 -0700 (PDT) (envelope-from avalon@cairo.anu.edu.au) Received: (from avalon@localhost) by cairo.anu.edu.au (8.9.3/8.9.3) id UAA01136 for hackers@freebsd.org; Fri, 28 Apr 2000 20:32:49 +1000 (EST) From: Darren Reed Message-Id: <200004281032.UAA01136@cairo.anu.edu.au> Subject: FreeBSD-4.0 PCMCIA broken ? To: hackers@freebsd.org Date: Fri, 28 Apr 2000 20:32:48 +1000 (Australia/NSW) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Does FreeBSD-4.0 support IRQ sharing ? Or rather, does pccardd support configuring devices in such a manner ? I suspect that part of my problem with getting my 3c589D to work under 4.0 is related to this. (It has so far refused to work). For example, under NetBSD: ... pciide0: primary channel interrupting at irq 14 pciide0: secondary channel interrupting at irq 15 uhci0: interrupting at irq 10 com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo pckbc0: using irq 1 for kbd slot pckbc0: using irq 12 for aux slot sb0 at isa0 port 0x220-0x237 irq 5 drq 1: dsp v3.01 fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2 cbb0: interrupting at irq 10 cbb1: interrupting at irq 10 ... - three different devices use irq 10 (this includes ep0, which is at pcmcia1/cardslot1/cbb1). If I try to put it at IRQ 10 with "device ep0 at isa? ... irq 10", it fails. If I try to make it go to another IRQ, it fails. If I look at dmesg from FreeBSD (sorry, cut-n-paste doesn't work across an air gap) I see: ata0: irq 14 ata1: irq 15 uhci0: irq 10 on pci0 pcic-pci0: irq 10 at device 10.0 on pci0 pcic-pci1: irq 10 at device 10.1 on pci0 fdc0: irq 6 atkbd0: irq 1 psm0: rq 12 pcic0: at port 0x3e0 iomem 0xd0000 irq 10 on isa0 pcic0: management irq 11 sio0 .. irq 4 ... sio1 .. irq 3 ... I've also got a 3Com 3CCM156B (modem) which pccardd shows as ""("") when I insert it, never mind that it fails to notice any pcmcia events after popping it out and then puttint it back in. It would also appear that pccardd fails to notice the 3c589D at boot time if the 3CCM156B is inserted. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 28 5:17:33 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from test.tar.com (test.tar.com [204.95.187.4]) by hub.freebsd.org (Postfix) with ESMTP id 8A51437BE73; Fri, 28 Apr 2000 05:17:29 -0700 (PDT) (envelope-from dick@test.tar.com) Received: (from dick@localhost) by test.tar.com (8.9.3/8.9.3) id HAA59319; Fri, 28 Apr 2000 07:17:26 -0500 (CDT) (envelope-from dick) Date: Fri, 28 Apr 2000 07:17:26 -0500 From: "Richard Seaman, Jr." To: Brian Fundakowski Feldman Cc: Luoqi Chen , hackers@FreeBSD.ORG Subject: Re: lock-ups due to the scheduler Message-ID: <20000428071726.I370@seaman.org> References: <200004270547.e3R5lfi24004@lor.watermarkgroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from green@FreeBSD.ORG on Thu, Apr 27, 2000 at 09:16:40PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG There may be additional issues with the scheduler, though they may not be related to the issue you have. Check www.freebsd.org/~dick/sched.descr I was under the impression that Peter Dufault had re-assumed this matter, but not much has happened on most of the issues. -- Richard Seaman, Jr. email: dick@seaman.org 5182 N. Maple Lane phone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 28 6:34:26 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id 0B82837B5CA; Fri, 28 Apr 2000 06:34:23 -0700 (PDT) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.10.1/8.10.1) id e3SDXmd18152; Fri, 28 Apr 2000 09:33:48 -0400 (EDT) Date: Fri, 28 Apr 2000 09:33:48 -0400 (EDT) From: Luoqi Chen Message-Id: <200004281333.e3SDXmd18152@lor.watermarkgroup.com> To: dick@seaman.org, green@FreeBSD.ORG Subject: Re: lock-ups due to the scheduler Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > There may be additional issues with the scheduler, though they may not > be related to the issue you have. Check www.freebsd.org/~dick/sched.descr > I was under the impression that Peter Dufault had re-assumed this matter, > but not much has happened on most of the issues. > Could you add the this problem to your list: p_rqindex does not encode which queue a process is on? Consider this scenario, we are lowering a process' priority from realtime to normal. This process is in runnable state on one of the run queues while another process is changing its p_rtprio, after it's done, a clock intr comes and the scheduler decides the process should go to another run queue, so it tries to remove process on the p_rqindex'th normal priority run queue and results in data corruption. When changing a process from one scheduling class to another, we should also move it to the apprioriate run queue (if it's in runnable state). When that's done, we will start getting reports about corrupted run queues... -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 28 10: 1:17 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from elisa.utopianet.net (elisa.utopianet.net [212.210.231.2]) by hub.freebsd.org (Postfix) with ESMTP id 63DD737B7D9 for ; Fri, 28 Apr 2000 10:01:09 -0700 (PDT) (envelope-from l.iania@sintesi.net) Received: from lorenzo (giorgia.sintesi.net [212.210.231.9]) by elisa.utopianet.net (8.9.1a/8.9.1) with SMTP id QAA21319 for ; Fri, 28 Apr 2000 16:36:52 +0200 (CEST) Message-ID: <017c01bfb11f$ab144c80$0500000a@sintesi.net> Reply-To: "Lorenzo Iania" From: "Lorenzo Iania" To: Subject: lpr: order of print requests Date: Fri, 28 Apr 2000 16:40:14 +0200 Organization: S.IN.TE.S.I. Srl MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have the following problem using lpr: when the number of consecutive requests grow, they are not printed in the same order. This happens on several versions from 2.2.7 to 3.4. All the requests are printed, but the order is not the same of the requests. Effectively the order is initially right, but then it fails and skips a number of requests that are printer later. Why this happens? What can I do? Any suggestions?? Thanks To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 28 13:13:38 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from Samizdat.uucom.com (samizdat.uucom.com [198.202.217.54]) by hub.freebsd.org (Postfix) with ESMTP id 55B4737B94B for ; Fri, 28 Apr 2000 13:13:35 -0700 (PDT) (envelope-from cshenton@uucom.com) Received: (from cshenton@localhost) by Samizdat.uucom.com (8.9.3/8.9.3) id QAA29500; Fri, 28 Apr 2000 16:13:32 -0400 (EDT) To: Jeroen Hogeveen Cc: hackers@FreeBSD.ORG Subject: Re: Asus K7V boot failure References: <3909FF8B.E8224960@EFMSoftware.COM> From: Chris Shenton Date: 28 Apr 2000 16:13:32 -0400 In-Reply-To: Jeroen Hogeveen's message of "Fri, 28 Apr 2000 23:15:55 +0200" Message-ID: Lines: 10 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 28 Apr 2000 23:15:55 +0200, Jeroen Hogeveen said: Jeroen> Hey Chris and Jordan, I've got one too, you should however Jeroen> disable your boot virus protection in the bios setup! Jeroen> This will fix the problem you described. Jeroen> Maybe something to mention in the FAQ, if it is not yet there. Yup, fixed here, and something definetely for an FAQ. Many thanks! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 28 13:17:22 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from southpass.baynetworks.com (ns2.BayNetworks.COM [134.177.3.16]) by hub.freebsd.org (Postfix) with ESMTP id B9C2B37B529 for ; Fri, 28 Apr 2000 13:17:19 -0700 (PDT) (envelope-from bwithrow@BayNetworks.COM) Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by southpass.baynetworks.com (8.9.1/8.9.1) with ESMTP id NAA01169 for ; Fri, 28 Apr 2000 13:10:06 -0700 (PDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id QAA24056 for ; Fri, 28 Apr 2000 16:22:04 -0400 (EDT) Received: from baynetworks.com (kyzyl [192.32.150.103]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id QAA14661; Fri, 28 Apr 2000 16:17:17 -0400 for Message-Id: <200004282017.QAA14661@pobox.engeast.BayNetworks.COM> X-Mailer: exmh version 2.1.1 10/15/1999 To: freebsd-hackers@freebsd.org Subject: Cross building freebsd? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Apr 2000 16:14:22 -0400 From: Robert Withrow Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've searched through the mailing list archives and otherwise searched around, but haven't found any real solid information, so... I'm looking for any and all information about for cross-building Freebsd for embedded Powerpc platforms. (The powerpc porting project is just getting started and this info isn't available there.) [Background: I've ported Chorus and Linux to this platform. So I pretty well understand the generic process. I just need freebsd-specific info.] Specifically, I need to know: 1. Exactly what FreeBSD-specific things need to be done to a GCC-2.95.2 compilation system to get cross builds to work? a. What headers should be used? (Not newlib, right?) b. What as and ld should be used. c. What kind of abi options are necessary? Like stack frames, -f, etc... d. etc.... I've scanned through the GCC and Binutils stuff and I have a rough idea, but I'd appreciate advice from someone who's actually been there and done that! (Maybe one of the original Alpha porters?) 2. What are the mechanical steps needed to insert a new port? a. I plan to scan for "[Aa]lpha" in the entire source tree and do what they did, but perhaps there is an easier way? Like, where are architecture-specific things hiding? 3. How do you actually cross-build FreeBSD? Is there a FAQ? a. Again, I plan on scanning for alpha, but a cookbook would be easier. Thanks! -- Robert Withrow -- (+1 978 288 8256) BWithrow@BayNetworks.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 28 14: 7:40 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from stipe.1stup.com (stipe.1stup.com [209.143.242.34]) by hub.freebsd.org (Postfix) with ESMTP id 2F4F537BA03 for ; Fri, 28 Apr 2000 14:07:28 -0700 (PDT) (envelope-from richieallen_2000@yahoo.com) Received: from yahoo.com (DNBHB107-16.splitrock.net [209.253.10.16]) by stipe.1stup.com (8.9.3/8.9.2) with SMTP id OAA04679; Fri, 28 Apr 2000 14:06:30 -0700 Date: Fri, 28 Apr 2000 14:06:30 -0700 From: richieallen_2000@yahoo.com Message-Id: <200004282106.OAA04679@stipe.1stup.com> Reply-To: richieallen_2000@yahoo.com To: richieallen_2000@yahoo.com Subject: Cancun,Mexico-Orlando,Florida-Maui,Hawii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Call NOW: 1-407-645-1232 KIDS STAY FREE Accomodations include: 5 days and 4 nights in a FIVE STAR RESORT or GOLD CROWN HOTEL. and admission to any of the major Theme Parks including Magic Kingdo, MGM Studios, Epcot Center and Animal Kingdom. KIDS STAY FREE Call Now and receive your choice of a FREE 3 day, 2 night BONUS GETAWAY to Hawaii, Mexico or Las Vegas!!!!! Over 50 Locations to choose from. KIDS STAY FREE Call now and receive a free upgrade to a fully furnished 2 bedroom, 2.5bath villa at no extra charge. Not enough? Receive a free Casino Cruise! This is the last week. CALL NOW: 1-407-461-2456 To be removed from this mailing list please reply to: richieallen_2000@yahoo.com ________________________________________________________ 1stUp.com - Free the Web® Get your free Internet access at http://www.1stUp.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 28 14:29:11 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from bachue.usc.unal.edu.co (bachue.usc.unal.edu.co [168.176.3.20]) by hub.freebsd.org (Postfix) with ESMTP id 1149937BA72 for ; Fri, 28 Apr 2000 14:29:02 -0700 (PDT) (envelope-from giffunip@asme.org) Received: from asme.org ([216.252.137.48]) by bachue.usc.unal.edu.co (Netscape Messaging Server 3.6) with ESMTP id AAA70BB; Fri, 28 Apr 2000 16:27:39 -0400 Message-ID: <390A02C7.D0EFF6BB@asme.org> Date: Fri, 28 Apr 2000 16:29:43 -0500 From: "Pedro F. Giffuni" Organization: Universidad Nacional de Colombia X-Mailer: Mozilla 4.5 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Robert Withrow Cc: freebsd-hackers@freebsd.org Subject: Re: Cross building freebsd? References: <200004282017.QAA14661@pobox.engeast.BayNetworks.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Robert Withrow wrote: > > I've searched through the mailing list archives and otherwise > searched around, but haven't found any real solid information, > so... > BEWARE: I have never done this, but I probably have a reasonable guess since I wrote the basic "crosskit" ports we carry. > > Specifically, I need to know: > > 1. Exactly what FreeBSD-specific things need to be done to a > GCC-2.95.2 compilation system to get cross builds to work? > Take a look at Jerry Hicks' crossm68k ports, there is everything you need to start with a cross binutils and a crossgcc. You should only have to change the TARGET, but it would be good to check the crossgcc FAQ at cygnus, JIC there is something special about the powerpc crosscompiler. > a. What headers should be used? (Not newlib, right?) > b. What as and ld should be used. > c. What kind of abi options are necessary? Like stack > frames, -f, etc... > d. etc.... > WRT (b) the crossbinutils will produce the as and ld you need. There are two possible paths: 1) building FreeBSD from the start (probably the hardest). - Since you are building for an embedded system you don't need any OS on your target. Something like powerpc-elf should work (look in the crossgcc FAQ for the supported targets). - You should then start porting FreeBSD's libc with this compiler; newlib is probably a good reference. - The rest of the userland has to be built, but I wouldn't bet on the resulting kernel booting due to problems while crossbuilding from 32 to 64 bits. 2) Using another target (probably the path used by FreeBSD-Alpha) -If you have access to the platform in question but just want the crossutils to help, you could use the equivalent NetBSD target (powerpc-netbsd-elf ?). -In this case you can also use NetBSD's headers and libraries while you get started, and get the FreeBSD userland (booter, etc) ported. - Eventually you can get a working kernel and some drivers. All more easily said than done... cheers, Pedro. > I've scanned through the GCC and Binutils stuff and I have a rough > idea, but I'd appreciate advice from someone who's actually been > there and done that! (Maybe one of the original Alpha porters?) > > 2. What are the mechanical steps needed to insert a new port? > > a. I plan to scan for "[Aa]lpha" in the entire source tree and > do what they did, but perhaps there is an easier way? Like, where > are architecture-specific things hiding? > > 3. How do you actually cross-build FreeBSD? Is there a FAQ? > > a. Again, I plan on scanning for alpha, but a cookbook would > be easier. > > Thanks! > > -- > Robert Withrow -- (+1 978 288 8256) > BWithrow@BayNetworks.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 28 15:14: 0 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 4563C37B892; Fri, 28 Apr 2000 15:13:41 -0700 (PDT) (envelope-from green@FreeBSD.org) Date: Fri, 28 Apr 2000 18:13:32 -0400 (EDT) From: Brian Fundakowski Feldman X-Sender: green@green.dyndns.org To: "Richard Seaman, Jr." Cc: Luoqi Chen , hackers@FreeBSD.ORG Subject: Re: lock-ups due to the scheduler In-Reply-To: <20000428071726.I370@seaman.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 28 Apr 2000, Richard Seaman, Jr. wrote: > There may be additional issues with the scheduler, though they may not > be related to the issue you have. Check www.freebsd.org/~dick/sched.descr > I was under the impression that Peter Dufault had re-assumed this matter, > but not much has happened on most of the issues. Why don't we do a investigation (reinvestigation for you, of course), evaluation of solutions, implementation of the best solution, and review between all of us, and get Bruce or Peter Dufault to review them as well? We could do this for each scheduler problem you have listed, and get them all fixed within a month's time, if we just handle them all as the individual cases, and work on each one serially? I'm quite willing to do everything I can to help, including the evaluation, solving, and testing of each problem separately. > -- > Richard Seaman, Jr. email: dick@seaman.org > 5182 N. Maple Lane phone: 262-367-5450 > Chenequa WI 53058 fax: 262-367-5852 -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 28 15:48:12 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from test.tar.com (test.tar.com [204.95.187.4]) by hub.freebsd.org (Postfix) with ESMTP id 1174B37B9F4; Fri, 28 Apr 2000 15:48:08 -0700 (PDT) (envelope-from dick@test.tar.com) Received: (from dick@localhost) by test.tar.com (8.9.3/8.9.3) id RAA61068; Fri, 28 Apr 2000 17:48:06 -0500 (CDT) (envelope-from dick) Date: Fri, 28 Apr 2000 17:48:06 -0500 From: "Richard Seaman, Jr." To: Brian Fundakowski Feldman Cc: Luoqi Chen , hackers@FreeBSD.org Subject: Re: lock-ups due to the scheduler Message-ID: <20000428174806.J370@seaman.org> References: <20000428071726.I370@seaman.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from green@FreeBSD.org on Fri, Apr 28, 2000 at 06:13:32PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Apr 28, 2000 at 06:13:32PM -0400, Brian Fundakowski Feldman wrote: > On Fri, 28 Apr 2000, Richard Seaman, Jr. wrote: > > > There may be additional issues with the scheduler, though they may not > > be related to the issue you have. Check www.freebsd.org/~dick/sched.descr > > I was under the impression that Peter Dufault had re-assumed this matter, > > but not much has happened on most of the issues. > > Why don't we do a investigation (reinvestigation for you, of course), > evaluation of solutions, implementation of the best solution, and > review between all of us, and get Bruce or Peter Dufault to review > them as well? We could do this for each scheduler problem you have > listed, and get them all fixed within a month's time, if we just > handle them all as the individual cases, and work on each one > serially? > > I'm quite willing to do everything I can to help, including the > evaluation, solving, and testing of each problem separately. Be my guest. There is a patch set, now about a year old at the same site as the description. I held up working on this because no one else seemed interested (I got no comments to a posting about a year ago), plus I wasn't sure my solution (an adaptation of Peter Dufault's solution) was right for SMP. In fact, I think it wasn't. Also, I wanted to give some of the other issues more study and got sidetracked on other things. Feel free to pick up any of this. I seem to remember that Bruce had some problems with Peter Dufault's original verion of the patch set, and I'm not aware that he ever looked at my modified version. In any event, the patch set is now out of date. -- Richard Seaman, Jr. email: dick@seaman.org 5182 N. Maple Lane phone: 262-367-5450 Chenequa WI 53058 fax: 262-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 28 16:25:49 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from virtual-voodoo.com (virtual-voodoo.com [204.120.165.254]) by hub.freebsd.org (Postfix) with ESMTP id DD29E37B593 for ; Fri, 28 Apr 2000 16:25:46 -0700 (PDT) (envelope-from steve@virtual-voodoo.com) Received: (from root@localhost) by virtual-voodoo.com (8.10.0/8.10.0) id e3SNPhD74505 for freebsd-hackers@freebsd.org; Fri, 28 Apr 2000 18:25:43 -0500 (EST) Date: Fri, 28 Apr 2000 18:25:43 -0500 (EST) From: Steve Ames Message-Id: <200004282325.e3SNPhD74505@virtual-voodoo.com> To: freebsd-hackers@freebsd.org Subject: swapinfo typo? Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG # swapinfo Device 1K-blocks Used Avail Capacity Type /dev/rad0s1b 102272 0 102272 0% Interleaved /dev/rad1s1b 255872 0 255872 0% Interleaved Total 358144 0 358144 0% # I'm probably misunderstanding something, but... should this just be reporting '/dev/ad' and not '/dev/rad'? -Steve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 28 17:41: 8 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13]) by hub.freebsd.org (Postfix) with ESMTP id EABBC37B99A for ; Fri, 28 Apr 2000 17:41:01 -0700 (PDT) (envelope-from ben@scientia.demon.co.uk) Received: from strontium.scientia.demon.co.uk ([192.168.91.36] ident=exim) by scientia.demon.co.uk with esmtp (Exim 3.12 #1) id 12lJy0-00063i-00 for FreeBSD-hackers@freebsd.org; Sat, 29 Apr 2000 00:14:36 +0100 Received: (from ben) by strontium.scientia.demon.co.uk (Exim 3.12 #7) id 12lJy0-0002OR-00 for FreeBSD-hackers@FreeBSD.org; Sat, 29 Apr 2000 00:14:36 +0100 Date: Sat, 29 Apr 2000 00:14:36 +0100 From: Ben Smithurst To: FreeBSD-hackers@FreeBSD.org Subject: Adding -maxdepth and -mindepth options to find(1) Message-ID: <20000429001436.F17098@strontium.scientia.demon.co.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="MnLPg7ZWsaic7Fhd" X-Mailer: Mutt 1.0i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --MnLPg7ZWsaic7Fhd Content-Type: text/plain; charset=us-ascii Hi, A request came up on the FreeBSD-questions list earlier for the -maxdepth option as found in GNU find to work in FreeBSD's find. It turns out that -prune will do what this guy wanted, but would it be a good idea to add -maxdepth (and -mindepth just to be consistent) for any other people who might want it? I've attached a patch to implement this, if I don't get any feedback I'll send-pr it instead, I thought I might get a few opinions here first. -- Ben Smithurst / ben@scientia.demon.co.uk / PGP: 0x99392F7D --MnLPg7ZWsaic7Fhd Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="find.diff" Index: extern.h =================================================================== RCS file: /usr/cvs/src/usr.bin/find/extern.h,v retrieving revision 1.9 diff -u -r1.9 extern.h --- extern.h 1999/12/19 15:43:18 1.9 +++ extern.h 2000/04/28 19:42:08 @@ -80,6 +80,8 @@ PLAN *c_xdev __P((void)); PLAN *c_openparen __P((void)); PLAN *c_closeparen __P((void)); +PLAN *c_maxdepth __P((char *)); +PLAN *c_mindepth __P((char *)); PLAN *c_mmin __P((char *)); PLAN *c_mtime __P((char *)); PLAN *c_not __P((void)); Index: find.1 =================================================================== RCS file: /usr/cvs/src/usr.bin/find/find.1,v retrieving revision 1.23 diff -u -r1.23 find.1 --- find.1 2000/03/01 10:48:32 1.23 +++ find.1 2000/04/28 19:48:12 @@ -245,6 +245,12 @@ If the file is a symbolic link, the pathname of the linked\-to file will be displayed preceded by ``\->''. The format is identical to that produced by ``ls \-dgils''. +.It Ic -maxdepth Ar n +True if the depth of the current file into the tree is less than or equal to +.Ar n . +.It Ic -mindepth Ar n +True if the depth of the current file into the tree is greater than or equal to +.Ar n . .It Ic -mmin Ar n True if the difference between the file last modification time and the time .Nm find Index: find.h =================================================================== RCS file: /usr/cvs/src/usr.bin/find/find.h,v retrieving revision 1.6 diff -u -r1.6 find.h --- find.h 1999/12/19 15:43:18 1.6 +++ find.h 2000/04/28 19:44:31 @@ -46,7 +46,7 @@ N_MTIME, N_NAME, N_NEWER, N_NOGROUP, N_NOT, N_NOUSER, N_OK, N_OPENPAREN, N_OR, N_PATH, N_PERM, N_PRINT, N_PRUNE, N_SIZE, N_TYPE, N_USER, N_XDEV, - N_PRINT0, N_DELETE + N_PRINT0, N_DELETE, N_MAXDEPTH, N_MINDEPTH }; /* node definition */ Index: function.c =================================================================== RCS file: /usr/cvs/src/usr.bin/find/function.c,v retrieving revision 1.22 diff -u -r1.22 function.c --- function.c 2000/02/05 18:42:34 1.22 +++ function.c 2000/04/28 22:42:14 @@ -717,6 +717,66 @@ } /* + * -maxdepth n functions -- + * + * Does the same as -prune if the level of the current file is greater + * than the specified maximum depth. + */ +int +f_maxdepth(plan, entry) + PLAN *plan; + FTSENT *entry; +{ + extern FTS *tree; + + if (entry->fts_level >= plan->t_data && fts_set(tree, entry, FTS_SKIP)) + err(1, "%s", entry->fts_path); + return (1); +} + +PLAN * +c_maxdepth(arg) + char *arg; +{ + PLAN *new; + + if (*arg == '-') + /* all other errors handled by find_parsenum() */ + errx(1, "-maxdepth: %s: value must be positive", arg); + + new = palloc(N_MAXDEPTH, f_maxdepth); + new->t_data = find_parsenum(new, "-maxdepth", arg, NULL); + return (new); + +} + +/* + * -mindepth n functions -- + * + * True if the current file is at or deeper than the specified minimum + * depth. + */ +int +f_mindepth(plan, entry) + PLAN *plan; + FTSENT *entry; +{ + + return (entry->fts_level >= plan->t_data); +} + +PLAN * +c_mindepth(arg) + char *arg; +{ + PLAN *new; + + new = palloc(N_MINDEPTH, f_mindepth); + new->t_data = find_parsenum(new, "-mindepth", arg, NULL); + return (new); +} + +/* * -mtime n functions -- * * True if the difference between the file modification time and the Index: option.c =================================================================== RCS file: /usr/cvs/src/usr.bin/find/option.c,v retrieving revision 1.9 diff -u -r1.9 option.c --- option.c 1999/12/19 15:43:19 1.9 +++ option.c 2000/04/28 19:41:56 @@ -84,6 +84,8 @@ { "-inum", N_INUM, c_inum, O_ARGV }, { "-links", N_LINKS, c_links, O_ARGV }, { "-ls", N_LS, c_ls, O_ZERO }, + { "-maxdepth", N_MAXDEPTH, c_maxdepth, O_ARGV }, + { "-mindepth", N_MINDEPTH, c_mindepth, O_ARGV }, { "-mmin", N_MMIN, c_mmin, O_ARGV }, { "-mtime", N_MTIME, c_mtime, O_ARGV }, { "-name", N_NAME, c_name, O_ARGV }, --MnLPg7ZWsaic7Fhd-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 28 18:38:22 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.100.7]) by hub.freebsd.org (Postfix) with ESMTP id 56C3137B99F for ; Fri, 28 Apr 2000 18:38:19 -0700 (PDT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id VAA44968; Fri, 28 Apr 2000 21:38:14 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <017c01bfb11f$ab144c80$0500000a@sintesi.net> References: <017c01bfb11f$ab144c80$0500000a@sintesi.net> Date: Fri, 28 Apr 2000 21:38:19 -0400 To: "Lorenzo Iania" , From: Garance A Drosihn Subject: Re: lpr: order of print requests Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 4:40 PM +0200 4/28/00, Lorenzo Iania wrote: >I have the following problem using lpr: >when the number of consecutive requests grow, they are not printed in the >same order. This happens on several versions from 2.2.7 to 3.4. All the >requests are printed, but the order is not the same of the requests. >Effectively the order is initially right, but then it fails and skips a >number of requests that are printer later. > >Why this happens? What can I do? Any suggestions?? I am not sure what you mean by "requests". Do you mean many 'lpr' commands from different users/hosts, or do you mean many files on a single 'lpr' command? If you mean many 'lpr' commands, are they coming in from many different hosts to some central print server? --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Apr 28 21: 0:19 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail0.u-aizu.ac.jp (mail0.u-aizu.ac.jp [163.143.1.43]) by hub.freebsd.org (Postfix) with ESMTP id EE8B137B5F3; Fri, 28 Apr 2000 21:00:11 -0700 (PDT) (envelope-from sarikaya@u-aizu.ac.jp) Received: from pross114.u-aizu.ac.jp (pross114 [163.143.180.102]) by mail0.u-aizu.ac.jp (8.9.3+3.1W/3.7Winternet-gw) with ESMTP id NAA21693; Sat, 29 Apr 2000 13:00:09 +0900 (JST) Received: from u-aizu.ac.jp (localhost [127.0.0.1]) by pross114.u-aizu.ac.jp (8.9.3+3.1W/3.7Wistcmx+kanji) with ESMTP id NAA09847; Sat, 29 Apr 2000 13:00:08 +0900 (JST) Message-ID: <390A5E48.D91C6A6F@u-aizu.ac.jp> Date: Sat, 29 Apr 2000 13:00:08 +0900 From: Behcet Sarikaya Organization: University of Aizu X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: FreeBSD Questions Cc: Thomas Uhrfelt , freebsd-hackers@FreeBSD.ORG Subject: Yamaha DS-XG Sound Card or Chip? Content-Type: multipart/alternative; boundary="------------865CC50BF2BE9DEEC642050F" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --------------865CC50BF2BE9DEEC642050F Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Have anyone successfully configured this card on FreeBSD? I think it is an on board sound chip in my Dell desktop. -- Behcet Sarikaya Computer Communications Lab. The University of Aizu Tsuruga, Ikki-machi, Aizu-wakamatsu City Fukushima, 965-8580 Japan Tel. +81-242-37-2559 Fax. +81-242-37-2742 Home page: http://www.u-aizu.ac.jp/~sarikaya/ email: sarikaya@u-aizu.ac.jp --------------865CC50BF2BE9DEEC642050F Content-Type: text/html; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Have anyone successfully configured this card on FreeBSD? I think it is an on board sound chip
in my Dell desktop. 
-- 
Behcet Sarikaya
Computer Communications Lab.
The University of Aizu
Tsuruga, Ikki-machi, Aizu-wakamatsu City
Fukushima, 965-8580 Japan
Tel. +81-242-37-2559 Fax. +81-242-37-2742 
Home page:  http://www.u-aizu.ac.jp/~sarikaya/
email: sarikaya@u-aizu.ac.jp
  --------------865CC50BF2BE9DEEC642050F-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 29 1:15:11 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ms.tokyo.jcom.ne.jp (ms.tokyo.jcom.ne.jp [210.234.123.18]) by hub.freebsd.org (Postfix) with ESMTP id 8676037B646; Sat, 29 Apr 2000 01:15:07 -0700 (PDT) (envelope-from knu@idaemons.org) Received: from daemon.local.idaemons.org (203-165-77-40.sugnm1.kt.home.ne.jp [203.165.77.40]) by ms.tokyo.jcom.ne.jp (8.9.3/3.7W 04/27/00) with ESMTP id RAA22627; Sat, 29 Apr 2000 17:15:04 +0900 (JST) Received: by daemon.local.idaemons.org (8.9.3/3.7W) id RAA49241; Sat, 29 Apr 2000 17:14:33 +0900 (JST) Date: Sat, 29 Apr 2000 17:14:31 +0900 Message-ID: <86pur9e32w.wl@localhost.local.idaemons.org> From: "Akinori -Aki- MUSHA" To: freebsd-hackers@FreeBSD.ORG, freebsd-ports@FreeBSD.ORG Subject: Re: Help me complete the FreeBSD specific zsh completions! Newsgroups: freebsd.hackers,freebsd.ports In-Reply-To: In your message of "Fri, 28 Apr 2000 03:04:40 +0900" <86aeifzah3.wl@localhost.local.idaemons.org> References: <86aeifzah3.wl@localhost.local.idaemons.org> User-Agent: Wanderlust/1.1.1 (Purple Rain) EMIKO/1.13.12 (Euglena sociabilis) FLIM/1.13.2 (Kasanui) APEL/10.2 MULE XEmacs/21.1 (patch 9) (Canyonlands) (i386--freebsd) Organization: Associated I. Daemons X-PGP-Public-Key: finger knu@FreeBSD.org X-PGP-Fingerprint: 1BEF D9B2 BABD 25D7 659A FD08 89C2 F3BE E981 4E16 MIME-Version: 1.0 (generated by EMIKO 1.13.12 - "Euglena sociabilis") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Here's an update patch for the shells/zsh-devel port: http://people.freebsd.org/~knu/ports/zsh-devel.diff.gz This updates the port corresponding to zsh 3.1.7-pre-1. Use that version to work on developing compdefs. -- / /__ __ / ) ) ) ) / Akinori -Aki- MUSHA aka / (_ / ( (__( @ idaemons.org / FreeBSD.org "We're only at home when we're on the run, on the wing, on the fly" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 29 4:13:39 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from njord.bart.nl (njord.bart.nl [194.158.170.15]) by hub.freebsd.org (Postfix) with ESMTP id 07BF537B6FE for ; Sat, 29 Apr 2000 04:13:36 -0700 (PDT) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org (abaddon@lucifer.is.an.elder.of.the.ninth-circle.org [195.38.216.226]) by njord.bart.nl (8.9.3/8.9.2) with ESMTP id NAA87386; Sat, 29 Apr 2000 13:13:32 +0200 (CEST) Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id MAA43275; Sat, 29 Apr 2000 12:52:57 +0200 (CEST) (envelope-from asmodai) Date: Sat, 29 Apr 2000 12:52:57 +0200 From: Jeroen Ruigrok/Asmodai To: Arun Sharma Cc: freebsd-hackers@freebsd.org Subject: Re: Fwd: socket.h and _POSIX_SOURCE Message-ID: <20000429125257.N1842@daemon.ninth-circle.org> References: <200004201604.JAA10995@sharmas.dhs.org> <20000424163942.E1842@daemon.ninth-circle.org> <20000425090106.A9742@sharmas.dhs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000425090106.A9742@sharmas.dhs.org>; from adsharma@sharmas.dhs.org on Tue, Apr 25, 2000 at 09:01:06AM -0700 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG -On [20000425 20:08], Arun Sharma (adsharma@sharmas.dhs.org) wrote: >Would it be fair to say this is a (POSIX non-compliance) bug in the >header files ? As Bruce Evans was kind enough to reassure me: sys/socket.h is not a POSIX header. 'nuff said I guess. -- Jeroen Ruigrok vd Werven/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best The BSD Programmer's Documentation Project Who looks under the surface does so at his own risk... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 29 4:17:56 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from quasar.uvt.ro (quasar.uvt.ro [193.226.13.67]) by hub.freebsd.org (Postfix) with ESMTP id 5D23837B6A3 for ; Sat, 29 Apr 2000 04:17:48 -0700 (PDT) (envelope-from ardelean@quasar.uvt.ro) Received: from localhost (ardelean@localhost) by quasar.uvt.ro (8.9.3/8.9.3) with SMTP id OAA13925 for ; Sat, 29 Apr 2000 14:20:20 +0300 (EEST) Date: Sat, 29 Apr 2000 14:20:20 +0300 (EEST) From: Gheorghe Ardelean To: freebsd-hackers@freebsd.org Subject: printing problems in 3.4 when removing the sl pseudo-device Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Anyone is aware of such a strange (?) behavior? When I am removing the sl pseudo-device from the kernel config file I am getting strange results printing files (at least .ps files like tiger.ps from gs examples). The printing is fine if I am putting the sl pseudo-device back in the kernel. I use FreeBSD 3.4-RELEASE on a Pentium III 450 with i440 BX motherboard. I'm not changing anything in BIOS when I use the two kernels! Here is my config file (tested on 8 different machines) with slighty different hardware configs. # # BOLTZMANN # machine "i386" #cpu "I386_CPU" #cpu "I486_CPU" #cpu "I586_CPU" cpu "I686_CPU" ident BOLTZMANN maxusers 32 #options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] #options MFS #Memory Filesystem #options MFS_ROOT #MFS usable as root device, "MFS" req'ed options NFS #Network Filesystem options NFS_ROOT #NFS usable as root device, "NFS" req'ed options MSDOSFS #MSDOS Filesystem options "CD9660" #ISO 9660 Filesystem options "CD9660_ROOT" #CD-ROM usable as root. "CD9660" req'ed options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=10000 #Be pessimistic about Joe SCSI device options UCONSOLE #Allow users to grab the console options FAILSAFE #Be conservative options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) syscall trace support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options QUOTA options VESA options "VM86" config kernel root on wd0 controller isa0 controller pnp0 # PnP support for ISA #controller eisa0 controller pci0 # Floppy drives controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 disk fd0 at fdc0 drive 0 disk fd1 at fdc0 drive 1 # IDE controller and disks #options "CMD640" # work around CMD640 chip deficiency controller wdc0 at isa? port "IO_WD1" bio irq 14 disk wd0 at wdc0 drive 0 disk wd1 at wdc0 drive 1 controller wdc1 at isa? port "IO_WD2" bio irq 15 disk wd2 at wdc1 drive 0 disk wd3 at wdc1 drive 1 # ATAPI devices options ATAPI #Enable ATAPI support for IDE bus options ATAPI_STATIC #Don't do it as an LKM device acd0 #IDE CD-ROM #device wfd0 #IDE Floppy (e.g. LS-120) # SCSI Controllers # A single entry for any of these controllers (ncr, ahb, ahc) is # sufficient for any number of installed devices. #controller ncr0 # NCR/Symbios Logic #controller ahb0 # EISA AHA1742 family controller ahc0 # AHA2940 and onboard AIC7xxx devices # SCSI peripherals # Only one of each of these is needed, they are dynamically allocated. controller scbus0 # SCSI bus (required) device da0 # Direct Access (disks) device sa0 # Sequential Access (tape etc) device cd0 # CD device pass0 # Passthrough device (direct SCSI) # atkbdc0 controls both the keyboard and the PS/2 mouse controller atkbdc0 at isa? port IO_KBD tty device atkbd0 at isa? tty irq 1 device psm0 at isa? tty irq 12 device vga0 at isa? port ? conflicts # splash screen/screen saver pseudo-device splash # syscons is the default console driver, resembling an SCO console device sc0 at isa? tty # Floating point support - do not disable. device npx0 at isa? port IO_NPX irq 13 # Power management support (see LINT for more options) #device apm0 at isa? disable flags 0x31 # Advanced Power Management # Serial (COM) ports device sio0 at isa? port "IO_COM1" flags 0x10 tty irq 4 device sio1 at isa? port "IO_COM2" tty irq 3 #device sio2 at isa? disable port "IO_COM3" tty irq 5 #device sio3 at isa? disable port "IO_COM4" tty irq 9 # Parallel port device ppc0 at isa? port? flags 0x40 net irq 7 controller ppbus0 # Parallel port bus (required) device lpt0 at ppbus? # Printer device plip0 at ppbus? # TCP/IP over parallel device ppi0 at ppbus? # Parallel port interface device #controller vpo0 at ppbus? # Requires scbus and da0 # PCI Ethernet NICs. device fxp0 # Intel EtherExpress PRO/100B (82557, 82558) # Pseudo devices - the number indicates how many units to allocated. pseudo-device loop # Network loopback pseudo-device ether # Ethernet support pseudo-device sl 1 # Kernel SLIP #pseudo-device ppp 1 # Kernel PPP #pseudo-device tun 1 # Packet tunnel pseudo-device pty 16 # Pseudo-ttys (telnet etc) pseudo-device gzip # Exec gzipped a.out's # The `bpfilter' pseudo-device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # The number of devices determines the maximum number of # simultaneous BPF clients programs runnable. pseudo-device bpfilter 2 #Berkeley packet filter # # END of Kernel config file # Gheorghe ARDELEAN West Univ. Of Timisoara Dept. of Theoretical and Computational Physics V. Parvan No.4, Ro-1900, Timisoara, ROMANIA Tel: +40-(0)56-194068 Ext. 203, 201, 108 | Fax: +40-(0)56-190333 Email: ardelean@quasar.uvt.ro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 29 6:19:26 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from quack.kfu.com (quack.kfu.com [170.1.70.2]) by hub.freebsd.org (Postfix) with ESMTP id ED20037B741 for ; Sat, 29 Apr 2000 06:19:20 -0700 (PDT) (envelope-from nsayer@quack.kfu.com) Received: from icarus.kfu.com (icarus.kfu.com [170.1.70.28]) by quack.kfu.com (8.9.2/8.9.3) with ESMTP id GAA55784 for ; Sat, 29 Apr 2000 06:19:19 -0700 (PDT) (envelope-from nsayer@quack.kfu.com) Received: from quack.kfu.com by icarus.kfu.com with ESMTP (8.9.3//ident-1.0) id GAA03514; Sat, 29 Apr 2000 06:18:48 -0700 (PDT) Message-ID: <390AE138.7871AC31@quack.kfu.com> Date: Sat, 29 Apr 2000 06:18:48 -0700 From: Nick Sayer X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: IPv6 & Bridging don't work together Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a filtering bridge that I am also trying to use as a 6to4 router. Alas, IPv6 does not appear to work correctly with the bridge. If I configure the interface on one side of the bridge, it is not ping6able by hosts on the other side. If I configure both sides with separate prefixes, then both of the prefixes show up on all of the hosts. I don't really care if I can bridge IPv6 or not, truth be told. With IPv6 the vast number of subnets makes it unnecessary to bridge. But I need to be able to either keep the two interfaces totally separate despite the bridging of other protocols (specifically IPv4) or I need bridging to work correctly. Either way. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 29 8:11: 6 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from t-mta4.odn.ne.jp (mfep4.odn.ne.jp [143.90.131.168]) by hub.freebsd.org (Postfix) with ESMTP id 684F837B787; Sat, 29 Apr 2000 08:11:02 -0700 (PDT) (envelope-from shigeisp@pop02.odn.ne.jp) Received: from athena.shige.org ([210.188.11.120]) by t-mta4.odn.ne.jp (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP id <20000429151101193.OOAH.8773.t-mta4.odn.ne.jp@mta4.odn.ne.jp>; Sun, 30 Apr 2000 00:11:01 +0900 To: knu@idaemons.org Cc: freebsd-hackers@FreeBSD.ORG, freebsd-ports@FreeBSD.ORG Subject: Re: Help me complete the FreeBSD specific zsh completions! From: Shigeyuki Fukushima (=?iso-2022-jp?B?GyRCSiFFZ0xQRzcbKEI=?=) In-Reply-To: <86pur9e32w.wl@localhost.local.idaemons.org> References: <86aeifzah3.wl@localhost.local.idaemons.org> <86pur9e32w.wl@localhost.local.idaemons.org> X-Mailer: Mew version 1.95b3 on Emacs 20.5 / Mule 4.0 =?iso-2022-jp?B?KBskQjJWMWMbKEIp?= X-URL: http://www.freebsd.org/~shige/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 30 Apr 2000 00:10:53 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 20 Message-Id: <20000429151101193.OOAH.8773.t-mta4.odn.ne.jp@mta4.odn.ne.jp> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From: "Akinori -Aki- MUSHA" Subject: Re: Help me complete the FreeBSD specific zsh completions! Date: Sat, 29 Apr 2000 17:14:31 +0900 knu> Here's an update patch for the shells/zsh-devel port: knu> http://people.freebsd.org/~knu/ports/zsh-devel.diff.gz knu> This updates the port corresponding to zsh 3.1.7-pre-1. Use that knu> version to work on developing compdefs. Updated zsh-devel port to 3.1.7.p1. Please use ports/shells/zsh-devel. :) If you develop some nice compdefs, please report not only to zsh developer group but also to me. :) Then, I'll update the above port. Thanks! --- shige Shigeyuki Fukushima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 29 9:12:26 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from sharmas.dhs.org (c62443-a.frmt1.sfba.home.com [24.0.69.165]) by hub.freebsd.org (Postfix) with ESMTP id 120BE37B6CB for ; Sat, 29 Apr 2000 09:12:23 -0700 (PDT) (envelope-from adsharma@sharmas.dhs.org) Received: (from adsharma@localhost) by sharmas.dhs.org (8.9.3/8.9.3) id JAA06851; Sat, 29 Apr 2000 09:11:53 -0700 Date: Sat, 29 Apr 2000 09:11:53 -0700 From: Arun Sharma To: Jeroen Ruigrok/Asmodai Cc: freebsd-hackers@freebsd.org Subject: Re: Fwd: socket.h and _POSIX_SOURCE Message-ID: <20000429091153.A6758@sharmas.dhs.org> References: <200004201604.JAA10995@sharmas.dhs.org> <20000424163942.E1842@daemon.ninth-circle.org> <20000425090106.A9742@sharmas.dhs.org> <20000429125257.N1842@daemon.ninth-circle.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <20000429125257.N1842@daemon.ninth-circle.org>; from Jeroen Ruigrok/Asmodai on Sat, Apr 29, 2000 at 12:52:57PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Apr 29, 2000 at 12:52:57PM +0200, Jeroen Ruigrok/Asmodai wrote: > -On [20000425 20:08], Arun Sharma (adsharma@sharmas.dhs.org) wrote: > >Would it be fair to say this is a (POSIX non-compliance) bug in the > >header files ? > > As Bruce Evans was kind enough to reassure me: > > sys/socket.h is not a POSIX header. > > 'nuff said I guess. I don't have access to the POSIX specification - so I can't check. But single unix (a superset of POSIX) includes sys/socket.h: http://www.opengroup.org/onlinepubs/007908799/xnsix.html Also, there is a lot of source code out there (I know at least two examples from KDE sources) where they are including and doing -D_POSIX_SOURCE. Both Solaris and Linux handle the above situation correctly. Are there any significant reasons why FreeBSD can't have the same behavior ? Or are you applying the "don't fix it if it isn't broken" principle ? -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 29 10:54:52 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 6A12637B6BC for ; Sat, 29 Apr 2000 10:54:48 -0700 (PDT) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id TAA37947; Sat, 29 Apr 2000 19:55:29 +0200 (CEST) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200004291755.TAA37947@info.iet.unipi.it> Subject: Re: IPv6 & Bridging don't work together In-Reply-To: <390AE138.7871AC31@quack.kfu.com> from Nick Sayer at "Apr 29, 2000 06:18:48 am" To: Nick Sayer Date: Sat, 29 Apr 2000 19:55:29 +0200 (CEST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nick, are you sure the problem does not depend upon having bridge_ipfw=1 ? I don't think there is anything else IPv4-specific in the bridging code, if it was we would also have problems with IPv4/IPX and other non-ip protocols. cheers luigi > Alas, > IPv6 does not appear to work correctly with the bridge. > > If I configure the interface on one side of the bridge, it is not > ping6able by > hosts on the other side. If I configure both sides with separate > prefixes, then > both of the prefixes show up on all of the hosts. > > I don't really care if I can bridge IPv6 or not, truth be told. With > IPv6 the > vast number of subnets makes it unnecessary to bridge. But I need to be > able to > either keep the two interfaces totally separate despite the bridging of > other > protocols (specifically IPv4) or I need bridging to work correctly. > Either way. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 29 12:39:18 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mauibuilt.com (mauibuilt.com [205.166.249.50]) by hub.freebsd.org (Postfix) with ESMTP id 08F2E37B5D2 for ; Sat, 29 Apr 2000 12:39:11 -0700 (PDT) (envelope-from freebsd@mauibuilt.com) Received: (from freebsd@localhost) by mauibuilt.com (8.9.3/8.9.3) id JAA08064 for freebsd-hackers@freebsd.org; Sat, 29 Apr 2000 09:53:08 -1000 (HST) (envelope-from freebsd) From: FreeBSD MAIL Message-Id: <200004291953.JAA08064@mauibuilt.com> Subject: Re: Xircom cards To: freebsd-hackers@freebsd.org Date: Sat, 29 Apr 2000 09:53:07 -1000 (HST) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I cvsuped to 5.0-current and am trying the Xircom driver now. I want to provide as much information as needed. below is information on how I built my kernel and various configuration files. Upon insertion I get the below message. and although I can see the card with netstat -in as soon as I run ifconfig it page faults. Also with -current my second PCMCIA controller dosn't work so I have it disabled in the kernel config. Ill keep checking for updated drivers and patches.. Hope this info helps. I have a Ricoh Majio laptop with 3 PCMCIA slots (2 controllers) which support cardbus and legacy. I have them in legacy mode. If there is any more info I should provide please let me know.. Richard Puga puga@mauibuilt.com ############/etc/pccard.conf######################## # Generally available IO ports io 0x240-0x360 # Generally available IRQs (Built-in sound-card owners remove 5) irq 3 5 10 11 13 15 # Available memory slots memory 0xd4000 96k # Xircom CreditCard Ethernet 10/100 + modem (Ethernet part) card "Xircom" "Ethernet Adapter" config auto "xe0" 9 insert logger -t pccard:$device -s Xircom CreditCard Modem inserted insert /etc/pccard_ether $device remove logger -t pccard:$device -s Xircom CreditCard Modem removed remove /sbin/ifconfig $device delete ##############INSERTING CARD BEFORE BOOT######################## xe0: xe: Probing xe0: Got version string (0x15) xe0: Got card ID (0x20) xe0: Card is Ethernet only xe0: Got MAC address (0x22) xe0 at port 0x240-0x24f iomem 0xd0000-0xd0fff irq 9 slot 1 on pccard1 xe0: attach xe0: Xircom CE3, bonding version 0x45, 100Mbps capable xe0: DingoID = 0x444b, RevisionID = 0x1, VendorID = 0 xe0: Ethernet address 00:10:a4:f4:fa:e6 xe0: supplying EUI64: 00:10:a4:ff:fe:f4:fa:e6 xe0: BPF listener attached device_probe_and_attach: xe0 attach returned 1 ##############INSERTING CARD AFTER BOOT######################## ricoh /root 6% pccard: card inserted, slot 1 Apr 29 10:13:27 ricoh /kernel: pccard: card inserted, slot 1 Apr 29 10:13:27 ricoh /kernel: pccard: card inserted, slot 1 Apr 29 10:13:32 ricoh pccardd[45]: Card "Xircom"("Ethernet Adapter") matched "Xircom" ("Ethernet Adapter") Apr 29 10:13:32 ricoh pccardd[45]: Card "Xircom"("Ethernet Adapter") matched "Xircom" ("Ethernet Adapter") Apr 29 10:13:32 ricoh pccardd[45]: Card "Xircom"("Ethernet Adapter") matched "Xircom" ("Ethernet Adapter") xe0: xe: Probing xe0: Got version string (0x15) xe0: Got card ID (0x20) xe0: Card is Ethernet only xe0: Got MAC address (0x22) xe0 at port 0x240-0x24f iomem 0xd0000-0xd0fff irq 9 slot 1 on pccard1 xe0: attach xe0: Cannot allocate ioport device_probe_and_attach: xe0 attach returned 12 Apr 29 10:13:38 ricoh /kernel: xe0: xe: Probing Apr 29 10:13:38 ricoh /kernel: xe0: xe: Probing Apr 29 10:13:38 ricoh /kernel: xe0: Got version string (0x15) Apr 29 10:13:38 ricoh /kernel: xe0: Got version string (0x15) Apr 29 10:13:38 ricoh /kernel: xe0: Got card ID (0x20) Apr 29 10:13:38 ricoh /kernel: xe0: Got card ID (0x20) Apr 29 10:13:38 ricoh /kernel: xe0: Card is Ethernet only Apr 29 10:13:38 ricoh /kernel: xe0: Card is Ethernet only Apr 29 10:13:38 ricoh /kernel: xe0: Got MAC address (0x22) Apr 29 10:13:38 ricoh /kernel: xe0: Got MAC address (0x22) Apr 29 10:13:38 ricoh /kernel: xe0 at port 0x240-0x24f iomem 0xd0000-0xd0fff irq 9 slot 1 on pccard1 Apr 29 10:13:38 ricoh /kernel: xe0 at port 0x240-0x24f iomem 0xd0000-0xd0fff irq 9 slot 1 on pccard1 Apr 29 10:13:38 ricoh /kernel: xe0: attach Apr 29 10:13:38 ricoh /kernel: xe0: attach Apr 29 10:13:38 ricoh /kernel: xe0: Cannot allocate ioport Apr 29 10:13:38 ricoh /kernel: xe0: Cannot allocate ioport Apr 29 10:13:38 ricoh /kernel: device_probe_and_attach: xe0 attach returned 12 Apr 29 10:13:38 ricoh /kernel: device_probe_and_attach: xe0 attach returned 12 Apr 29 10:13:38 ricoh pccardd[45]: driver allocation failed for Xircom(Ethernet Adapter): Cannot allocate memory Apr 29 10:13:38 ricoh pccardd[45]: driver allocation failed for Xircom(Ethernet Adapter): Cannot allocate memory Apr 29 10:13:38 ricoh pccardd[45]: driver allocation failed for Xircom(Ethernet Adapter): Cannot allocate memory ##############KERNEL CONFIG######################## # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.freebsd.org/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.ORG/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ./LINT configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in LINT. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.252 2000/04/15 18:46:15 asmodai Exp $ machine i386 cpu I386_CPU cpu I486_CPU cpu I586_CPU cpu I686_CPU ident GENERIC maxusers 32 #makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols options MATH_EMULATE #Support for x87 emulation options INET #InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options MFS #Memory Filesystem options MD_ROOT #MD is a potential root device options NFS #Network Filesystem options NFS_ROOT #NFS usable as root device, NFS required options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options CD9660_ROOT #CD-ROM usable as root, CD9660 required options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] #options SCSI_DELAY=15000 #Delay (in ms) before probing SCSI options UCONSOLE #Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B #Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options ICMP_BANDLIM #Rate limit bad replies # To make an SMP kernel, the next two are needed #options SMP # Symmetric MultiProcessor Kernel #options APIC_IO # Symmetric (APIC) I/O # Optionally these may need tweaked, (defaults shown): #options NCPU=2 # number of CPUs #options NBUS=4 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=24 # number of INTs device isa #device eisa device pci #options COMPAT_OLDISA # Old ISA driver shims #options COMPAT_OLDPCI # Old PCI driver shims # Floppy drives device fdc0 at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 device fd1 at fdc0 drive 1 # ATA and ATAPI devices device ata0 at isa? port IO_WD1 irq 14 device ata1 at isa? port IO_WD2 irq 15 device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives options ATA_STATIC_ID #Static device numbering #options ATA_ENABLE_ATAPI_DMA #Enable DMA on ATAPI devices # SCSI Controllers #device ahb # EISA AHA1742 family #device ahc # AHA2940 and onboard AIC7xxx devices #device amd # AMD 53C974 (Teckram DC-390(T)) #device dpt # DPT Smartcache - See LINT for options! #device isp # Qlogic family #device ncr # NCR/Symbios Logic #device sym # NCR/Symbios Logic (newer chipsets) #device adv0 at isa? #device adw #device bt0 at isa? #device aha0 at isa? #device aic0 at isa? # # SCSI peripherals #device scbus # SCSI bus (required) #device da # Direct Access (disks) #device sa # Sequential Access (tape etc) #device cd # CD #device pass # Passthrough device (direct SCSI access) # RAID controllers #device ida # Compaq Smart RAID #device amr # AMI MegaRAID #device mlx # Mylex DAC960 family # # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 device psm0 at atkbdc? irq 12 device vga0 at isa? # splash screen/screen saver pseudo-device splash # syscons is the default console driver, resembling an SCO console device sc0 at isa? # Enable this for the pcvt (VT220 compatible) console driver #device vt0 at isa? #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor # If you have a ThinkPAD, uncomment this along with the rest of the PCVT lines #options PCVT_SCANSET=2 # IBM keyboards are non-std # Floating point support - do not disable. device npx0 at nexus? port IO_NPX irq 13 # Power management support (see LINT for more options) device apm0 at nexus? disable flags 0x20 # Advanced Power Management # PCCARD (PCMCIA) support device card device pcic0 at isa? irq 10 port 0x3e0 iomem 0xd0000 device pcic1 at isa? irq 11 port 0x3e2 iomem 0xd4000 disable # Serial (COM) ports device sio0 at isa? port IO_COM1 flags 0x10 irq 4 device sio1 at isa? port IO_COM2 irq 3 device sio2 at isa? disable port IO_COM3 irq 5 device sio3 at isa? disable port IO_COM4 irq 9 # Parallel port device ppc0 at isa? irq 7 device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # PCI Ethernet NICs. #device de # DEC/Intel DC21x4x (``Tulip'') #device fxp # Intel EtherExpress PRO/100B (82557, 82558) #device tx # SMC 9432TX (83c170 ``EPIC'') #device vx # 3Com 3c590, 3c595 (``Vortex'') #device wx # Intel Gigabit Ethernet Card (``Wiseman'') # PCI Ethernet NICs that use the common MII bus controller code. device miibus # MII bus support #device dc # DEC/Intel 21143 and various workalikes #device rl # RealTek 8129/8139 #device sf # Adaptec AIC-6915 (``Starfire'') #device sis # Silicon Integrated Systems SiS 900/SiS 7016 #device ste # Sundance ST201 (D-Link DFE-550TX) #device tl # Texas Instruments ThunderLAN #device vr # VIA Rhine, Rhine II #device wb # Winbond W89C840F #device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. device ed0 at isa? port 0x280 irq 10 iomem 0xd8000 device ex device ep # WaveLAN/IEEE 802.11 wireless NICs. Note: the WaveLAN/IEEE really # exists only as a PCMCIA device, so there is no ISA attatement needed # and resources will always be dynamically assigned by the pccard code. device wi # Aironet 4500/4800 802.11 wireless NICs. Note: the declaration below will # work for PCMCIA and PCI cards, as well as ISA cards set to ISA PnP # mode (the factory default). If you set the switches on your ISA # card for a manually chosen I/O address and IRQ, you must specify # those paremeters here. device an # BayStack 660 and others device awi # The probe order of these is presently determined by i386/isa/isa_compat.c. #device ie0 at isa? port 0x300 irq 10 iomem 0xd0000 #device fe0 at isa? port 0x300 #device le0 at isa? port 0x300 irq 5 iomem 0xd0000 #device lnc0 at isa? port 0x280 irq 10 drq 0 #device cs0 at isa? port 0x300 #device sn0 at isa? port 0x300 irq 10 # Disabled because it is currently broken. device xe # Pseudo devices - the number indicates how many units to allocated. pseudo-device loop # Network loopback pseudo-device ether # Ethernet support pseudo-device sl 1 # Kernel SLIP pseudo-device ppp 1 # Kernel PPP pseudo-device tun # Packet tunnel. pseudo-device pty # Pseudo-ttys (telnet etc) pseudo-device md # Memory "disks" pseudo-device gif 4 # IPv6 and IPv4 tunneling pseudo-device faith 1 # IPv6-to-IPv4 relaying (translation) # The `bpf' pseudo-device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! pseudo-device bpf # Berkeley packet filter # USB support #device uhci # UHCI PCI->USB interface #device ohci # OHCI PCI->USB interface #device usb # USB Bus (required) #device ugen # Generic #device uhid # "Human Interface Devices" #device ukbd # Keyboard #device ulpt # Printer #device umass # Disks/Mass storage - Requires scbus and da #device ums # Mouse #device urio # Diamond Rio 500 MP3 player # USB Ethernet, requires mii #device aue # ADMtek USB ethernet #device cue # CATC USB ethernet #device kue # Kawasaki LSI USB ethernet #device sbc0 at isa? port 0x220 irq 5 drq 1 flags 0x15 device pcm options IPFILTER #ipfilter support options IPFILTER_LOG #ipfilter logging ----- End of forwarded message from freebsd ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 29 13: 4:57 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 79B2937B98A; Sat, 29 Apr 2000 13:04:52 -0700 (PDT) (envelope-from kris@FreeBSD.org) Received: from localhost (kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) with ESMTP id NAA19911; Sat, 29 Apr 2000 13:04:51 -0700 (PDT) (envelope-from kris@FreeBSD.org) X-Authentication-Warning: freefall.freebsd.org: kris owned process doing -bs Date: Sat, 29 Apr 2000 13:04:51 -0700 (PDT) From: Kris Kennaway To: Ben Smithurst Cc: FreeBSD-hackers@FreeBSD.org Subject: Re: Adding -maxdepth and -mindepth options to find(1) In-Reply-To: <20000429001436.F17098@strontium.scientia.demon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 29 Apr 2000, Ben Smithurst wrote: > any other people who might want it? I've attached a patch to implement > this, if I don't get any feedback I'll send-pr it instead, I thought I > might get a few opinions here first. Good idea - haven't reviewed the patch, though. Kris ---- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 29 19:46:42 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13]) by hub.freebsd.org (Postfix) with ESMTP id 547BC37BA52; Sat, 29 Apr 2000 19:46:38 -0700 (PDT) (envelope-from ben@scientia.demon.co.uk) Received: from strontium.scientia.demon.co.uk ([192.168.91.36] ident=exim) by scientia.demon.co.uk with esmtp (Exim 3.12 #1) id 12lixo-0008fX-00; Sun, 30 Apr 2000 02:56:04 +0100 Received: (from ben) by strontium.scientia.demon.co.uk (Exim 3.12 #7) id 12lixo-0004Pl-00; Sun, 30 Apr 2000 02:56:04 +0100 Date: Sun, 30 Apr 2000 02:56:04 +0100 From: Ben Smithurst To: Kris Kennaway Cc: FreeBSD-hackers@FreeBSD.org Subject: Re: Adding -maxdepth and -mindepth options to find(1) Message-ID: <20000430025604.B22035@strontium.scientia.demon.co.uk> References: <20000429001436.F17098@strontium.scientia.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kris Kennaway wrote: > On Sat, 29 Apr 2000, Ben Smithurst wrote: > >> any other people who might want it? I've attached a patch to implement >> this, if I don't get any feedback I'll send-pr it instead, I thought I >> might get a few opinions here first. > > Good idea - haven't reviewed the patch, though. Turns out the patch doesn't quite work as it stands... Something like 'find . -name foo -maxdepth 1' won't work because the maxdepth code will only be executed if the previous conditions match. (So 'find . -maxdepth 1 -name foo' works fine.) I guess I'll have to find a way around that which isn't too ugly. -- Ben Smithurst / ben@scientia.demon.co.uk / PGP: 0x99392F7D To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Apr 29 19:47: 2 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13]) by hub.freebsd.org (Postfix) with ESMTP id A1BB137BB54; Sat, 29 Apr 2000 19:46:41 -0700 (PDT) (envelope-from ben@scientia.demon.co.uk) Received: from strontium.scientia.demon.co.uk ([192.168.91.36] ident=exim) by scientia.demon.co.uk with esmtp (Exim 3.12 #1) id 12ljjw-0008r0-00; Sun, 30 Apr 2000 03:45:48 +0100 Received: (from ben) by strontium.scientia.demon.co.uk (Exim 3.12 #7) id 12ljjv-000Ait-00; Sun, 30 Apr 2000 03:45:47 +0100 Date: Sun, 30 Apr 2000 03:45:47 +0100 From: Ben Smithurst To: Kris Kennaway Cc: FreeBSD-hackers@FreeBSD.org Subject: Re: Adding -maxdepth and -mindepth options to find(1) Message-ID: <20000430034547.C22035@strontium.scientia.demon.co.uk> References: <20000429001436.F17098@strontium.scientia.demon.co.uk> <20000430025604.B22035@strontium.scientia.demon.co.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="yrj/dFKFPuw6o+aM" X-Mailer: Mutt 1.0i In-Reply-To: <20000430025604.B22035@strontium.scientia.demon.co.uk> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii > Turns out the patch doesn't quite work as it stands... Something like > 'find . -name foo -maxdepth 1' won't work because the maxdepth code > will only be executed if the previous conditions match. (So 'find . > -maxdepth 1 -name foo' works fine.) I guess I'll have to find a way > around that which isn't too ugly. The attached patch should actually work, and includes some -Wall fixes and added $FreeBSD$ tags. It doesn't seem quite as clean, as it involves modifying find_execute rather than keeping all the code for the operators separate, but I don't really see a way around this. -- Ben Smithurst / ben@scientia.demon.co.uk / PGP: 0x99392F7D --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="find.diff" Index: extern.h =================================================================== RCS file: /usr/cvs/src/usr.bin/find/extern.h,v retrieving revision 1.9 diff -u -r1.9 extern.h --- extern.h 1999/12/19 15:43:18 1.9 +++ extern.h 2000/04/30 02:03:36 @@ -80,9 +80,12 @@ PLAN *c_xdev __P((void)); PLAN *c_openparen __P((void)); PLAN *c_closeparen __P((void)); +PLAN *c_maxdepth __P((char *)); +PLAN *c_mindepth __P((char *)); PLAN *c_mmin __P((char *)); PLAN *c_mtime __P((char *)); PLAN *c_not __P((void)); PLAN *c_or __P((void)); -extern int ftsoptions, isdeprecated, isdepth, isoutput, issort, isxargs; +extern int ftsoptions, isdeprecated, isdepth, isoutput, issort, isxargs, + mindepth, maxdepth; Index: find.1 =================================================================== RCS file: /usr/cvs/src/usr.bin/find/find.1,v retrieving revision 1.23 diff -u -r1.23 find.1 --- find.1 2000/03/01 10:48:32 1.23 +++ find.1 2000/04/28 19:48:12 @@ -245,6 +245,12 @@ If the file is a symbolic link, the pathname of the linked\-to file will be displayed preceded by ``\->''. The format is identical to that produced by ``ls \-dgils''. +.It Ic -maxdepth Ar n +True if the depth of the current file into the tree is less than or equal to +.Ar n . +.It Ic -mindepth Ar n +True if the depth of the current file into the tree is greater than or equal to +.Ar n . .It Ic -mmin Ar n True if the difference between the file last modification time and the time .Nm find Index: find.c =================================================================== RCS file: /usr/cvs/src/usr.bin/find/find.c,v retrieving revision 1.7 diff -u -r1.7 find.c --- find.c 1998/11/29 11:34:30 1.7 +++ find.c 2000/04/30 02:43:35 @@ -35,7 +35,9 @@ */ #ifndef lint -static char sccsid[] = "@(#)find.c 8.5 (Berkeley) 8/5/94"; +static const char sccsid[] = "@(#)find.c 8.5 (Berkeley) 8/5/94"; +static const char rcsid[] = + "$FreeBSD$"; #endif /* not lint */ #include @@ -206,12 +208,21 @@ continue; } + if (mindepth != -1 && entry->fts_level < mindepth) + continue; + /* * Call all the functions in the execution plan until one is * false or all have been executed. This is where we do all * the work specified by the user on the command line. */ for (p = plan; p && (p->eval)(p, entry); p = p->next); + + if (maxdepth != -1 && entry->fts_level >= maxdepth) { + if (fts_set(tree, entry, FTS_SKIP)) + err(1, "%s", entry->fts_path); + continue; + } } if (errno) err(1, "fts_read"); Index: find.h =================================================================== RCS file: /usr/cvs/src/usr.bin/find/find.h,v retrieving revision 1.6 diff -u -r1.6 find.h --- find.h 1999/12/19 15:43:18 1.6 +++ find.h 2000/04/28 19:44:31 @@ -46,7 +46,7 @@ N_MTIME, N_NAME, N_NEWER, N_NOGROUP, N_NOT, N_NOUSER, N_OK, N_OPENPAREN, N_OR, N_PATH, N_PERM, N_PRINT, N_PRUNE, N_SIZE, N_TYPE, N_USER, N_XDEV, - N_PRINT0, N_DELETE + N_PRINT0, N_DELETE, N_MAXDEPTH, N_MINDEPTH }; /* node definition */ Index: function.c =================================================================== RCS file: /usr/cvs/src/usr.bin/find/function.c,v retrieving revision 1.22 diff -u -r1.22 function.c --- function.c 2000/02/05 18:42:34 1.22 +++ function.c 2000/04/30 02:16:30 @@ -35,8 +35,9 @@ */ #ifndef lint -static char sccsid[] = "@(#)function.c 8.10 (Berkeley) 5/4/95"; -static char rcsid[] = "$FreeBSD: src/usr.bin/find/function.c,v 1.22 2000/02/05 18:42:34 joe Exp $"; +static const char sccsid[] = "@(#)function.c 8.10 (Berkeley) 5/4/95"; +static const char rcsid[] = + "$FreeBSD: src/usr.bin/find/function.c,v 1.22 2000/02/05 18:42:34 joe Exp $"; #endif /* not lint */ #include @@ -717,6 +718,68 @@ } /* + * -maxdepth n functions -- + * + * Does the same as -prune if the level of the current file is greater + * than the specified maximum depth. + * + * Note that -maxdepth and -mindepth are handled specially in + * find_execute() so their f_* functions here do nothing. + */ +int +f_maxdepth(plan, entry) + PLAN *plan; + FTSENT *entry; +{ + return (1); +} + +PLAN * +c_maxdepth(arg) + char *arg; +{ + PLAN *new; + + if (*arg == '-') + /* all other errors handled by find_parsenum() */ + errx(1, "-maxdepth: %s: value must be positive", arg); + + new = palloc(N_MAXDEPTH, f_maxdepth); + maxdepth = find_parsenum(new, "-maxdepth", arg, NULL); + return (new); + +} + +/* + * -mindepth n functions -- + * + * True if the current file is at or deeper than the specified minimum + * depth. + */ +int +f_mindepth(plan, entry) + PLAN *plan; + FTSENT *entry; +{ + return (1); +} + +PLAN * +c_mindepth(arg) + char *arg; +{ + PLAN *new; + + if (*arg == '-') + /* all other errors handled by find_parsenum() */ + errx(1, "-maxdepth: %s: value must be positive", arg); + + new = palloc(N_MINDEPTH, f_mindepth); + mindepth = find_parsenum(new, "-mindepth", arg, NULL); + return (new); +} + +/* * -mtime n functions -- * * True if the difference between the file modification time and the @@ -1005,9 +1068,6 @@ #endif return new; } - - /* - /* * -print functions -- Index: ls.c =================================================================== RCS file: /usr/cvs/src/usr.bin/find/ls.c,v retrieving revision 1.5 diff -u -r1.5 ls.c --- ls.c 1998/07/06 21:01:14 1.5 +++ ls.c 2000/04/30 02:18:13 @@ -32,7 +32,9 @@ */ #ifndef lint -static char sccsid[] = "@(#)ls.c 8.1 (Berkeley) 6/6/93"; +static const char sccsid[] = "@(#)ls.c 8.1 (Berkeley) 6/6/93"; +static const char rcsid[] = + "$FreeBSD$"; #endif /* not lint */ #include Index: main.c =================================================================== RCS file: /usr/cvs/src/usr.bin/find/main.c,v retrieving revision 1.9 diff -u -r1.9 main.c --- main.c 1998/11/29 11:34:30 1.9 +++ main.c 2000/04/30 02:18:17 @@ -41,7 +41,9 @@ #endif /* not lint */ #ifndef lint -static char sccsid[] = "@(#)main.c 8.4 (Berkeley) 5/4/95"; +static const char sccsid[] = "@(#)main.c 8.4 (Berkeley) 5/4/95"; +static const char rcsid[] = + "$FreeBSD$"; #endif /* not lint */ #include @@ -67,6 +69,7 @@ int isoutput; /* user specified output operator */ int issort; /* do hierarchies in lexicographical order */ int isxargs; /* don't permit xargs delimiting chars */ +int mindepth = -1, maxdepth = -1; /* minimum and maximum depth */ static void usage __P((void)); Index: misc.c =================================================================== RCS file: /usr/cvs/src/usr.bin/find/misc.c,v retrieving revision 1.2 diff -u -r1.2 misc.c --- misc.c 1995/05/30 06:30:13 1.2 +++ misc.c 2000/04/30 02:18:20 @@ -35,7 +35,9 @@ */ #ifndef lint -static char sccsid[] = "@(#)misc.c 8.2 (Berkeley) 4/1/94"; +static const char sccsid[] = "@(#)misc.c 8.2 (Berkeley) 4/1/94"; +static const char rcsid[] = + "$FreeBSD$"; #endif /* not lint */ #include Index: operator.c =================================================================== RCS file: /usr/cvs/src/usr.bin/find/operator.c,v retrieving revision 1.5 diff -u -r1.5 operator.c --- operator.c 1998/11/29 12:17:09 1.5 +++ operator.c 2000/04/30 02:18:23 @@ -35,7 +35,9 @@ */ #ifndef lint -static char sccsid[] = "@(#)operator.c 8.1 (Berkeley) 6/6/93"; +static const char sccsid[] = "@(#)operator.c 8.1 (Berkeley) 6/6/93"; +static const char rcsid[] = + "$FreeBSD$"; #endif /* not lint */ #include Index: option.c =================================================================== RCS file: /usr/cvs/src/usr.bin/find/option.c,v retrieving revision 1.9 diff -u -r1.9 option.c --- option.c 1999/12/19 15:43:19 1.9 +++ option.c 2000/04/30 02:18:28 @@ -84,6 +84,8 @@ { "-inum", N_INUM, c_inum, O_ARGV }, { "-links", N_LINKS, c_links, O_ARGV }, { "-ls", N_LS, c_ls, O_ZERO }, + { "-maxdepth", N_MAXDEPTH, c_maxdepth, O_ARGV }, + { "-mindepth", N_MINDEPTH, c_mindepth, O_ARGV }, { "-mmin", N_MMIN, c_mmin, O_ARGV }, { "-mtime", N_MTIME, c_mtime, O_ARGV }, { "-name", N_NAME, c_name, O_ARGV }, --yrj/dFKFPuw6o+aM-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message