From owner-freebsd-hackers Sun Jan 17 01:58:12 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA25071 for freebsd-hackers-outgoing; Sun, 17 Jan 1999 01:58:12 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from sturm.canonware.com (canonware.com [204.107.140.54]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA25066 for ; Sun, 17 Jan 1999 01:58:11 -0800 (PST) (envelope-from jasone@canonware.com) Received: from localhost (jasone@localhost) by sturm.canonware.com (8.8.8/8.8.8) with ESMTP id BAA02528; Sun, 17 Jan 1999 01:51:56 -0800 (PST) (envelope-from jasone@canonware.com) Date: Sun, 17 Jan 1999 01:51:55 -0800 (PST) From: Jason Evans To: Matthew Dillon cc: Terry Lambert , hackers@FreeBSD.ORG Subject: Re: Path to SMP In-Reply-To: <199901170641.WAA46889@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 Matthew Dillon initially asked: > Is anyone currently working on the next big step in the SMP > puzzle? That is, implementing kernel threads with preemptive > scheduling? Matthew Dillon continued on to infer that this is all that is necessary in order to have good SMP support for threaded applications (assuming the Linux definition of kernel threads): > The idea being that one then has the ability to run > preemptable kernel threads in parallel on SMP-capable > boxes because the code must assume preemption in the > same manner on both uni and multi cpu systems. > > Once implemented, we would begin to migrate functionality > from non-preemptive threads to preemptive threads from > the outside-in, and parallel SMP operation in supervisor > mode migrates along with it. Terry Lambert replied: :Jason Evans has started work on an async call based mechanism. : [...] Matthew Dillon replied: > This sounds like it is solving a different problem. It would be > a rather complex solution to a relatively simple problem - processes > can already 'almost' run in supervisor mode, in parallel, in an SMP > environment. Actually, I don't think it's enough to have the ability to run multiple "clone()d" processes in supervisor mode, in parallel. The problem is that these processes can block in the kernel. For an N->M mapping of threads->processes, this means a process can block, thus preventing other schedulable user threads from running. In the LinuxThreads model, every user thread is associated with a clone()d process, but this doesn't scale well, and has the additional problem of slow thread context switches (despite what Linux users claim about their fast kernel context switching being good enough). Solaris goes to great lengths to deal with this problem. It has to make sure that there is always an extra LWP available if it wants to always be able to schedule threads on idle processors, even if all of its other LWP's are blocked in the kernel. The complexity associated with this approach is staggering. You don't even want to know how they do it. =( The asynchronous system call mechanism allows a simpler solution, and appears to me to achieve the same level of flexibility and similar performance to the Solaris solution. The idea is to have a pool of kernel thread (not the Linux definition) contexts that can be used to execute asynchronous system calls. The kernel never has to worry in advance about running out of contexts, since it can always create more on the fly. So, as I see it, this doesn't solve a different problem than you originally brought up; it goes the final step in solving the problem of creating truly good support for threaded applications, both for SMP and UP machines. Jason Jason Evans http://www.canonware.com/~jasone Home phone: (650) 856-8204 Work phone: (415) 808-8742 "I once knew a happy medium. Her name was Zohar." - James Foster To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 17 11:24:49 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA17243 for freebsd-hackers-outgoing; Sun, 17 Jan 1999 11:24:49 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA17238 for ; Sun, 17 Jan 1999 11:24:48 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id LAA51387; Sun, 17 Jan 1999 11:24:38 -0800 (PST) (envelope-from dillon) Date: Sun, 17 Jan 1999 11:24:38 -0800 (PST) From: Matthew Dillon Message-Id: <199901171924.LAA51387@apollo.backplane.com> To: Jason Evans Cc: Matthew Dillon , Terry Lambert , hackers@FreeBSD.ORG Subject: Re: Path to SMP References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Matthew Dillon initially asked: : :> Is anyone currently working on the next big step in the SMP :> puzzle? That is, implementing kernel threads with preemptive :> scheduling? : :Matthew Dillon continued on to infer that this is all that is necessary in :order to have good SMP support for threaded applications (assuming the :Linux definition of kernel threads): : :... : :Actually, I don't think it's enough to have the ability to run multiple :"clone()d" processes in supervisor mode, in parallel. The problem is that :these processes can block in the kernel. For an N->M mapping of :threads->processes, this means a process can block, thus preventing other :... :schedulable user threads from running. In the LinuxThreads model, every :user thread is associated with a clone()d process, but this doesn't scale :well, and has the additional problem of slow thread context switches :... There is nothing magic about a supervisor-supervisor context switch, and the overhead of cloning processes exists only because the full struct proc is being duplicated - also not necessary. All we really need is the concept of a 'task' verses 'process'. A process is made up of one or more scheduling entities called 'tasks'. tasks are trivial to create, switch between, and destroy. I think it can be that simple. The problem UNIXs have now is that the scheduling entity is also the resource management entity, so you start to have to go through loops to make it efficient. If interrupts are moved into kernel threads, stack overhead becomes much more predictable so the stack utilization resource might come in at, say, 8K per thread instead of 16K or 32K per thread. Also, you can still implement a semi-synchronous cross-thread call without having to deal with the overhead of a fully-async design. -Matt Matthew Dillon :Jason Evans To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 17 12:04:05 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA21696 for freebsd-hackers-outgoing; Sun, 17 Jan 1999 12:04:05 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from rah.star-gate.com (sj-dsl-9-129-138.dspeed.net [209.249.129.138]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA21689 for ; Sun, 17 Jan 1999 12:04:04 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.1/8.8.8) with ESMTP id MAA08740 for ; Sun, 17 Jan 1999 12:03:55 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199901172003.MAA08740@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: hackers@FreeBSD.ORG Subject: mmap and processes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Jan 1999 12:03:55 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is there an easy way to determine the mmaped regions of a process? Tnks, Amancio To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sun Jan 17 12:08:10 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA22196 for freebsd-hackers-outgoing; Sun, 17 Jan 1999 12:08:10 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles218.castles.com [208.214.165.218]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA22191 for ; Sun, 17 Jan 1999 12:08:08 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id MAA08391; Sun, 17 Jan 1999 12:04:39 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901172004.MAA08391@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Amancio Hasty cc: hackers@FreeBSD.ORG Subject: Re: mmap and processes In-reply-to: Your message of "Sun, 17 Jan 1999 12:03:55 PST." <199901172003.MAA08740@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Jan 1999 12:04:38 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Is there an easy way to determine the mmaped regions of a process? cat /proc/$pid/map -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ 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 Sun Jan 17 21:14:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA16656 for freebsd-hackers-outgoing; Sun, 17 Jan 1999 21:14:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA16649; Sun, 17 Jan 1999 21:14:29 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id VAA57485; Sun, 17 Jan 1999 21:14:25 -0800 (PST) (envelope-from dillon) Date: Sun, 17 Jan 1999 21:14:25 -0800 (PST) From: Matthew Dillon Message-Id: <199901180514.VAA57485@apollo.backplane.com> To: "John S. Dyson" , dg@root.com, jkh@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Found problem w/ Paging performance over NFS Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is pretty cool - I figured out why the paging performance is so horrible over NFS but good to local disk. It turns out that the NFS subsystem looks at B_ASYNC in the bp. This flag is not set by the paging code, so the NFS writes requested by the pageout daemon were being done synchronously. Setting B_ASYNC makes the paging go a whole lot faster, but creates other problems relating to pbgetvp() and pbrelvp() calls - these calls associate a vnode with a bp without linking the bp into the vnode or messing with the vnode's reference count. The problem is that NFS ( and possibly other subsystems), assumes that it can call reassignbuf() on any bp when, in fact, it can't. bp's handed to them from the paging system ( or any other subsystem that uses pbgetvp() ) cannot be reassigned using reassignbuf(). nfs_doio() hits this sometimes when you ^C a program. In anycase, I fixed things up to formally separate bp's that use pbgetvp() and bp's that do not, put in some asserts to enforce it, and fixed the code in nfs_doio() that was messing things up. The B_PAGING flag is now associated specifically with 'bp's that quickly assign b_vp without messing with links or reference counts'. I've also upgraded my LAN to 100BaseTX to test it. With 4 nfsiod's running, I am getting excellent paging performance to NFS swap - 1.5 to 2.5 megabytes a second on pageout instead of 250 KBytes/sec. The diskless workstation now pages out as well as a normal server! -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 Jan 17 21:49:55 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA21348 for freebsd-hackers-outgoing; Sun, 17 Jan 1999 21:49:55 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA21333 for ; Sun, 17 Jan 1999 21:49:48 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id VAA27590; Sun, 17 Jan 1999 21:49:43 -0800 (PST) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma027588; Sun, 17 Jan 99 21:49:30 -0800 Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id VAA04615; Sun, 17 Jan 1999 21:49:30 -0800 (PST) From: Archie Cobbs Message-Id: <199901180549.VAA04615@bubba.whistle.com> Subject: Loading KLD from the kernel To: freebsd-hackers@FreeBSD.ORG Date: Sun, 17 Jan 1999 21:49:30 -0800 (PST) Cc: julian@whistle.com (Julian Elischer) X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG What's the correct way to request loading of a KLD module from within the kernel (but not from an interrupt handler). I see the kldload() syscall function.. should I just call it directly? Same question for unloading a KLD module... Thanks, -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 Jan 17 23:59:03 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA05885 for freebsd-hackers-outgoing; Sun, 17 Jan 1999 23:59:03 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from fep2-orange.clear.net.nz (fep2-orange.clear.net.nz [203.97.32.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA05880 for ; Sun, 17 Jan 1999 23:59:01 -0800 (PST) (envelope-from jabley@buddha.clear.net.nz) Received: from buddha.clear.net.nz (buddha.clear.net.nz [192.168.24.106]) by fep2-orange.clear.net.nz (1.5/1.9) with ESMTP id UAA06280; Mon, 18 Jan 1999 20:58:55 +1300 (NZDT) Received: (from jabley@localhost) by buddha.clear.net.nz (8.9.2/8.9.1) id UAA15756; Mon, 18 Jan 1999 20:58:49 +1300 (NZDT) (envelope-from jabley) Date: Mon, 18 Jan 1999 20:58:48 +1300 From: Joe Abley To: Andrzej Bialecki Cc: "Daniel C. Sobral" , Mike Smith , freebsd-hackers@FreeBSD.ORG, jabley@clear.co.nz Subject: Re: FICL and setting BTX variables Message-ID: <19990118205848.A15736@clear.co.nz> References: <19990113204253.D1312@clear.co.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from Andrzej Bialecki on Wed, Jan 13, 1999 at 11:31:48AM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, everything has been a little quiet on this - I'm not sure whether to interpret the silence as acceptance or boredom :) I have filed kern/9551 which contains unified diffs for the two Makefiles concerned, and the text of the two awk scripts replacing softcore.pl and merge_help.pl, as previously posted. If there are sub-optimalities in either script, please let me know. Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 00:40:41 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA11074 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 00:40:41 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from Thingol.KryptoKom.DE (Thingol.KryptoKom.DE [194.245.91.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA11068 for ; Mon, 18 Jan 1999 00:40:39 -0800 (PST) (envelope-from edebruin@iname.com) Received: (from mail@localhost) by Thingol.KryptoKom.DE (8.8.7/8.8.4) id JAA11631 for ; Mon, 18 Jan 1999 09:41:25 +0100 Received: from cirdan.kryptokom.de by via smtpp (Version 1.1.1beta6) id kwa11626; Mon Jan 18 09:41:20 1999 Received: by Cirdan.KryptoKom.DE (8.8.5/8.8.5) with ESMTP id JAA03244 for ; Mon, 18 Jan 1999 09:31:35 +0100 Original: Received: from iname.com (localhost [127.0.0.1]) by borg.kryptokom.de (8.8.8/8.8.8) with ESMTP id JAA27065 for ; Mon, 18 Jan 1999 09:55:10 +0100 (CET) (envelope-from edebruin@iname.com) Message-ID: <36A2F6EB.2296FD8D@iname.com> Date: Mon, 18 Jan 1999 09:55:07 +0100 From: eT Reply-To: debruin@KryptoKom.DE Organization: KryptoKom GmbH X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-19980804-SNAP i386) X-Accept-Language: en MIME-Version: 1.0 To: Hackers FreeBSD Subject: Status of LDAP and FreeBSD? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I was wondering what the current status of developement/implementation of the LDAP protocol on FreeBSD 3.0 was? Any information would be appeciated. eT -- Etienne de Bruin; eT@kryptokom.de; edebruin@iname.com "i'm living proof that the spirit moves" - dc talk, the truth. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 01:00:32 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA13010 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 01:00:32 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from niwa.cri.nz (clam.niwa.cri.nz [131.203.55.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA13003 for ; Mon, 18 Jan 1999 01:00:28 -0800 (PST) (envelope-from w.knowles@niwa.cri.nz) Received: from niwa.cri.nz (wdk.greta.niwa.cri.nz [131.203.63.16]) by niwa.cri.nz (8.9.1/8.9.1) with ESMTP id WAA09624; Mon, 18 Jan 1999 22:00:07 +1300 (NZDT) Message-ID: <36A2F817.9F9AE689@niwa.cri.nz> Date: Mon, 18 Jan 1999 22:00:07 +1300 From: Wayne Knowles Organization: NIWA (NZ) X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: debruin@KryptoKom.DE CC: Hackers FreeBSD Subject: Re: Status of LDAP and FreeBSD? References: <36A2F6EB.2296FD8D@iname.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG eT wrote: > > I was wondering what the current status of developement/implementation of the > LDAP protocol on FreeBSD 3.0 was? > > Any information would be appeciated. OpenLDAP is the best free implementation. It builds under FreeBSD without any problems, and I see that the latest version (1.1.2) is now in the FreeBSD ports collection. For more info on OpenLDAP visit: http://www.openldap.org Wayne To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 01:05:59 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA13354 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 01:05:59 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id BAA13338 for ; Mon, 18 Jan 1999 01:05:55 -0800 (PST) (envelope-from root@dyson.iquest.net) Received: (qmail 25212 invoked from network); 18 Jan 1999 09:05:45 -0000 Received: from dyson.iquest.net (198.70.144.127) by iquest3.iquest.net with SMTP; 18 Jan 1999 09:05:45 -0000 Received: (from root@localhost) by dyson.iquest.net (8.9.1/8.9.1) id EAA25734; Mon, 18 Jan 1999 04:05:34 -0500 (EST) From: "John S. Dyson" Message-Id: <199901180905.EAA25734@dyson.iquest.net> Subject: Re: Found problem w/ Paging performance over NFS In-Reply-To: <199901180514.VAA57485@apollo.backplane.com> from Matthew Dillon at "Jan 17, 99 09:14:25 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Mon, 18 Jan 1999 04:05:32 -0500 (EST) Cc: dg@root.com, jkh@FreeBSD.ORG, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > This is pretty cool - I figured out why the paging performance is so > horrible over NFS but good to local disk. > > It turns out that the NFS subsystem looks at B_ASYNC in the bp. This > flag is not set by the paging code, so the NFS writes requested by the > pageout daemon were being done synchronously. > ... > > I've also upgraded my LAN to 100BaseTX to test it. With 4 nfsiod's > running, I am getting excellent paging performance to NFS swap - 1.5 to > 2.5 megabytes a second on pageout instead of 250 KBytes/sec. The diskless > workstation now pages out as well as a normal server! > Intergalactic!!! :-). John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 01:42:13 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA17430 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 01:42:13 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA17425 for ; Mon, 18 Jan 1999 01:42:10 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id SAA10369; Mon, 18 Jan 1999 18:41:43 +0900 (JST) Message-ID: <36A2EECA.6C90A85A@newsguy.com> Date: Mon, 18 Jan 1999 17:20:26 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Joe Abley CC: Andrzej Bialecki , Mike Smith , freebsd-hackers@FreeBSD.ORG Subject: Re: FICL and setting BTX variables References: <19990113204253.D1312@clear.co.nz> <19990118205848.A15736@clear.co.nz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Joe Abley wrote: > > Well, everything has been a little quiet on this - I'm not sure whether to > interpret the silence as acceptance or boredom :) > > I have filed kern/9551 which contains unified diffs for the two Makefiles > concerned, and the text of the two awk scripts replacing softcore.pl and > merge_help.pl, as previously posted. > > If there are sub-optimalities in either script, please let me know. Don't worry. A soon as this get into the tree, you get to modify softcore.awk to get rid of all redundant spaces as well as (...) comments. :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com If you sell your soul to the Devil and all you get is an MCSE from it, you haven't gotten market rate. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 02:24:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA22089 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 02:24:30 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from localhost (gserver.com [209.180.80.210]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA22035 for ; Mon, 18 Jan 1999 02:24:07 -0800 (PST) (envelope-from surfchina@gserver.com) Received: (surfchina@localhost) by gserver.com (8.8.8) id DAA11283; Mon, 18 Jan 1999 03:28:51 -0700 (MST) Date: Mon, 18 Jan 1999 03:28:51 -0700 (MST) From: surfchina@gserver.com (Surf China) Message-Id: <199901181028.DAA11283@gserver.com> To: freebsd-hackers@FreeBSD.ORG Subject: SurfChina.com - Search Engine for China Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dear friend, Do you ever wonder where to find information about China? Well, wonder no more. Come check out SurfChina.com (http://www.surfchina.com), the BEST SEARCH ENGINE for China. SurfChina.com's database consists of thousands of China, Chinese related web sites, all sites are carefully categorized into over 300 categories, which makes search very easy. New sites and categories are added everyday. You can find Chinese companies, Chinese culture sites, travel agencies, employment opportunities, Chinese newspapers, and much, much more. Take a look for yourself, and tell a friend about SurfChina.com, so everyone can take advantage of this wonderful resource. SurfChina.com also provides China statistical information service. We work directly with the State Statistical Bureau of China to provide the latest, the most accurate, and most authritative China statistical data for our clients. To find out more about this service, please visit http://www.surfchina.com/stats/ Sincerely yours, SurfChina.com team To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 02:36:27 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA23537 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 02:36:27 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from localhost (gserver.com [209.180.80.210]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA23530 for ; Mon, 18 Jan 1999 02:36:26 -0800 (PST) (envelope-from surfchina@gserver.com) Received: (surfchina@localhost) by gserver.com (8.8.8) id DAA17356; Mon, 18 Jan 1999 03:41:12 -0700 (MST) Date: Mon, 18 Jan 1999 03:41:12 -0700 (MST) From: surfchina@gserver.com (Surf China) Message-Id: <199901181041.DAA17356@gserver.com> To: hackers@FreeBSD.ORG Subject: SurfChina.com - Search Engine for China Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dear friend, Do you ever wonder where to find information about China? Well, wonder no more. Come check out SurfChina.com (http://www.surfchina.com), the BEST SEARCH ENGINE for China. SurfChina.com's database consists of thousands of China, Chinese related web sites, all sites are carefully categorized into over 300 categories, which makes search very easy. New sites and categories are added everyday. You can find Chinese companies, Chinese culture sites, travel agencies, employment opportunities, Chinese newspapers, and much, much more. Take a look for yourself, and tell a friend about SurfChina.com, so everyone can take advantage of this wonderful resource. SurfChina.com also provides China statistical information service. We work directly with the State Statistical Bureau of China to provide the latest, the most accurate, and most authritative China statistical data for our clients. To find out more about this service, please visit http://www.surfchina.com/stats/ Sincerely yours, SurfChina.com team To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 02:44:09 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA24076 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 02:44:09 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA24071 for ; Mon, 18 Jan 1999 02:44:06 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by nlsystems.com (8.9.1/8.8.5) with SMTP id KAA42491; Mon, 18 Jan 1999 10:44:20 GMT Date: Mon, 18 Jan 1999 10:44:19 +0000 (GMT) From: Doug Rabson To: Archie Cobbs cc: freebsd-hackers@FreeBSD.ORG, Julian Elischer Subject: Re: Loading KLD from the kernel In-Reply-To: <199901180549.VAA04615@bubba.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 17 Jan 1999, Archie Cobbs wrote: > What's the correct way to request loading of a KLD module from within > the kernel (but not from an interrupt handler). I see the kldload() > syscall function.. should I just call it directly? > > Same question for unloading a KLD module... The right thing to do is to call linker_load_file() like this: linker_file_t lf; int error = linker_load_file(filename, &lf); if (error) ...; ... do things with file ... linker_unload_file(lf); Obviously you shouldn't unload the file while you are still using code from it. You can lookup symbols in the file using linker_file_lookup_symbol() if you need to. To unload a file by name, use linker_find_file_by_name() to get the handle and then call linker_unload_file(). -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 06:33:39 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA17756 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 06:33:39 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from zed.ludd.luth.se (zed.ludd.luth.se [130.240.16.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA17741 for ; Mon, 18 Jan 1999 06:33:12 -0800 (PST) (envelope-from pb@ludd.luth.se) Received: from father.ludd.luth.se (pb@father.ludd.luth.se [130.240.16.18]) by zed.ludd.luth.se (8.8.5/8.8.5) with ESMTP id PAA05161 for ; Mon, 18 Jan 1999 15:32:47 +0100 From: Peter Brevik Received: (pb@localhost) by father.ludd.luth.se (8.6.11/8.6.11) id PAA27511 for freebsd-hackers@freebsd.org; Mon, 18 Jan 1999 15:32:45 +0100 Message-Id: <199901181432.PAA27511@father.ludd.luth.se> Subject: sysinstall used to add slices while system running? To: freebsd-hackers@FreeBSD.ORG Date: Mon, 18 Jan 1999 15:32:45 +0100 (MET) X-Mailer: ELM [version 2.4ME+ PL15 (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 Situation: One harddisc with slice1=dos slice2=fbsd Can a add a slice3 plus a partition within that slice while the system is running, or will that corrupt data due in-core / disc differences. Or overwrite anything critical ..? /pb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 08:41:55 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA03027 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 08:41:55 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA03017; Mon, 18 Jan 1999 08:41:54 -0800 (PST) (envelope-from brett@lariat.org) Received: (from brett@localhost) by lariat.lariat.org (8.8.8/8.8.6) id JAA28896; Mon, 18 Jan 1999 09:41:43 -0700 (MST) Message-Id: <4.1.19990118092136.0465ede0@mail.lariat.org> X-Sender: brett@mail.lariat.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 18 Jan 1999 09:32:12 -0700 To: chat@FreeBSD.ORG From: Brett Glass Subject: Attempt to relicense BSD code under the GPL Cc: 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 According to the Web page at http://www.cs.utah.edu/projects/flexmach/oskit/index.html The latest version of the "OSKit", whose STATED goal is to lower the barrier to entry to OS R&D, has just been re-released UNDER THE GPL. This is not only absurd (because the GPL *is* a barrier to OS R&D) but also illegal, because it conflicts with the licensing provisions of the BSD code which has been incorporated into the package. Those who are concerned about the attempted use of the GPL (which is anti-business, anti-innovation, and sometimes referred to as a "viral" or "cult" license) on BSD code should contact Jay Lepreau at lepreau@cs.utah.edu. Kernel authors in particular should be outraged at the unauthorized and unwarranted GPLing of their code and should protested what is, essentially, hijacking of their work. I'm copying this to hackers, but please address responses to chat. --Brett Glass P.S. -- Perhaps it is time to add a clause to the BSD license used in FreeBSD specifically prohibiting relicensing of that code, or derivative works, under the GPL. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 08:47:24 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA03654 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 08:47:24 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from caldera.telops.gte.com ([143.91.91.101]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA03649 for ; Mon, 18 Jan 1999 08:47:22 -0800 (PST) (envelope-from ehm@concentric.net) Received: from concentric.net (localhost [127.0.0.1]) by caldera.telops.gte.com (8.8.7/8.8.7) with ESMTP id KAA29349; Mon, 18 Jan 1999 10:46:15 -0600 Message-ID: <36A36557.650B39C2@concentric.net> Date: Mon, 18 Jan 1999 10:46:15 -0600 From: Erik Moe X-Mailer: Mozilla 4.04C-Caldera [en] (X11; I; Linux 2.0.33 i686) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: CAMify amd0(Tekram DC390 and other AMD 53c974 cards) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, I have an interest in seeing the amd0 driver being supported by the new CAM SCSI subsystem. I don't have a Tekram card, but I have an Qlogic PCI-Basic with an AMD 53c974 which used to work under the FreeBSD 2.2.x series. If work is underway, I am willing to test. If work has yet to begin, I would be willing to work on the modifications. I have experience writing low-level SCSI drivers. I wrote the low-level driver for the Qlogic PCI SCSI adapter (ISP1020) used by Linux. Erik Moe ehm@concentric.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 08:48:27 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA03938 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 08:48:27 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from kalypso.iqm.unicamp.br (kalypso.iqm.unicamp.br [143.106.51.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA03918; Mon, 18 Jan 1999 08:48:21 -0800 (PST) (envelope-from vazquez@iqm.unicamp.br) Received: by kalypso.iqm.unicamp.br (V-MTA, from userid 105) id 12CAC293; Mon, 18 Jan 1999 14:48:06 -0200 (EDT) Date: Mon, 18 Jan 1999 14:48:05 -0200 From: Pedro A M Vazquez To: Brett Glass Cc: chat@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Attempt to relicense BSD code under the GPL Message-ID: <19990118144805.Q18957@kalypso.iqm.unicamp.br> References: <4.1.19990118092136.0465ede0@mail.lariat.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <4.1.19990118092136.0465ede0@mail.lariat.org>; from Brett Glass on Mon, Jan 18, 1999 at 09:32:12AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mon, Jan 18, 1999 at 09:32:12AM -0700, Brett Glass wrote: > > P.S. -- Perhaps it is time to add a clause to the BSD license used > in FreeBSD specifically prohibiting relicensing of that code, or > derivative works, under the GPL. > maybe something as stated on Eric Young's SSLeay package: The licence and distribution terms for any publically available version or derivative of this code cannot be changed. i.e. this code cannot simply be copied and put under another distribution licence [including the GNU Public Licence.] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 10:01:15 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA12733 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 10:01:15 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from rah.star-gate.com (sj-dsl-9-129-138.dspeed.net [209.249.129.138]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA12727; Mon, 18 Jan 1999 10:01:08 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.1/8.8.8) with ESMTP id KAA26691; Mon, 18 Jan 1999 10:00:30 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199901181800.KAA26691@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "John S. Dyson" cc: dillon@apollo.backplane.com (Matthew Dillon), dg@root.com, jkh@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Found problem w/ Paging performance over NFS In-reply-to: Your message of "Mon, 18 Jan 1999 04:05:32 EST." <199901180905.EAA25734@dyson.iquest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Jan 1999 10:00:30 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Most Cool. Going to drag out my 100BaseTX cards out and plug them in 8) Cheers, Amancio To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 10:12:10 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA13786 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 10:12:10 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp3.xs4all.nl (smtp3.xs4all.nl [194.109.6.53]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA13781 for ; Mon, 18 Jan 1999 10:12:07 -0800 (PST) (envelope-from stephw@xs4all.nl) Received: from xs3.xs4all.nl (stephw@xs3.xs4all.nl [194.109.6.44]) by smtp3.xs4all.nl (8.8.8/8.8.8) with ESMTP id TAA22017 for ; Mon, 18 Jan 1999 19:12:00 +0100 (CET) Received: (from stephw@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) id TAA03618 for freebsd-hackers@freebsd.org; Mon, 18 Jan 1999 19:11:59 +0100 (CET) Date: Mon, 18 Jan 1999 19:11:59 +0100 From: Stephanie Wehner To: freebsd-hackers@FreeBSD.ORG Subject: video cds and atapi-cd.c Message-ID: <19990118191159.T25497@xs3.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I was wondering how to get freebsd to read a video cd with an ide drive. Unfortunately I couldn't really find anything. I had a look at some linux tools for that but things are quite different there. Looking into atapi-cd.c I found some stuff in acd_open_track commented out e.g. "case CDR_XA2:". Did anyone ever have a look at that and why's this commented out ? thx, bye, Stephanie ----------------------------<> _@r4k.net <>-----------------<> FreeBSD <>--- "I had to hit him -- he was starting to make sense." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 10:16:14 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA14424 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 10:16:14 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA14412 for ; Mon, 18 Jan 1999 10:16:09 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id RAA08116; Mon, 18 Jan 1999 17:02:15 +0100 From: Luigi Rizzo Message-Id: <199901181602.RAA08116@labinfo.iet.unipi.it> Subject: Re: video cds and atapi-cd.c To: stephw@xs4all.nl (Stephanie Wehner) Date: Mon, 18 Jan 1999 17:02:15 +0100 (MET) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <19990118191159.T25497@xs3.xs4all.nl> from "Stephanie Wehner" at Jan 18, 99 07:11:40 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I was wondering how to get freebsd to read a video cd with an ide > drive. Unfortunately I couldn't really find anything. I had a look > at some linux tools for that but things are quite different there. > Looking into atapi-cd.c I found some stuff in acd_open_track > commented out e.g. "case CDR_XA2:". Did anyone ever have a look > at that and why's this commented out ? if someone sends me a VideoCD i might have a look at this code 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 Jan 18 10:29:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA15774 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 10:29:30 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA15767; Mon, 18 Jan 1999 10:29:28 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id KAA75302; Mon, 18 Jan 1999 10:29:23 -0800 (PST) (envelope-from dillon) Date: Mon, 18 Jan 1999 10:29:23 -0800 (PST) From: Matthew Dillon Message-Id: <199901181829.KAA75302@apollo.backplane.com> To: Amancio Hasty Cc: "John S. Dyson" , dillon@apollo.backplane.com (Matthew Dillon), dg@root.com, jkh@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Found problem w/ Paging performance over NFS Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Most Cool. Going to drag out my 100BaseTX cards out and plug them in 8) : : Cheers, : Amancio Note! It will be in my commits for 4.0 after the tree split. I haven't committed it into the 3.x tree yet. -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 Jan 18 10:53:41 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA18845 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 10:53:41 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from feral-gw.feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA18835 for ; Mon, 18 Jan 1999 10:53:39 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral-gw.feral.com (8.8.7/8.8.7) with ESMTP id KAA15924; Mon, 18 Jan 1999 10:53:14 -0800 Date: Mon, 18 Jan 1999 10:53:10 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Erik Moe cc: freebsd-hackers@FreeBSD.ORG Subject: Re: CAMify amd0(Tekram DC390 and other AMD 53c974 cards) In-Reply-To: <36A36557.650B39C2@concentric.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, Erik- I used some of your concepts from the 1020 driver in the conjoint ISP 2X00/1XXX driver that's FreeBSD/NetBSD (and there's a linux version too...)- thinks for the neat idea about quickly figuring out the number of in/out mailbox registers to use for a particular command. If this is the 53c974, this really could be a conjoint ESP100 - 53c974 - FAS266 driver, couldn't it? Basically this is chip core is plunked right into the middle of the 10X0 which then wraps a risc processor aroundit. I'd love to see a newer driver using this (I did the SunOS/Solaris esp driver)- particularly if it had a micro state machine to (quickly) manage all the 7-10 interrupts/command that you have to do... I haven't the bandwidth to really drive any of this, but I'd be glad to provide testing and even equipment resources (maybe you can slogin into feral- maybe we can make this work on FreeBSD/alpha as a good proof of concept)...? > Hello, > > I have an interest in seeing the amd0 driver being supported by the new > CAM SCSI subsystem. I don't have a Tekram card, but I have an Qlogic > PCI-Basic with an AMD 53c974 which used to work under the FreeBSD 2.2.x > series. If work is underway, I am willing to test. If work has yet to > begin, I would be willing to work on the modifications. I have > experience writing low-level SCSI drivers. I wrote the low-level driver > for the Qlogic PCI SCSI adapter (ISP1020) used by Linux. > > Erik Moe > ehm@concentric.net > > 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 Jan 18 11:05:47 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA21119 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 11:05:47 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles250.castles.com [208.214.165.250]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA21098 for ; Mon, 18 Jan 1999 11:05:43 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id LAA17965; Mon, 18 Jan 1999 11:01:54 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901181901.LAA17965@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Joe Abley cc: Andrzej Bialecki , "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG Subject: Re: FICL and setting BTX variables In-reply-to: Your message of "Mon, 18 Jan 1999 20:58:48 +1300." <19990118205848.A15736@clear.co.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Jan 1999 11:01:54 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Well, everything has been a little quiet on this - I'm not sure whether to > interpret the silence as acceptance or boredom :) The former is always a safe assumption. Silence around here is a resounding agreement. > I have filed kern/9551 which contains unified diffs for the two Makefiles > concerned, and the text of the two awk scripts replacing softcore.pl and > merge_help.pl, as previously posted. Thanks. Not being able to detect style bugs in awk scripts, I've gone ahead and committed your stuff (I tested it too 8). > If there are sub-optimalities in either script, please let me know. I'm sure we'll hear about any of them.... Thanks! -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 11:19:54 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA23047 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 11:19:54 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA23035 for ; Mon, 18 Jan 1999 11:19:51 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id MAA00894; Mon, 18 Jan 1999 12:11:25 -0700 (MST) Date: Mon, 18 Jan 1999 12:11:25 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199901181911.MAA00894@narnia.plutotech.com> To: mjacob@feral.com cc: hackers@FreeBSD.ORG Subject: Re: CAMify amd0(Tekram DC390 and other AMD 53c974 cards) X-Newsgroups: pluto.freebsd.hackers In-Reply-To: User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article you wrote: > > I'd love to see a newer driver using this (I did the SunOS/Solaris esp > driver)- particularly if it had a micro state machine to (quickly) manage > all the 7-10 interrupts/command that you have to do... > I'm also keen to see AMD support return to the FreeBSD SCSI subsystem. I don't know of anyone working on this driver right now, and I'm currently quite booked, but I'll assist in whatever ways I can if you decide to do this work. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 11:24:03 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA23693 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 11:24:03 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from feral-gw.feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA23655 for ; Mon, 18 Jan 1999 11:23:59 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral-gw.feral.com (8.8.7/8.8.7) with ESMTP id LAA16115; Mon, 18 Jan 1999 11:23:34 -0800 Date: Mon, 18 Jan 1999 11:23:34 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: "Justin T. Gibbs" cc: hackers@FreeBSD.ORG Subject: Re: CAMify amd0(Tekram DC390 and other AMD 53c974 cards) In-Reply-To: <199901181911.MAA00894@narnia.plutotech.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 *moi?* You know *I'm* booked... I'm hoping Erik will decide to take it on... On Mon, 18 Jan 1999, Justin T. Gibbs wrote: > In article you wrote: > > > > I'd love to see a newer driver using this (I did the SunOS/Solaris esp > > driver)- particularly if it had a micro state machine to (quickly) manage > > all the 7-10 interrupts/command that you have to do... > > > > I'm also keen to see AMD support return to the FreeBSD SCSI subsystem. > I don't know of anyone working on this driver right now, and I'm currently > quite booked, but I'll assist in whatever ways I can if you decide > to do this work. > > -- > Justin > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 11:26:00 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA23926 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 11:26:00 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA23908 for ; Mon, 18 Jan 1999 11:25:57 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.9.1/8.9.1) with ESMTP id MAA03522; Mon, 18 Jan 1999 12:25:48 -0700 (MST) (envelope-from gibbs@plutotech.com) Message-Id: <199901181925.MAA03522@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: mjacob@feral.com cc: "Justin T. Gibbs" , hackers@FreeBSD.ORG Subject: Re: CAMify amd0(Tekram DC390 and other AMD 53c974 cards) In-reply-to: Your message of "Mon, 18 Jan 1999 11:23:34 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Jan 1999 12:17:32 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >*moi?* You know *I'm* booked... I'm hoping Erik will decide to take it >on... My intention was to add my support in addition to yours for Erik's efforts. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 12:18:15 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA03568 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 12:18:15 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from monk.via.net (monk.via.net [209.81.9.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA03556; Mon, 18 Jan 1999 12:18:11 -0800 (PST) (envelope-from joe@monk.via.net) Received: (from joe@localhost) by monk.via.net (8.8.8/8.8.8) id MAA15347; Mon, 18 Jan 1999 12:18:06 -0800 (PST) (envelope-from joe) From: Joe McGuckin Message-Id: <199901182018.MAA15347@monk.via.net> Date: Mon, 18 Jan 1999 12:18:05 -0800 (PST) To: chat@FreeBSD.ORG Cc: hackers@FreeBSD.ORG Subject: Re: Attempt to relicense BSD code under the GPL X-Mailer: Ishmail 1.3.1-970608-bsdi MIME-Version: 1.0 Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Also, I wouldn't think that it is proper to slap a GNU style copyleft on software that was funded by the government (in this case, DARPA). Joe McGuckin ViaNet Communications 1235 Pear Ave, Suite 107 Mountain View, CA 90403 Phone: 650-969-2203 Cell: 415-710-4894 Fax: 650-969-2124 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 12:26:11 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA04770 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 12:26:11 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA04765; Mon, 18 Jan 1999 12:26:10 -0800 (PST) (envelope-from brett@lariat.org) Received: (from brett@localhost) by lariat.lariat.org (8.8.8/8.8.6) id NAA01160; Mon, 18 Jan 1999 13:26:01 -0700 (MST) Message-Id: <4.1.19990118132031.06324a60@mail.lariat.org> X-Sender: brett@mail.lariat.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 18 Jan 1999 13:21:20 -0700 To: Joe McGuckin , chat@FreeBSD.ORG From: Brett Glass Subject: Re: Attempt to relicense BSD code under the GPL Cc: hackers@FreeBSD.ORG In-Reply-To: <199901182018.MAA15347@monk.via.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 12:18 PM 1/18/99 -0800, Joe McGuckin wrote: > >Also, I wouldn't think that it is proper to slap a GNU style copyleft >on software that was funded by the government (in this case, DARPA). I agree. Yet another reason to e-mail these folks and protest this move. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 12:35:36 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA06108 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 12:35:36 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA06103 for ; Mon, 18 Jan 1999 12:35:34 -0800 (PST) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.9.1/8.9.1) id VAA09298; Mon, 18 Jan 1999 21:34:58 +0100 (CET) (envelope-from sos) From: Søren Schmidt Message-Id: <199901182034.VAA09298@freebsd.dk> Subject: Re: video cds and atapi-cd.c In-Reply-To: <19990118191159.T25497@xs3.xs4all.nl> from Stephanie Wehner at "Jan 18, 1999 7:11:59 pm" To: stephw@xs4all.nl (Stephanie Wehner) Date: Mon, 18 Jan 1999 21:34:58 +0100 (CET) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It seems Stephanie Wehner wrote: > Hi, > > I was wondering how to get freebsd to read a video cd with an ide > drive. Unfortunately I couldn't really find anything. I had a look > at some linux tools for that but things are quite different there. Try use cdcontrol and use the info cmd, it might turn out usefull info about the layout of the CD. > Looking into atapi-cd.c I found some stuff in acd_open_track > commented out e.g. "case CDR_XA2:". Did anyone ever have a look > at that and why's this commented out ? Yeah, I wrote it :), its code for writing a CDR/CDRW, the XA2 format is not supported for writing (yet).. - Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 13:10:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA12099 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 13:10:16 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA12015; Mon, 18 Jan 1999 13:10:05 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id OAA20295; Mon, 18 Jan 1999 14:09:58 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp01.primenet.com, id smtpd020216; Mon Jan 18 14:09:52 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id OAA01203; Mon, 18 Jan 1999 14:09:51 -0700 (MST) From: Terry Lambert Message-Id: <199901182109.OAA01203@usr05.primenet.com> Subject: Re: Attempt to relicense BSD code under the GPL To: brett@lariat.org (Brett Glass) Date: Mon, 18 Jan 1999 21:09:51 +0000 (GMT) Cc: joe@monk.via.net, chat@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <4.1.19990118132031.06324a60@mail.lariat.org> from "Brett Glass" at Jan 18, 99 01:21:20 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >Also, I wouldn't think that it is proper to slap a GNU style copyleft > >on software that was funded by the government (in this case, DARPA). > > I agree. Yet another reason to e-mail these folks and protest this > move. I agree too, but the RT OS from the Red Stone missle folks was a DARPA funded project, and it's under GPL. It looks like GPL is "politically correct" in government circles these days. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 14:26:59 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA23547 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 14:26:59 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA23542 for ; Mon, 18 Jan 1999 14:26:57 -0800 (PST) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id PAA18746; Mon, 18 Jan 1999 15:26:51 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpd018565; Mon Jan 18 15:26:39 1999 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id PAA04448; Mon, 18 Jan 1999 15:26:33 -0700 (MST) From: Terry Lambert Message-Id: <199901182226.PAA04448@usr05.primenet.com> Subject: Re: Path to SMP To: dillon@apollo.backplane.com (Matthew Dillon) Date: Mon, 18 Jan 1999 22:26:32 +0000 (GMT) Cc: jasone@canonware.com, dillon@apollo.backplane.com, tlambert@primenet.com, hackers@FreeBSD.ORG In-Reply-To: <199901171924.LAA51387@apollo.backplane.com> from "Matthew Dillon" at Jan 17, 99 11:24:38 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :Actually, I don't think it's enough to have the ability to run multiple > :"clone()d" processes in supervisor mode, in parallel. The problem is that > :these processes can block in the kernel. For an N->M mapping of > :threads->processes, this means a process can block, thus preventing other > :... > :schedulable user threads from running. In the LinuxThreads model, every > :user thread is associated with a clone()d process, but this doesn't scale > :well, and has the additional problem of slow thread context switches > :... > > There is nothing magic about a supervisor-supervisor context switch, > and the overhead of cloning processes exists only because the full > struct proc is being duplicated - also not necessary. > > All we really need is the concept of a 'task' verses 'process'. A process > is made up of one or more scheduling entities called 'tasks'. tasks are > trivial to create, switch between, and destroy. I think it can be > that simple. A "task" is an execution context. For a thread entering the kernel, this is, in fact, a system call context that contains: (1) A reference to the caller's VM space. (2) A kernel stack (3) The program counter This is exactly what's needed for an async system call interface, as well. > The problem UNIXs have now is that the scheduling entity is also the > resource management entity, so you start to have to go through loops > to make it efficient. I think you meant "hoops"? The problem is that the kernel is doing work on behalf of a user process, either in the trap or the fault entry mechanisms. For the interrupt entry, the kernel is doing work on behalf of hardware -- latently tied to a request by a user process, but not the same thing, since there is a sleep/wakeup mechanism synchronizing the completion notification. In other words, faults and traps have an associated process context, while interrupts don't. I agree that there needs to be the concept of a trap/fault context that is seperate from the idea of a process. That's what an async call gate gives you, in fact: a method of divorcing trap context from a process. > If interrupts are moved into kernel threads, stack overhead becomes much > more predictable so the stack utilization resource might come in at, say, > 8K per thread instead of 16K or 32K per thread. Moving interrupts into kernel threads would be a mistake. Interrupts don't need a context other than the kernel VM space. On the other hand, interrupts should be low latency, and then if there is additional processing that is required seperate from the act of getting the interrupt freed, *that* can go into a seperate "upper level" soft interrupt mechanism (e.g., as queued "work to do"). You see that in the serial driver and the network stacks, but it really applies to all interrupts. The virtue of this for SMP is to allow interrupt processing of shared interrupts to occur on one processor only (a dispatch implies temporary ownership of the Interrupt "resource"), and other interrupts can be simultaneously dispatched to other processors. They are given back to the "virtual wire" when the interrupt is reenabled (acknowledged). It's probably useful to think of these as async contexts, with the same stack and program counter requirements, but a pointer to the kernel, not a user space VM. I think these aren't threads, because anything in the kernel gets the kernel VM space access, and I think they aren't scheduling entities at all, so scheduler information would be overkill. They only execute as a result of being "scheduled" by a hardware event. You could probably statically allocate one of these for every hardware interrupt that's possible, and leave it at that. The interrupt handler would execute on the interrupt private stack. A split interrupt model also has a better chance of meeting the timing constraints of hard real-time hardware task duration semantics. > Also, you can still > implement a semi-synchronous cross-thread call without having to deal > with the overhead of a fully-async design. I don't think you need inter-thread IPC within the kernel, unless you are considering the sleep/wakeup mechnisms as a type of IPC. Even so, interrupts are the result of a slept context, eventually, and they don't have to operate in the context of preempting a kernel stack from a process in order to be able to execute, if done correctly. So even if you are communicating a wakeup *to* a task, you aren't communicating it *from* a task context, you're doing it from an interrupt context. The issue with the scheduler is to consider kernel execution contexts that are the result of a trap as preemptible by faults and interrupts. That is, that CPU's are just another consumable resource, and what you're really scheduling is what context is currently active in the CPU, and not "quantum". Which leaves us with the problem of how to get the CPU's into user space; the problem is one of statically associating a context that has no kernel stack with the user space "process". This is a pretty trivial problem to solve, without going to a monolithic number of kernel threads (which would seriously damage your cache locality). So in user space, you have the processes VM, and you have your program counter, but you don't have a kernel stack. The only part you need to replicate to get multiple CPU's into a single user space process is the program counter. You could do this very easily by requesting a "run in me" -- a type of system call. But pretty obviously, you don't exceed the number of CPU's, and the default is probably one, the one implied by the processes being instanced in the first place. More kernel threads don't buy you more CPU cycles, unless you are looking at a kernel thread as a means of allocating N out of every N + M quantums. And that's a scheduling policy issue that doesn't belong in the hands of the user space programmer anyway, but in the hands of the system administrative policy (or by proxy, in a credential restricted scheduling policy API). It's pretty obvious from this that the context an interrupt needs vs, the context that a process needs are two very different animals. One could easily imagine queueing a blocking system call from CPU #1, and that call being serviced by CPU #4, while the enqueueing call itself returns immediately to user space, and the process continuing to have its code executed by CPU's #1 and #3. Returning to the "run in me" call, we see that it's a component of the user space call conversion scheduler, and not anything to do with kernel threads. Because the calls are made asynchronously, the process need not give away its quantum, merely to make a system call. In actuality, the act of blocking a kernel thread on a system call is what causes unnecessary process context switch overhead, and the related overhead normally associated with the "L1 cache busting" and the APIC bus contention overhead from the IPI's to implement MESI based cache coherency that occurs from unbounded migration. So a design that uses async calls, in fact, neatly sidesteps the cache and scheduling problems that follow from the idea of blocking a kernel thread and switching to a different context because of the block. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 16:01:58 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA04404 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 16:01:58 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA04399; Mon, 18 Jan 1999 16:01:57 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id QAA82498; Mon, 18 Jan 1999 16:01:52 -0800 (PST) (envelope-from dillon) Date: Mon, 18 Jan 1999 16:01:52 -0800 (PST) From: Matthew Dillon Message-Id: <199901190001.QAA82498@apollo.backplane.com> To: "John S. Dyson" , dg@root.com, jkh@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Found problem w/ Paging performance over NFS Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Here's another piece of code to check: in kern/vfs_bio.c, allocbuf() } else if (m->flags & PG_BUSY) { s = splvm(); if (m->flags & PG_BUSY) { vm_page_flag_set(m, PG_WANTED); tsleep(m, PVM, "pgtblk", 0); } splx(s); goto doretry; } else { ... if (tinc > (newbsize - toff)) tinc = newbsize - toff; if (bp->b_flags & B_CACHE) vfs_buf_set_valid(bp, off, toff, tinc, m); vm_page_flag_clear(m, PG_ZERO); vm_page_wire(m); } Shouldn't those conditionals be 'm->busy || (m->flags & PG_BUSY)' instead of just testing against PG_BUSY? A pageout operation will set m->busy without setting PG_BUSY. -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 Jan 18 16:04:40 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA05585 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 16:04:40 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from send106.yahoomail.com (send106.yahoomail.com [205.180.60.43]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA05570 for ; Mon, 18 Jan 1999 16:04:38 -0800 (PST) (envelope-from robertbutler@yahoo.com) Message-ID: <19990119000544.5151.rocketmail@send106.yahoomail.com> Received: from [205.226.11.3] by send106.yahoomail.com; Mon, 18 Jan 1999 16:05:44 PST Date: Mon, 18 Jan 1999 16:05:44 -0800 (PST) From: Robert Butler Subject: any tool == DDB + kernel source file? To: 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 appreciated for any pointer. Robert _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 16:07:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA06979 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 16:07:53 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA06929; Mon, 18 Jan 1999 16:07:51 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id RAA12237; Mon, 18 Jan 1999 17:07:39 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp04.primenet.com, id smtpd012053; Mon Jan 18 17:07:25 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id RAA19784; Mon, 18 Jan 1999 17:07:17 -0700 (MST) From: Terry Lambert Message-Id: <199901190007.RAA19784@usr09.primenet.com> Subject: Re: Forward all spam to UCE@FTC.GOV To: zach@uffdaonline.net (Zach Heilig) Date: Tue, 19 Jan 1999 00:07:17 +0000 (GMT) Cc: marko@uk.radan.com, jbryant@unix.tfs.net, freebsd-hackers@FreeBSD.ORG, freebsd-chat@FreeBSD.ORG In-Reply-To: <19990115095653.A16631@znh.org> from "Zach Heilig" at Jan 15, 99 09:56:53 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'm pretty sure anytime there are damages [perhaps fines as well?] in > excess of a certain amount (I think $1000), it is also considered > felony. Yes; hence the distinction between "larceny" and "grand larceny". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 17:20:24 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA16236 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 17:20:24 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id RAA16229 for ; Mon, 18 Jan 1999 17:20:15 -0800 (PST) (envelope-from root@dyson.iquest.net) Received: (qmail 4151 invoked from network); 19 Jan 1999 01:20:09 -0000 Received: from dyson.iquest.net (198.70.144.127) by iquest3.iquest.net with SMTP; 19 Jan 1999 01:20:09 -0000 Received: (from root@localhost) by dyson.iquest.net (8.9.1/8.9.1) id UAA27272; Mon, 18 Jan 1999 20:20:06 -0500 (EST) From: "John S. Dyson" Message-Id: <199901190120.UAA27272@dyson.iquest.net> Subject: Re: Found problem w/ Paging performance over NFS In-Reply-To: <199901190001.QAA82498@apollo.backplane.com> from Matthew Dillon at "Jan 18, 99 04:01:52 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Mon, 18 Jan 1999 20:20:06 -0500 (EST) Cc: dg@root.com, jkh@FreeBSD.ORG, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Here's another piece of code to check: > > in kern/vfs_bio.c, allocbuf() > > } else if (m->flags & PG_BUSY) { > s = splvm(); > if (m->flags & PG_BUSY) { > vm_page_flag_set(m, PG_WANTED); > tsleep(m, PVM, "pgtblk", 0); > } > splx(s); > goto doretry; > } else { > ... > if (tinc > (newbsize - toff)) > tinc = newbsize - toff; > if (bp->b_flags & B_CACHE) > vfs_buf_set_valid(bp, off, toff, tinc, m); > vm_page_flag_clear(m, PG_ZERO); > vm_page_wire(m); > } > > Shouldn't those conditionals be 'm->busy || (m->flags & PG_BUSY)' instead > of just testing against PG_BUSY? A pageout operation will set m->busy > without setting PG_BUSY. > The existing code is okay. Pageouts don't need to set PG_BUSY. Also, *generally* during buffer cache read write operations, the PG_BUSY flag doesn't need to be set during the *entire* operation. Think filesystems with block sizes < PAGE_SIZE as an example. PG_BUSY is quite severe, and not always needed. John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 17:28:48 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA17554 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 17:28:48 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA17525; Mon, 18 Jan 1999 17:28:43 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id RAA84794; Mon, 18 Jan 1999 17:28:35 -0800 (PST) (envelope-from dillon) Date: Mon, 18 Jan 1999 17:28:35 -0800 (PST) From: Matthew Dillon Message-Id: <199901190128.RAA84794@apollo.backplane.com> To: "John S. Dyson" Cc: dg@root.com, jkh@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Found problem w/ Paging performance over NFS References: <199901190120.UAA27272@dyson.iquest.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> :> in kern/vfs_bio.c, allocbuf() :> :> } else if (m->flags & PG_BUSY) { :> s = splvm(); :> if (m->flags & PG_BUSY) { :> vm_page_flag_set(m, PG_WANTED); :> tsleep(m, PVM, "pgtblk", 0); :> } :> splx(s); :> goto doretry; :> } else { :> ... :> if (tinc > (newbsize - toff)) :> tinc = newbsize - toff; :> if (bp->b_flags & B_CACHE) :> vfs_buf_set_valid(bp, off, toff, tinc, m); :> vm_page_flag_clear(m, PG_ZERO); :> vm_page_wire(m); :> } :> :> Shouldn't those conditionals be 'm->busy || (m->flags & PG_BUSY)' instead :> of just testing against PG_BUSY? A pageout operation will set m->busy :> without setting PG_BUSY. :> :The existing code is okay. Pageouts don't need to set PG_BUSY. Also, *generally* :during buffer cache read write operations, the PG_BUSY flag doesn't need to be set :during the *entire* operation. Think filesystems with block sizes < PAGE_SIZE :as an example. : :PG_BUSY is quite severe, and not always needed. : :John Ok. I just figured out the interaction -- in fact, we *can't* test m->busy in this section of code because of the following sequence: vm_fault -> vnode_pager_getpages -> ffs_getpages -> ffs_read -> cluster_read -> getblk -> allocbuf ( lockup ) ffs_getpages converts the PG_BUSY into a vm_page_t->busy before getting into the cluster stuff, and thus allocbuf() deep down cannot sleep on vm_page_t->busy. Ick. I'm going to add a comment explaining that case. -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 Jan 18 17:30:40 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA17919 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 17:30:40 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id RAA17882 for ; Mon, 18 Jan 1999 17:30:34 -0800 (PST) (envelope-from root@dyson.iquest.net) Received: (qmail 17769 invoked from network); 19 Jan 1999 01:30:26 -0000 Received: from dyson.iquest.net (198.70.144.127) by iquest3.iquest.net with SMTP; 19 Jan 1999 01:30:26 -0000 Received: (from root@localhost) by dyson.iquest.net (8.9.1/8.9.1) id UAA27297; Mon, 18 Jan 1999 20:30:22 -0500 (EST) From: "John S. Dyson" Message-Id: <199901190130.UAA27297@dyson.iquest.net> Subject: Re: Found problem w/ Paging performance over NFS In-Reply-To: <199901190128.RAA84794@apollo.backplane.com> from Matthew Dillon at "Jan 18, 99 05:28:35 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Mon, 18 Jan 1999 20:30:22 -0500 (EST) Cc: dg@root.com, jkh@FreeBSD.ORG, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > : > :PG_BUSY is quite severe, and not always needed. > : > :John > > Ok. I just figured out the interaction -- in fact, we *can't* test m->busy > in this section of code because of the following sequence: > > vm_fault -> vnode_pager_getpages -> ffs_getpages -> ffs_read -> > cluster_read -> getblk -> allocbuf ( lockup ) > > ffs_getpages converts the PG_BUSY into a vm_page_t->busy before getting into > the cluster stuff, and thus allocbuf() deep down cannot sleep on > vm_page_t->busy. > > Ick. I'm going to add a comment explaining that case. > Yep, it is *very* important to understand the interactions, or either clustering won't work on alot of filesystems or worse things will happen. John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 17:34:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA18291 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 17:34:53 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA18285 for ; Mon, 18 Jan 1999 17:34:51 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id RAA84965; Mon, 18 Jan 1999 17:34:46 -0800 (PST) (envelope-from dillon) Date: Mon, 18 Jan 1999 17:34:46 -0800 (PST) From: Matthew Dillon Message-Id: <199901190134.RAA84965@apollo.backplane.com> To: hackers@FreeBSD.ORG Subject: Anyone know how to put a gzip'd kernel on the floppy? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I can get the new multi-stage ELF loader thingy working with uncompressed kernels, but I can't get it to work with gzip'd kernels. I've tried stripping the symbols prior to gzip'ing ... no luck, the loader doesn't recognize the gzip'd kernel. Has anyone figured out how to do this? I need to fit a workstation kernel ( i.e. that is inclusive of sound drivers) onto a floppy and not having much luck. It would fit fine if I could compress it. -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 Jan 18 17:44:45 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA19525 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 17:44:45 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA19518 for ; Mon, 18 Jan 1999 17:44:42 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.2/8.9.2/Netplex) with ESMTP id JAA13063; Tue, 19 Jan 1999 09:44:24 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199901190144.JAA13063@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Matthew Dillon cc: hackers@FreeBSD.ORG Subject: Re: Anyone know how to put a gzip'd kernel on the floppy? In-reply-to: Your message of "Mon, 18 Jan 1999 17:34:46 PST." <199901190134.RAA84965@apollo.backplane.com> Date: Tue, 19 Jan 1999 09:44:23 +0800 From: Peter Wemm Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon wrote: > I can get the new multi-stage ELF loader thingy working with uncompressed > kernels, but I can't get it to work with gzip'd kernels. I've tried > stripping the symbols prior to gzip'ing ... no luck, the loader doesn't > recognize the gzip'd kernel. > > Has anyone figured out how to do this? I need to fit a workstation > kernel ( i.e. that is inclusive of sound drivers) onto a floppy and > not having much luck. It would fit fine if I could compress it. Just: gzip kernel; cp kernel.gz /floppy The key is that the file is called kernel.gz on the floppy, and you ask it to load "kernel" and not "kernel.gz". Cheers, -Peter -- Peter Wemm Netplex Consulting "No coffee, No workee!" :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 17:48:13 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA20012 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 17:48:13 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA20000 for ; Mon, 18 Jan 1999 17:48:09 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id RAA85079; Mon, 18 Jan 1999 17:47:49 -0800 (PST) (envelope-from dillon) Date: Mon, 18 Jan 1999 17:47:49 -0800 (PST) From: Matthew Dillon Message-Id: <199901190147.RAA85079@apollo.backplane.com> To: Peter Wemm Cc: hackers@FreeBSD.ORG Subject: Re: Anyone know how to put a gzip'd kernel on the floppy? References: <199901190144.JAA13063@spinner.netplex.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thanks Jordan, Peter! -Matt Matthew Dillon :> I can get the new multi-stage ELF loader thingy working with uncompressed :> kernels, but I can't get it to work with gzip'd kernels. I've tried :> stripping the symbols prior to gzip'ing ... no luck, the loader doesn't :> recognize the gzip'd kernel. :... :Just: gzip kernel; cp kernel.gz /floppy : :The key is that the file is called kernel.gz on the floppy, and you ask it :to load "kernel" and not "kernel.gz". : :Cheers, :-Peter :-- :Peter Wemm Netplex Consulting :"No coffee, No workee!" :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 18:36:29 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA26165 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 18:36:29 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles139.castles.com [208.214.165.139]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA26157 for ; Mon, 18 Jan 1999 18:36:27 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id SAA00675; Mon, 18 Jan 1999 18:33:04 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901190233.SAA00675@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Matthew Dillon cc: hackers@FreeBSD.ORG Subject: Re: Anyone know how to put a gzip'd kernel on the floppy? In-reply-to: Your message of "Mon, 18 Jan 1999 17:34:46 PST." <199901190134.RAA84965@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Jan 1999 18:33:04 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I can get the new multi-stage ELF loader thingy working with uncompressed > kernels, but I can't get it to work with gzip'd kernels. I've tried > stripping the symbols prior to gzip'ing ... no luck, the loader doesn't > recognize the gzip'd kernel. > > Has anyone figured out how to do this? I need to fit a workstation > kernel ( i.e. that is inclusive of sound drivers) onto a floppy and > not having much luck. It would fit fine if I could compress it. Take an ELF kernel. Gzip it, so you have 'kernel.gz'. Put it on your boot media. If you need to explicitly reference it, use eg. 'load kernel' (the .gz extension is searched automatically). -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 19:36:50 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA03638 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 19:36:50 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from net177138.hcv.com (net177138.hcv.com [209.153.177.138]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA03633 for ; Mon, 18 Jan 1999 19:36:49 -0800 (PST) (envelope-from matthew@wolfepub.com) Received: from thunder ([10.0.0.12]) by net177138.hcv.com (8.8.8/8.8.8) with SMTP id WAA29385 for ; Mon, 18 Jan 1999 22:32:39 -0500 (EST) (envelope-from matthew@wolfepub.com) Message-Id: <4.1.19990118220855.00a155a0@firebat.wolfepub.com> X-Sender: matthew@firebat.wolfepub.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 18 Jan 1999 22:38:04 -0500 To: hackers@FreeBSD.ORG From: Matthew Hagerty Subject: My BIOS wants to know "Do you have a PNP OS?" In-Reply-To: <199901190144.JAA13063@spinner.netplex.com.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greetings, What should the "PNP OS?" option in a BIOS be set to? What effect does this setting have on FreeBSD? I'm having trouble with the following system: I think it is an Intel board, but there are no markings, however it is in a Micronics case and looks and smells like an Intel board. Everything is built-in, i.e. on the board: Dual Processor LX chipset Adaptec SCSI (AIC-7880H) Intel Ethernet (10/100) (82555) Cirus Logic Video (GD5446) All hard disks are SCSI and one Sony CDU-701 IDE CDROM. When I set the PNP-OS option to "Yes", FreeBSD-3.0 (CDROM) cannot find the address of the Ethernet controller. However FreeBSD-2.2.8 (CDROM) can. When I switch the PNP-OS option to "No" then FreeBSD-3.0 finds the controller!? What is "really" going on? What should a setting like this "usually" be? Also (sorry, a little off topic), neither 2.2.8 nor 3.0 can detect the CDROM. The BIOS sets it up fine and I can even boot and start the install from the CD, but when I try to select CDROM from the Media menu it says there are no CDROMs available? Any hints? Does this look more like a CD problem or an IDE/Intel board problem? The detection pauses for a *very* long time for which ever controller the CD is conneted to. Thanks, Matthew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 19:49:09 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA04699 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 19:49:09 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smarter.than.nu (lal-99-91.Reshall.Berkeley.EDU [169.229.99.91]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA04693 for ; Mon, 18 Jan 1999 19:49:07 -0800 (PST) (envelope-from brian@CSUA.Berkeley.EDU) Received: from localhost (localhost [127.0.0.1]) by smarter.than.nu (8.9.1/8.9.1) with ESMTP id TAA05579; Mon, 18 Jan 1999 19:48:59 -0800 (PST) (envelope-from brian@CSUA.Berkeley.EDU) Date: Mon, 18 Jan 1999 19:48:58 -0800 (PST) From: "Brian W. Buchanan" X-Sender: brian@smarter.than.nu To: Matthew Hagerty cc: hackers@FreeBSD.ORG Subject: Re: My BIOS wants to know "Do you have a PNP OS?" In-Reply-To: <4.1.19990118220855.00a155a0@firebat.wolfepub.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 18 Jan 1999, Matthew Hagerty wrote: > What should the "PNP OS?" option in a BIOS be set to? What effect does > this setting have on FreeBSD? This should be set to "No". When set to yes, the BIOS will violate the PCI spec and not configure the PCI cards in your system. -- Brian Buchanan brian@CSUA.Berkeley.EDU -------------------------------------------------------------------------- FreeBSD - The Power to Serve! http://www.freebsd.org daemon(n): 1. an attendant power or spirit : GENIUS 2. the cute little mascot of the FreeBSD operating system To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 19:56:02 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA05122 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 19:54:56 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from net177138.hcv.com (net177138.hcv.com [209.153.177.138]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA05117 for ; Mon, 18 Jan 1999 19:54:52 -0800 (PST) (envelope-from matthew@wolfepub.com) Received: from thunder ([10.0.0.12]) by net177138.hcv.com (8.8.8/8.8.8) with SMTP id WAA29406 for ; Mon, 18 Jan 1999 22:50:43 -0500 (EST) (envelope-from matthew@wolfepub.com) Message-Id: <4.1.19990118225451.00938180@firebat.wolfepub.com> X-Sender: matthew@firebat.wolfepub.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 18 Jan 1999 22:56:08 -0500 To: hackers@FreeBSD.ORG From: Matthew Hagerty Subject: (more info) My BIOS wants to know "Do you have a PNP OS?" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greetings, I found the board on Intel's page: http://support.intel.com/support/motherboards/server/r440lx/ Hope this helps... Thanks again, Matthew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 19:59:17 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA05587 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 19:59:17 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles139.castles.com [208.214.165.139]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA05582 for ; Mon, 18 Jan 1999 19:59:16 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id TAA01143; Mon, 18 Jan 1999 19:54:37 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901190354.TAA01143@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: "Brian W. Buchanan" cc: Matthew Hagerty , hackers@FreeBSD.ORG Subject: Re: My BIOS wants to know "Do you have a PNP OS?" In-reply-to: Your message of "Mon, 18 Jan 1999 19:48:58 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Jan 1999 19:54:37 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Mon, 18 Jan 1999, Matthew Hagerty wrote: > > > What should the "PNP OS?" option in a BIOS be set to? What effect does > > this setting have on FreeBSD? > > This should be set to "No". When set to yes, the BIOS will violate the > PCI spec and not configure the PCI cards in your system. ^may Most will actually configure PCI cards; those that don't may configure just those that might form part of the boot path. More significantly, when set to "yes", ISA PnP cards will not be automatically configured. This is bad. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 20:52:05 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA13371 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 20:52:05 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA13357 for ; Mon, 18 Jan 1999 20:52:01 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id UAA11042; Mon, 18 Jan 1999 20:51:53 -0800 (PST) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma011040; Mon, 18 Jan 99 20:51:51 -0800 Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id UAA07575; Mon, 18 Jan 1999 20:51:51 -0800 (PST) From: Archie Cobbs Message-Id: <199901190451.UAA07575@bubba.whistle.com> Subject: Re: Loading KLD from the kernel In-Reply-To: from Doug Rabson at "Jan 18, 99 10:44:19 am" To: dfr@nlsystems.com (Doug Rabson) Date: Mon, 18 Jan 1999 20:51:51 -0800 (PST) Cc: freebsd-hackers@FreeBSD.ORG, julian@whistle.com (Julian Elischer) X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug Rabson writes: > > What's the correct way to request loading of a KLD module from within > > the kernel (but not from an interrupt handler). I see the kldload() > > syscall function.. should I just call it directly? > > > > Same question for unloading a KLD module... > > The right thing to do is to call linker_load_file() like this: > > linker_file_t lf; > int error = linker_load_file(filename, &lf); > if (error) > ...; Thanks!! That works great. Now I have another much more minor question.. when kldload() loads a module, it increments "lf->userrefs" .. I assume this field is for the "client" code to use (eg, kld syscalls or other kernel entity). If this field is zero, you can't unload the module from root shell: linkerunload: attempt to unload file which was not loaded by user I'm trying to understand the exact semantics of userrefs, and how we can allow root to unload a KLD from the shell that was loaded from the kernel (after checking that it's safe, of course)? I tried simply incrementing lf->userrefs after loading the module from the kernel, but somehow it went back to zero (?) Thanks, -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 Mon Jan 18 21:07:04 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA14763 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 21:07:04 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from oreo.adsu.bellsouth.com (oreo.adsu.bellsouth.com [205.152.173.36]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA14757 for ; Mon, 18 Jan 1999 21:07:00 -0800 (PST) (envelope-from ck@oreo.adsu.bellsouth.com) Received: (from ck@localhost) by oreo.adsu.bellsouth.com (8.9.1/8.9.1) id AAA07057 for hackers@freebsd.org; Tue, 19 Jan 1999 00:06:55 -0500 (EST) (envelope-from ck) Date: Tue, 19 Jan 1999 00:06:55 -0500 From: Christian Kuhtz To: hackers@FreeBSD.ORG Subject: protocol implementation Message-ID: <19990119000654.K5878@oreo.adsu.bellsouth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello: I am in the process of coding a new protocol stack and it is time to start mating the higher layers to media access layer. The question is: How is this done best in FreeBSD? The stack components are coded as klds. And I need to be able to create frames on the Ethernet (which is the primary media target, but not exclusively) and pick up frames. The system will run IP and well as this new stack in parallel. Can somebody shed some light on this? Thanks in advance, Chris -- "We are not bound by any concept, we are just bound to make any concept work better than others." -- Dr. Ferry Porsche [Disclaimer: I speak for myself and my views are my own and not in any way to be construed as the views of BellSouth Corporation. ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 22:17:26 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA22447 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 22:17:26 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA22442 for ; Mon, 18 Jan 1999 22:17:25 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id WAA18439; Mon, 18 Jan 1999 22:07:15 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdg18430; Tue Jan 19 06:07:13 1999 Date: Mon, 18 Jan 1999 22:07:09 -0800 (PST) From: Julian Elischer To: Christian Kuhtz cc: hackers@FreeBSD.ORG Subject: Re: protocol implementation In-Reply-To: <19990119000654.K5878@oreo.adsu.bellsouth.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 19 Jan 1999, Christian Kuhtz wrote: > > Hello: > > I am in the process of coding a new protocol stack and it is time to start > mating the higher layers to media access layer. > > The question is: How is this done best in FreeBSD? Each media-type driver needs to know how to detect that protocol. e,g for ethernet, the file if_ethersubr.c needs to be modified so that incoming packets of your protocol are recognised. The output routine there needs to know about your sockaddr type so that it can encode it witht eh right header before sending it. This is the only place where you need to actually edit code. The very existance of (your equivalent of) the following code will create the linkages needed fo rth ekernel to find your protocol stack from the socket end of things. (this is taken from some code here) Thisimplements a protocol family woth two different sub-protocols (e.g similar to udp and tcp as sub protocols of the ip family) /* * Control and data socket type descriptors */ static struct pr_usrreqs ngc_usrreqs = { NULL, /* abort */ pru_accept_notsupp, ngc_attach, ngc_bind, ngc_connect, pru_connect2_notsupp, pru_control_notsupp, ngc_detach, NULL, /* disconnect */ pru_listen_notsupp, NULL, /* setpeeraddr */ pru_rcvd_notsupp, pru_rcvoob_notsupp, ngc_send, pru_sense_null, NULL, /* shutdown */ ng_setsockaddr, sosend, soreceive, sopoll }; static struct pr_usrreqs ngd_usrreqs = { NULL, /* abort */ pru_accept_notsupp, ngd_attach, NULL, /* bind */ ngd_connect, pru_connect2_notsupp, pru_control_notsupp, ngd_detach, NULL, /* disconnect */ pru_listen_notsupp, NULL, /* setpeeraddr */ pru_rcvd_notsupp, pru_rcvoob_notsupp, ngd_send, pru_sense_null, NULL, /* shutdown */ ng_setsockaddr, sosend, soreceive, sopoll }; /* * Definitions of protocols supported in the NETGRAPH domain. */ extern struct domain ngdomain; /* stop compiler warnings */ static struct protosw ngsw[] = { { SOCK_DGRAM, &ngdomain, NG_CONTROL, PR_ATOMIC | PR_ADDR | PR_RIGHTS, 0, 0, 0, 0, NULL, 0, 0, 0, 0, &ngc_usrreqs }, { SOCK_DGRAM, &ngdomain, NG_DATA, PR_ATOMIC | PR_ADDR, 0, 0, 0, 0, NULL, 0, 0, 0, 0, &ngd_usrreqs } }; struct domain ngdomain = { AF_NETGRAPH, "netgraph", 0, NULL, NULL, ngsw, &ngsw[sizeof(ngsw) / sizeof(ngsw[0])], 0, NULL, 0, 0 }; DOMAIN_SET(ng); In addition you need to add code to link in your ISR code. Once again here is our version of that code.. alter to taste.. /* * Pick an item off the queue, process it, and dispose of the queue entry. * Should be running at splnet. */ static void ngintr(void) { hook_p hook; struct ng_queue_entry *ngq; struct mbuf *m; meta_p meta; void *retaddr; struct ng_mesg *msg; node_p node; int error = 0; int s; while (1) { s = splhigh(); if ((ngq = ngqbase)) { ngqbase = ngq->next; ngqsize--; } splx(s); if (ngq == NULL) return; switch (ngq->flags) { case NGQF_DATA: hook = ngq->body.data.da_hook; m = ngq->body.data.da_m; meta = ngq->body.data.da_meta; RETURN_QBLK(ngq); NG_SEND_DATA(error, hook, m, meta); ng_unref_hook(hook); break; case NGQF_MESG: node = ngq->body.msg.msg_node; msg = ngq->body.msg.msg_msg; retaddr = ngq->body.msg.msg_retaddr; RETURN_QBLK(ngq); if (node->flags & NG_INVALID) { FREE(msg, M_NETGRAPH); } else { CALL_MSG_HANDLER(error, node, msg, retaddr, NULL); } ng_unref(node); if (retaddr) FREE(retaddr, M_NETGRAPH); break; default: RETURN_QBLK(ngq); } } } NETISR_SET(NETISR_NG, ngintr); Once again.. the very inclusion of this code links itself in on linking. the trick is the NETISR_SET macro. This code uses our own queue, and is queuing structures wich point to the mbufs. You would but probably use a normal interface queue as you will see in if_ethersubr.c and ipintr() (ip_input.c from memory) instead, and queue the mbufs directly usinghte IF_QUEUE() macro. (and it's friends). (IF_DEQUEUE()) The code snippet for queing the packets is as follows.. this is run in the driver code, where the code above is in the protocol stack and recieves the packets. /* queue the data for packup by hte protocol stack */ s = splhigh(); if (ngqbase) { ngqlast->next = q; } else { ngqbase = q; } ngqlast = q; ngqsize++; splx(s); /* Schedule software interrupt to handle it later */ schednetisr(NETISR_NG); > > The stack components are coded as klds. And I need to be able to create > frames on the Ethernet (which is the primary media target, but not > exclusively) and pick up frames. The system will run IP and well as this > new stack in parallel. Unfortunatly, at this time you can't add a protocol entirely by KLD, as you still need to change in-line code in if_ethersubr.c that is being worked on, but may take a while to coome to light. julian > > Can somebody shed some light on this? > > Thanks in advance, > Chris > > -- > "We are not bound by any concept, we are just bound to make any concept work > better than others." -- Dr. Ferry Porsche > > [Disclaimer: I speak for myself and my views are my own and not in any way to > be construed as the views of BellSouth Corporation. ] > > 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 Jan 18 22:57:37 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA26288 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 22:57:37 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA26280 for ; Mon, 18 Jan 1999 22:57:35 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id WAA11998; Mon, 18 Jan 1999 22:56:56 -0800 (PST) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma011996; Mon, 18 Jan 99 22:56:29 -0800 Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id WAA09547; Mon, 18 Jan 1999 22:56:29 -0800 (PST) From: Archie Cobbs Message-Id: <199901190656.WAA09547@bubba.whistle.com> Subject: Re: Found problem w/ Paging performance over NFS In-Reply-To: <199901190128.RAA84794@apollo.backplane.com> from Matthew Dillon at "Jan 18, 99 05:28:35 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Mon, 18 Jan 1999 22:56:29 -0800 (PST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon writes: > Ok. I just figured out the interaction -- in fact, we *can't* test m->busy > in this section of code because of the following sequence: > > vm_fault -> vnode_pager_getpages -> ffs_getpages -> ffs_read -> > cluster_read -> getblk -> allocbuf ( lockup ) > > ffs_getpages converts the PG_BUSY into a vm_page_t->busy before getting into > the cluster stuff, and thus allocbuf() deep down cannot sleep on > vm_page_t->busy. > > Ick. I'm going to add a comment explaining that case. Yow. I don't think it's possible to overcomment the VM subsystem.. :-) -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 Mon Jan 18 23:09:59 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA27522 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 23:09:59 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA27517 for ; Mon, 18 Jan 1999 23:09:56 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id XAA90152; Mon, 18 Jan 1999 23:09:48 -0800 (PST) (envelope-from dillon) Date: Mon, 18 Jan 1999 23:09:48 -0800 (PST) From: Matthew Dillon Message-Id: <199901190709.XAA90152@apollo.backplane.com> To: Archie Cobbs Cc: hackers@FreeBSD.ORG Subject: Re: Found problem w/ Paging performance over NFS References: <199901190656.WAA09547@bubba.whistle.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Matthew Dillon writes: :> Ok. I just figured out the interaction -- in fact, we *can't* test m->busy :> in this section of code because of the following sequence: :> :> vm_fault -> vnode_pager_getpages -> ffs_getpages -> ffs_read -> :> cluster_read -> getblk -> allocbuf ( lockup ) :> :> ffs_getpages converts the PG_BUSY into a vm_page_t->busy before getting into :> the cluster stuff, and thus allocbuf() deep down cannot sleep on :> vm_page_t->busy. :> :... :Yow. I don't think it's possible to overcomment the VM subsystem.. :-) : :-Archie Heh. Believe you me, I'm commenting everything that takes me more then 5 minutes to puzzle out, and then some! This stuff is starting to look pretty good, I'll open the patchset up to anyone who is interested in testing it. You can pop it off my site. WARNING! Make backups of your original files or be prepared to re-check them out fresh from the cvs tree. This is highly experimental code. (for latest) http://www.backplane.com/FreeBSD/ (last snapshot, fresh at posting time) http://www.backplane.com/FreeBSD/dillon-swapper-A15.tgz http://www.backplane.com/FreeBSD/FreeBSDVMWork.html I've been testing the stuff on a 48MB diskless workstation. I've successfully run a -j14 buildworld and it's running a -j18 right now. If that works, I'll try a -j30 next. It's actually kinda hard to get it to grind on a 100BaseTX LAN with the NFS paging fixes in place :-) BTW, the patch set also includes Luoqi's NFS fix. -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 Jan 18 23:32:20 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA29077 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 23:32:20 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA29061 for ; Mon, 18 Jan 1999 23:32:15 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id XAA20455; Mon, 18 Jan 1999 23:30:42 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdc20447; Tue Jan 19 07:30:40 1999 Date: Mon, 18 Jan 1999 23:30:33 -0800 (PST) From: Julian Elischer To: Matthew Dillon cc: Archie Cobbs , hackers@FreeBSD.ORG Subject: Re: Found problem w/ Paging performance over NFS In-Reply-To: <199901190709.XAA90152@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 please commit luoqi's NFS fix.... On Mon, 18 Jan 1999, Matthew Dillon wrote: > > :Matthew Dillon writes: > :> Ok. I just figured out the interaction -- in fact, we *can't* test m->busy > :> in this section of code because of the following sequence: > :> > :> vm_fault -> vnode_pager_getpages -> ffs_getpages -> ffs_read -> > :> cluster_read -> getblk -> allocbuf ( lockup ) > :> > :> ffs_getpages converts the PG_BUSY into a vm_page_t->busy before getting into > :> the cluster stuff, and thus allocbuf() deep down cannot sleep on > :> vm_page_t->busy. > :> > :... > :Yow. I don't think it's possible to overcomment the VM subsystem.. :-) > : > :-Archie > > Heh. Believe you me, I'm commenting everything that takes me more then > 5 minutes to puzzle out, and then some! > > This stuff is starting to look pretty good, I'll open the patchset up > to anyone who is interested in testing it. You can pop it off my site. > > WARNING! Make backups of your original files or be prepared to re-check > them out fresh from the cvs tree. This is highly experimental code. > > (for latest) > > http://www.backplane.com/FreeBSD/ > > (last snapshot, fresh at posting time) > > http://www.backplane.com/FreeBSD/dillon-swapper-A15.tgz > http://www.backplane.com/FreeBSD/FreeBSDVMWork.html > > I've been testing the stuff on a 48MB diskless workstation. I've > successfully run a -j14 buildworld and it's running a -j18 right now. > If that works, I'll try a -j30 next. It's actually kinda hard to get > it to grind on a 100BaseTX LAN with the NFS paging fixes in place :-) > > BTW, the patch set also includes Luoqi's NFS fix. > > -Matt > > Matthew Dillon > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 23:32:37 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA29115 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 23:32:37 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id XAA29104 for ; Mon, 18 Jan 1999 23:32:32 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 102VeD-00014v-00; Tue, 19 Jan 1999 00:32:25 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id AAA55482; Tue, 19 Jan 1999 00:32:09 -0700 (MST) Message-Id: <199901190732.AAA55482@harmony.village.org> To: Mike Smith Subject: Re: My BIOS wants to know "Do you have a PNP OS?" Cc: hackers@FreeBSD.ORG In-reply-to: Your message of "Mon, 18 Jan 1999 19:54:37 PST." <199901190354.TAA01143@dingo.cdrom.com> References: <199901190354.TAA01143@dingo.cdrom.com> Date: Tue, 19 Jan 1999 00:32:08 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199901190354.TAA01143@dingo.cdrom.com> Mike Smith writes: : More significantly, when set to "yes", ISA PnP cards will not be : automatically configured. This is bad. Unless they are supported as plug and play cards by FreeBSD, no? In which case it is good, since many plug and pray cards don't have good "default" configurations. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 23:39:14 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA29870 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 23:39:14 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from korin.warman.org.pl (korin.nask.waw.pl [195.187.243.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA29850 for ; Mon, 18 Jan 1999 23:39:09 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id IAA28145; Tue, 19 Jan 1999 08:43:31 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Tue, 19 Jan 1999 08:43:31 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: Peter Wemm cc: Matthew Dillon , hackers@FreeBSD.ORG Subject: Re: Anyone know how to put a gzip'd kernel on the floppy? In-Reply-To: <199901190144.JAA13063@spinner.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 19 Jan 1999, Peter Wemm wrote: > Matthew Dillon wrote: > > I can get the new multi-stage ELF loader thingy working with uncompressed > > kernels, but I can't get it to work with gzip'd kernels. I've tried > > stripping the symbols prior to gzip'ing ... no luck, the loader doesn't > > recognize the gzip'd kernel. > > > > Has anyone figured out how to do this? I need to fit a workstation > > kernel ( i.e. that is inclusive of sound drivers) onto a floppy and > > not having much luck. It would fit fine if I could compress it. > > Just: gzip kernel; cp kernel.gz /floppy > > The key is that the file is called kernel.gz on the floppy, and you ask it > to load "kernel" and not "kernel.gz". If you're really tight on space, you may also consider using kzip on /boot/loader - you get ca. 50kB more then. Andrzej Bialecki -------------------- ++-------++ ------------------------------------- ||PicoBSD|| FreeBSD in your pocket? Go and see: Research & Academic |+-------+| "Small & Embedded FreeBSD" Network in Poland | |TT~~~| | http://www.freebsd.org/~picobsd/ -------------------- ~-+==---+-+ ------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Mon Jan 18 23:56:34 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA01129 for freebsd-hackers-outgoing; Mon, 18 Jan 1999 23:56:34 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA01124 for ; Mon, 18 Jan 1999 23:56:32 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id XAA90420; Mon, 18 Jan 1999 23:56:22 -0800 (PST) (envelope-from dillon) Date: Mon, 18 Jan 1999 23:56:22 -0800 (PST) From: Matthew Dillon Message-Id: <199901190756.XAA90420@apollo.backplane.com> To: Julian Elischer Cc: Archie Cobbs , hackers@FreeBSD.ORG Subject: Re: Found problem w/ Paging performance over NFS References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :please commit luoqi's NFS fix.... : Oh, sorry... I thought Luoqi was going to do it. I'll commit it right now. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 01:00:38 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA06421 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 01:00:38 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles139.castles.com [208.214.165.139]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA06414 for ; Tue, 19 Jan 1999 01:00:36 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id AAA02686; Tue, 19 Jan 1999 00:57:03 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901190857.AAA02686@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Warner Losh cc: Mike Smith , hackers@FreeBSD.ORG Subject: Re: My BIOS wants to know "Do you have a PNP OS?" In-reply-to: Your message of "Tue, 19 Jan 1999 00:32:08 MST." <199901190732.AAA55482@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Jan 1999 00:57:03 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > In message <199901190354.TAA01143@dingo.cdrom.com> Mike Smith writes: > : More significantly, when set to "yes", ISA PnP cards will not be > : automatically configured. This is bad. > > Unless they are supported as plug and play cards by FreeBSD, no? No. You need "pnp os enable" in userconfig to have the FreeBSD PnP code assign resources for the card, and that's extremely bad because it doesn't have any real knowledge of what resources are available. > In > which case it is good, since many plug and pray cards don't have good > "default" configurations. Acutally, since the BIOS is respnsible for making resource assignments for the cards, and since the BIOS is the only thing that has any real idea as to where it's safe to assign a card, letting the BIOS do the work is almost always best (modulo BIOS bugs). -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 01:02:13 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA06781 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 01:02:13 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles139.castles.com [208.214.165.139]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA06774 for ; Tue, 19 Jan 1999 01:02:11 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id AAA02702; Tue, 19 Jan 1999 00:58:22 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901190858.AAA02702@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Andrzej Bialecki cc: Peter Wemm , Matthew Dillon , hackers@FreeBSD.ORG Subject: Re: Anyone know how to put a gzip'd kernel on the floppy? In-reply-to: Your message of "Tue, 19 Jan 1999 08:43:31 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Jan 1999 00:58:22 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > > The key is that the file is called kernel.gz on the floppy, and you ask it > > to load "kernel" and not "kernel.gz". > > If you're really tight on space, you may also consider using kzip on > /boot/loader - you get ca. 50kB more then. I had enabled this, but it breaks the aout-elf upgrade because the bootblocks are built before the new kzip is, and the old one calls 'ld' incorrectly. I don't know that it should qualify as a build-tool? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 02:27:41 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA16617 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 02:27:41 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from korin.warman.org.pl (korin.nask.waw.pl [195.187.243.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA16609 for ; Tue, 19 Jan 1999 02:27:37 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id LAA19115; Tue, 19 Jan 1999 11:30:59 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Tue, 19 Jan 1999 11:30:59 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: Mike Smith cc: Peter Wemm , Matthew Dillon , hackers@FreeBSD.ORG Subject: Re: Anyone know how to put a gzip'd kernel on the floppy? In-Reply-To: <199901190858.AAA02702@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 19 Jan 1999, Mike Smith wrote: > > > > > > The key is that the file is called kernel.gz on the floppy, and you ask it > > > to load "kernel" and not "kernel.gz". > > > > If you're really tight on space, you may also consider using kzip on > > /boot/loader - you get ca. 50kB more then. > > I had enabled this, but it breaks the aout-elf upgrade because the > bootblocks are built before the new kzip is, and the old one calls > 'ld' incorrectly. I don't know that it should qualify as a build-tool? Well, IMHO for future releases probably yes - it's good to save space where you can, especially on the boot floppies. If Jordan can still fit the contents of the floppies for 3.1-R without it, then let's wait with this for the 4.0 - there are plans to merge floppy building code with picobsd anyway. Andrzej Bialecki -------------------- ++-------++ ------------------------------------- ||PicoBSD|| FreeBSD in your pocket? Go and see: Research & Academic |+-------+| "Small & Embedded FreeBSD" Network in Poland | |TT~~~| | http://www.freebsd.org/~picobsd/ -------------------- ~-+==---+-+ ------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 02:42:28 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA18378 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 02:42:28 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA18342 for ; Tue, 19 Jan 1999 02:42:23 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by nlsystems.com (8.9.1/8.8.5) with SMTP id JAA46023; Tue, 19 Jan 1999 09:21:19 GMT Date: Tue, 19 Jan 1999 09:21:18 +0000 (GMT) From: Doug Rabson To: Archie Cobbs cc: freebsd-hackers@FreeBSD.ORG, Julian Elischer Subject: Re: Loading KLD from the kernel In-Reply-To: <199901190451.UAA07575@bubba.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 18 Jan 1999, Archie Cobbs wrote: > Doug Rabson writes: > > > What's the correct way to request loading of a KLD module from within > > > the kernel (but not from an interrupt handler). I see the kldload() > > > syscall function.. should I just call it directly? > > > > > > Same question for unloading a KLD module... > > > > The right thing to do is to call linker_load_file() like this: > > > > linker_file_t lf; > > int error = linker_load_file(filename, &lf); > > if (error) > > ...; > > Thanks!! That works great. > > Now I have another much more minor question.. when kldload() loads > a module, it increments "lf->userrefs" .. I assume this field is > for the "client" code to use (eg, kld syscalls or other kernel > entity). > > If this field is zero, you can't unload the module from root shell: > > linkerunload: attempt to unload file which was not loaded by user > > I'm trying to understand the exact semantics of userrefs, and how > we can allow root to unload a KLD from the shell that was loaded > from the kernel (after checking that it's safe, of course)? > > I tried simply incrementing lf->userrefs after loading the module > from the kernel, but somehow it went back to zero (?) This field is a count of how many times a user has loaded the file using kldload(2). It is there to prevent a user from unloading a file which was loaded explicitly by the kernel (e.g. as a dependancy). Incrementing userrefs should have worked though - can you watch what happens in the debugger and find out why it is being reset? The extra error checks added recently to kldload(2) seem to have broken the user refcount anyway. The intention is that if the file is already present, kldload(2) will simply increment the refcounts. That way two unrelated user programs can kldload/kldunload the same file without stepping on each other's toes. I think instead of returning EEXIST, it should increment the refcounts and return the file id. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 02:43:35 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA18544 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 02:43:35 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA18537 for ; Tue, 19 Jan 1999 02:43:31 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id TAA23233; Tue, 19 Jan 1999 19:41:16 +0900 (JST) Message-ID: <36A45AF2.98F1ED88@newsguy.com> Date: Tue, 19 Jan 1999 19:14:10 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Mike Smith CC: Andrzej Bialecki , Peter Wemm , Matthew Dillon , hackers@FreeBSD.ORG Subject: Re: Anyone know how to put a gzip'd kernel on the floppy? References: <199901190858.AAA02702@dingo.cdrom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith wrote: > > > If you're really tight on space, you may also consider using kzip on > > /boot/loader - you get ca. 50kB more then. > > I had enabled this, but it breaks the aout-elf upgrade because the > bootblocks are built before the new kzip is, and the old one calls > 'ld' incorrectly. I don't know that it should qualify as a build-tool? Ok, let me show my complete ignorance about the make world process. Why don't you kzip at install time instead of build time? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com If you sell your soul to the Devil and all you get is an MCSE from it, you haven't gotten market rate. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 04:14:41 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA29589 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 04:14:41 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ics.com (ics.com [140.186.40.192]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA29581 for ; Tue, 19 Jan 1999 04:14:40 -0800 (PST) (envelope-from kaleb@ics.com) Received: from kaleb.keithley.belmont.ma.us (ics.com [140.186.40.192]) by ics.com (8.9.0.Beta5/8.9.0.Beta5) with SMTP id HAA22925 Tue, 19 Jan 1999 07:14:33 -0500 (EST) Message-ID: <36A48B58.41C67EA6@ics.com> Date: Tue, 19 Jan 1999 08:40:40 -0500 From: "Kaleb S. KEITHLEY" Organization: Integrated Computer Solutions X-Mailer: Mozilla 3.04Gold (X11; I; FreeBSD 3.0-RELEASE i386) MIME-Version: 1.0 To: hackers@FreeBSD.ORG Subject: How the other half lives References: <36A3EE7B.B9AA4E9A@lydon.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > http://www.sysinternals.com/nt5src.htm > -- Kaleb To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 04:33:27 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA01060 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 04:33:27 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA01055 for ; Tue, 19 Jan 1999 04:33:24 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id XAA03291; Tue, 19 Jan 1999 23:03:16 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.2/8.9.0) id XAA07059; Tue, 19 Jan 1999 23:03:15 +1030 (CST) Date: Tue, 19 Jan 1999 23:03:14 +1030 From: Greg Lehey To: "Kaleb S. KEITHLEY" Cc: hackers@FreeBSD.ORG Subject: Re: How the other half lives Message-ID: <19990119230314.H4646@freebie.lemis.com> References: <36A3EE7B.B9AA4E9A@lydon.com> <36A48B58.41C67EA6@ics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <36A48B58.41C67EA6@ics.com>; from Kaleb S. KEITHLEY on Tue, Jan 19, 1999 at 08:40:40AM -0500 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tuesday, 19 January 1999 at 8:40:40 -0500, Kaleb S. KEITHLEY wrote: >> >> http://www.sysinternals.com/nt5src.htm The links to the .c files don't work right. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 07:16:39 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA14916 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 07:16:39 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from qix (hibou.obs-besancon.fr [193.52.184.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA14887 for ; Tue, 19 Jan 1999 07:16:32 -0800 (PST) (envelope-from jmz@FreeBSD.ORG) Received: (from jmz@localhost) by qix (8.9.2/8.8.7) id QAA10060; Tue, 19 Jan 1999 16:18:40 +0100 (MET) Date: Tue, 19 Jan 1999 16:18:40 +0100 (MET) Message-Id: <199901191518.QAA10060@qix> X-Authentication-Warning: qix: jmz set sender to jmz@qix using -f From: Jean-Marc Zucconi To: mike@smith.net.au CC: brian@CSUA.Berkeley.EDU, matthew@wolfepub.com, hackers@FreeBSD.ORG In-reply-to: <199901190354.TAA01143@dingo.cdrom.com> (message from Mike Smith on Mon, 18 Jan 1999 19:54:37 -0800) Subject: Re: My BIOS wants to know "Do you have a PNP OS?" X-Mailer: Emacs Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> Mike Smith writes: >> On Mon, 18 Jan 1999, Matthew Hagerty wrote: >> >> > What should the "PNP OS?" option in a BIOS be set to? What effect does >> > this setting have on FreeBSD? >> >> This should be set to "No". When set to yes, the BIOS will violate the >> PCI spec and not configure the PCI cards in your system. > ^may > Most will actually configure PCI cards; those that don't may configure > just those that might form part of the boot path. > More significantly, when set to "yes", ISA PnP cards will not be > automatically configured. This is bad. This is not my experience. My 3C509B won't work when the PnP option is set to NO. Jean-Marc -- Jean-Marc Zucconi PGP Key: finger jmz@FreeBSD.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 08:37:08 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA06384 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 08:37:08 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles238.castles.com [208.214.165.238]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA06377; Tue, 19 Jan 1999 08:37:06 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id IAA05229; Tue, 19 Jan 1999 08:33:41 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901191633.IAA05229@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Jean-Marc Zucconi cc: mike@smith.net.au, brian@CSUA.Berkeley.EDU, matthew@wolfepub.com, hackers@FreeBSD.ORG Subject: Re: My BIOS wants to know "Do you have a PNP OS?" In-reply-to: Your message of "Tue, 19 Jan 1999 16:18:40 +0100." <199901191518.QAA10060@qix> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Jan 1999 08:33:38 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >>>>> Mike Smith writes: > > >> On Mon, 18 Jan 1999, Matthew Hagerty wrote: > >> > >> > What should the "PNP OS?" option in a BIOS be set to? What effect does > >> > this setting have on FreeBSD? > >> > >> This should be set to "No". When set to yes, the BIOS will violate the > >> PCI spec and not configure the PCI cards in your system. > > ^may > > > Most will actually configure PCI cards; those that don't may configure > > just those that might form part of the boot path. > > > More significantly, when set to "yes", ISA PnP cards will not be > > automatically configured. This is bad. > > This is not my experience. My 3C509B won't work when the PnP option is > set to NO. Is that "509B" or "905B"? The '509 is not a PnP card, and if it's failing with "PnP OS" set to "NO", I can only guess that some part of the ISA PNP process is tying it in knots. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 08:48:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA07837 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 08:48:16 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.cyberzone.net (mail.cyberzone.net [209.150.2.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA07826 for ; Tue, 19 Jan 1999 08:48:15 -0800 (PST) (envelope-from seth@pengar.com) Received: from [192.168.0.2] (cz-cblk-150-9-130.cyberzone.net [209.150.9.130]) by mail.cyberzone.net (Post.Office MTA v3.5.3 release 222 ID# 553-55039U3600L350S0V35) with ESMTP id net; Tue, 19 Jan 1999 11:28:06 -0500 X-Sender: seth-pc@hobbiton.shire.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Jan 1999 11:47:57 -0700 To: freebsd-hackers@FreeBSD.ORG From: Seth Leigh Subject: Not so sinister. Was:(Re: Attempt to relicense BSD code under the GPL) Cc: lepreau@cs.utah.edu Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hey, guys, let's simmer down a little. I just talked to Jay Lepreau over email about this. He is the guy whom Brett Glass mentioned should be emailed about this. Apparently there has been a misunderstanding. In fact, Jay just emailed me saying that he had reread his license page, and now understands where we are coming from. He said he will add some info to clarify this to the license page. Only the stuff that THEY have done (THEY = the U of Utah CS folks whose project web page we are talking about) is under the GPL. They are not attempting to relicense stuff they have used from other, BSD-licensed sources. The original licenses for those individual components still apply. However, Jay told me that as their project is a whole source code framework, and the code that they have written themselves is GPLed, then someone will have a hard time using their whole framework without the final work being under GPL. If you wanted to write a project that only included those components the Utah guys are using that are under BSD license, for example, you could do it and not be GPL, but what would be the point, as you could get those BSD-licensed components from other sources. It's only if you want to use their whole framework that you get stuck with the GPL. Since this framework is their own project, they have the right to impose whatever license they choose for it. This isn't to say I agree with them using the GPL. I am no expert on the subject, but I will frankly admit that the whole GPL thing leaves an uneasy feeling in my stomach. I am a programmer, I have a pretty decent standard of living, and I think that probably all or most of the companies I have worked for could not have paid me the money I have earned if their products were all bound by the GPL. However, this whole controversy of "Attempt to relicense BSD code under the GPL" is nothing but a big misunderstanding. Which leads me to my last point. When I emailed Jay Lepreau, I tried to come across as wanting an answer, but not to attack him, flame him, or anything else. He replied that mine was one of the few polite emails on this subject, implying that he had received a lot more total flame letters. That's shameful, and I hope that none on this list were involved. The last thing FreeBSD needs is a bunch of people thinking we are nothing but a bunch of asshole zealots. Please, there are enough asshole zealots out there, let's not let the whole world think FreeBSD fans are among them. Plus, now that the truth about this "controversy" is known, don't you feel just a little bit foolish for the flame emails ? Seth Leigh To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 09:23:06 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA13163 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 09:23:06 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA13155; Tue, 19 Jan 1999 09:23:04 -0800 (PST) (envelope-from thorpej@lestat.nas.nasa.gov) Received: from lestat (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.8.8/8.6.12) with ESMTP id JAA21557; Tue, 19 Jan 1999 09:22:43 -0800 (PST) Message-Id: <199901191722.JAA21557@lestat.nas.nasa.gov> To: Mike Smith Cc: Jean-Marc Zucconi , brian@CSUA.Berkeley.EDU, matthew@wolfepub.com, hackers@FreeBSD.ORG Subject: Re: My BIOS wants to know "Do you have a PNP OS?" Reply-To: Jason Thorpe From: Jason Thorpe Date: Tue, 19 Jan 1999 09:22:43 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 19 Jan 1999 08:33:38 -0800 Mike Smith wrote: > Is that "509B" or "905B"? The '509 is not a PnP card, and if it's > failing with "PnP OS" set to "NO", I can only guess that some part of > the ISA PNP process is tying it in knots. Yes, the _509B_ has a PnP mode. That is why NetBSD has an if_ep_isapnp.c -- Jason R. Thorpe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 09:30:55 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA14081 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 09:30:55 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from shale.csir.co.za (shale.csir.co.za [146.64.46.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA14073 for ; Tue, 19 Jan 1999 09:30:51 -0800 (PST) (envelope-from reg@shale.csir.co.za) Received: (from reg@localhost) by shale.csir.co.za (8.9.2/8.9.2) id TAA58041; Tue, 19 Jan 1999 19:29:36 +0200 (SAT) (envelope-from reg) Date: Tue, 19 Jan 1999 19:29:36 +0200 From: Jeremy Lea To: Seth Leigh Cc: freebsd-hackers@FreeBSD.ORG, lepreau@cs.utah.edu Subject: Re: Not so sinister. Was:(Re: Attempt to relicense BSD code under the GPL) Message-ID: <19990119192936.D826@shale.csir.co.za> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Seth Leigh on Tue, Jan 19, 1999 at 11:47:57AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, On Tue, Jan 19, 1999 at 11:47:57AM -0700, Seth Leigh wrote: > Apparently there has been a misunderstanding. In fact, Jay just emailed me > saying that he had reread his license page, and now understands where we > are coming from. He said he will add some info to clarify this to the > license page. Only the stuff that THEY have done (THEY = the U of Utah CS > folks whose project web page we are talking about) is under the GPL. They > are not attempting to relicense stuff they have used from other, > BSD-licensed sources. The original licenses for those individual > components still apply. [...] > However, this whole controversy of "Attempt to relicense BSD code under the > GPL" is nothing but a big misunderstanding. But you missed the point of the complaint. The GPL will not allow them to do this. If they want to use the GPL for their own code, then it forces them to use the GPL for their entire code base (whatever they are linking and packaging). They've misunderstood the terms of the GPL. To quote (from /usr/src/contrib/gcc/COPYING): " 2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License." Read that last clause carefully. Regards, -Jeremy -- | If I was not so weak, if I was not so cold, --+-- If I was not so scared of being broken, growing old, | I would be. I would be... frail. | - jars of clay / much afraid / frail To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 10:01:36 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA17265 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 10:01:36 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from rah.star-gate.com (sj-dsl-9-129-138.dspeed.net [209.249.129.138]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA17260 for ; Tue, 19 Jan 1999 10:01:35 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.9.1/8.8.8) with ESMTP id KAA34258; Tue, 19 Jan 1999 10:00:32 -0800 (PST) (envelope-from hasty@rah.star-gate.com) Message-Id: <199901191800.KAA34258@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Greg Lehey cc: "Kaleb S. KEITHLEY" , hackers@FreeBSD.ORG Subject: Re: How the other half lives In-reply-to: Your message of "Tue, 19 Jan 1999 23:03:14 +1030." <19990119230314.H4646@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Jan 1999 10:00:32 -0800 From: Amancio Hasty Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On Tuesday, 19 January 1999 at 8:40:40 -0500, Kaleb S. KEITHLEY wrote: > >> > >> http://www.sysinternals.com/nt5src.htm > > The links to the .c files don't work right. > > Greg Thats right the links to the .c files don't work and does the page have links to the makefiles and .h files 8) Cheers, Amancio To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 10:05:20 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA17660 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 10:05:20 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA17646 for ; Tue, 19 Jan 1999 10:05:18 -0800 (PST) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id LAA24865; Tue, 19 Jan 1999 11:05:12 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp03.primenet.com, id smtpd024715; Tue Jan 19 11:05:04 1999 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id LAA17691; Tue, 19 Jan 1999 11:04:53 -0700 (MST) From: Terry Lambert Message-Id: <199901191804.LAA17691@usr04.primenet.com> Subject: Re: Loading KLD from the kernel To: dfr@nlsystems.com (Doug Rabson) Date: Tue, 19 Jan 1999 18:04:52 +0000 (GMT) Cc: archie@whistle.com, freebsd-hackers@FreeBSD.ORG, julian@whistle.com In-Reply-To: from "Doug Rabson" at Jan 19, 99 09:21:18 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I tried simply incrementing lf->userrefs after loading the module > > from the kernel, but somehow it went back to zero (?) > > This field is a count of how many times a user has loaded the file using > kldload(2). It is there to prevent a user from unloading a file which was > loaded explicitly by the kernel (e.g. as a dependancy). Incrementing > userrefs should have worked though - can you watch what happens in the > debugger and find out why it is being reset? Shouldn't a kernel load as a dependency also cause a reference count increment? I think the problem is that dependency vs. explicit loads are not seperate in the idea of loading from kernel space. Archie: look closely at the kldload to see what it does differently, since what you are doing is an explicit load from kernel space, which differs from a dependency based load. I think you need to add dependency references, as well, to account for hooks between particular nodes (i.e., the thing need to be a real reference count, not a load count). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 10:15:04 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA18949 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 10:15:04 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bingsun2.cc.binghamton.edu (bingsun2.cc.binghamton.edu [128.226.1.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA18935 for ; Tue, 19 Jan 1999 10:15:02 -0800 (PST) (envelope-from bf20761@binghamton.edu) Received: from localhost (bf20761@localhost) by bingsun2.cc.binghamton.edu (8.8.7/8.6.9) with SMTP id NAA11509; Tue, 19 Jan 1999 13:14:46 -0500 (EST) Date: Tue, 19 Jan 1999 13:14:45 -0500 (EST) From: zhihuizhang X-Sender: bf20761@bingsun2 To: Sabrina Minshall cc: hackers Subject: Re: stack info In-Reply-To: <199901190433.UAA13330@shell.accesscom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 18 Jan 1999, Sabrina Minshall wrote: > Hi Zhihui, > > Since you're hot off this topic, I have a question. > > 1. When a process enters kernel mode (via system call) what > stack is used (in the top half)? is it a common stack to all > processes or is it per process? Where is it located? I have not read that part of the source code. As I understand it, the stack you use when you enter into kernel mode is the kernel stack. It is a per-process resource. It should be at the top of the u-area. In FreeBSD, I think the size of the u-area is two pages. > > 2. When the kernel is executing in the botton half, what stack is used? > is it kstack, or tmpstk? kstack is the kernel stack. tmpstk is used when the CPU is idle (see swtch.s). I am not sure what stack is used when an interrupt happens (the kernel is executing in the bottom half). However, since the interrupt handler does not have a process context, it should not use kstack. Maybe there is a third stack reserved for it or it could use tmpstk? > > 3. Does the kernel have multiple stacks for in the bottom half? Like > interrupt stack, etc? > I am not sure about this. See above. Zhihui Zhang ------------ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 10:29:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA20196 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 10:29:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA20190 for ; Tue, 19 Jan 1999 10:29:27 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.1/8.9.1) id TAA35677; Tue, 19 Jan 1999 19:28:58 +0100 (CET) (envelope-from des) To: Wes Peters Cc: Steve Kargl , Matthew Dillon , dervish@bantu.cl.msu.edu, hackers@FreeBSD.ORG Subject: Re: What are the advantages of ELF kernels? References: <199901112152.NAA25190@troutmask.apl.washington.edu> <369A9070.F9DCC718@softweyr.com> From: Dag-Erling Smorgrav Date: 19 Jan 1999 19:28:56 +0100 In-Reply-To: Wes Peters's message of "Mon, 11 Jan 1999 16:59:44 -0700" Message-ID: Lines: 10 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Peters writes: > Being able to keep up with other developments in the world of development > tools, not becoming a backwater, is an important point. This will allow > FreeBSD to be a first-class Ada development system, using GNATS. ;^) Oops - GNATS is a problem report database. Gnat is an Ada compiler. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 10:48:00 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA22133 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 10:48:00 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA22124 for ; Tue, 19 Jan 1999 10:47:59 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id KAA05898; Tue, 19 Jan 1999 10:38:31 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdVY5884; Tue Jan 19 18:38:24 1999 Message-ID: <36A4D118.1CFBAE39@whistle.com> Date: Tue, 19 Jan 1999 10:38:16 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2.7-RELEASE i386) MIME-Version: 1.0 To: zhihuizhang CC: Sabrina Minshall , hackers Subject: Re: stack info References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG zhihuizhang wrote: > > On Mon, 18 Jan 1999, Sabrina Minshall wrote: > > > Hi Zhihui, > > > > Since you're hot off this topic, I have a question. > > > > 1. When a process enters kernel mode (via system call) what > > stack is used (in the top half)? is it a common stack to all > > processes or is it per process? Where is it located? > > I have not read that part of the source code. As I understand it, the > stack you use when you enter into kernel mode is the kernel stack. It is > a per-process resource. It should be at the top of the u-area. In > FreeBSD, I think the size of the u-area is two pages. under -current the kernel stack for each process is a separate KV area. this is because SMP requires that two processes running at the same time ahve DIFFERENT addresses for their stacks. (also needed for threads (processes with shared address spaces)) > > > > > 2. When the kernel is executing in the botton half, what stack is used? > > is it kstack, or tmpstk? > > kstack is the kernel stack. tmpstk is used when the CPU is idle (see > swtch.s). I am not sure what stack is used when an interrupt happens > (the kernel is executing in the bottom half). However, since the > interrupt handler does not have a process context, it should not use > kstack. Maybe there is a third stack reserved for it or it could use > tmpstk? At this time the bottom half runs in the kernel stack of whatever process was running at that time. In -current a separate interrupt stack was under consideration but I haven't seen it done yet. > > > > > 3. Does the kernel have multiple stacks for in the bottom half? Like > > interrupt stack, etc? > > > I am not sure about this. See above. > > Zhihui Zhang > ------------ > > 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 Jan 19 10:58:13 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA23170 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 10:58:13 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from obie.softweyr.com ([204.68.178.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA23161 for ; Tue, 19 Jan 1999 10:58:09 -0800 (PST) (envelope-from wes@obie.softweyr.com) Received: (from wes@localhost) by obie.softweyr.com (8.8.8/8.8.8) id LAA09022; Tue, 19 Jan 1999 11:56:18 -0700 (MST) (envelope-from wes) From: Wes Peters Message-Id: <199901191856.LAA09022@obie.softweyr.com> Subject: Re: Not so sinister. In-Reply-To: <19990119192936.D826@shale.csir.co.za> from Jeremy Lea at "Jan 19, 99 07:29:36 pm" To: reg@shale.csir.co.za (Jeremy Lea) Date: Tue, 19 Jan 1999 11:56:17 -0700 (MST) Cc: seth@pengar.com, freebsd-hackers@FreeBSD.ORG, lepreau@cs.utah.edu X-Mailer: ELM [version 2.4ME+ PL40 (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 Jeremy Lea is alleged to have said: > > But you missed the point of the complaint. The GPL will not allow them to > do this. If they want to use the GPL for their own code, then it forces > them to use the GPL for their entire code base (whatever they are linking > and packaging). They've misunderstood the terms of the GPL. > > To quote (from /usr/src/contrib/gcc/COPYING): > " 2. You may modify your copy or copies of the Program or any portion > of it, thus forming a work based on the Program, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) You must cause the modified files to carry prominent notices > stating that you changed the files and the date of any change. > > b) You must cause any work that you distribute or publish, that in > whole or in part contains or is derived from the Program or any > part thereof, to be licensed as a whole at no charge to all third > parties under the terms of this License." > > Read that last clause carefully. I have. The BSD sources being distributed by Mr. Lepreau do not "contain" the U of U extensions, nor are they "derived from" the U of U extensions. The two may be comined to create an "aggregate work", which does not conflict with the above licensing clause. This has been a standard interpretation of the GPL for years. Mr. Lepreau is well within his rights in both the Berkeley license and GPL to distribute the code in this manner. In fact, the Berkeley license places NO restrictions on redistribution, other than the requirement for proper attribution; creating an entire distribution of BSD code under the GPL would be allowable. That said, I would still encourage Mr. Lepreau to reconsider his use of the GPL virus; a Berkeley-style license is much more open and free, and better encourages the use of the code. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC wes@softweyr.com http://www.softweyr.com/~softweyr/ +1.801.915.2061 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 11:04:07 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA23987 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 11:04:07 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from obie.softweyr.com ([204.68.178.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA23979 for ; Tue, 19 Jan 1999 11:04:05 -0800 (PST) (envelope-from wes@obie.softweyr.com) Received: (from wes@localhost) by obie.softweyr.com (8.8.8/8.8.8) id MAA09041; Tue, 19 Jan 1999 12:03:37 -0700 (MST) (envelope-from wes) From: Wes Peters Message-Id: <199901191903.MAA09041@obie.softweyr.com> Subject: Re: What are the advantages of ELF kernels? In-Reply-To: from Dag-Erling Smorgrav at "Jan 19, 99 07:28:56 pm" To: des@flood.ping.uio.no (Dag-Erling Smorgrav) Date: Tue, 19 Jan 1999 12:03:37 -0700 (MST) Cc: wes@softweyr.com, sgk@troutmask.apl.washington.edu, dillon@apollo.backplane.com, dervish@bantu.cl.msu.edu, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL40 (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 Dag-Erling Smorgrav is alleged to have said: > Wes Peters writes: > > Being able to keep up with other developments in the world of development > > tools, not becoming a backwater, is an important point. This will allow > > FreeBSD to be a first-class Ada development system, using GNATS. ;^) > > Oops - GNATS is a problem report database. Gnat is an Ada compiler. OK, Gnat too then. Or the language of real programmers, Fortran. ;^) -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC wes@softweyr.com http://www.softweyr.com/~softweyr/ +1.801.915.2061 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 11:51:49 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA29647 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 11:51:49 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA29635; Tue, 19 Jan 1999 11:51:41 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id UAA25391; Tue, 19 Jan 1999 20:51:32 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA52121; Tue, 19 Jan 1999 20:51:32 +0100 (MET) Date: Tue, 19 Jan 1999 20:51:32 +0100 From: Eivind Eklund To: Jean-Marc Zucconi Cc: hackers@FreeBSD.ORG Subject: Re: My BIOS wants to know "Do you have a PNP OS?" Message-ID: <19990119205131.A52012@bitbox.follo.net> References: <199901190354.TAA01143@dingo.cdrom.com> <199901191518.QAA10060@qix> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199901191518.QAA10060@qix>; from Jean-Marc Zucconi on Tue, Jan 19, 1999 at 04:18:40PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Most will actually configure PCI cards; those that don't may configure > > just those that might form part of the boot path. > > > More significantly, when set to "yes", ISA PnP cards will not be > > automatically configured. This is bad. > > This is not my experience. My 3C509B won't work when the PnP option is > set to NO. Add PnP support to the if_ep.c, then. There is an example of how to do this at the end of if_ed.c; you need to look at the output of pnpinfo to find out what ids to put in there. If you don't know how to do this, throw the output of pnpinfo at me and I'll try to get back to you with patches. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 11:56:36 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA00259 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 11:56:36 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smarter.than.nu (lal-99-91.Reshall.Berkeley.EDU [169.229.99.91]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA00253; Tue, 19 Jan 1999 11:56:35 -0800 (PST) (envelope-from brian@CSUA.Berkeley.EDU) Received: from localhost (localhost [127.0.0.1]) by smarter.than.nu (8.9.1/8.9.1) with ESMTP id LAA16124; Tue, 19 Jan 1999 11:56:30 -0800 (PST) (envelope-from brian@CSUA.Berkeley.EDU) Date: Tue, 19 Jan 1999 11:56:29 -0800 (PST) From: "Brian W. Buchanan" X-Sender: brian@smarter.than.nu To: Jean-Marc Zucconi cc: hackers@FreeBSD.ORG Subject: Re: My BIOS wants to know "Do you have a PNP OS?" In-Reply-To: <199901191518.QAA10060@qix> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 19 Jan 1999, Jean-Marc Zucconi wrote: > > More significantly, when set to "yes", ISA PnP cards will not be > > automatically configured. This is bad. > > This is not my experience. My 3C509B won't work when the PnP option is > set to NO. Is this a PnP card? If not, you may need to tell BIOS to reserve its IRQ so that it isn't assigned to another PnP card in the system. -- Brian Buchanan brian@CSUA.Berkeley.EDU -------------------------------------------------------------------------- FreeBSD - The Power to Serve! http://www.freebsd.org daemon(n): 1. an attendant power or spirit : GENIUS 2. the cute little mascot of the FreeBSD operating system To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 11:58:41 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA00442 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 11:58:41 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from qix (cabri.obs-besancon.fr [193.52.184.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA00429 for ; Tue, 19 Jan 1999 11:58:32 -0800 (PST) (envelope-from jmz@FreeBSD.ORG) Received: (from jmz@localhost) by qix (8.9.2/8.8.7) id VAA10964; Tue, 19 Jan 1999 21:00:46 +0100 (MET) Date: Tue, 19 Jan 1999 21:00:46 +0100 (MET) Message-Id: <199901192000.VAA10964@qix> X-Authentication-Warning: qix: jmz set sender to jmz@qix using -f From: Jean-Marc Zucconi To: mike@smith.net.au CC: mike@smith.net.au, brian@CSUA.Berkeley.EDU, matthew@wolfepub.com, hackers@FreeBSD.ORG In-reply-to: <199901191633.IAA05229@dingo.cdrom.com> (message from Mike Smith on Tue, 19 Jan 1999 08:33:38 -0800) Subject: Re: My BIOS wants to know "Do you have a PNP OS?" X-Mailer: Emacs Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> Mike Smith writes: >> >>>>> Mike Smith writes: >> >> This is not my experience. My 3C509B won't work when the PnP option is >> set to NO. > Is that "509B" or "905B"? The '509 is not a PnP card, and if it's > failing with "PnP OS" set to "NO", I can only guess that some part of > the ISA PNP process is tying it in knots. This is an old ISA 509B, and mine is PnP (this is what the bios says!) 1 3C5x9 board(s) on ISA found at 0x300 ep0 at 0x300-0x30f irq 10 on isa ep0: utp[*UTP*] address 00:60:97:5c:0b:45 If I boot with PNP=NO in the bios, it is still recognized/attached by the ep driver but it does not work - all I get is timeouts. Jean-Marc -- Jean-Marc Zucconi PGP Key: finger jmz@FreeBSD.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 14:26:18 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA16864 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 14:26:18 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from net177138.hcv.com (net177138.hcv.com [209.153.177.138]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA16855 for ; Tue, 19 Jan 1999 14:26:13 -0800 (PST) (envelope-from matthew@wolfepub.com) Received: from thunder ([10.0.0.12]) by net177138.hcv.com (8.8.8/8.8.8) with SMTP id RAA00386 for ; Tue, 19 Jan 1999 17:22:03 -0500 (EST) (envelope-from matthew@wolfepub.com) Message-Id: <4.1.19990119172451.0093b4a0@firebat.wolfepub.com> X-Sender: matthew@firebat.wolfepub.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 19 Jan 1999 17:27:27 -0500 To: hackers@FreeBSD.ORG From: Matthew Hagerty Subject: IO-APIC support Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, I was wondering if FreeBSD-3.0 and/or 2.2.8-Release support PCI IRQs to IO-APIC mapping. This is a setting in my BIOS and I need to know if it should be enabled? Thank you, Matthew matthew@wolfepub.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 15:26:11 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA24316 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 15:26:11 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA24308 for ; Tue, 19 Jan 1999 15:26:08 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id IAA18625; Wed, 20 Jan 1999 08:25:27 +0900 (JST) Message-ID: <36A510DC.FFB2E863@newsguy.com> Date: Wed, 20 Jan 1999 08:10:20 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Wes Peters CC: Dag-Erling Smorgrav , sgk@troutmask.apl.washington.edu, dillon@apollo.backplane.com, dervish@bantu.cl.msu.edu, hackers@FreeBSD.ORG Subject: Re: What are the advantages of ELF kernels? References: <199901191903.MAA09041@obie.softweyr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Wes Peters wrote: > > Dag-Erling Smorgrav is alleged to have said: > > Wes Peters writes: > > > Being able to keep up with other developments in the world of development > > > tools, not becoming a backwater, is an important point. This will allow > > > FreeBSD to be a first-class Ada development system, using GNATS. ;^) > > > > Oops - GNATS is a problem report database. Gnat is an Ada compiler. > > OK, Gnat too then. Or the language of real programmers, Fortran. ;^) *REAL* real programmers use Forth, so FreeBSD is covered now. :-) Besides, Ada is for munchkins. :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com If you sell your soul to the Devil and all you get is an MCSE from it, you haven't gotten market rate. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 15:27:03 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA24420 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 15:27:03 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA24410 for ; Tue, 19 Jan 1999 15:27:01 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id IAA18608; Wed, 20 Jan 1999 08:25:11 +0900 (JST) Message-ID: <36A50F27.98B3FC7@newsguy.com> Date: Wed, 20 Jan 1999 08:03:04 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Jeremy Lea CC: Seth Leigh , freebsd-hackers@FreeBSD.ORG, lepreau@cs.utah.edu Subject: Re: Not so sinister. Was:(Re: Attempt to relicense BSD code under the GPL) References: <19990119192936.D826@shale.csir.co.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Jeremy Lea wrote: > > But you missed the point of the complaint. The GPL will not allow them to > do this. If they want to use the GPL for their own code, then it forces > them to use the GPL for their entire code base (whatever they are linking > and packaging). They've misunderstood the terms of the GPL. > > To quote (from /usr/src/contrib/gcc/COPYING): > " 2. You may modify your copy or copies of the Program or any portion > of it, thus forming a work based on the Program, and copy and > distribute such modifications or work under the terms of Section 1 > above, provided that you also meet all of these conditions: > > a) You must cause the modified files to carry prominent notices > stating that you changed the files and the date of any change. > > b) You must cause any work that you distribute or publish, that in > whole or in part contains or is derived from the Program or any > part thereof, to be licensed as a whole at no charge to all third > parties under the terms of this License." "Packaging" things together is usually not perceived as being the same as "contains". The BSD source is not "inside" the GPL source. This is why FreeBSD can "package" GPL stuff together with our BSD stuff. :-) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com If you sell your soul to the Devil and all you get is an MCSE from it, you haven't gotten market rate. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 17:34:24 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA08072 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 17:34:24 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from tokyonet-entrance.astec.co.jp (tokyonet-entrance.astec.co.jp [202.239.16.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA08066 for ; Tue, 19 Jan 1999 17:34:22 -0800 (PST) (envelope-from junichi@astec.co.jp) Received: from amont.astec.co.jp (amont.astec.co.jp [172.20.10.1]) by tokyonet-entrance.astec.co.jp (8.9.1+3.0W/3.7W-astecMX2.3) with ESMTP id KAA23354; Wed, 20 Jan 1999 10:34:14 +0900 (JST) Received: from localhost (sakura.astec.co.jp [172.20.10.61]) by amont.astec.co.jp (8.7.6/3.6W-astecMX2.4) with ESMTP id KAA22031; Wed, 20 Jan 1999 10:34:13 +0900 (JST) To: gibbs@narnia.plutotech.com Cc: mjacob@feral.com, hackers@FreeBSD.ORG Subject: Re: CAMify amd0(Tekram DC390 and other AMD 53c974 cards) In-Reply-To: Your message of "Mon, 18 Jan 1999 12:11:25 -0700 (MST)" <199901181911.MAA00894@narnia.plutotech.com> References: <199901181911.MAA00894@narnia.plutotech.com> X-Mailer: Mew version 1.93pre1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990120103413Q.junichi@astec.co.jp> Date: Wed, 20 Jan 1999 10:34:13 +0900 From: Satoh Junichi X-Dispatcher: imput version 980815 Lines: 22 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG From: "Justin T. Gibbs" Subject: Re: CAMify amd0(Tekram DC390 and other AMD 53c974 cards) Date: Mon, 18 Jan 1999 12:11:25 -0700 (MST) > In article you wrote: > > > > I'd love to see a newer driver using this (I did the SunOS/Solaris esp > > driver)- particularly if it had a micro state machine to (quickly) manage > > all the 7-10 interrupts/command that you have to do... > > > > I'm also keen to see AMD support return to the FreeBSD SCSI subsystem. > I don't know of anyone working on this driver right now, and I'm currently > quite booked, but I'll assist in whatever ways I can if you decide > to do this work. I'm writing an AMD 53c974 CAM driver which is based on the NetBSD esp driver. It is under development and does not work now. It will work soon. --- Junichi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 17:39:42 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA08597 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 17:39:42 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from feral-gw.feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA08589 for ; Tue, 19 Jan 1999 17:39:40 -0800 (PST) (envelope-from mjacob@feral.com) Received: from localhost (mjacob@localhost) by feral-gw.feral.com (8.8.7/8.8.7) with ESMTP id RAA22224; Tue, 19 Jan 1999 17:38:52 -0800 Date: Tue, 19 Jan 1999 17:38:51 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@feral-gw Reply-To: mjacob@feral.com To: Satoh Junichi cc: gibbs@narnia.plutotech.com, hackers@FreeBSD.ORG Subject: Re: CAMify amd0(Tekram DC390 and other AMD 53c974 cards) In-Reply-To: <19990120103413Q.junichi@astec.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Cool. Good. Actually, Erik was referring to a different chip, but the addition of more drivers is very good news! Thanks! On Wed, 20 Jan 1999, Satoh Junichi wrote: > From: "Justin T. Gibbs" > Subject: Re: CAMify amd0(Tekram DC390 and other AMD 53c974 cards) > Date: Mon, 18 Jan 1999 12:11:25 -0700 (MST) > > > In article you wrote: > > > > > > I'd love to see a newer driver using this (I did the SunOS/Solaris esp > > > driver)- particularly if it had a micro state machine to (quickly) manage > > > all the 7-10 interrupts/command that you have to do... > > > > > > > I'm also keen to see AMD support return to the FreeBSD SCSI subsystem. > > I don't know of anyone working on this driver right now, and I'm currently > > quite booked, but I'll assist in whatever ways I can if you decide > > to do this work. > > I'm writing an AMD 53c974 CAM driver which is based on the NetBSD esp > driver. It is under development and does not work now. > > It will work soon. > --- > Junichi > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 18:55:17 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA16680 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 18:55:17 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bingsun2.cc.binghamton.edu (bingsun2.cc.binghamton.edu [128.226.1.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA16670 for ; Tue, 19 Jan 1999 18:55:12 -0800 (PST) (envelope-from bf20761@binghamton.edu) Received: from localhost (bf20761@localhost) by bingsun2.cc.binghamton.edu (8.8.7/8.6.9) with SMTP id VAA11001 for ; Tue, 19 Jan 1999 21:55:03 -0500 (EST) Date: Tue, 19 Jan 1999 21:55:02 -0500 (EST) From: zhihuizhang X-Sender: bf20761@bingsun2 To: hackers Subject: Documentation on PC timing Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Can anyone tell me where I can find good (online) documentation on PC timer programming? Thanks a lot. -------------------------------------------------- | Zhihui Zhang, http://cs.binghamton.edu/~zzhang | | Dept. of Computer Science, SUNY at Binghamton | -------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 20:36:08 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA28022 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 20:36:08 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA27970 for ; Tue, 19 Jan 1999 20:36:01 -0800 (PST) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.8.8/8.8.8) id UAA29685 for hackers@freebsd.org; Tue, 19 Jan 1999 20:35:53 -0800 (PST) (envelope-from sef) Date: Tue, 19 Jan 1999 20:35:53 -0800 (PST) From: Sean Eric Fagan Message-Id: <199901200435.UAA29685@kithrup.com> To: hackers@FreeBSD.ORG Subject: HP OmniBook 4100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Okay, I got one of these at work, and am having a rather difficult time of it. I was given a 3Com Megahertz CardBus ethercard for it; this didn't work at all. Pity. I traded it with a semicoworker for a 3Com EtherLink III card, which everyone tells me should work. And it does work under Win95, and is found by FreeBSD (both 2.2.8-RELEASE and 3.0-RELEASE, provided I to a power-cycle of the machine after done with Win95). However, it doesn't *work* -- it doesn't seem to send any packets, and just sits there after telling me my default router is set up. Now, I tried the PAO version, and that does work with it. However, that's 2.2.7, and, gosh darn it, I can't seem to find that anywhere anymore, so after making filesystems in the slice and installing the boot manager, it tells me that it can't find a certain set of distfiles (namely, all of them). So. Anyone know what the heck is going on? And, more importantly, how I get this sucker working? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 21:14:45 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA02958 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 21:14:45 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA02951 for ; Tue, 19 Jan 1999 21:14:44 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (localhost.cdrom.com [127.0.0.1]) by zippy.cdrom.com (8.9.2/8.9.1) with ESMTP id VAA43398; Tue, 19 Jan 1999 21:14:37 -0800 (PST) To: Sean Eric Fagan cc: hackers@FreeBSD.ORG Subject: Re: HP OmniBook 4100 In-reply-to: Your message of "Tue, 19 Jan 1999 20:35:53 PST." <199901200435.UAA29685@kithrup.com> Date: Tue, 19 Jan 1999 21:14:37 -0800 Message-ID: <43394.916809277@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Now, I tried the PAO version, and that does work with it. However, that's > 2.2.7, and, gosh darn it, I can't seem to find that anywhere anymore, so afte Not relevant. Look in the options screen - the release string is an editable variable for a very good reason. :-) - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Tue Jan 19 23:39:17 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA18728 for freebsd-hackers-outgoing; Tue, 19 Jan 1999 23:39:17 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.calweb.com (mail.calweb.com [208.131.56.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA18722 for ; Tue, 19 Jan 1999 23:39:14 -0800 (PST) (envelope-from jkf@calweb.com) Received: by mail.calweb.com (8.8.6/8.8.6) with SMTP id XAA27754 for ; Tue, 19 Jan 1999 23:39:07 -0800 (PST) X-SMTP: helo web2.calweb.com from jkf@calweb.com server jkf@web2.calweb.com ip 208.131.56.52 Date: Tue, 19 Jan 1999 23:39:06 -0800 (PST) From: "Jason K. Fritcher" To: freebsd-hackers@FreeBSD.ORG Subject: Symbol mappings in loadable objects. 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. After hunting through the mailing list archives for a solution, I am at a loss for my problem. I have been expermimenting with dynamic loadable objects using dlopen() and dlsym(). I have figured out how to get the main code to obtain pointers to symbols in the loaded object and to call them, but I can not figure out how to get the loadable object to call function in the main code. All I get when running the main code is this error: dlopen: ./mod_blah.so: Undefined symbol "blah_blah" I have tried looking through the Apache code to see if there was anything obvious in there, I have also looked through the code to Listar, and again couldn't find anything appearant. I have read dlopen(3), dlsym(3), and link(5), but I can't find anything useful. The commands I am using to compile the modules is: gcc -DPIC -fPIC -g -o mod_blah.o -c mod_blah.c ld -shared -o mod_blah.so mod_blah.o And I'm compiling the main program like this: gcc -g -o blah blah.c If any other information is needed let me know, and I'll answer any questions to the best of my ability. If there is any online info on doing this, pointers would be much appriciated. Otherwise, maybe a couple hints to help me along. :) Thanx. -------------------------------------------------------------------------- Jason K. Fritcher System Administrator jkf@calweb.com CalWeb Internet Services http://www.calweb.com/ 916-641-9320 -------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 20 00:19:58 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA23191 for freebsd-hackers-outgoing; Wed, 20 Jan 1999 00:19:58 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA23186 for ; Wed, 20 Jan 1999 00:19:56 -0800 (PST) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.8.8/8.8.8) id AAA11071 for hackers@freebsd.org; Wed, 20 Jan 1999 00:19:49 -0800 (PST) (envelope-from sef) Date: Wed, 20 Jan 1999 00:19:49 -0800 (PST) From: Sean Eric Fagan Message-Id: <199901200819.AAA11071@kithrup.com> To: hackers@FreeBSD.ORG Subject: Re: HP OmniBook 4100 In-Reply-To: <43484.916809671@zippy.cdrom.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Okay, thanks to Jordan's advice, and some help from Nate, I got it installed and even on the net. Only sorta. The network performance of the card is *HORRIBLE*. First of all, it doesn't recognize pings -- if I do "ping kithrup" from it, and run tcpdump on kithrup, I see the ICMP ECHO and replies via tcpdump, but the laptoip doesn't get anything. I tried ftp'ing something (about 875k), and it got a whopping 5k bytes in, and hung. The network, that is, not the computer. I found some mention in the mailing list archives about problems, but it seemed to be that they were cleared up by now. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 20 01:16:14 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA29803 for freebsd-hackers-outgoing; Wed, 20 Jan 1999 01:16:14 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from zippy.dyn.ml.org (kenya-175.ppp.hooked.net [206.169.227.175]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA29798 for ; Wed, 20 Jan 1999 01:16:12 -0800 (PST) (envelope-from garbanzo@hooked.net) Received: from localhost (garbanzo@zippy.dyn.ml.org [127.0.0.1]) by zippy.dyn.ml.org (8.9.1/8.8.8) with ESMTP id BAA08612; Wed, 20 Jan 1999 01:19:22 -0800 (PST) (envelope-from garbanzo@hooked.net) Date: Wed, 20 Jan 1999 01:19:21 -0800 (PST) From: Alex Zepeda X-Sender: garbanzo@zippy.dyn.ml.org To: "Jason K. Fritcher" cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Symbol mappings in loadable objects. 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 Tue, 19 Jan 1999, Jason K. Fritcher wrote: > The commands I am using to compile the modules is: > > gcc -DPIC -fPIC -g -o mod_blah.o -c mod_blah.c > ld -shared -o mod_blah.so mod_blah.o > > And I'm compiling the main program like this: > > gcc -g -o blah blah.c You didn't say whether you were using an ELF or an a.out box, but judging by your comments, you need to add -export-dynamic to your command line so that: gcc -g -o blah blah.c turns into something like: gcc -export-dynamic -g -o blah blah.c - alex | "Contrary to popular belief, penguins are not the salvation of modern | | technology. Neither do they throw parties for the urban proletariat." | | Powered by FreeBSD http://www.freebsd.org/ | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 20 08:55:13 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA20509 for freebsd-hackers-outgoing; Wed, 20 Jan 1999 08:55:13 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA20488 for ; Wed, 20 Jan 1999 08:55:03 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.2/8.9.2/Netplex) with ESMTP id AAA20914; Thu, 21 Jan 1999 00:54:15 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199901201654.AAA20914@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Greg Lehey cc: "Kaleb S. KEITHLEY" , hackers@FreeBSD.ORG Subject: Re: How the other half lives In-reply-to: Your message of "Tue, 19 Jan 1999 23:03:14 +1030." <19990119230314.H4646@freebie.lemis.com> Date: Thu, 21 Jan 1999 00:54:15 +0800 From: Peter Wemm Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greg Lehey wrote: > On Tuesday, 19 January 1999 at 8:40:40 -0500, Kaleb S. KEITHLEY wrote: > >> > >> http://www.sysinternals.com/nt5src.htm > > The links to the .c files don't work right. There are no links.. It's a view of the layout of the NT source tree, not the sources themselves. The layout was mined from the ASSERT stuff in the binaries. > Greg Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 20 10:05:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA26926 for freebsd-hackers-outgoing; Wed, 20 Jan 1999 10:05:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA26921 for ; Wed, 20 Jan 1999 10:05:29 -0800 (PST) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.8.8/8.8.8) id KAA18762 for hackers@freebsd.org; Wed, 20 Jan 1999 10:05:19 -0800 (PST) (envelope-from sef) Date: Wed, 20 Jan 1999 10:05:19 -0800 (PST) From: Sean Eric Fagan Message-Id: <199901201805.KAA18762@kithrup.com> To: hackers@FreeBSD.ORG Subject: Re: HP OmniBook 4100 In-Reply-To: <44655.916832931@zippy.cdrom.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Solved! The problem was there was a conflict with the IRQ. PAO's pccardd can chose any IRQ, so it chose a free one. The one that was in my pccardd.conf (10) conflicted with the USB controller's IRQ. It's not on the network at nice speeds. Nate is the smartest person I have ever met. Well, in the top two or three thousand, anyway ;). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 20 11:32:36 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA07613 for freebsd-hackers-outgoing; Wed, 20 Jan 1999 11:32:36 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.calweb.com (mail.calweb.com [208.131.56.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA07606 for ; Wed, 20 Jan 1999 11:32:33 -0800 (PST) (envelope-from jkf@calweb.com) Received: by mail.calweb.com (8.8.6/8.8.6) with SMTP id LAA26051; Wed, 20 Jan 1999 11:32:25 -0800 (PST) X-SMTP: helo devnull from jkf@calweb.com server @devnull.calweb.com ip 207.173.135.51 Message-ID: <013301be44ab$9c366720$3387adcf@devnull.calweb.com> From: "Jason K. Fritcher" To: Cc: Subject: Re: Symbol mappings in loadable objects. Date: Wed, 20 Jan 1999 11:32:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I just realized, I hit reply, instead of reply all, to the original response, so here is a copy to the list. >On Tue, 19 Jan 1999, Jason K. Fritcher wrote: >You didn't say whether you were using an ELF or an a.out box, but judging I am developing on a 3.0-release box that I upgraded to -current at the beginning of December. >by your comments, you need to add -export-dynamic to your command line so >that: > >gcc -g -o blah blah.c > >turns into something like: > >gcc -export-dynamic -g -o blah blah.c That did the trick on the 3.0 box. Just to try it, I compiled this code without the -export-dynamic flag on a 2.2.5 box and it works. Why is the default of 2.2.5 to export the symbols, and in 3.0 a flag is needed? Thanx for the help. :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 20 12:27:09 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA13657 for freebsd-hackers-outgoing; Wed, 20 Jan 1999 12:27:09 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA13652 for ; Wed, 20 Jan 1999 12:27:07 -0800 (PST) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.8.8/8.8.8) id MAA29556; Wed, 20 Jan 1999 12:26:58 -0800 (PST) (envelope-from sef) Date: Wed, 20 Jan 1999 12:26:58 -0800 (PST) From: Sean Eric Fagan Message-Id: <199901202026.MAA29556@kithrup.com> To: hackers@FreeBSD.ORG Subject: Re: HP OmniBook 4100 Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Solved! The problem was there was a conflict with the IRQ. PAO's >pccardd can chose any IRQ, so it chose a free one. The one that was in >my pccardd.conf (10) conflicted with the USB controller's IRQ. > >It's not on the network at nice speeds. That should have been "now on the network" :). Unfortunately, when I brought it into the office, it stopped working. I'm getting very upset with my new toy :). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 20 16:16:02 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA08005 for freebsd-hackers-outgoing; Wed, 20 Jan 1999 16:16:02 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA07998 for ; Wed, 20 Jan 1999 16:16:00 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id QAA15560; Wed, 20 Jan 1999 16:15:52 -0800 (PST) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.1/8.9.1) id QAA05959; Wed, 20 Jan 1999 16:15:52 -0800 (PST) (envelope-from jdp@polstra.com) Date: Wed, 20 Jan 1999 16:15:52 -0800 (PST) Message-Id: <199901210015.QAA05959@vashon.polstra.com> To: jkf@calweb.com Subject: Re: Symbol mappings in loadable objects. Newsgroups: polstra.freebsd.hackers In-Reply-To: <013301be44ab$9c366720$3387adcf@devnull.calweb.com> Organization: Polstra & Co., Seattle, WA Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <013301be44ab$9c366720$3387adcf@devnull.calweb.com>, Jason K. Fritcher wrote: > > > >gcc -export-dynamic -g -o blah blah.c > > That did the trick on the 3.0 box. > > Just to try it, I compiled this code without the -export-dynamic flag on a > 2.2.5 box and it works. Why is the default of 2.2.5 to export the symbols, > and in 3.0 a flag is needed? Because 2.2.5 uses the a.out object file format, while 3.0 uses ELF. They're two entirely different linkers, and they don't behave 100% identically. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 20 18:00:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA19842 for freebsd-hackers-outgoing; Wed, 20 Jan 1999 18:00:16 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA19831 for ; Wed, 20 Jan 1999 18:00:13 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id RAA10868 for ; Wed, 20 Jan 1999 17:30:57 -0800 (PST) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma010865; Wed, 20 Jan 99 17:30:51 -0800 Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id RAA26927 for freebsd-hackers@freebsd.org; Wed, 20 Jan 1999 17:30:51 -0800 (PST) From: Archie Cobbs Message-Id: <199901210130.RAA26927@bubba.whistle.com> Subject: AF_MAX duplicately defined To: freebsd-hackers@FreeBSD.ORG Date: Wed, 20 Jan 1999 17:30:51 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Anyone know why AF_MAX is defined in both sys/socket.h AND sys/mount.h? In sys/mount.h: #include #define AF_MAX 32 /* XXX */ [ ... ] /* * Network export information */ struct netexport { struct netcred ne_defexported; /* Default export */ struct radix_node_head *ne_rtable[AF_MAX+1]; /* Individual exports */ }; Yuck. Why can't mount.h just include socket.h (or the includer of mount.h just include socket.h)? Thanks, -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 Wed Jan 20 18:22:59 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA22654 for freebsd-hackers-outgoing; Wed, 20 Jan 1999 18:22:59 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from wrath.cs.utah.edu (wrath.cs.utah.edu [155.99.198.100]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA22649 for ; Wed, 20 Jan 1999 18:22:57 -0800 (PST) (envelope-from danderse@cs.utah.edu) Received: from torrey.cs.utah.edu (torrey.cs.utah.edu [155.99.212.91]) by wrath.cs.utah.edu (8.8.8/8.8.8) with ESMTP id TAA26664; Wed, 20 Jan 1999 19:21:42 -0700 (MST) Received: (from danderse@localhost) by torrey.cs.utah.edu (8.9.1/8.9.1) id TAA91556; Wed, 20 Jan 1999 19:21:41 -0700 (MST) (envelope-from danderse@cs.utah.edu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 20 Jan 1999 19:21:41 -0700 (MST) From: "David G. Andersen" To: "Daniel C. Sobral" Cc: Jeremy Lea , Seth Leigh , freebsd-hackers@FreeBSD.ORG, lepreau@cs.utah.edu Subject: Re: Not so sinister. Was:(Re: Attempt to relicense BSD code under the GPL) In-Reply-To: Daniel C. Sobral's message of Wed, January 20 1999 <36A50F27.98B3FC7@newsguy.com> References: <19990119192936.D826@shale.csir.co.za> <36A50F27.98B3FC7@newsguy.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <13990.36446.656181.63829@torrey.cs.utah.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Lo and Behold, Daniel C. Sobral said: > > b) You must cause any work that you distribute or publish, that in > > whole or in part contains or is derived from the Program or any > > part thereof, to be licensed as a whole at no charge to all third > > parties under the terms of this License." > > "Packaging" things together is usually not perceived as being the > same as "contains". The BSD source is not "inside" the GPL source. > This is why FreeBSD can "package" GPL stuff together with our BSD > stuff. :-) And to expand upon what Daniel said a bit, it's important to consider one of the really neat things about the OSKit - that most of the code that's encapsulated is done so without modifying the original source at all. (Except bugfixes and such. We make a strong attempt to back-port all bugfixes to the original FreeBSD sources). If you look at the OSKit, then, it has this funky "freebsd/src" directory, which contains, virtually unmodified, all of the FreeBSD sources. The FreeBSD code isn't simply ripped out and glommed in to our own code (the stuff labeled with the GPL). The glue code which permits the various parts of the OSKit to interoperate was, however, written by the Utah folk. It's what makes the OSKit the OSKit, and not just some randomly created collection of sources. :-) -Dave [Oblig. disclaimer: I speak for myself, not for my employer. If you want a legal discussion of stuff in the oskit, you'll have to get Jay to pound on the legal folks at Utah for one. IANAL, thank god. :-] -- work: danderse@cs.utah.edu me: angio@pobox.com University of Utah http://www.angio.net/ Computer Science - Flux Research Group To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 20 20:56:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA09300 for freebsd-hackers-outgoing; Wed, 20 Jan 1999 20:56:44 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA09279; Wed, 20 Jan 1999 20:56:40 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id UAA10191; Wed, 20 Jan 1999 20:56:32 -0800 (PST) (envelope-from dillon) Date: Wed, 20 Jan 1999 20:56:32 -0800 (PST) From: Matthew Dillon Message-Id: <199901210456.UAA10191@apollo.backplane.com> To: current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Heads up! New swapper and VM changes being committed to -4.x tonight. Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The new swapper and a bunch of VM stuff I've been sitting on is going to be committed into the new -current tree tonight. These changes also include the most recent NFS fix ( of two.. the one prior to this one has already been committed ). This fix and numerous other minor VM bug fixes that are applicable to the -3.x tree will be backported once some external testing has been done. Hopefully *before* the 3.1 freeze. New material not related to out-and-out bug fixes will probably not be backported to -3.x. Or, if it is, not for some time. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 20 22:52:47 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA24015 for freebsd-hackers-outgoing; Wed, 20 Jan 1999 22:52:47 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from lion.butya.kz (butya-gw.butya.kz [194.87.112.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA24009 for ; Wed, 20 Jan 1999 22:52:38 -0800 (PST) (envelope-from root@butya.kz) Received: from root by lion.butya.kz with local (Exim 2.054 #1) id 103DyX-000136-00 for freebsd-hackers@freebsd.org; Thu, 21 Jan 1999 12:52:21 +0600 Date: Wed, 20 Jan 1999 19:17:18 +0600 (ALMT) From: Boris Popov To: freebsd-hackers@FreeBSD.ORG Subject: Two bugs and suggestion for IPX stack Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1094206439-916838238=:29453" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --0-1094206439-916838238=:29453 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, for about a two months ago I make few changes in IPX stack related to broadcast bug, internal net support and little bug in SPX implementation. As they work stable I suggest them to discuss and commit in to source tree. Here is a short explanation: Broadcasts: local host never get broadcast packet originated by itself. Novell implementation do that, and this simplify programming. Internal net: it is possible to implement internal net conception like used in Netware servers by configure loopback interface as follows: ifconfig lo0 ipx 0x5a5a.1 After that, server programs like mars_nwe , can use only network 0x5a5a and host 1. Of course this requires small changes to ipx stack and IPXrouted. SPX bug are just invalid order of operators :) All patches are simple and attached at the end of letter. BTW, I mostly finish work on Netware client (typical throughput about 730Kb/s on 10Mbit network). Higher rates is possible with packet burst mode, so does any body know the details ? -- Boris Popov --0-1094206439-916838238=:29453 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=diff1 Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=diff1 ZGlmZiAtcnViIC4vc2FwX3RhYmxlcy5jIG5ldy9zYXBfdGFibGVzLmMNCi0t LSAuL3NhcF90YWJsZXMuYwlNb24gRmViIDE2IDE5OjU0OjMyIDE5OTgNCisr KyBuZXcvc2FwX3RhYmxlcy5jCVNhdCBEZWMgIDUgMjE6MDU6MjYgMTk5OA0K QEAgLTEzNCw2ICsxMzQsNyBAQA0KIAkJZm9yKHNhcCA9IHNoLT5mb3J3OyBz YXAgIT0gKHNhcF9lbnRyeSAqKXNoOyBzYXAgPSBzYXAtPmZvcncpIHsNCiAJ CQlpZiAoU2VydlR5cGUgIT0gc2FwLT5zYXAuU2VydlR5cGUpDQogCQkJCWNv bnRpbnVlOw0KKyNpZiAwDQogCQkJaWYgKGlmcCA9PSBzYXAtPmlmcCkNCiAJ CQkJY29udGludWU7DQogDQpAQCAtMTQ3LDYgKzE0OCw3IEBADQogCQkJCQln b3RvIG5leHQ7DQogCQkJCWNzYXAgPSBjc2FwLT5jbG9uZTsNCiAJCQl9DQor I2VuZGlmDQogDQogCQkJaWYgKG50b2hzKHNhcC0+c2FwLmhvcHMpIDwgYmVz dGhvcHMpIHsNCiAJCQkJYmVzdCA9IHNhcDsNCmRpZmYgLXJ1YiAuL3N0YXJ0 dXAuYyBuZXcvc3RhcnR1cC5jDQotLS0gLi9zdGFydHVwLmMJU2F0IEZlYiAy MiAyMjowMTowMSAxOTk3DQorKysgbmV3L3N0YXJ0dXAuYwlXZWQgSmFuIDIw IDE4OjQ0OjMxIDE5OTkNCkBAIC0xODMsNiArMTgzLDkgQEANCiAJCQl9DQog CQkJaWZzLmludF9kc3RhZGRyID0gKmJyZGFkZHI7DQogCQl9DQorCQlpZiAo aWZzLmludF9mbGFncyAmIElGRl9MT09QQkFDSykgew0KKwkJCWlmcy5pbnRf ZHN0YWRkciA9IGlmcy5pbnRfYWRkcjsNCisJCX0NCiAJCS8qIA0KIAkJICog YWxyZWFkeSBrbm93biB0byB1cz8gDQogCQkgKiB3aGF0IG1ha2VzIGEgUE9J TlRPUE9JTlQgaWYgdW5pcXVlIGlzIGl0cyBkc3QgYWRkciwNCkBAIC0xOTIs OSArMTk1LDYgQEANCiAJCQlpZl9pZndpdGhkc3RhZGRyKCZpZnMuaW50X2Rz dGFkZHIpKSB8fA0KIAkJCSggKChpZnMuaW50X2ZsYWdzICYgSUZGX1BPSU5U T1BPSU5UKSA9PSAwKSAmJg0KIAkJCWlmX2lmd2l0aGFkZHIoJmlmcy5pbnRf YWRkcikpKQ0KLQkJCWNvbnRpbnVlOw0KLQkJLyogbm8gb25lIGNhcmVzIGFi b3V0IHNvZnR3YXJlIGxvb3BiYWNrIGludGVyZmFjZXMgKi8NCi0JCWlmIChp ZnMuaW50X2ZsYWdzICYgSUZGX0xPT1BCQUNLKQ0KIAkJCWNvbnRpbnVlOw0K IAkJaWZwID0gKHN0cnVjdCBpbnRlcmZhY2UgKikNCiAJCQltYWxsb2Moc2Rs LT5zZGxfbmxlbiArIDEgKyBzaXplb2YoaWZzKSk7DQo= --0-1094206439-916838238=:29453 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=diff2 Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=diff2 ZGlmZiAtcnViIC4vaXB4X291dHB1dGZsLmMgbmV3L2lweF9vdXRwdXRmbC5j DQotLS0gLi9pcHhfb3V0cHV0ZmwuYwlNb24gRmViIDE2IDE5OjM0OjMwIDE5 OTgNCisrKyBuZXcvaXB4X291dHB1dGZsLmMJV2VkIEphbiAyMCAxNTozODo1 NyAxOTk5DQpAQCAtMTE4LDcgKzExOCw3IEBADQogCSAqIHN1Y2ggYSBwYWNr ZXQuDQogCSAqLw0KIAlpZiAoZHN0LT5zaXB4X2FkZHIueF9ob3N0LmNfaG9z dFswXSYxKSB7DQotCQlpZiAoKGlmcC0+aWZfZmxhZ3MgJiBJRkZfQlJPQURD QVNUKSA9PSAwKSB7DQorCQlpZiAoKGlmcC0+aWZfZmxhZ3MgJiAoSUZGX0JS T0FEQ0FTVCB8IElGRl9MT09QQkFDSykpID09IDApIHsNCiAJCQllcnJvciA9 IEVBRERSTk9UQVZBSUw7DQogCQkJZ290byBiYWQ7DQogCQl9DQpAQCAtMTI2 LDYgKzEyNiw3IEBADQogCQkJZXJyb3IgPSBFQUNDRVM7DQogCQkJZ290byBi YWQ7DQogCQl9DQorCQltMC0+bV9mbGFncyB8PSBNX0JDQVNUOw0KIAl9DQog DQogCWlmIChodG9ucyhpcHgtPmlweF9sZW4pIDw9IGlmcC0+aWZfbXR1KSB7 DQpkaWZmIC1ydWIgLi9zcHhfdXNycmVxLmMgbmV3L3NweF91c3JyZXEuYw0K LS0tIC4vc3B4X3VzcnJlcS5jCVdlZCBKYW4gMTMgMTQ6NDE6MDAgMTk5OQ0K KysrIG5ldy9zcHhfdXNycmVxLmMJV2VkIEphbiAyMCAxODo1MTowNSAxOTk5 DQpAQCAtMTMzNSwxMyArMTMzNSwxMyBAQA0KIAlpcHhwID0gc290b2lweHBj Yihzbyk7DQogDQogCU1BTExPQyhjYiwgc3RydWN0IHNweHBjYiAqLCBzaXpl b2YgKmNiLCBNX1BDQiwgTV9OT1dBSVQpOw0KLQliemVybyhjYiwgc2l6ZW9m ICpjYik7DQotCXNiID0gJnNvLT5zb19zbmQ7DQogDQogCWlmIChjYiA9PSBO VUxMKSB7DQogCQllcnJvciA9IEVOT0JVRlM7DQogCQlnb3RvIHNweF9hdHRh Y2hfZW5kOw0KIAl9DQorCWJ6ZXJvKGNiLCBzaXplb2YgKmNiKTsNCisJc2Ig PSAmc28tPnNvX3NuZDsNCiANCiAJbW0gPSBtX2dldGNscihNX0RPTlRXQUlU LCBNVF9IRUFERVIpOw0KIAlpZiAobW0gPT0gTlVMTCkgew0K --0-1094206439-916838238=:29453-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 20 23:03:14 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA25316 for freebsd-hackers-outgoing; Wed, 20 Jan 1999 23:03:14 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from hokkshideh.jetcafe.org (hokkshideh.jetcafe.org [205.147.43.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA25307 for ; Wed, 20 Jan 1999 23:03:11 -0800 (PST) (envelope-from dave@jetcafe.org) Received: from hokkshideh.jetcafe.org (localhost [127.0.0.1]) by hokkshideh.jetcafe.org (8.8.8/8.8.5) with ESMTP id XAA12368 for ; Wed, 20 Jan 1999 23:02:55 -0800 (PST) Message-Id: <199901210702.XAA12368@hokkshideh.jetcafe.org> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-hackers@FreeBSD.ORG Subject: ELF cross compiling on 2.2.X Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Jan 1999 23:02:55 -0800 From: Dave Hayes Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well after searching the mail archives, I still cannot find the 'elfkit'. If I want to produce ELF shared libraries on a 2.2.X machine, what do I do? My current understanding is: either upgrade to 3.0 or get binutils-2.9.1 and egcs and configure them to cross compile to linux. Is this correct? ------ Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org Keep Usenet Free - http://www.jetcafe.org/~dave/usenet >>> The opinions expressed above are entirely my own <<< What we see depends on mainly what we look for. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Wed Jan 20 23:08:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA25822 for freebsd-hackers-outgoing; Wed, 20 Jan 1999 23:08:30 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles232.castles.com [208.214.165.232]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA25815 for ; Wed, 20 Jan 1999 23:08:24 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id XAA06685; Wed, 20 Jan 1999 23:03:59 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901210703.XAA06685@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Boris Popov cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Two bugs and suggestion for IPX stack In-reply-to: Your message of "Wed, 20 Jan 1999 19:17:18 +0600." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Jan 1999 23:03:58 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > for about a two months ago I make few changes in IPX stack related > to broadcast bug, internal net support and little bug in SPX > implementation. As they work stable I suggest them to discuss and commit > in to source tree. Here is a short explanation: ... > All patches are simple and attached at the end of letter. Do you have more changes as part of your ongoing work, or should we commit these immediately to simplify your work? > BTW, I mostly finish work on Netware client (typical throughput > about 730Kb/s on 10Mbit network). Higher rates is possible with packet > burst mode, so does any body know the details ? I can't help you with the details there, sorry. Are you going to be able to release this code for us to use? We'd be very happy indeed to see this available; anything else we can do to help? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ 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 Jan 21 00:55:49 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA06195 for freebsd-hackers-outgoing; Thu, 21 Jan 1999 00:55:49 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA06177; Thu, 21 Jan 1999 00:55:46 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id AAA05930; Thu, 21 Jan 1999 00:55:38 -0800 (PST) (envelope-from dillon) Date: Thu, 21 Jan 1999 00:55:38 -0800 (PST) From: Matthew Dillon Message-Id: <199901210855.AAA05930@apollo.backplane.com> To: current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Heads up! New swapper and VM changes have been committed to -4.x References: <199901210456.UAA10191@apollo.backplane.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG It's all in. The more feedback the better. You will have to recompile KVM-related support programs, especially pstat. I also suggest recompiling libkvm, ps, top, vmstat, systat, etc... The new swapper is not understood by top or systat yet but it is well understood by pstat -s ( aka swapinfo ), and pstat -ss will dump the radix tree. One thing I haven't been able to test, because I forgot: Interleaved swap ( more then one swap device ). I'll try to test that ASAP. I've tested everything else as well as I've been able, mainly by running 'make -j30 buildworld', make on various ports, eatmem, and other applications all at once on my test box. No comments on syntax, please, the commit is understood to be rough and the syntax and comments will be fixed up with more commits. I intend to make further forced commits to document special items, such as core bug fixes, and addlib other comments. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 21 01:44:11 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA11959 for freebsd-hackers-outgoing; Thu, 21 Jan 1999 01:44:11 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from korin.warman.org.pl (korin.nask.waw.pl [195.187.243.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA11929; Thu, 21 Jan 1999 01:43:54 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id KAA28172; Thu, 21 Jan 1999 10:47:55 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Thu, 21 Jan 1999 10:47:55 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: Matthew Dillon cc: current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Heads up! New swapper and VM changes being committed to -4.x tonight. In-Reply-To: <199901210456.UAA10191@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 Wed, 20 Jan 1999, Matthew Dillon wrote: > The new swapper and a bunch of VM stuff I've been sitting > on is going to be committed into the new -current tree tonight. I'm more than willing to test it in low memory conditions.. :-) I have that special 386SX/4MB RAM machine in the corner to test things like picobsd memory requirements... Andrzej Bialecki -------------------- ++-------++ ------------------------------------- ||PicoBSD|| FreeBSD in your pocket? Go and see: Research & Academic |+-------+| "Small & Embedded FreeBSD" Network in Poland | |TT~~~| | http://www.freebsd.org/~picobsd/ -------------------- ~-+==---+-+ ------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 21 02:39:38 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA17319 for freebsd-hackers-outgoing; Thu, 21 Jan 1999 02:39:38 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from lion.butya.kz (butya-gw.butya.kz [194.87.112.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA17312 for ; Thu, 21 Jan 1999 02:39:29 -0800 (PST) (envelope-from bp@butya.kz) Received: from bp (helo=localhost) by lion.butya.kz with local-smtp (Exim 2.054 #1) id 103FPB-0001nL-00; Thu, 21 Jan 1999 14:23:57 +0600 Date: Thu, 21 Jan 1999 14:23:57 +0600 (ALMT) From: Boris Popov To: Mike Smith cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Two bugs and suggestion for IPX stack In-Reply-To: <199901210703.XAA06685@dingo.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 20 Jan 1999, Mike Smith wrote: > > Do you have more changes as part of your ongoing work, or should we > commit these immediately to simplify your work? These patches are minimal to make IPX usable for applications. One patch that not submited, change structure of sockaddr_ipx: struct sockaddr_ipx { u_char sipx_len; u_char sipx_family; struct ipx_addr sipx_addr; - char sipx_zero[2]; + u_char sipx_pt; + char sipx_zero; }; New field sipx_pt should be filled in ipx_input() subroutine. There is also ability to pass it to ipx_output(), but it can affect existing applications. That helps to deal with IPX packet types without involving SO_HEADERS_ON_INPUT. With that, there is no additional patches. So if introducing sipx_pt is correct, I can send this patch to commit with others. > > BTW, I mostly finish work on Netware client (typical throughput > > about 730Kb/s on 10Mbit network). Higher rates is possible with packet > > burst mode, so does any body know the details ? > > I can't help you with the details there, sorry. Are you going to be > able to release this code for us to use? We'd be very happy indeed to > see this available; anything else we can do to help? Of course, I will release this code next week (if nothing serious happens :). And if someone can review and test fs part of code (it should have _enough_ bugs, especially for paged IO) that will be very helpfull. -- Boris Popov To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 21 08:00:18 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA19564 for freebsd-hackers-outgoing; Thu, 21 Jan 1999 08:00:18 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA19556 for ; Thu, 21 Jan 1999 08:00:15 -0800 (PST) (envelope-from crossd@cs.rpi.edu) Received: from cs.rpi.edu (crossd@o2.cs.rpi.edu [128.113.96.156]) by cs.rpi.edu (8.9.1/8.9.1) with ESMTP id LAA28568 for ; Thu, 21 Jan 1999 11:00:05 -0500 (EST) Message-Id: <199901211600.LAA28568@cs.rpi.edu> To: hackers@FreeBSD.ORG Subject: device driver writing Date: Thu, 21 Jan 1999 11:00:03 -0500 From: "David E. Cross" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am attempting to write a very simple device driver for the serial port (8250 only) as a KLD (this is for demonstration purposes to a class). I admit I have never written a UNIX device drvier before, but KLD makes it look so easy :). The problem that I am having is that I do not know how to hook in to the interupts. I have looked at sio.c and noticde the 'struct isa_device', that contains the information I want to set (I think), but I do not see where or how this information is registered with the kernel. Any pointers/sample code would be appreciated, thanks :) -- David Cross To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 21 08:32:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA23082 for freebsd-hackers-outgoing; Thu, 21 Jan 1999 08:32:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA23071 for ; Thu, 21 Jan 1999 08:32:26 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 2.10 #1) id 103N1V-000NVQ-00; Thu, 21 Jan 1999 18:32:01 +0200 From: Sheldon Hearn To: "David E. Cross" cc: hackers@FreeBSD.ORG Subject: Re: device driver writing In-reply-to: Your message of "Thu, 21 Jan 1999 11:00:03 EST." <199901211600.LAA28568@cs.rpi.edu> Date: Thu, 21 Jan 1999 18:32:01 +0200 Message-ID: <90359.916936321@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 21 Jan 1999 11:00:03 EST, "David E. Cross" wrote: > Any pointers/sample code would be appreciated, thanks :) The sio(4) manpage might be a good start. Get cracking on that so that you have a context to think within when someone else points you at sample code like moused. :-) 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 Jan 21 10:56:26 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA12274 for freebsd-hackers-outgoing; Thu, 21 Jan 1999 10:56:26 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA12269; Thu, 21 Jan 1999 10:56:24 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 103PGp-0002yV-00; Thu, 21 Jan 1999 11:55:59 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id LAA79083; Thu, 21 Jan 1999 11:53:46 -0700 (MST) Message-Id: <199901211853.LAA79083@harmony.village.org> To: Andrzej Bialecki Subject: Re: Heads up! New swapper and VM changes being committed to -4.x tonight. Cc: Matthew Dillon , current@FreeBSD.ORG, hackers@FreeBSD.ORG In-reply-to: Your message of "Thu, 21 Jan 1999 10:47:55 +0100." References: Date: Thu, 21 Jan 1999 11:53:46 -0700 From: Warner Losh Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Andrzej Bialecki writes: : I'm more than willing to test it in low memory conditions.. :-) I have : that special 386SX/4MB RAM machine in the corner to test things like : picobsd memory requirements... So how well does this work? I have a 4MB machine that I'd like to run FreeBSD on, including X on a low res screen... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 21 16:06:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA20148 for freebsd-hackers-outgoing; Thu, 21 Jan 1999 16:06:44 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA20132 for ; Thu, 21 Jan 1999 16:06:35 -0800 (PST) (envelope-from vev@michvhf.com) Received: (qmail 462 invoked by uid 1001); 22 Jan 1999 00:06:26 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Thu, 21 Jan 1999 19:06:25 -0500 (EST) X-Face: *0^4Iw) To: freebsd-hackers@FreeBSD.ORG Subject: USER_LDT on 2.2.8 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In trying to run wine I built a kernel with options USER_LDT compiled in. I did this on 2.2.7 with no trouble, but on 2.2.8 I get sig 11's. It'll happen during bootup, while compiling or a number of other simple tasks. I know sig 11's are an indication of a hardware problem, but that's not the only thing it can be (I've seen null pointers do it too) and it didn't do it with previous versions of FreeBSD. If I recompile without it I have no problems at all and the compiles, etc. go along just fine. Any ideas? If you want to see the conf file it's at: http://paprika.michvhf.com/~vev/kernel.conf Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include TEAM-OS2 Online Searchable Campground Listings http://www.camping-usa.com "There is no outfit less entitled to lecture me about bloat than the federal government" -- Tony Snow ========================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 21 21:29:47 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA19055 for freebsd-hackers-outgoing; Thu, 21 Jan 1999 21:29:47 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA19035 for ; Thu, 21 Jan 1999 21:29:42 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id VAA47602; Thu, 21 Jan 1999 21:29:33 -0800 (PST) (envelope-from dillon) Date: Thu, 21 Jan 1999 21:29:33 -0800 (PST) From: Matthew Dillon Message-Id: <199901220529.VAA47602@apollo.backplane.com> To: hackers@FreeBSD.ORG Subject: sorflush() bug fix in uipc_usrreq.c -- need someone to review this Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This fix is currently comitted to -4.x. I don't want to backport it to -3.x until I get an independant review. This code is ( I believe ) part of the message queue flushing for typically unix domain sockets, relating to file descriptor passing. This code is attempting to flush the in-transit file descriptors when both sides of the connection go poof. The problem ( I believe ) is that it is calling sorflush() potentially on non-sockets. While most uses of file descriptor passing pass only sockets, if this bug is hit for those uses that do not, it could corrupt kernel memory or cause a crash. I need someone to check the code and tell me I'm not blowing smoke before I backport this :-) -Matt Matthew Dillon *** uipc_usrreq.c 1998/10/25 17:44:51 1.37 --- uipc_usrreq.c 1999/01/21 08:03:49 *************** *** 1114,1121 **** /* * for each FD on our hit list, do the following two things */ ! for (i = nunref, fpp = extra_ref; --i >= 0; ++fpp) ! sorflush((struct socket *)(*fpp)->f_data); for (i = nunref, fpp = extra_ref; --i >= 0; ++fpp) closef(*fpp, (struct proc *) NULL); free((caddr_t)extra_ref, M_FILE); --- 1114,1124 ---- /* * for each FD on our hit list, do the following two things */ ! for (i = nunref, fpp = extra_ref; --i >= 0; ++fpp) { ! struct file *tfp = *fpp; ! if (tfp->f_type == DTYPE_SOCKET && tfp->f_data != NULL) ! sorflush((struct socket *)(tfp->f_data)); ! } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 21 22:35:26 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA27970 for freebsd-hackers-outgoing; Thu, 21 Jan 1999 22:35:26 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA27965 for ; Thu, 21 Jan 1999 22:35:23 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id WAA00535; Thu, 21 Jan 1999 22:35:11 -0800 (PST) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma000527; Thu, 21 Jan 99 22:34:44 -0800 Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id WAA10001; Thu, 21 Jan 1999 22:34:44 -0800 (PST) From: Archie Cobbs Message-Id: <199901220634.WAA10001@bubba.whistle.com> Subject: Re: Loading KLD from the kernel In-Reply-To: from Doug Rabson at "Jan 19, 99 09:21:18 am" To: dfr@nlsystems.com (Doug Rabson) Date: Thu, 21 Jan 1999 22:34:44 -0800 (PST) Cc: freebsd-hackers@FreeBSD.ORG, julian@whistle.com X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug Rabson writes: > > I tried simply incrementing lf->userrefs after loading the module > > from the kernel, but somehow it went back to zero (?) > > This field is a count of how many times a user has loaded the file using > kldload(2). It is there to prevent a user from unloading a file which was > loaded explicitly by the kernel (e.g. as a dependancy). Incrementing > userrefs should have worked though - can you watch what happens in the > debugger and find out why it is being reset? Well, now it seems to work.. Nevermind :-) -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 Thu Jan 21 22:39:14 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA28370 for freebsd-hackers-outgoing; Thu, 21 Jan 1999 22:39:14 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id WAA28363 for ; Thu, 21 Jan 1999 22:39:11 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 22637 invoked from network); 22 Jan 1999 06:39:00 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 22 Jan 1999 06:39:00 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id BAA00257; Fri, 22 Jan 1999 01:38:57 -0500 (EST) Message-Id: <199901220638.BAA00257@y.dyson.net> Subject: Error in vm_fault change To: hackers@FreeBSD.ORG, dillon@apollo.backplane.org Date: Fri, 22 Jan 1999 01:38:57 -0500 (EST) From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The below code removed has an effect almost the opposite of the complaint that it seems have remedied by removing it. This code snippet (which was very carefully thought out) provides a punishment for a process that is grabbing pages from the cache queue, and allows for THAT process to block, without loosing that page that is needed. Other processes will be runnable, if they have their needed memory pages, and not be disturbed. Those pages accessed by other runnable processes will not be freed by the pageout daemon (due to the stats that it accumulates.) Remember, that the cache+free counts is the traditional free count. This is a way that a process which does massive activations of free (cache) pages, that process will be throttled. This will also allow the pageout daemon to do the mapped page stats correctly. Note that previous discussions regarding proper buffer cache mgmt of inactive and cache pages (which I came up with a proper solution) are not appropriate here, since the buffer cache pages do need to be freed with "lower" priority. The wakeup of the daemon here, allows the system to catch up with the reactivations. The wakeup of the daemon in the buffer cache code is silly because the priority of the buffer cache items should most all of the time be lower priority, and the sophisticated priority calculations done by the pageout daemon become specious there. This is a *critical* feature, and progressive removal of such features will eventually hurt the already pretty good performance of the VM code under load. Please review the comment, because, again, the effect of the code removal does NOT IN ANY WAY help the situation that is described (in fact, it can make it worse.) #if 0 /* * Code removed. In a low-memory situation (say, a * memory-bound program is running), the last thing you * do is starve reactivations for other processes. * XXX we need to find a better way. */ if (((queue - fs.m->pc) == PQ_CACHE) && (cnt.v_free_count + cnt.v_cache_count) < cnt.v_free_min) { vm_page_activate(fs.m); unlock_and_deallocate(&fs); VM_WAIT; goto RetryFault; } #endif -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Thu Jan 21 22:57:03 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA00259 for freebsd-hackers-outgoing; Thu, 21 Jan 1999 22:57:03 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA00254 for ; Thu, 21 Jan 1999 22:57:00 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id WAA48081; Thu, 21 Jan 1999 22:56:49 -0800 (PST) (envelope-from dillon) Date: Thu, 21 Jan 1999 22:56:49 -0800 (PST) From: Matthew Dillon Message-Id: <199901220656.WAA48081@apollo.backplane.com> To: "John S. Dyson" Cc: hackers@FreeBSD.ORG Subject: Re: Error in vm_fault change References: <199901220638.BAA00257@y.dyson.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The problem is that in a heavy paging situation, which can be brought about by a single memory-hogging process, OTHER process's pages can wind up in the cache very easily. Consider tcsh or ssh -- all you have to do is not type for a few seconds in a heavily paging environment and some critical page will get thrown into the cache. The memory-hogging process, on the otherhand, tends to be allocating new pages or touching very recently allocated pages. This code does nothing to block the memory hogging process because those pages are not in the cache. In my tests, I was able to almost completely lockup a machine due to a single memory-hogging process. The memory hogging process caused the other processes to go into VM sleep in the code below. At *bset*, the other processes were able to page in a single page once a second or so... no where near enough to make them runnable long enough to be useable. Additionally, by sleeping, these process's pages then became eligable for getting thrown back into the cache. When I removed this piece of code, the machine remained useable with four memory hogging processes running. This code is punishing the wrong processes. -Matt :The below code removed has an effect almost the opposite of the :complaint that it seems have remedied by removing it. This :code snippet (which was very carefully thought out) provides :a punishment for a process that is grabbing pages from the cache :queue, and allows for THAT process to block, without loosing that :page that is needed. Other processes will be runnable, if they :have their needed memory pages, and not be disturbed. Those :pages accessed by other runnable processes will not be freed :by the pageout daemon (due to the stats that it accumulates.) : :Remember, that the cache+free counts is the traditional free :count. This is a way that a process which does massive activations :of free (cache) pages, that process will be throttled. This will :also allow the pageout daemon to do the mapped page stats correctly. : :Note that previous discussions regarding proper buffer cache mgmt :of inactive and cache pages (which I came up with a proper solution) :are not appropriate here, since the buffer cache pages do need to :be freed with "lower" priority. The wakeup of the daemon here, :allows the system to catch up with the reactivations. The wakeup :of the daemon in the buffer cache code is silly because the priority :of the buffer cache items should most all of the time be lower :priority, and the sophisticated priority calculations done by the :pageout daemon become specious there. : :This is a *critical* feature, and progressive removal of such features :will eventually hurt the already pretty good performance of the VM code :under load. : :Please review the comment, because, again, the effect of the code :removal does NOT IN ANY WAY help the situation that is described (in :fact, it can make it worse.) : :#if 0 : /* : * Code removed. In a low-memory situation (say, a : * memory-bound program is running), the last thing you : * do is starve reactivations for other processes. : * XXX we need to find a better way. : */ : if (((queue - fs.m->pc) == PQ_CACHE) && : (cnt.v_free_count + cnt.v_cache_count) < cnt.v_free_min) { : vm_page_activate(fs.m); : unlock_and_deallocate(&fs); : VM_WAIT; : goto RetryFault; : } :#endif :-- :John | Never try to teach a pig to sing, :dyson@iquest.net | it makes one look stupid :jdyson@nc.com | and it irritates the pig. : :To Unsubscribe: send mail to majordomo@FreeBSD.org :with "unsubscribe freebsd-hackers" in the body of the message : Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 00:06:23 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA06415 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 00:06:23 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bright.fx.genx.net (bright.fx.genx.net [206.64.4.154]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA06395; Fri, 22 Jan 1999 00:06:19 -0800 (PST) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.fx.genx.net (8.9.1/8.9.1) with ESMTP id DAA66522; Fri, 22 Jan 1999 03:12:13 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.fx.genx.net: bright owned process doing -bs Date: Fri, 22 Jan 1999 03:12:13 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.fx.genx.net To: hackers@FreeBSD.ORG cc: sparc@FreeBSD.ORG Subject: Need sparc openboot reference 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 Searching through http://docs.sun.com i'm having a hard time finding a reference on how to interact with the sparc 'BIOS'. can anyone give me a url (specific) or recommend a book that details this? since i have a 170/e and not a regular 170 (usparc) it's not booting netbsd correctly, i need to find out why. I am looking at netbsd/linux code right now, but a more descriptive to the point reference would be very helpful. thanks. oh and.... woo hoo! 4.0! 4.0! 4.0! 4.0! 4.0! thank you. Alfred Perlstein - Programmer, HotJobs Inc. - www.hotjobs.com -- There are operating systems, and then there's FreeBSD. -- http://www.freebsd.org/ 4.0-current (had to update the sig) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 00:28:47 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA08545 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 00:28:47 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA08517; Fri, 22 Jan 1999 00:28:44 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id RAA22642; Fri, 22 Jan 1999 17:28:24 +0900 (JST) Message-ID: <36A83677.DE06A25F@newsguy.com> Date: Fri, 22 Jan 1999 17:27:35 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: Alfred Perlstein CC: hackers@FreeBSD.ORG, sparc@FreeBSD.ORG Subject: Re: Need sparc openboot reference References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > > Searching through http://docs.sun.com i'm having a hard time finding a > reference on how to interact with the sparc 'BIOS'. > > can anyone give me a url (specific) or recommend a book that details this? http://playground.sun.com/pub/1275/ ftp://playground.sun.com/pub/p1275/ http://www.firmworks.com/ I guess Sun split out it's firmware section to form FirmWorks, and that's why you can't find anything. Generally, www.forth.org (*not* forth.com, though that one also include nice links :) is the best way to find something related to Forth. (Which means, of course, that I just have to put something there about loader.) -- Daniel C. Sobral (8-DCS) dcs@newsguy.com If you sell your soul to the Devil and all you get is an MCSE from it, you haven't gotten market rate. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 00:31:54 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA08847 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 00:31:54 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id AAA08839 for ; Fri, 22 Jan 1999 00:31:51 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 373 invoked from network); 22 Jan 1999 08:31:37 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 22 Jan 1999 08:31:37 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id DAA00487; Fri, 22 Jan 1999 03:31:37 -0500 (EST) Message-Id: <199901220831.DAA00487@y.dyson.net> Subject: Re: Error in vm_fault change In-Reply-To: <199901220656.WAA48081@apollo.backplane.com> from Matthew Dillon at "Jan 21, 99 10:56:49 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Fri, 22 Jan 1999 03:31:37 -0500 (EST) Cc: dyson@iquest.net, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon said: > > The problem is that in a heavy paging situation, which can be > brought about by a single memory-hogging process, OTHER > process's pages can wind up in the cache very easily. > There are other mechanisms that really do work (but are soft) in severe cases by setting the memory limit. The other purpose of that wakeup is to tell the pageout daemon that memory is low. If the other process's pages are placed onto the cache queue, then you have a severe thrashing situation. In that case, by eliminating this code, you are pessimizing the normal case of slight amount of paging, and making it work better for thrashing by a hoggy process. However, thrashing by a hoggy process should be managed by limits. :-(. You are breaking any notion of the pageout daemon keeping stats in normal low memory conditions, but thrashing is hopeless anyway without limits (am I repeating myself?) > > The memory-hogging process, on the otherhand, tends to be > allocating new pages or touching very recently allocated > pages. This code does nothing to block the memory hogging > process because those pages are not in the cache. > In that case, then it won't help, but then the soft memory limit code does (or perhaps a new set of hard memory limit code.) In severe thrashing conditions, then the argument that you make is silly anyway -- you do want to deactivate the hoggy processes pages then. In normal paging conditions, the simple block of the process is fine. Again, it seems that you might be testing in severe conditions, and applying a fix that breaks something for less severe conditions. (If you didn't play with the memory limits mechanisms, then any change that you have made like this is premature!!!) I think that you'll find that hard limits will kill system performance, but the soft limit code does work too softly. Maybe a scheme of high and low water mark will work. You really do NOT want to apply too many wierd heuristics, because they quickly become policy (and bad policy in some cases.) Given that, all you can do is to make the code work well for total throughput, and then add the biases with other mechanisms. You are breaking the "total throughput" situation, when you should be applying a specific bias to the bad process. Think global managment regarding the VM code, and let policy reside at another layer. If you try to put policy at the layer that you are trying to (by breaking an important wakeup), you'll just pessimize other applications. You want to push the knee out as far as you can, but total thrashing can be dealt with by limiting the errant process. When doing your test, set the soft limit to 1/5 or less of system memory. Memory will still get stolen from "nice" processes, but not as severely. The maximum memory per process shouldn't be set very high anyway -- it doesn't do anything until paging is needed anyway. > > Additionally, by sleeping, these process's pages then became eligable > for getting thrown back into the cache. > Only in severe thrashing situations, if you have pushed the pages through 10000's of pages of inactive and active queue then you are really running programs like testswap. That needs to be solved by a limits thing. The VM code is doing the correct thing by maximizing global performance. If you want to do policy things, then dont do it by breaking the rest of the system. > > When I removed this piece of code, the machine remained useable > with four memory hogging processes running. > QED. You are not running a real load. This is a perfect example of optimizing for the wrong thing. At this level, you want to maximize system throughput, even if the evil processes are the ones that provide that. Limiting the RSS of the evil processes should be done explicitly in a different way. (It could be called by vm_fault, but effectively, it would be at a different layer.) This is exactly the opposite kind of problem with Linux -- they have historically optimized for low level latency, and now, you are making the mistake that I made at first: optimize for a synthetically, rediculous high load. Think of the VM code as trying to maximize GLOBAL throughput. If you want to diddle things, that should be done differently (with an explicit RSS limiting code section.) My statement and assertion stands that by removing that code, then you are pessimizing the performance of the system under normal, light paging conditions. You have a good goal, but wrong fix. If you want to play with that, then you should consider trimming the RSS of the process while faulting the new page in. There is a soft trimming capability in the VM daemon, but it is slow. By having a higher hard limit, then the problem is solved (but as I implied above, might be tricky, due to the direct and sudden impact on the evil process performance.) This is a perfect example of working around an (artificial) problem with something that on the surface helps, but actually hurts in other ways. The negative feedback in the VM code, (which upon code inspection, might also be damaged by the way that the swap pager doesn't appear to block), is a way that the system can properly maximize global performance. Again, local peformance (truly penalizing really really bad processes) needs to be handled with explicit resource mgmt. Properly implemented, the explicit resource mgmt will leave more of the global resource available for the rest of the system, and again the system will adjust properly. By removing that piece of code, you will have removed a part of that proper adjustment mechanism. > This code is punishing the wrong processes. > I don't think so, but you have forgotten about the soft limit code. (BTW, I did have hard limit code, but it was so severe that the evil process paged too heavily.) Since we were mostly interested in global performance and not penalizing evil, errant processes that malloc and touch large numbers of pages, then I never installed the hard limit code. You really do have to wake-up the pagedaemon when the free memory is low, or you'll cause severe problems. If you have an evil process, then set the memory limit to 64M or less (much less than 1/2 of memory.) I just played with that earlier today, and it did work. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 01:04:08 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA12504 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 01:04:08 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA12499 for ; Fri, 22 Jan 1999 01:04:06 -0800 (PST) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id SAA26802; Fri, 22 Jan 1999 18:03:56 +0900 (JST) Message-ID: <36A83B24.4EB28834@newsguy.com> Date: Fri, 22 Jan 1999 17:47:32 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.ORG Subject: ports Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Who first came up with the idea? -- Daniel C. Sobral (8-DCS) dcs@newsguy.com If you sell your soul to the Devil and all you get is an MCSE from it, you haven't gotten market rate. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 01:10:42 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA12983 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 01:10:42 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id BAA12978 for ; Fri, 22 Jan 1999 01:10:40 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 16819 invoked from network); 22 Jan 1999 09:10:24 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 22 Jan 1999 09:10:24 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id EAA00340; Fri, 22 Jan 1999 04:10:22 -0500 (EST) Message-Id: <199901220910.EAA00340@y.dyson.net> Subject: Re: Error in vm_fault change (correct fix for problem posed) In-Reply-To: <199901220656.WAA48081@apollo.backplane.com> from Matthew Dillon at "Jan 21, 99 10:56:49 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Fri, 22 Jan 1999 04:10:22 -0500 (EST) Cc: dyson@iquest.net, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM916996222-326-0_ Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG --ELM916996222-326-0_ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Matthew Dillon said: > > The problem is that in a heavy paging situation, which can be > brought about by a single memory-hogging process, OTHER > process's pages can wind up in the cache very easily. > Attached is a rough copy of my current vm_fault (it is relative to earlier this month in FreeBSD.) Note that it isn't optimum, but is CORRECT regarding the problem that you posed (a hogging process.) It eats CPU, so needs some work -- but should not be brain surgery. I don't have time to perfect it, and this has too hard a limit, but works really well (under X especially :-)). -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. --ELM916996222-326-0_ Content-Type: *unknown*/x-csh Content-Disposition: attachment; filename=vm_fault.c Content-Description: /sys/vm/vm_fault.c Content-Transfer-Encoding: 7bit /* * Copyright (c) 1991, 1993 * The Regents of the University of California. All rights reserved. * Copyright (c) 1994 John S. Dyson * All rights reserved. * Copyright (c) 1994 David Greenman * All rights reserved. * * * This code is derived from software contributed to Berkeley by * The Mach Operating System project at Carnegie-Mellon University. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * This product includes software developed by the University of * California, Berkeley and its contributors. * 4. Neither the name of the University nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * from: @(#)vm_fault.c 8.4 (Berkeley) 1/12/94 * * * Copyright (c) 1987, 1990 Carnegie-Mellon University. * All rights reserved. * * Authors: Avadis Tevanian, Jr., Michael Wayne Young * * Permission to use, copy, modify and distribute this software and * its documentation is hereby granted, provided that both the copyright * notice and this permission notice appear in all copies of the * software, derivative works or modified versions, and any portions * thereof, and that both notices appear in supporting documentation. * * CARNEGIE MELLON ALLOWS FREE USE OF THIS SOFTWARE IN ITS "AS IS" * CONDITION. CARNEGIE MELLON DISCLAIMS ANY LIABILITY OF ANY KIND * FOR ANY DAMAGES WHATSOEVER RESULTING FROM THE USE OF THIS SOFTWARE. * * Carnegie Mellon requests users of this software to return to * * Software Distribution Coordinator or Software.Distribution@CS.CMU.EDU * School of Computer Science * Carnegie Mellon University * Pittsburgh PA 15213-3890 * * any improvements or extensions that they make and grant Carnegie the * rights to redistribute these changes. * * $Id: vm_fault.c,v 1.91 1998/11/25 07:40:49 dg Exp $ */ /* * Page fault handling module. */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include static int vm_fault_additional_pages __P((vm_page_t, int, int, vm_page_t *, int *)); #define VM_FAULT_READ_AHEAD 8 #define VM_FAULT_READ_BEHIND 7 #define VM_FAULT_READ (VM_FAULT_READ_AHEAD+VM_FAULT_READ_BEHIND+1) struct faultstate { vm_page_t m; vm_object_t object; vm_pindex_t pindex; vm_page_t first_m; vm_object_t first_object; vm_pindex_t first_pindex; vm_map_t map; vm_map_entry_t entry; int lookup_still_valid; struct vnode *vp; }; static void release_page(struct faultstate *fs) { vm_page_wakeup(fs->m); vm_page_deactivate(fs->m); fs->m = NULL; } static void unlock_map(struct faultstate *fs) { if (fs->lookup_still_valid) { vm_map_lookup_done(fs->map, fs->entry); fs->lookup_still_valid = FALSE; } } static void _unlock_things(struct faultstate *fs, int dealloc) { vm_object_pip_wakeup(fs->object); if (fs->object != fs->first_object) { vm_page_free(fs->first_m); vm_object_pip_wakeup(fs->first_object); fs->first_m = NULL; } if (dealloc) { vm_object_deallocate(fs->first_object); } unlock_map(fs); if (fs->vp != NULL) { vput(fs->vp); fs->vp = NULL; } } #define unlock_things(fs) _unlock_things(fs, 0) #define unlock_and_deallocate(fs) _unlock_things(fs, 1) static void _vm_page_limit(void) { struct proc *p = curproc; quad_t limit, size; if ((p->p_vmspace == NULL) || (p->p_flag & P_SYSTEM)) return; #if 0 limit = qmin(p->p_rlimit[RLIMIT_RSS].rlim_cur, p->p_rlimit[RLIMIT_RSS].rlim_max); #endif limit = p->p_rlimit[RLIMIT_RSS].rlim_max; size = p->p_vmspace->vm_pmap.pm_stats.resident_count * PAGE_SIZE; if (limit >= 0 && size >= limit) { vm_pageout_map_deactivate_pages(&p->p_vmspace->vm_map, (vm_pindex_t)(limit >> PAGE_SHIFT) ); } } /* * vm_fault: * * Handle a page fault occuring at the given address, * requiring the given permissions, in the map specified. * If successful, the page is inserted into the * associated physical map. * * NOTE: the given address should be truncated to the * proper page address. * * KERN_SUCCESS is returned if the page fault is handled; otherwise, * a standard error specifying why the fault is fatal is returned. * * * The map in question must be referenced, and remains so. * Caller may hold no locks. */ int vm_fault(vm_map_t map, vm_offset_t vaddr, vm_prot_t fault_type, int fault_flags) { vm_prot_t prot; int result; boolean_t wired; int map_generation; vm_page_t old_m; vm_object_t next_object; vm_page_t marray[VM_FAULT_READ]; int hardfault; int faultcount; struct faultstate fs; cnt.v_vm_faults++; /* needs lock XXX */ hardfault = 0; RetryFault:; if ((cnt.v_free_count + cnt.v_cache_count) < cnt.v_free_min) { _vm_page_limit(); } fs.map = map; /* * Find the backing store object and offset into it to begin the * search. */ if ((result = vm_map_lookup(&fs.map, vaddr, fault_type, &fs.entry, &fs.first_object, &fs.first_pindex, &prot, &wired)) != KERN_SUCCESS) { if ((result != KERN_PROTECTION_FAILURE) || ((fault_flags & VM_FAULT_WIRE_MASK) != VM_FAULT_USER_WIRE)) { return result; } /* * If we are user-wiring a r/w segment, and it is COW, then * we need to do the COW operation. Note that we don't COW * currently RO sections now, because it is NOT desirable * to COW .text. We simply keep .text from ever being COW'ed * and take the heat that one cannot debug wired .text sections. */ result = vm_map_lookup(&fs.map, vaddr, VM_PROT_READ|VM_PROT_WRITE|VM_PROT_OVERRIDE_WRITE, &fs.entry, &fs.first_object, &fs.first_pindex, &prot, &wired); if (result != KERN_SUCCESS) { return result; } /* * If we don't COW now, on a user wire, the user will never * be able to write to the mapping. If we don't make this * restriction, the bookkeeping would be nearly impossible. */ if ((fs.entry->protection & VM_PROT_WRITE) == 0) fs.entry->max_protection &= ~VM_PROT_WRITE; } map_generation = fs.map->timestamp; if (fs.entry->eflags & MAP_ENTRY_NOFAULT) { panic("vm_fault: fault on nofault entry, addr: %lx", (u_long)vaddr); } /* * Make a reference to this object to prevent its disposal while we * are messing with it. Once we have the reference, the map is free * to be diddled. Since objects reference their shadows (and copies), * they will stay around as well. */ vm_object_reference(fs.first_object); vm_object_pip_add(fs.first_object, 1); fs.vp = vnode_pager_lock(fs.first_object); if ((fault_type & VM_PROT_WRITE) && (fs.first_object->type == OBJT_VNODE)) { vm_freeze_copyopts(fs.first_object, fs.first_pindex, fs.first_pindex + 1); } fs.lookup_still_valid = TRUE; if (wired) fault_type = prot; fs.first_m = NULL; /* * Search for the page at object/offset. */ fs.object = fs.first_object; fs.pindex = fs.first_pindex; /* * See whether this page is resident */ while (TRUE) { if (fs.object->flags & OBJ_DEAD) { unlock_and_deallocate(&fs); return (KERN_PROTECTION_FAILURE); } fs.m = vm_page_lookup(fs.object, fs.pindex); if (fs.m != NULL) { int queue, s; /* * If the page is being brought in, wait for it and * then retry. */ if ((fs.m->flags & PG_BUSY) || (fs.m->busy && (fs.m->valid & VM_PAGE_BITS_ALL) != VM_PAGE_BITS_ALL)) { unlock_things(&fs); s = splvm(); if ((fs.m->flags & PG_BUSY) || (fs.m->busy && (fs.m->valid & VM_PAGE_BITS_ALL) != VM_PAGE_BITS_ALL)) { vm_page_flag_set(fs.m, PG_WANTED | PG_REFERENCED); cnt.v_intrans++; tsleep(fs.m, PSWP, "vmpfw", 0); } splx(s); vm_object_deallocate(fs.first_object); goto RetryFault; } queue = fs.m->queue; s = splvm(); vm_page_unqueue_nowakeup(fs.m); splx(s); /* * Mark page busy for other processes, and the pagedaemon. */ if (((queue - fs.m->pc) == PQ_CACHE) && (cnt.v_free_count + cnt.v_cache_count) < cnt.v_free_min) { vm_page_activate(fs.m); unlock_and_deallocate(&fs); VM_WAIT; goto RetryFault; } vm_page_busy(fs.m); if (((fs.m->valid & VM_PAGE_BITS_ALL) != VM_PAGE_BITS_ALL) && fs.m->object != kernel_object && fs.m->object != kmem_object) { goto readrest; } break; } if (((fs.object->type != OBJT_DEFAULT) && (((fault_flags & VM_FAULT_WIRE_MASK) == 0) || wired)) || (fs.object == fs.first_object)) { if (fs.pindex >= fs.object->size) { unlock_and_deallocate(&fs); return (KERN_PROTECTION_FAILURE); } /* * Allocate a new page for this object/offset pair. */ fs.m = vm_page_alloc(fs.object, fs.pindex, (fs.vp || fs.object->backing_object)? VM_ALLOC_NORMAL: VM_ALLOC_ZERO); if (fs.m == NULL) { unlock_and_deallocate(&fs); VM_WAIT; goto RetryFault; } } readrest: if (fs.object->type != OBJT_DEFAULT && (((fault_flags & VM_FAULT_WIRE_MASK) == 0) || wired)) { int rv; int reqpage; int ahead, behind; if (fs.first_object->behavior == OBJ_RANDOM) { ahead = 0; behind = 0; } else { behind = (vaddr - fs.entry->start) >> PAGE_SHIFT; if (behind > VM_FAULT_READ_BEHIND) behind = VM_FAULT_READ_BEHIND; ahead = ((fs.entry->end - vaddr) >> PAGE_SHIFT) - 1; if (ahead > VM_FAULT_READ_AHEAD) ahead = VM_FAULT_READ_AHEAD; } if ((fs.first_object->type != OBJT_DEVICE) && (fs.first_object->behavior == OBJ_SEQUENTIAL)) { vm_pindex_t firstpindex, tmppindex; if (fs.first_pindex < 2*(VM_FAULT_READ_BEHIND + VM_FAULT_READ_AHEAD + 1)) firstpindex = 0; else firstpindex = fs.first_pindex - 2*(VM_FAULT_READ_BEHIND + VM_FAULT_READ_AHEAD + 1); for(tmppindex = fs.first_pindex - 1; tmppindex >= firstpindex; --tmppindex) { vm_page_t mt; mt = vm_page_lookup( fs.first_object, tmppindex); if (mt == NULL || (mt->valid != VM_PAGE_BITS_ALL)) break; if (mt->busy || (mt->flags & (PG_BUSY | PG_FICTITIOUS)) || mt->hold_count || mt->wire_count) continue; if (mt->dirty == 0) vm_page_test_dirty(mt); if (mt->dirty) { vm_page_protect(mt, VM_PROT_NONE); vm_page_deactivate(mt); } else { vm_page_cache(mt); } } ahead += behind; behind = 0; } /* * now we find out if any other pages should be paged * in at this time this routine checks to see if the * pages surrounding this fault reside in the same * object as the page for this fault. If they do, * then they are faulted in also into the object. The * array "marray" returned contains an array of * vm_page_t structs where one of them is the * vm_page_t passed to the routine. The reqpage * return value is the index into the marray for the * vm_page_t passed to the routine. */ faultcount = vm_fault_additional_pages( fs.m, behind, ahead, marray, &reqpage); /* * Call the pager to retrieve the data, if any, after * releasing the lock on the map. */ unlock_map(&fs); rv = faultcount ? vm_pager_get_pages(fs.object, marray, faultcount, reqpage) : VM_PAGER_FAIL; if (rv == VM_PAGER_OK) { /* * Found the page. Leave it busy while we play * with it. */ /* * Relookup in case pager changed page. Pager * is responsible for disposition of old page * if moved. */ fs.m = vm_page_lookup(fs.object, fs.pindex); if(!fs.m) { unlock_and_deallocate(&fs); goto RetryFault; } hardfault++; break; } /* * Remove the bogus page (which does not exist at this * object/offset); before doing so, we must get back * our object lock to preserve our invariant. * * Also wake up any other process that may want to bring * in this page. * * If this is the top-level object, we must leave the * busy page to prevent another process from rushing * past us, and inserting the page in that object at * the same time that we are. */ if (rv == VM_PAGER_ERROR) printf("vm_fault: pager read error, pid %d (%s)\n", curproc->p_pid, curproc->p_comm); /* * Data outside the range of the pager or an I/O error */ /* * XXX - the check for kernel_map is a kludge to work * around having the machine panic on a kernel space * fault w/ I/O error. */ if (((fs.map != kernel_map) && (rv == VM_PAGER_ERROR)) || (rv == VM_PAGER_BAD)) { vm_page_free(fs.m); fs.m = NULL; unlock_and_deallocate(&fs); return ((rv == VM_PAGER_ERROR) ? KERN_FAILURE : KERN_PROTECTION_FAILURE); } if (fs.object != fs.first_object) { vm_page_free(fs.m); fs.m = NULL; /* * XXX - we cannot just fall out at this * point, m has been freed and is invalid! */ } } /* * We get here if the object has default pager (or unwiring) or the * pager doesn't have the page. */ if (fs.object == fs.first_object) fs.first_m = fs.m; /* * Move on to the next object. Lock the next object before * unlocking the current one. */ fs.pindex += OFF_TO_IDX(fs.object->backing_object_offset); next_object = fs.object->backing_object; if (next_object == NULL) { /* * If there's no object left, fill the page in the top * object with zeros. */ if (fs.object != fs.first_object) { vm_object_pip_wakeup(fs.object); fs.object = fs.first_object; fs.pindex = fs.first_pindex; fs.m = fs.first_m; } fs.first_m = NULL; if ((fs.m->flags & PG_ZERO) == 0) { vm_page_zero_fill(fs.m); cnt.v_ozfod++; } cnt.v_zfod++; break; } else { if (fs.object != fs.first_object) { vm_object_pip_wakeup(fs.object); } fs.object = next_object; vm_object_pip_add(fs.object, 1); } } #if defined(DIAGNOSTIC) if ((fs.m->flags & PG_BUSY) == 0) panic("vm_fault: not busy after main loop"); #endif /* * PAGE HAS BEEN FOUND. [Loop invariant still holds -- the object lock * is held.] */ old_m = fs.m; /* save page that would be copied */ /* * If the page is being written, but isn't already owned by the * top-level object, we have to copy it into a new page owned by the * top-level object. */ if (fs.object != fs.first_object) { /* * We only really need to copy if we want to write it. */ if (fault_type & VM_PROT_WRITE) { /* * This allows pages to be virtually copied from a backing_object * into the first_object, where the backing object has no other * refs to it, and cannot gain any more refs. Instead of a * bcopy, we just move the page from the backing object to the * first object. Note that we must mark the page dirty in the * first object so that it will go out to swap when needed. */ if (map_generation == fs.map->timestamp && /* * Only one shadow object */ (fs.object->shadow_count == 1) && /* * No COW refs, except us */ (fs.object->ref_count == 1) && /* * Noone else can look this object up */ (fs.object->handle == NULL) && /* * No other ways to look the object up */ ((fs.object->type == OBJT_DEFAULT) || (fs.object->type == OBJT_SWAP)) && /* * We don't chase down the shadow chain */ (fs.object == fs.first_object->backing_object) && /* * grab the lock if we need to */ (fs.lookup_still_valid || (((fs.entry->eflags & MAP_ENTRY_IS_A_MAP) == 0) && lockmgr(&fs.map->lock, LK_EXCLUSIVE|LK_NOWAIT, (void *)0, curproc) == 0))) { fs.lookup_still_valid = 1; /* * get rid of the unnecessary page */ vm_page_protect(fs.first_m, VM_PROT_NONE); vm_page_free(fs.first_m); fs.first_m = NULL; /* * grab the page and put it into the process'es object */ vm_page_rename(fs.m, fs.first_object, fs.first_pindex); fs.first_m = fs.m; fs.first_m->dirty = VM_PAGE_BITS_ALL; vm_page_busy(fs.first_m); fs.m = NULL; cnt.v_cow_optim++; } else { /* * Oh, well, lets copy it. */ vm_page_copy(fs.m, fs.first_m); } if (fs.m) { /* * We no longer need the old page or object. */ release_page(&fs); } vm_object_pip_wakeup(fs.object); /* * Only use the new page below... */ cnt.v_cow_faults++; fs.m = fs.first_m; fs.object = fs.first_object; fs.pindex = fs.first_pindex; } else { prot &= ~VM_PROT_WRITE; } } /* * We must verify that the maps have not changed since our last * lookup. */ if (!fs.lookup_still_valid && (fs.map->timestamp != map_generation)) { vm_object_t retry_object; vm_pindex_t retry_pindex; vm_prot_t retry_prot; /* * Since map entries may be pageable, make sure we can take a * page fault on them. */ /* * To avoid trying to write_lock the map while another process * has it read_locked (in vm_map_pageable), we do not try for * write permission. If the page is still writable, we will * get write permission. If it is not, or has been marked * needs_copy, we enter the mapping without write permission, * and will merely take another fault. */ result = vm_map_lookup(&fs.map, vaddr, fault_type & ~VM_PROT_WRITE, &fs.entry, &retry_object, &retry_pindex, &retry_prot, &wired); map_generation = fs.map->timestamp; /* * If we don't need the page any longer, put it on the active * list (the easiest thing to do here). If no one needs it, * pageout will grab it eventually. */ if (result != KERN_SUCCESS) { release_page(&fs); unlock_and_deallocate(&fs); return (result); } fs.lookup_still_valid = TRUE; if ((retry_object != fs.first_object) || (retry_pindex != fs.first_pindex)) { release_page(&fs); unlock_and_deallocate(&fs); goto RetryFault; } /* * Check whether the protection has changed or the object has * been copied while we left the map unlocked. Changing from * read to write permission is OK - we leave the page * write-protected, and catch the write fault. Changing from * write to read permission means that we can't mark the page * write-enabled after all. */ prot &= retry_prot; } /* * Put this page into the physical map. We had to do the unlock above * because pmap_enter may cause other faults. We don't put the page * back on the active queue until later so that the page-out daemon * won't find us (yet). */ if (prot & VM_PROT_WRITE) { vm_page_flag_set(fs.m, PG_WRITEABLE); vm_object_set_flag(fs.m->object, OBJ_WRITEABLE|OBJ_MIGHTBEDIRTY); /* * If the fault is a write, we know that this page is being * written NOW. This will save on the pmap_is_modified() calls * later. */ if (fault_flags & VM_FAULT_DIRTY) { fs.m->dirty = VM_PAGE_BITS_ALL; } } unlock_things(&fs); fs.m->valid = VM_PAGE_BITS_ALL; vm_page_flag_clear(fs.m, PG_ZERO); pmap_enter(fs.map->pmap, vaddr, VM_PAGE_TO_PHYS(fs.m), prot, wired); if (((fault_flags & VM_FAULT_WIRE_MASK) == 0) && (wired == 0)) { pmap_prefault(fs.map->pmap, vaddr, fs.entry); } vm_page_flag_set(fs.m, PG_MAPPED|PG_REFERENCED); if (fault_flags & VM_FAULT_HOLD) vm_page_hold(fs.m); /* * If the page is not wired down, then put it where the pageout daemon * can find it. */ if (fault_flags & VM_FAULT_WIRE_MASK) { if (wired) vm_page_wire(fs.m); else vm_page_unwire(fs.m, 1); } else { vm_page_activate(fs.m); } if (curproc && (curproc->p_flag & P_INMEM) && curproc->p_stats) { if (hardfault) { curproc->p_stats->p_ru.ru_majflt++; } else { curproc->p_stats->p_ru.ru_minflt++; } } /* * Unlock everything, and return */ vm_page_wakeup(fs.m); vm_object_deallocate(fs.first_object); return (KERN_SUCCESS); } /* * vm_fault_wire: * * Wire down a range of virtual addresses in a map. */ int vm_fault_wire(map, start, end) vm_map_t map; vm_offset_t start, end; { register vm_offset_t va; register pmap_t pmap; int rv; pmap = vm_map_pmap(map); /* * Inform the physical mapping system that the range of addresses may * not fault, so that page tables and such can be locked down as well. */ pmap_pageable(pmap, start, end, FALSE); /* * We simulate a fault to get the page and enter it in the physical * map. */ for (va = start; va < end; va += PAGE_SIZE) { rv = vm_fault(map, va, VM_PROT_READ|VM_PROT_WRITE, VM_FAULT_CHANGE_WIRING); if (rv) { if (va != start) vm_fault_unwire(map, start, va); return (rv); } } return (KERN_SUCCESS); } /* * vm_fault_user_wire: * * Wire down a range of virtual addresses in a map. This * is for user mode though, so we only ask for read access * on currently read only sections. */ int vm_fault_user_wire(map, start, end) vm_map_t map; vm_offset_t start, end; { register vm_offset_t va; register pmap_t pmap; int rv; pmap = vm_map_pmap(map); /* * Inform the physical mapping system that the range of addresses may * not fault, so that page tables and such can be locked down as well. */ pmap_pageable(pmap, start, end, FALSE); /* * We simulate a fault to get the page and enter it in the physical * map. */ for (va = start; va < end; va += PAGE_SIZE) { rv = vm_fault(map, va, VM_PROT_READ, VM_FAULT_USER_WIRE); if (rv) { if (va != start) vm_fault_unwire(map, start, va); return (rv); } } return (KERN_SUCCESS); } /* * vm_fault_unwire: * * Unwire a range of virtual addresses in a map. */ void vm_fault_unwire(map, start, end) vm_map_t map; vm_offset_t start, end; { register vm_offset_t va, pa; register pmap_t pmap; pmap = vm_map_pmap(map); /* * Since the pages are wired down, we must be able to get their * mappings from the physical map system. */ for (va = start; va < end; va += PAGE_SIZE) { pa = pmap_extract(pmap, va); if (pa != (vm_offset_t) 0) { pmap_change_wiring(pmap, va, FALSE); vm_page_unwire(PHYS_TO_VM_PAGE(pa), 1); } } /* * Inform the physical mapping system that the range of addresses may * fault, so that page tables and such may be unwired themselves. */ pmap_pageable(pmap, start, end, TRUE); } /* * Routine: * vm_fault_copy_entry * Function: * Copy all of the pages from a wired-down map entry to another. * * In/out conditions: * The source and destination maps must be locked for write. * The source map entry must be wired down (or be a sharing map * entry corresponding to a main map entry that is wired down). */ void vm_fault_copy_entry(dst_map, src_map, dst_entry, src_entry) vm_map_t dst_map; vm_map_t src_map; vm_map_entry_t dst_entry; vm_map_entry_t src_entry; { vm_object_t dst_object; vm_object_t src_object; vm_ooffset_t dst_offset; vm_ooffset_t src_offset; vm_prot_t prot; vm_offset_t vaddr; vm_page_t dst_m; vm_page_t src_m; #ifdef lint src_map++; #endif /* lint */ src_object = src_entry->object.vm_object; src_offset = src_entry->offset; /* * Create the top-level object for the destination entry. (Doesn't * actually shadow anything - we copy the pages directly.) */ dst_object = vm_object_allocate(OBJT_DEFAULT, (vm_size_t) OFF_TO_IDX(dst_entry->end - dst_entry->start)); dst_entry->object.vm_object = dst_object; dst_entry->offset = 0; prot = dst_entry->max_protection; /* * Loop through all of the pages in the entry's range, copying each * one from the source object (it should be there) to the destination * object. */ for (vaddr = dst_entry->start, dst_offset = 0; vaddr < dst_entry->end; vaddr += PAGE_SIZE, dst_offset += PAGE_SIZE) { /* * Allocate a page in the destination object */ do { dst_m = vm_page_alloc(dst_object, OFF_TO_IDX(dst_offset), VM_ALLOC_NORMAL); if (dst_m == NULL) { VM_WAIT; } } while (dst_m == NULL); /* * Find the page in the source object, and copy it in. * (Because the source is wired down, the page will be in * memory.) */ src_m = vm_page_lookup(src_object, OFF_TO_IDX(dst_offset + src_offset)); if (src_m == NULL) panic("vm_fault_copy_wired: page missing"); vm_page_copy(src_m, dst_m); /* * Enter it in the pmap... */ vm_page_flag_clear(dst_m, PG_ZERO); pmap_enter(dst_map->pmap, vaddr, VM_PAGE_TO_PHYS(dst_m), prot, FALSE); vm_page_flag_set(dst_m, PG_WRITEABLE|PG_MAPPED); /* * Mark it no longer busy, and put it on the active list. */ vm_page_activate(dst_m); vm_page_wakeup(dst_m); } } /* * This routine checks around the requested page for other pages that * might be able to be faulted in. This routine brackets the viable * pages for the pages to be paged in. * * Inputs: * m, rbehind, rahead * * Outputs: * marray (array of vm_page_t), reqpage (index of requested page) * * Return value: * number of pages in marray */ static int vm_fault_additional_pages(m, rbehind, rahead, marray, reqpage) vm_page_t m; int rbehind; int rahead; vm_page_t *marray; int *reqpage; { int i,j; vm_object_t object; vm_pindex_t pindex, startpindex, endpindex, tpindex; vm_page_t rtm; int cbehind, cahead; object = m->object; pindex = m->pindex; /* * we don't fault-ahead for device pager */ if (object->type == OBJT_DEVICE) { *reqpage = 0; marray[0] = m; return 1; } /* * if the requested page is not available, then give up now */ if (!vm_pager_has_page(object, OFF_TO_IDX(object->paging_offset) + pindex, &cbehind, &cahead)) { return 0; } if ((cbehind == 0) && (cahead == 0)) { *reqpage = 0; marray[0] = m; return 1; } if (rahead > cahead) { rahead = cahead; } if (rbehind > cbehind) { rbehind = cbehind; } /* * try to do any readahead that we might have free pages for. */ if ((rahead + rbehind) > ((cnt.v_free_count + cnt.v_cache_count) - cnt.v_free_reserved)) { vm_pageout_deficit += rahead + rbehind; pagedaemon_wakeup(); marray[0] = m; *reqpage = 0; return 1; } /* * scan backward for the read behind pages -- in memory */ if (pindex > 0) { if (rbehind > pindex) { rbehind = pindex; startpindex = 0; } else { startpindex = pindex - rbehind; } for ( tpindex = pindex - 1; tpindex >= startpindex; tpindex -= 1) { if (vm_page_lookup( object, tpindex)) { startpindex = tpindex + 1; break; } if (tpindex == 0) break; } for(i = 0, tpindex = startpindex; tpindex < pindex; i++, tpindex++) { rtm = vm_page_alloc(object, tpindex, VM_ALLOC_NORMAL); if (rtm == NULL) { for (j = 0; j < i; j++) { vm_page_free(marray[j]); } marray[0] = m; *reqpage = 0; return 1; } marray[i] = rtm; } } else { startpindex = 0; i = 0; } marray[i] = m; /* page offset of the required page */ *reqpage = i; tpindex = pindex + 1; i++; /* * scan forward for the read ahead pages */ endpindex = tpindex + rahead; if (endpindex > object->size) endpindex = object->size; for( ; tpindex < endpindex; i++, tpindex++) { if (vm_page_lookup(object, tpindex)) { break; } rtm = vm_page_alloc(object, tpindex, VM_ALLOC_NORMAL); if (rtm == NULL) { break; } marray[i] = rtm; } /* return number of bytes of pages */ return i; } --ELM916996222-326-0_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 03:46:25 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA29028 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 03:46:25 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA29023 for ; Fri, 22 Jan 1999 03:46:24 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id DAA52510; Fri, 22 Jan 1999 03:46:13 -0800 (PST) (envelope-from dillon) Date: Fri, 22 Jan 1999 03:46:13 -0800 (PST) From: Matthew Dillon Message-Id: <199901221146.DAA52510@apollo.backplane.com> To: "John S. Dyson" Cc: hackers@FreeBSD.ORG Subject: Re: Error in vm_fault change References: <199901220831.DAA00487@y.dyson.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> When I removed this piece of code, the machine remained useable :> with four memory hogging processes running. :> :QED. You are not running a real load. This is a perfect example of optimizing :for the wrong thing. At this level, you want to maximize system throughput, even :if the evil processes are the ones that provide that. Limiting the RSS of the :evil processes should be done explicitly in a different way. (It could be called Sure I am... I am simulating what happens when a couple of users all decide to run the 'nn' newsreader at the same time. In BEST's early days, when the machines had only 128MB of ram, the above occured about half a dozen times every day. Each time the even would cause the machine to basically stop for 10 seconds while it furiously rearranged memory. The only reason it doesn't happen now is that we throw 256MB (minimum) on the platforms and the cache is big enough to absorb nn's 10-15 MB footprint without going into a tizzy. Basically, what happens is that a few programs create a thrashing situation The proper action is to *not* start penalizing the rest of the machine! My personal opinion is that memory allocation needs some sort of scheduler - something that works somewhat like the cpu scheduler but schedules memory rather then cpu. This way the static processes are still allowed to run while the heavy-memory processes ( in a low memory situation ) get blocked more. With this in place, the pager gets a view of the overall load on the machine that is not skewed by a small number of memory hogging processes. A scheduler is not an artificial block/sleep mechanism such as the piece of code I ripped out -- it is scheduling available free memory to processes needing memory based on their memory-hogging priority. So, for example, a process that has been freeing memory recently is given a very high allocation priority whereas a process that has been allocating a lot of memory is given a lower allocation priority. The priority of the requester is run through the scheduler -- say a fractional/fair scheduler, which decides how to dole out the available free memory. Processes only block when memory is exhausted, and then only based on their scheduling priority. The root ssh login and shell still works, as do the processes that tend to be memory-neutral. A fractional/fair scheduler usually has a very smooth degredation curve, too. -Matt :-- :John | Never try to teach a pig to sing, :dyson@iquest.net | it makes one look stupid :jdyson@nc.com | and it irritates the pig. Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 04:19:35 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA05376 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 04:19:35 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA05341 for ; Fri, 22 Jan 1999 04:19:27 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by nlsystems.com (8.9.1/8.8.5) with SMTP id MAA60013; Fri, 22 Jan 1999 12:20:09 GMT Date: Fri, 22 Jan 1999 12:20:09 +0000 (GMT) From: Doug Rabson To: "David E. Cross" cc: hackers@FreeBSD.ORG Subject: Re: device driver writing In-Reply-To: <199901211600.LAA28568@cs.rpi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 21 Jan 1999, David E. Cross wrote: > > I am attempting to write a very simple device driver for the serial port > (8250 only) as a KLD (this is for demonstration purposes to a class). I admit > I have never written a UNIX device drvier before, but KLD makes it look so > easy :). The problem that I am having is that I do not know how to hook > in to the interupts. I have looked at sio.c and noticde the > 'struct isa_device', that contains the information I want to set (I think), > but I do not see where or how this information is registered with the kernel. > Any pointers/sample code would be appreciated, thanks :) Unfortunately the ISA code in -current is not well suited to loadable drivers. It would probably be possible to call intr_create() to set up an interrupt but it would be ugly. Garrett has been working on the i386 isa code to move it to the new device framework in -current. When that happens, things will be a lot easier. I don't know how long it will be before this arrives in the tree though :-(. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 04:24:07 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA07718 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 04:24:07 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA07712 for ; Fri, 22 Jan 1999 04:24:04 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from localhost (dfr@localhost) by nlsystems.com (8.9.1/8.8.5) with SMTP id MAA60028; Fri, 22 Jan 1999 12:25:08 GMT Date: Fri, 22 Jan 1999 12:25:08 +0000 (GMT) From: Doug Rabson To: Matthew Dillon cc: hackers@FreeBSD.ORG Subject: Re: sorflush() bug fix in uipc_usrreq.c -- need someone to review this In-Reply-To: <199901220529.VAA47602@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 21 Jan 1999, Matthew Dillon wrote: > This fix is currently comitted to -4.x. I don't want to backport it to > -3.x until I get an independant review. > > This code is ( I believe ) part of the message queue flushing for > typically unix domain sockets, relating to file descriptor passing. > This code is attempting to flush the in-transit file descriptors when > both sides of the connection go poof. > > The problem ( I believe ) is that it is calling sorflush() potentially > on non-sockets. While most uses of file descriptor passing pass only > sockets, if this bug is hit for those uses that do not, it could corrupt > kernel memory or cause a crash. > > I need someone to check the code and tell me I'm not blowing smoke before > I backport this :-) It looks right to me but I'm not very familiar with that section of code. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 04:38:59 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA10749 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 04:38:59 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from implode.root.com (root.com [208.221.12.98]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA10744 for ; Fri, 22 Jan 1999 04:38:58 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id EAA27145; Fri, 22 Jan 1999 04:34:50 -0800 (PST) Message-Id: <199901221234.EAA27145@implode.root.com> To: Matthew Dillon cc: "John S. Dyson" , hackers@FreeBSD.ORG Subject: Re: Error in vm_fault change In-reply-to: Your message of "Fri, 22 Jan 1999 03:46:13 PST." <199901221146.DAA52510@apollo.backplane.com> From: David Greenman Reply-To: dg@root.com Date: Fri, 22 Jan 1999 04:34:50 -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > A scheduler is not an artificial block/sleep mechanism such as the > piece of code I ripped out -- it is scheduling available free memory > to processes needing memory based on their memory-hogging priority. > So, for example, a process that has been freeing memory recently is > given a very high allocation priority whereas a process that has been > allocating a lot of memory is given a lower allocation priority. The > priority of the requester is run through the scheduler -- say a > fractional/fair scheduler, which decides how to dole out the available > free memory. Processes only block when memory is exhausted, and then > only based on their scheduling priority. The root ssh login and shell > still works, as do the processes that tend to be memory-neutral. A > fractional/fair scheduler usually has a very smooth degredation curve, > too. What John is saying is that such a policy will usually not provide the best overall system performance - in fact it can be a major pessimization. Both John and I have done literally years of experimentation with various algorithms, testing overall performance as well as effect on interactive response times and what was in FreeBSD was a pretty good balance between these two. That's not to say that it was the "best" balance or that it can't be significantly improved, but some of the things you're proposing are really quite counter to the experiance we've gained in this area. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 06:12:08 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA20957 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 06:12:08 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns.oeno.com (ns.oeno.com [194.100.99.145]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA20951 for ; Fri, 22 Jan 1999 06:12:04 -0800 (PST) (envelope-from will@ns.oeno.com) Received: (qmail 19074 invoked by uid 1001); 22 Jan 1999 12:24:50 -0000 To: dillon@apollo.backplane.com (Matthew Dillon) Cc: hackers@FreeBSD.ORG Subject: Re: Review and report of linux kernel VM References: <199901140720.XAA22609@apollo.backplane.com> From: Ville-Pertti Keinonen Date: 22 Jan 1999 14:23:39 +0200 In-Reply-To: dillon@apollo.backplane.com's message of "14 Jan 1999 09:21:08 +0200" Message-ID: <8690evpkc4.fsf@not.oeno.com> Lines: 69 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG dillon@apollo.backplane.com (Matthew Dillon) writes: > In general terms, linux's VM system is much cleaner then FreeBSD's... and > I mean a *whole lot* cleaner, but at the cost of eating some extra memory. Whaat? You appear to be confusing cleanliness (as I understand it, and I'm afraid that many other readers of your review might understand it) with simplicity. I would claim the exact opposite. The Linux VM system is simpler, but far *less* clean because of the very inflexible (almost non-existent) "layers". Not to mention the code, which shares the (IMHO) poor source organization and apparently arbitrary dependencies of Linux as a whole. The Linux VM system looks like it hasn't been designed at all, just implemented. The basic organization (although not that much of the code) is still based on versions of Linux that only had one page table for all tasks, was fully i386-specific (complete with hard-coded constants all over the place), implemented shared libraries by having a per-task array of shared library addresses, sharing pages by scanning through all tasks to find one with the same library etc. Subsystems in Linux don't seem to get re-written, they only evolve. Perhaps my critique addresses the Linux code more than the functionality...but they are related. What's my definition of clean then? For example, common operations shouldn't need to resort to brute-forceish approaches (not in many cases, anyhow). Which reminds me, your swp_pager_meta_free_all looks a bit frightening...do you intend to keep it like it is? > Problems ... In addition to the problems you stated, as far as I can tell, swap backing is not shared for copy-on-write associations (copy-on-write pages get swapped out multiple times, all but the last don't free any memory) unless the page was swapped out when the maps were copied, in which case it ends up copy-on-access...maybe, I'm not sure whether the swap cache eliminates this. This (and many of the things you pointed out) is due to the simplistic approach where pages don't really have an identity (only mappings) unless they are backed by an inode. Which is perhaps at the core of most of the algorithmic differences between Mach/4.4BSD and Linux VM systems. IMHO pages need to have an identity even when they are not associated with files (based on a quick glance, NetBSD's UVM seems to retain this property while optimizing the management of anonymous pages. I'm not convinced in terms of the choice of data structures for the anon maps in UVM, though). > reference information. Instead, it uses the vm_object and pmap modules. > I actually like this feature of FreeBSD. A lot. Additionally, the way FreeBSD does things has better potential for concurrency (even though the locks have been ripped out) compared to Linux. > Linux demarks interrupts from supervisor code much better then we do. You seem to consider simpler to mean cleaner/better. Although in this case, I'd agree that much of the complexity of FreeBSD is unnecessary. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 09:50:11 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA13974 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 09:50:11 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id JAA13950 for ; Fri, 22 Jan 1999 09:50:04 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 22695 invoked from network); 22 Jan 1999 17:49:52 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 22 Jan 1999 17:49:52 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id MAA03968; Fri, 22 Jan 1999 12:49:50 -0500 (EST) Message-Id: <199901221749.MAA03968@y.dyson.net> Subject: Re: Error in vm_fault change In-Reply-To: <199901221146.DAA52510@apollo.backplane.com> from Matthew Dillon at "Jan 22, 99 03:46:13 am" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Fri, 22 Jan 1999 12:49:50 -0500 (EST) Cc: dyson@iquest.net, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon said: > > Basically, what happens is that a few programs create a thrashing situation > The proper action is to *not* start penalizing the rest of the machine! > Your "fix" doesn't really do that, but works around it in a very rough and subobtimal way. It is kind of like a drug that isn't very specific and has lots of side effects. A more specific fix is needed. > > My personal opinion is that memory allocation needs some sort of > scheduler - something that works somewhat like the cpu scheduler but > schedules memory rather then cpu. This way the static processes are > still allowed to run while the heavy-memory processes ( in a low memory > situation ) get blocked more. With this in place, the pager gets a > view of the overall load on the machine that is not skewed by a small > number of memory hogging processes. > Please refer to the code that I supllied to you. It isn't perfect, but with only a few mods (cleanups), it does work very well. The key to a real fix is some hysteresis (which I am running nicely -- and it decreases CPU overhead significantly.) Both memory usage is controlled, AND the undesirable and unfortunate loss of the wait on low free memory queues is now retained. > > A scheduler is not an artificial block/sleep mechanism such as the > piece of code I ripped out -- it is scheduling available free memory > to processes needing memory based on their memory-hogging priority. > Bzzzt... Never, never, never schedule (or think) in terms of "priority." It is the wrong parameter. Priority is only a convienience term for comp-sci classes that unfortunately gets carried through into practice. Set your scheduling goals "max memory", time deadline, or somesuch. Then calculate processes to run, block, or available memory for the process based upon those factors (in the best case, bin packing -- but that isn't often practical.) The mod that I submitted is based upon a max memory goal. I have been through this over and over again, on OSes that try to resolve things into priority.... Yuck!!! "Priority" ends up being a function of too many variables to be meaningful. The only way that priority is useful is for a very short term scheduling parameter -- not useful in longer term resource mgmt though. One shouldn't really think in terms of anything but demand on and requirements of resources. Attempts to give "bonus points" to "nice processes" complicates matters, and obfuscates the issue of "goals" and "requirements." Those processes that are easy on the system will naturally be treated nicely by the system, given a proper scheme. (Actually, "bonus points" will severely negatively affect the attainment of "goals" and "requirements.") It is very important to have a focused goal of requirements, and solve them. Trying to fix a problem with something that is only borne out by a simple anecdotal example is really not a good thing in the long term. This will build upon itself until the system really performs poorly. Understanding is the key. Global policy needs to optimize for performance, and local policy needs to perform resource limiting. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 10:14:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA17075 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 10:14:53 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from korin.warman.org.pl (korin.nask.waw.pl [195.187.243.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA17067; Fri, 22 Jan 1999 10:14:50 -0800 (PST) (envelope-from abial@nask.pl) Received: from localhost (abial@localhost) by korin.warman.org.pl (8.9.1/8.8.5) with SMTP id TAA20228; Fri, 22 Jan 1999 19:20:05 +0100 (CET) X-Authentication-Warning: korin.warman.org.pl: abial owned process doing -bs Date: Fri, 22 Jan 1999 19:20:05 +0100 (CET) From: Andrzej Bialecki X-Sender: abial@korin.warman.org.pl To: Warner Losh cc: Matthew Dillon , current@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: Heads up! New swapper and VM changes being committed to -4.x tonight. In-Reply-To: <199901211853.LAA79083@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 21 Jan 1999, Warner Losh wrote: > In message Andrzej Bialecki writes: > : I'm more than willing to test it in low memory conditions.. :-) I have > : that special 386SX/4MB RAM machine in the corner to test things like > : picobsd memory requirements... > > So how well does this work? I have a 4MB machine that I'd like to run > FreeBSD on, including X on a low res screen... Hmmm.. Did I mention that I just left for a week to another country? Probably not :) I'll do the testing when I'm back. Andrzej Bialecki -------------------- ++-------++ ------------------------------------- ||PicoBSD|| FreeBSD in your pocket? Go and see: Research & Academic |+-------+| "Small & Embedded FreeBSD" Network in Poland | |TT~~~| | http://www.freebsd.org/~picobsd/ -------------------- ~-+==---+-+ ------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 11:14:58 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA26532 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 11:14:58 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA26527 for ; Fri, 22 Jan 1999 11:14:57 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id LAA26857; Fri, 22 Jan 1999 11:14:47 -0800 (PST) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.1/8.9.1) id LAA10262; Fri, 22 Jan 1999 11:14:46 -0800 (PST) (envelope-from jdp@polstra.com) Date: Fri, 22 Jan 1999 11:14:46 -0800 (PST) Message-Id: <199901221914.LAA10262@vashon.polstra.com> To: dave@jetcafe.org Subject: Re: ELF cross compiling on 2.2.X Newsgroups: polstra.freebsd.hackers In-Reply-To: <199901210702.XAA12368@hokkshideh.jetcafe.org> Organization: Polstra & Co., Seattle, WA Cc: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <199901210702.XAA12368@hokkshideh.jetcafe.org>, Dave Hayes wrote: > Well after searching the mail archives, I still cannot find > the 'elfkit'. Give up, it's long gone. It was for FreeBSD-2.1.0, anyway, and is now totally obsolete. I deleted it from my FTP site not long ago. > If I want to produce ELF shared libraries on > a 2.2.X machine, what do I do? My current understanding is: > > either upgrade to 3.0 That's really your best bet. > get binutils-2.9.1 and egcs and configure them to cross compile > to linux. Binutils-2.9.1 has an "i386-unknown-freebsdelf" target that's closer. But there are still some additional patches that need to be made. You're best off just using FreeBSD-3.x. Note, you also need an ELF version of gcc. Again, that's in FreeBSD-3.x. And, you need the startup files, and probably some other stuff. All in FreeBSD-3.x. :-) John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Nobody ever went broke underestimating the taste of the American public." -- H. L. Mencken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 11:53:46 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA01760 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 11:53:46 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA01755 for ; Fri, 22 Jan 1999 11:53:42 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id LAA56414; Fri, 22 Jan 1999 11:53:25 -0800 (PST) (envelope-from dillon) Date: Fri, 22 Jan 1999 11:53:25 -0800 (PST) From: Matthew Dillon Message-Id: <199901221953.LAA56414@apollo.backplane.com> To: "John S. Dyson" Cc: hackers@FreeBSD.ORG Subject: Re: Error in vm_fault change References: <199901221749.MAA03968@y.dyson.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Basically what it comes down to is that I do not think it is appropriate for there to be hacks all around the kernel to arbitrarily block processes in low memory situations. At the very worst, those same 'blockages' could be implemented in one place - the memory allocator, and nowhere else. But we can do much better. I like your RLIMIT_RSS code, but it isn't enough and I think it is implemented in the wrong place. I believe the correct place to implement the 'memory scheduler' is in vm_page_alloc() and vm_wait(). vm_page_alloc() uses some algorithm X ( which could simply be the RSS check ) to determine whether to return NULL or not for VM_ALLOC_NORMAL or VM_ALLOC_ZERO requests. vm_wait() ould implement the RSS enforcement as well as other sophistication. For example, it could determine that the enforcement is insufficient and start scaling it, or it could determine that the system is thrashing and implement a more sophisticated swap/sleep strategy. We can play with the scheduling and enforcement algorithms much more easily this way, too. What do you say ? -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 12:37:37 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA07885 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 12:37:37 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA07880 for ; Fri, 22 Jan 1999 12:37:35 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id MAA56617; Fri, 22 Jan 1999 12:36:57 -0800 (PST) (envelope-from dillon) Date: Fri, 22 Jan 1999 12:36:57 -0800 (PST) From: Matthew Dillon Message-Id: <199901222036.MAA56617@apollo.backplane.com> To: Ville-Pertti Keinonen Cc: hackers@FreeBSD.ORG Subject: Re: Review and report of linux kernel VM References: <199901140720.XAA22609@apollo.backplane.com> <8690evpkc4.fsf@not.oeno.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Whaat? : :You appear to be confusing cleanliness (as I understand it, and I'm :afraid that many other readers of your review might understand it) :with simplicity. : :I would claim the exact opposite. The Linux VM system is simpler, but :far *less* clean because of the very inflexible (almost non-existent) :"layers". Not to mention the code, which shares the (IMHO) poor :source organization and apparently arbitrary dependencies of Linux as :a whole. The Linux VM system implements all the core features that the FreeBSD VM system implements, just not as efficiently. Its use of a page table paradigm to do VM-specific object layering is really not that bad of an idea. It *does* lock them into a more ridgid scheme ( for example, the linux scheme starts to break down when you share huge objects between processes ), but so far they've been able to implement the same core feature set that we have in our VM system. Thus, it is not possible to argue that their system is inferior from an algorithmic standpoint, only from an implementation standpoint and a flexibility standpoint. We can hardly be proud of our VFS/BIO layering which has been so buggy these last few years. The types of bugs I'm finding in FreeBSD have nothing to do with the algorithms and everything to do with the code being uncommented and virtually unreadable due to the hundreds of badly thought out optimizations and other hacks that have obscured the core implementation. When I say clean, I mean 'readable, obvious, and functionallty layered'. I had no trouble following the linux code even going deep into the paging and VFS subsystems. Following FreeBSD code has been like pulling nails. It's why we are *still* finding bugs in our VM system, after years of work. FreeBSD's VM system is definitely more flexible and efficient. Given the choice, I would much rather keep FreeBSD's VM system. That flexibility has come at the cost of dirtying up the code considerably, though. What use is flexibility if every new feature brings half a dozen bugs to light and creates half a dozen more of its own? My current work is to keep the flexibility while cleaning up the code. If we can clean up the code, we will have a clean, flexible, AND kickass VM system rather then simply a kickass VM system. : :What's my definition of clean then? For example, common operations :shouldn't need to resort to brute-forceish approaches (not in many :cases, anyhow). Which reminds me, your swp_pager_meta_free_all looks :a bit frightening...do you intend to keep it like it is? 'efficiency'. As I stated, Linux's VM code is not terribly efficient. I would disagree with the 'brute force' line, though. They've stuck to their guns pretty well and the core concepts are sound. Linux simply has not had the long operational history that BSD has and they are having to relearn many of the same lessons. It should be noted that linux can still implement inode-based object layering underneath their existing VM system. Their direct use of pagetables for bookkeeping does not prevent that. :In addition to the problems you stated, as far as I can tell, swap :backing is not shared for copy-on-write associations (copy-on-write :pages get swapped out multiple times, all but the last don't free any :memory) unless the page was swapped out when the maps were copied, in :which case it ends up copy-on-access...maybe, I'm not sure whether the :swap cache eliminates this. : :This (and many of the things you pointed out) is due to the simplistic :approach where pages don't really have an identity (only mappings) :unless they are backed by an inode. Which is perhaps at the core of :most of the algorithmic differences between Mach/4.4BSD and Linux VM :systems. : :IMHO pages need to have an identity even when they are not associated :with files (based on a quick glance, NetBSD's UVM seems to retain :this property while optimizing the management of anonymous pages. I'm :not convinced in terms of the choice of data structures for the anon :maps in UVM, though). Pages under linux *DO* have an identity, but you have to look it up in the meta objects backing the page tables based on the position of the page in the page table. They do not implement swap as a paging layer as we do, but then again our implementation of swap as a paging layer is a mostly degenerate case in our vm_object layering system so it amounts to pretty much the same thing. I don't think COW pages get swapped multiple times, but I could be wrong. My read is that when a linux process forks, the swap block associates are shared even for COW pages. The COWed pages are marked read-only and split if a write fault occurs. Unless it's writing the same shared page from different processes to the same swap block over and over again, that is. It shouldn't have to - I was under the impression that the swap had a bunch of per-swap-block flags to keep track of the clean/dirty state, so once one process swaps out a page, the others may scan it but will not redundantly swap it out. :> reference information. Instead, it uses the vm_object and pmap modules. :> I actually like this feature of FreeBSD. A lot. : :Additionally, the way FreeBSD does things has better potential for :concurrency (even though the locks have been ripped out) compared to :Linux. I disagree. FreeBSD still must hold locks through pmap changes and those scan all related processes, just as linux does. The difference is that since FreeBSD can delete page tables, it generally winds up scanning many FEWER processes to change the pmap state for a page then linux. Linux must scan/adjust the pmap state for e very process mmap()ing the page whether or not it is using the page. :> Linux demarks interrupts from supervisor code much better then we do. : :You seem to consider simpler to mean cleaner/better. Although in this :case, I'd agree that much of the complexity of FreeBSD is unnecessary. : My philosophy is, in general, that (1) one must separate the algorithm from the implementation and that (2) any algorithm can be cleanly implemented. If it isn't, it should be rewritten. If the programmer can't reimplement it, either the programmer is unworthy of the algorithm or the programmer isn't experienced enough to do it right, or the algorithm is bad. There is no middle ground in my world view. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 12:43:20 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA08567 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 12:43:20 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mercury.inktomi.com (mercury.inktomi.com [209.1.32.126]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA08560 for ; Fri, 22 Jan 1999 12:43:19 -0800 (PST) (envelope-from jplevyak@inktomi.com) Received: from proxydev.inktomi.com (proxydev.inktomi.com [209.1.32.44]) by mercury.inktomi.com (8.9.1a/8.9.1) with ESMTP id MAA08062 for ; Fri, 22 Jan 1999 12:43:20 -0800 (PST) Received: (from jplevyak@localhost) by proxydev.inktomi.com (8.8.5/8.7.3) id MAA12266 for freebsd-hackers@FreeBSD.ORG; Fri, 22 Jan 1999 12:43:09 -0800 (PST) Message-ID: <19990122124309.C11064@proxydev.inktomi.com> Date: Fri, 22 Jan 1999 12:43:09 -0800 From: John Plevyak To: freebsd-hackers@FreeBSD.ORG Subject: raw devices and disk geometry Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I am trying to find the disk of a raw disk partition (/dev/rwd2c). I have noticed the following in 3.0-CURRENT Jan 12: 1) DIOCGPART does not seem to return valid pointers: The code: struct disklabel dl; struct partinfo dp; int fd,res; fd = open("/dev/rwd2c", O_RDWR, 0); printf("%d : %s\n", fd, strerror(errno)); res = ioctl(fd,DIOCGDINFO,&dl); printf("%d : %s\n", res, strerror(errno)); res = ioctl(fd,DIOCGPART,&dp); printf("%d : %s\n", res, strerror(errno)); printf("%d %d\n", dp.disklab, dp.part); returns: 3 : Undefined error: 0 0 : Undefined error: 0 0 : Undefined error: 0 879 0 dl has valid data in it, but dp has invalid pointers. There is a comment in /usr/include/sys/disklabel.h that DIOCGPART is used internally. Does this mean that this ioctl cannot be used outside of the kernel? 2) lseek on raw disks does not seem to produce an error when the size is exceeded. In fact, it acts very oddly when given SEEK_END for a 2GB disk the following code: o = lseek(fd,0,SEEK_END); printf("%llu\n", o); printf("%d\n", read(fd,d,8192)); o = lseek(fd,0,SEEK_CUR); printf("%llu\n", o); printf("%d\n", read(fd,d,8192)); o = 2*1073741824LL - 128 * 8192; o = lseek(fd,o,SEEK_SET); printf("%llu\n", o); printf("%d\n", read(fd,d,8192)); o = lseek(fd,-8192,SEEK_END); printf("%lld\n", o); printf("%d\n", read(fd,d,8192)); produces 0 8192 8192 8192 2146435072 -1 -8192 -1 3) lseek followed by read *can* be used to determine the size of the partition of course this requires a binary search. Are these known issues? Is there a better way of determining the size of a partition from a program? I am willing to debug if this is not the desired behavior. john -- John Bradley Plevyak, PhD, jplevyak@inktomi.com, PGP KeyID: 051130BD Inktomi Corporation, 1900 S. Norfolk Street, Suite 110, San Mateo, CA 94403 W:(415)653-2830 F:(415)653-2801 P:(888)491-1332/5103192436.4911332@pagenet.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 15:18:12 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA00582 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 15:18:12 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id PAA00559 for ; Fri, 22 Jan 1999 15:18:09 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 24577 invoked from network); 22 Jan 1999 23:17:55 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 22 Jan 1999 23:17:55 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id SAA36795; Fri, 22 Jan 1999 18:17:54 -0500 (EST) Message-Id: <199901222317.SAA36795@y.dyson.net> Subject: Re: Error in vm_fault change In-Reply-To: <199901221953.LAA56414@apollo.backplane.com> from Matthew Dillon at "Jan 22, 99 11:53:25 am" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Fri, 22 Jan 1999 18:17:54 -0500 (EST) Cc: dyson@iquest.net, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon said: > > Basically what it comes down to is that I do not think it is appropriate > for there to be hacks all around the kernel to arbitrarily block processes > in low memory situations. At the very worst, those same 'blockages' could > be implemented in one place - the memory allocator, and nowhere else. But > we can do much better. > That isn't a hack. > > I like your RLIMIT_RSS code, but it isn't enough and I think it is > implemented in the wrong place. > Didn't guarantee that was clean, for sure. > > We can play with the scheduling and enforcement algorithms much more > easily this way, too. What do you say ? > But don't take away the capabilities that are already in the code. The algorithms already work well, and removing things with the mistaken notion that something is being "fixed" isn't a good thing (please refer to the comment that you added with the #if 0.) vm_page_alloc isn't likely the right place to put the policy either. Note that vm_page_alloc doesn't assume any kind of process context (or shouldn't). Even though I put the object rundown in vm_page_free, that should also not be there. (The best way to do that would be a light weight kernel thread, but my kernel supports those things very inexpensively, unlike the BSD kernels.) If you want to put a layer between fault and vm_page_alloc, that *might* make sense. However, vm_fault is the only normally "approved" place that pages are read in and put into the address space (at least on a dynamic basis.) The prefaulting does also, but that is much more static and definitely more machine dependent. IMO, prefaulting should never cause competition for resources, so shouldn't be applicable to this discussion. Again, you CAN put a layer in between vm_fault and vm_page_alloc/lookup -- however the only place where the policy makes sense is in the fault code (or a routine called by it.) vm_page_alloc is called by low level kernel services that should not have policy associated with them. Note that I created the fault status block -- which can allow for layering in the fault code itself. One purpose of it was to allow for splitting the code cheaply (the other was to guarantee small offsets relative to a base pointer, shrinking the code further), and also to get rid of the UGLY macros. The fault code is much smaller than it used to be (and even smaller than UVM.) It might be a good thing to split that up -- but maybe not. Also, the fault status block might allow for handling faults through continuations -- but the rest of the VM code doesn't know how to deal with process stacks appearing and disappearing :-(. Given the VM code (and the way that it should be), the fault code is the ONLY place where process pages are/should be directly created (in normal global memory conditions.) I suggest that adding a layer between fault and alloc/lookup is probably redundant, because the place for the code is already there!!! The only thing that the code in vm_pageout should do is generally to manage global conditions (I think that soft-RSS limiting is okay there also -- but likely not optimal.) It is probably best to do the local soft-RSS limiting also where the pages are allocated and managed (in vm_fault.) One (the original) reason for putting the soft-rss limiting in vm_pageout, is that RSS limiting is generally undesirable unless memory conditions are low. However, the same algorithm can be put into vm_fault (in fact, the *exact* same code is called from vm_fault into the correct routine in vm_pageout.) Please don't go in the direction of doing local trimming as a primary page management method -- then that starts to regress to broken NT stuff. Frankly, the version of the hard-RSS limiting that I am running performs much better than earlier versions had (in the past), but I took some of the advice that I gave you and implemented those capabilities. Again, the code that you removed with '#if 0' is still operative in my kernel, and the trimming works correctly. Looking at the code that had been removed, isn't it silly to have done so, when a more direct and correct method really solves the problem? :-). One thing about the VM code that is critical for the system to run correctly, is that you must wake up the pageout daemon BEFORE you run out of memory. Waiting until the system runs out of memory will weaken the probability for the pageout daemon to run in parallel (in the sense of waiting for I/O completion, or in SMP applications) with user processes. Of course, that is also predicated upon allowing the swap_pager to block :-). If the pageout code just blasts away clean pages after trying to launder a small number of dirty pages, your system will also suffer, by having to re-read those clean pages aggressively freed. Reading pages from swap is pretty quick, but undesirable when they might have been kept with a more carefully considered pageout policy. It only takes waking up the pageout daemon a few pages early for the system to be able to take proper advantage of its behavior. On large systems, those "few" pages might number a few hundred, but who cares? The mistakes made by allowing the pageout daemon to make mistakes haphazardly cost alot because with broken algorithms, the daemon requires more I/O, even if it looks like there is more free memory. I/O and latency are the parameters that needs to be optimized, who cares about any notion of "free" memory, when it doesn't mean anything to the user -- due to excessive paging? Note that it isn't usually pageouts that make processes (systems) run slow, it is the lack of memory for page allocation, or it is latency time to read needed pages from the disk. Since you can only write out so many pages per second, and since the pageout daemon policy is to be waken up BEFORE the system is out of memory, and the cache queue (which is fairly large, given proper policy) can be used to fullfill memory needs, then the need or desirability of the pageout daemon going "nuts" by wrecklessly freeing or caching pages isn't a desirable behavior. The cache queue does buffer that errant behavior, but forgetting that it only buffers the errant behavior of the pageout daemon is very unwise. I really hope that isn't what is happening now. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 15:20:25 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA00884 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 15:20:25 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ceia.nordier.com (m2-48-dbn.dial-up.net [196.34.155.112]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA00856 for ; Fri, 22 Jan 1999 15:20:18 -0800 (PST) (envelope-from rnordier@nordier.com) Received: (from rnordier@localhost) by ceia.nordier.com (8.8.7/8.6.12) id BAA02045; Sat, 23 Jan 1999 01:19:09 +0200 (SAT) From: Robert Nordier Message-Id: <199901222319.BAA02045@ceia.nordier.com> Subject: Re: raw devices and disk geometry In-Reply-To: <19990122124309.C11064@proxydev.inktomi.com> from John Plevyak at "Jan 22, 99 12:43:09 pm" To: jplevyak@inktomi.com (John Plevyak) Date: Sat, 23 Jan 1999 01:19:07 +0200 (SAT) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (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 John Plevyak wrote: > I am trying to find the disk of a raw disk partition (/dev/rwd2c). > > I have noticed the following in 3.0-CURRENT Jan 12: > > 1) DIOCGPART does not seem to return valid pointers: > > 2) lseek on raw disks does not seem to produce an error > when the size is exceeded. In fact, it acts very > oddly when given SEEK_END > 3) lseek followed by read *can* be used to determine the size of > the partition of course this requires a binary search. > > Are these known issues? Is there a better way of determining > the size of a partition from a program? DIOCGPART is for internal use and not used outside the kernel. You can't necessarily rely on lseek() when applied to a device. However, what you want to do seems fairly simple: if (ioctl(fd, DIOCGDINFO, &dl) == -1) errx(1, "%s: IOCTL(DIOCGDINFO)", argv[1]); for (i = 0; i < dl.d_npartitions; i++) printf("%c: %u\n", 'a' + i, dl.d_partitions[i].p_size); With sample output: /dev/rwd0: a: 0 b: 0 c: 8438850 d: 0 e: 0 f: 0 g: 0 h: 0 /dev/rwd0c: a: 65536 b: 282304 c: 4305357 d: 0 e: 65536 f: 3891981 g: 0 h: 0 The 'c' (raw) partitions give, respectively, the size of the whole disk, and of the FreeBSD slice ("fdisk partition"). -- Robert Nordier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 15:37:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA02252 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 15:37:53 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from hda.hda.com (hda-bicnet.bicnet.net [209.244.238.132] (may be forged)) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA02228 for ; Fri, 22 Jan 1999 15:37:44 -0800 (PST) (envelope-from dufault@hda.hda.com) Received: (from dufault@localhost) by hda.hda.com (8.8.5/8.8.5) id SAA22095; Fri, 22 Jan 1999 18:31:59 -0500 (EST) From: Peter Dufault Message-Id: <199901222331.SAA22095@hda.hda.com> Subject: Re: Error in vm_fault change In-Reply-To: <199901221953.LAA56414@apollo.backplane.com> from Matthew Dillon at "Jan 22, 99 11:53:25 am" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Fri, 22 Jan 1999 18:31:58 -0500 (EST) Cc: dyson@iquest.net, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Basically what it comes down to is that I do not think it is appropriate > for there to be hacks all around the kernel to arbitrarily block processes > in low memory situations. At the very worst, those same 'blockages' could > be implemented in one place - the memory allocator, and nowhere else. But > we can do much better. No one will argue with that. While moving things to one place you should define requirements also so that you can see that changes don't break anything. As someone interested in realtime I'll toss two requirements at you: you should be able to behave as if you have less physical memory than you do to permit locked in regions (should be easy), and your algorithms should be able to define a maximum amount of time (for a specific configuration) that it will take to reduce that number, that is, if I give you five seconds warning can you guarantee me more two more MB memory? For the second requirement don't concern yourself with obvious Unixy issues or anything outside the VM subsystem, only that the algorithms in your now well contained subsystem are determinate. Peter -- Peter Dufault (dufault@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 15:45:18 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA03192 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 15:45:18 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA03160 for ; Fri, 22 Jan 1999 15:45:14 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id QAA15051; Fri, 22 Jan 1999 16:45:02 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp01.primenet.com, id smtpd014934; Fri Jan 22 16:44:47 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id QAA12241; Fri, 22 Jan 1999 16:44:35 -0700 (MST) From: Terry Lambert Message-Id: <199901222344.QAA12241@usr09.primenet.com> Subject: Re: Error in vm_fault change To: dillon@apollo.backplane.com (Matthew Dillon) Date: Fri, 22 Jan 1999 23:44:35 +0000 (GMT) Cc: dyson@iquest.net, hackers@FreeBSD.ORG In-Reply-To: <199901220656.WAA48081@apollo.backplane.com> from "Matthew Dillon" at Jan 21, 99 10:56:49 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I think that both the approach that Matt has suggested and the current RSS code that John suggested as a replacement are both contrary to the goals the John and David have put forth. The bix issue here seems to be data cache thrashing. In a non-unified VM and buffer cache system, this was hard limited by the quota placed on the total in-use of physical memory by both the VM and buffer cache; frequently, this was implemented using watermarking, and the high watermark on each, when agregated, almost always exceeded the total available physical memory. The question is really one of "how do I make processes behave", not one of "how do I punish/reward badly/well behaved processes". I think the RSS fix is needlessly complex. I offer a suggestion that is vastly simpler, amenable to policy exception via madvise, and otherwise altogether more in line with a real soloution to the problem. What I suggest is that vnodes with more than a certain number of pages associated with them be forced to steal pages from their own usage, instead of obtaining them from the system page pool. The limitation should be based on the available memory divided by the number of active vnodes, plus some additional fudge factors. In this way, vnodes do not compete with each other for real resources, except in low memory conditions. In general, when we talk about badly behaved processes, we are talking about processes with large working sets that are directly mapped to vnode backing objects. In effect, the suggested soloution is a soft working set quota that attempts to minimize swap usage under normal circumstances. The fudge factors are to account for non-vnode page usage, and for the relative average fill of a vnode associated VM object's page list. This soloution was tried, and worked very well, in a UnixWare 2.0 kernel, in an attempt to resolve the "bad" ld behaviour of mapping the object files to be linked, and then randomly accessing the symbol tables, which effectively thrashed everything but clean object file pages out of cache at the expense of backing store for things like the mouse management code in the X server. The end result was a big disconnect in the "move mouse, wiggle cursor" feedback that a human needs to be confident that the system is working (and, in effect, made X an impossible to use developement environment on UnixWare). Note that this is unrelated to the actual "fix" that was eventually part of the UnixWare release (a "fixed" scheduling class that gives the X server a certain percentage of the CPU to let it thrash its own pages back in). Obviously, this won't resolve the "huge number of files in one badly behaved process" problem. A more general soloution would require process-based limits instead, and would need to consider process "vesting" in files (e.g., one file is opened by two processes, for example, libc.so; do you thrash pages of libc.so out of core because one of the processes is an idiot, and therefore has exceeded its per process working set quota with a bunc of other files? No...). The simplest "best case" that can be arrived at with a small amount of code is to set per-vnode limits, and then allow certain madvise (like the one used by ld.so) parameters to ignore the limits on a per-vnode basis. Hell, you could do it with a chflags on /usr/lib/*.so, if you wanted to approach it that way... Anyway, that's my 2 cents; back on my head... er, back to work. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 15:53:36 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA04306 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 15:53:36 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id PAA04299 for ; Fri, 22 Jan 1999 15:53:34 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 8225 invoked from network); 22 Jan 1999 23:53:18 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 22 Jan 1999 23:53:18 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id SAA36870; Fri, 22 Jan 1999 18:53:18 -0500 (EST) Message-Id: <199901222353.SAA36870@y.dyson.net> Subject: Re: Error in vm_fault change In-Reply-To: <199901222344.QAA12241@usr09.primenet.com> from Terry Lambert at "Jan 22, 99 11:44:35 pm" To: tlambert@primenet.com (Terry Lambert) Date: Fri, 22 Jan 1999 18:53:18 -0500 (EST) Cc: dillon@apollo.backplane.com, dyson@iquest.net, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert said: > > I think the RSS fix is needlessly complex. I offer a suggestion > that is vastly simpler, amenable to policy exception via madvise, > and otherwise altogether more in line with a real soloution to the > problem. > Actually, the RSS code has been in the kernel for about 3yrs now, and is well understood. If it was being written from scratch, I would be more likely to agree with you. The kernel RSS limiting code works mostly for private data in the process. > > What I suggest is that vnodes with more than a certain number of > pages associated with them be forced to steal pages from their > own usage, instead of obtaining them from the system page pool. > Vnodes aren't the only structure that contains data -- maybe you mean vm objects also. In fact, vnode or "shared" data isn't usually the problem with memory usage. However a vnode quota is probably a good idea also. > > In general, when we talk about badly behaved processes, we are > talking about processes with large working sets that are directly > mapped to vnode backing objects. > Not necessarily, think the new versions of GNU C++ :-). > > This soloution was tried, and worked very well, in a UnixWare 2.0 > kernel > No UnixWare kernel VM ever worked very well, did it? -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 15:54:58 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA04443 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 15:54:58 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id PAA04436 for ; Fri, 22 Jan 1999 15:54:56 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 9943 invoked from network); 22 Jan 1999 23:54:43 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 22 Jan 1999 23:54:43 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id SAA36875; Fri, 22 Jan 1999 18:54:44 -0500 (EST) Message-Id: <199901222354.SAA36875@y.dyson.net> Subject: Re: Error in vm_fault change In-Reply-To: <199901222331.SAA22095@hda.hda.com> from Peter Dufault at "Jan 22, 99 06:31:58 pm" To: dufault@hda.com (Peter Dufault) Date: Fri, 22 Jan 1999 18:54:44 -0500 (EST) Cc: dillon@apollo.backplane.com, dyson@iquest.net, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Peter Dufault said: > > Basically what it comes down to is that I do not think it is appropriate > > for there to be hacks all around the kernel to arbitrarily block processes > > in low memory situations. At the very worst, those same 'blockages' could > > be implemented in one place - the memory allocator, and nowhere else. But > > we can do much better. > > No one will argue with that. While moving things to one place you > should define requirements also so that you can see that changes > don't break anything. > > As someone interested in realtime I'll toss two requirements at > you: you should be able to behave as if you have less physical > memory than you do to permit locked in regions (should be easy), > and your algorithms should be able to define a maximum amount of > time (for a specific configuration) that it will take to reduce > that number, that is, if I give you five seconds warning can you > guarantee me more two more MB memory? For the second requirement > don't concern yourself with obvious Unixy issues or anything outside > the VM subsystem, only that the algorithms in your now well contained > subsystem are determinate. > Your comments about "goals" are correct. The obsolete notion of priority is specious. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 16:15:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA08914 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 16:15:53 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA08908 for ; Fri, 22 Jan 1999 16:15:51 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id RAA24815; Fri, 22 Jan 1999 17:15:31 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp03.primenet.com, id smtpd024700; Fri Jan 22 17:15:24 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id RAA13495; Fri, 22 Jan 1999 17:15:13 -0700 (MST) From: Terry Lambert Message-Id: <199901230015.RAA13495@usr09.primenet.com> Subject: Re: Error in vm_fault change To: dyson@iquest.net Date: Sat, 23 Jan 1999 00:15:13 +0000 (GMT) Cc: tlambert@primenet.com, dillon@apollo.backplane.com, hackers@FreeBSD.ORG In-Reply-To: <199901222353.SAA36870@y.dyson.net> from "John S. Dyson" at Jan 22, 99 06:53:18 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Actually, the RSS code has been in the kernel for about 3yrs now, and > is well understood. If it was being written from scratch, I would be > more likely to agree with you. The kernel RSS limiting code works mostly > for private data in the process. Nevertheless, an RSS based implementation is still going to fail to address the major issue for a public server platform. Matt's objects are grounded in the idea that one or two users can stage a DOS attack against other users of the system, and, in general, if you allow semi-literate people to run code from the net, this *will* happen, even without evil intent. > > What I suggest is that vnodes with more than a certain number of > > pages associated with them be forced to steal pages from their > > own usage, instead of obtaining them from the system page pool. > > Vnodes aren't the only structure that contains data -- maybe you > mean vm objects also. In fact, vnode or "shared" data isn't usually > the problem with memory usage. However a vnode quota is probably > a good idea also. I think that the general case of the quota is on the object_t, but the enforcement of the quota is in the page case. One of the obvious reasons for wanting a VM object alias is to allow direct read-only or COW mapping of of pages already in core as part of an MFS object backed by core pages and/or swap. I don't argue the (de)merits (IMO) of trying to solve what I think is the wrong problem. But I will say that the enforcement of the quota on all objects is highly problematic, and that there is already a very nice chokepoint presenting itself for our (ab)use, and that is the vnode pager. I think it would be very hard to implement general VM object quota enforcement, and I think that it's the wrong thing to do in any case (except maybe as a means of global policy enforcement). I also think that it moves away from the idea of implementing some form of per process working set quota, and it disallows special cases for "well behaved code that nevertheless needs a lot of pages, just as if it were really badly behaved code". > > In general, when we talk about badly behaved processes, we are > > talking about processes with large working sets that are directly > > mapped to vnode backing objects. > > Not necessarily, think the new versions of GNU C++ :-). I'd argue that creating a lot of dirty data pages that are being used is not a bad behaviour; maybe it's bad compiler architecture, but that's another issue. The specific bad behaviour that I'd like to enforce is file I/O based, and has to do with intentional thrashing by a process, either because it's out of control (maybe the idiot OS doesn't propagate SIGHUP to groups, like all other OS's or something), or because it's badly designed in such a way that it thrashes a file. Basically, this would mean that if the page at the end of the LRU that's going to be forced out is dirty, so be it. It will increase swapping for that process, but reduce swapping overally by 2 times as much, in that it won't force pages that another process is about to use out of core. Think of paging out as positive caching and avoiding it as negative caching. Negative caching is 2 times better than positive caching, for most applications where the hash space doesn't bloat out of control. In the vm_object_t case, the hash space is (relatively) fixed, so it's a major win. > > This soloution was tried, and worked very well, in a UnixWare 2.0 > > kernel > > No UnixWare kernel VM ever worked very well, did it? Actually, Steve Baumel, the architect of the SVR4.2 (UnixWare 2.x) SMP aware VM system did one hell of a job. He addressed most of the real issues, including the ability to autogrow thread stacks, very early on in the game. It's very much a shame that other groups within USL failed to utilize his code. And that their participation on standards committies were such that we ended up with standards where the stack is passed to the thread at creation time, instead of the creation interface being responsible for the stack creation. Basically, don't blame Steve's design for the bad implementation of various parts of SVR4.2. It's a matter of source tree organization that prevented the working set quota going into the SVR4.2 source tree. Just as the FreeBSD source tree is rather badly organized for seperating architectural pieces, the USL source tree was nearly impossible to get cross-subsystem changes integrated into. Each compilable developement source tree was actually a combination of three seperate source repositories (one for the kernel peieces from third parties, one for the system independent code, and one for the architecture specific code), and control of the repositories was decentralized, as was control of the interfaces. Organizationally, I'd say SVR4.2 was damn lucky to even have a mechanism like user defined scheduling classes that could be abused to address the problem at all. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 17:13:52 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA15547 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 17:13:52 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id RAA15537 for ; Fri, 22 Jan 1999 17:13:49 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 13648 invoked from network); 23 Jan 1999 01:10:46 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 23 Jan 1999 01:10:46 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id UAA37690; Fri, 22 Jan 1999 20:10:45 -0500 (EST) Message-Id: <199901230110.UAA37690@y.dyson.net> Subject: Re: Error in vm_fault change In-Reply-To: <199901230015.RAA13495@usr09.primenet.com> from Terry Lambert at "Jan 23, 99 00:15:13 am" To: tlambert@primenet.com (Terry Lambert) Date: Fri, 22 Jan 1999 20:10:45 -0500 (EST) Cc: dyson@iquest.net, tlambert@primenet.com, dillon@apollo.backplane.com, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert said: > > Actually, the RSS code has been in the kernel for about 3yrs now, and > > is well understood. If it was being written from scratch, I would be > > more likely to agree with you. The kernel RSS limiting code works mostly > > for private data in the process. > > Nevertheless, an RSS based implementation is still going to fail to > address the major issue for a public server platform. Matt's > objects are grounded in the idea that one or two users can stage > a DOS attack against other users of the system, and, in general, if > you allow semi-literate people to run code from the net, this *will* > happen, even without evil intent. > The RSS limiting and mgmt as I have proposed is as effective as possible (in fact, could be extended to support shared objects.) > > I also think that it moves away from the idea of implementing some > form of per process working set quota, and it disallows special cases > for "well behaved code that nevertheless needs a lot of pages, just > as if it were really badly behaved code". > The RSS limiting does (fully) support that, if slightly extended. (note that the FreeBSD RSS limiting also moves pages to lower priority queues as needed.) > > > > Not necessarily, think the new versions of GNU C++ :-). > > I'd argue that creating a lot of dirty data pages that are being used > is not a bad behaviour; maybe it's bad compiler architecture, but > that's another issue. > And that has to be dealt with. Just because certain tools are hogs, doesn't mean that FreeBSD should just explain the problem away as "the other program is the bad guy." > > The specific bad behaviour that I'd like to enforce is file I/O based, > and has to do with intentional thrashing by a process, either because > it's out of control (maybe the idiot OS doesn't propagate SIGHUP to > groups, like all other OS's or something), or because it's badly > designed in such a way that it thrashes a file. > Normal file I/O already works well. However, the per vnode limiting (for mmap) is indeed very easy (almost trivial) to implement. This is of course, true if the limit is greater than the buffer cache size, and only becomes slightly less trivial if less than the buffer cache size (due to the required buffer cache mgmt.) If you want, you can almost freely yank pages from a process (like the pageout daemon does), and the system will properly handle that case. The FreeBSD VM code is very robust when abused, and is one reason it is critical to understand that the FreeBSD VM code can fix mistakes for you. Making changes to the code (without complete understanding) might partially provide some of the desired result, but might also eventually show a problem. (The FreeBSD code does try to close loops, and compensate for unforseen conditions.) IMO, the code should be relentless in the persuit of handling difficult loads. > > > > This soloution was tried, and worked very well, in a UnixWare 2.0 > > > kernel > > > > No UnixWare kernel VM ever worked very well, did it? > > Actually, Steve Baumel, the architect of the SVR4.2 (UnixWare 2.x) > SMP aware VM system did one hell of a job. He addressed most of the > real issues, including the ability to autogrow thread stacks, very > early on in the game. > Autogrowing thread stacks is very easy in FreeBSD, but it is an issue of specification and requirement. Moving thread stacks would be more problematical. > > It's a matter of source tree organization that prevented the working > set quota going into the SVR4.2 source tree. Just as the FreeBSD source > tree is rather badly organized for seperating architectural pieces, the > USL source tree was nearly impossible to get cross-subsystem changes > integrated into. Each compilable developement source tree was actually > a combination of three seperate source repositories (one for the kernel > peieces from third parties, one for the system independent code, and one > for the architecture specific code), and control of the repositories was > decentralized, as was control of the interfaces. > Well, RSS limiting on FreeBSD 1st pass will take 200 lines of code (max), and a 2nd pass optimized might be another 100-200 lines (it is likely that the code will actually be less than 1/2 that size.) To me, it is more an issue of not understanding what is there (due to a lack of patience and not asking the authors for specific answers.) The FreeBSD code is extremely flexible, but is mostly broken in the sense of SMP (IMO) or non standard UNIX requirements (like true realtime goals.) >From what I have seen, single solutions aren't often the best answer. Fully handling the issue of memory contention will definitely include per process RSS limiting, but other forms of limiting might be easier and make more sense in addition to the per-process limiting. The per-vnode limiting will definitely help the per process limiting. In fact, rather than per-vnode limiting, perhaps shared object limiting in general should be implemented, with proper consideration for fairness. (Fairness needs to be carefully defined, since it starts implying "policy.") Policy decisions often trade off performance in situations that aren't considered. So much for all of this rambling -- IMO for normal U**X timesharing purposes, the most important issue is to limit the effect of an ill behaved process on the rest of the system. In this case, then the supplied RSS limiting is sufficient. The hard part is to decide what to do with the pages that are "limited." Not only does my supplied RSS limiting limit "RSS", but also moves pages to lower priority queues. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 18:28:55 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA25672 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 18:28:55 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from etinc.com (et-gw.etinc.com [207.252.1.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA25658 for ; Fri, 22 Jan 1999 18:28:51 -0800 (PST) (envelope-from dennis@etinc.com) Received: from dbsys (dbsys.etinc.com [207.252.1.18]) by etinc.com (8.8.8/8.6.9) with SMTP id VAA02348; Fri, 22 Jan 1999 21:29:24 GMT Message-Id: <199901222129.VAA02348@etinc.com> X-Sender: dennis@etinc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 22 Jan 1999 21:34:08 -0500 To: Ville-Pertti Keinonen From: Dennis Subject: Re: Review and report of linux kernel VM Cc: hackers@FreeBSD.ORG In-Reply-To: <8690evpkc4.fsf@not.oeno.com> References: <199901140720.XAA22609@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 02:23 PM 1/22/99 +0200, you wrote: [much snippage] >The Linux VM system looks like it hasn't been designed at all, just >implemented. This pretty much sums up the whole OS...LOL. Sort of alike a Frankenstein OS. db To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 19:17:55 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA02430 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 19:17:55 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.nacamar.de (mail.nacamar.de [194.162.162.200]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA02422 for ; Fri, 22 Jan 1999 19:17:52 -0800 (PST) (envelope-from rohrbach@mail.nacamar.de) Received: (from rohrbach@localhost) by mail.nacamar.de (8.8.7/8.8.8MB-19980212) id EAA05618 for freebsd-hackers@freebsd.org; Sat, 23 Jan 1999 04:17:39 +0100 (CET) Message-ID: <19990123041739.G4581@nacamar.net> Date: Sat, 23 Jan 1999 04:17:39 +0100 From: "Karsten W. Rohrbach" To: freebsd-hackers@FreeBSD.ORG Subject: Re: SCSI question... and some enum idea Reply-To: rohrbach@nacamar.net Mail-Followup-To: freebsd-hackers@freebsd.org References: <19981224102230.T365@acheron.middleboro.ma.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Kenneth P. Stox on Thu, Dec 24, 1998 at 11:48:21AM -0600 X-Arbitrary-Number-Of-The-Day: 42 X-Sender: rohrbach@nacamar.net X-Organisation: Nacamar Data Communications GmbH X-Address: Robert-Bosch-Str. 32, 63303 Dreieich, Germany X-Phone: vox: +49 6103 993 870 fax: +49 6103 993 199 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kenneth P. Stox (ken@stox.sa.enteract.com) @ Thu, Dec 24, 1998 at 11:48:21AM -0600: > > > 1) Our box is a multi-LUN SCSI device. Are multiple LUNs supported in FreeBSD > > by default? (A complication is that I don't know what version of FreeBSD our > > client runs. I've been told -current, but I doubt that. I'm guessing 2.0.x. > > I will find out for sure on Monday, but getting a jump over the weekend would > > be cool.) > > I can't speak on 2.X, but 3.X supports them just fine. I should note that > my experience with multiple LUN's has been limited to a CD drive. > i got a box with 2940u2w(aic789x) and raid array on an infortrend ift3102 running here. the ift does create multiple luns for the different logical disks - and it works excellent for me. btw, what came to my mind in this context was the enumeration of disk devices (da?)... on some $$$ un*x boxes you got a scheme where the device inode enumeration is fixed to the bus, scsi id and lun of the device (pretty good idea that) so that if you sometimes add or remove your second disk the third doesnt get the second and gets a mount error with wrong filesystem type... so you would use /dev/disk/bus0id0lun0a or something as root device... is this a good idea or is it rather nasty? i am often swapping in/out our cd toaster of my department which is jumpered to id4 and i'm a lazy bastard, so my drive on id5 and the cdrom on id6 change device numbers sometimes... /k > > > > 2) Can I access multiple LUNs through individual device files? If so, can I > > assume that the kernel will pop up messages saying what files have devices > > attached? > > Yes. I have been using a 7 CD changer for some time with no problems. > They come up as cd0 through cd6. I have used with with both Adaptec and > NCR controllers. > > > 3) Should I have the client do "/dev/MAKEDEV all" before rebooting with the > > device attached? That would do what I want under NetBSD, but I'm not quite > > sure about FreeBSD. > > Since, you don't mention what kind of multiple LUN device you are talking > about, that is hard to answer. :-) > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- "Nuclear war can ruin your whole compile." -- Karl Lehenbauer http://www.nacamar.de - http://www.nacamar.net - http://www.webmonster.de http://www.apache.de - http://www.quakeforum.de - finger rohrbach@nacamar.net PGP Key fingerprint = F9 A0 DF 91 74 07 6A 1C 5F 0B E0 6B 4D CD 8C 44 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 19:35:10 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA04656 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 19:35:10 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from psf.Pinyon.ORG (ppp1-237.presc.dialup.futureone.com [209.250.11.237]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA04647 for ; Fri, 22 Jan 1999 19:35:06 -0800 (PST) (envelope-from rcarter@psf.Pinyon.ORG) Received: from psf.Pinyon.ORG (localhost [127.0.0.1]) by psf.Pinyon.ORG (8.9.2/8.9.2) with ESMTP id UAA18297; Fri, 22 Jan 1999 20:31:38 -0700 (MST) (envelope-from rcarter@psf.Pinyon.ORG) Message-Id: <199901230331.UAA18297@psf.Pinyon.ORG> X-Mailer: exmh version 2.0.2 2/24/98 To: dyson@iquest.net cc: dufault@hda.com (Peter Dufault), dillon@apollo.backplane.com, hackers@FreeBSD.ORG Subject: Re: Error in vm_fault change In-reply-to: Your message of "Fri, 22 Jan 1999 18:54:44 EST." <199901222354.SAA36875@y.dyson.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Jan 1999 20:31:38 -0700 From: "Russell L. Carter" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG %> As someone interested in realtime I'll toss two requirements at %> you: you should be able to behave as if you have less physical %> memory than you do to permit locked in regions (should be easy), %> and your algorithms should be able to define a maximum amount of %> time (for a specific configuration) that it will take to reduce %> that number, that is, if I give you five seconds warning can you %> guarantee me more two more MB memory? For the second requirement %> don't concern yourself with obvious Unixy issues or anything outside %> the VM subsystem, only that the algorithms in your now well contained %> subsystem are determinate. %> %Your comments about "goals" are correct. The obsolete notion of priority %is specious. No, it isn't. People (or rather organizations) are now using "OSS unix" stuff to do things like control flight and targeting and other interesting stuff. The lingo is based on "priority". Who gives a shit about interactive users ;-). Meeting deadlines is probably orthogonal to system throughput. Russell % %-- %John | Never try to teach a pig to sing, %dyson@iquest.net | it makes one look stupid %jdyson@nc.com | and it irritates the pig. % %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 Jan 22 19:36:38 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA04868 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 19:36:38 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.nacamar.de (mail.nacamar.de [194.162.162.200]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA04855 for ; Fri, 22 Jan 1999 19:36:34 -0800 (PST) (envelope-from rohrbach@mail.nacamar.de) Received: (from rohrbach@localhost) by mail.nacamar.de (8.8.7/8.8.8MB-19980212) id EAA07736; Sat, 23 Jan 1999 04:36:16 +0100 (CET) Message-ID: <19990123043616.H4581@nacamar.net> Date: Sat, 23 Jan 1999 04:36:16 +0100 From: "Karsten W. Rohrbach" To: Khetan Gajjar , "original recipient in envelope at link.cpt.nsc.iafrica.com" , Nathan Dorfman Cc: Alfred Perlstein , "John W. DeBoskey" Subject: Re: cdrecord / projected & actual sizes don't seem right Reply-To: rohrbach@nacamar.net Mail-Followup-To: Khetan Gajjar , "original recipient in envelope at link.cpt.nsc.iafrica.com" , Nathan Dorfman , Alfred Perlstein , "John W. DeBoskey" References: <19990105202736.B16219@rtfm.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Khetan Gajjar on Sun, Jan 10, 1999 at 01:10:25AM +0200 X-Arbitrary-Number-Of-The-Day: 42 X-Sender: rohrbach@nacamar.net X-Organisation: Nacamar Data Communications GmbH X-Address: Robert-Bosch-Str. 32, 63303 Dreieich, Germany X-Phone: vox: +49 6103 993 870 fax: +49 6103 993 199 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hm... i just wondered about what was the posix realtime extensions in the kernel and compiled them in (3.0-RELEASE). the VeryFunnyThing(TM) is that cdrecord does not complain anymore about not being able to set realtime privileges (cdrecord -vv ... shows that) and i can burn 4x with minimum buffer watermark at 98% and x running with netscape, building a kernel and simultaneously make buildworld and viewing ps files in ghostscript. seems to work smoothly. /k Khetan Gajjar (khetan@link.freebsd.os.org.za) @ Sun, Jan 10, 1999 at 01:10:25AM +0200: > On Tue, 5 Jan 1999, Nathan Dorfman wrote: > > >Al, as for your error, I've been using RW media with cdrecord, -current, > >and the CDRW4260 ever since I got it. What's the problem you're having? > >Maybe you're forgetting that a) you need to blank CDRW media before recording > >onto it, cdrecord blank=all or b) the drive writes RW media at 2x, so set > >speed=2. > > I'd also advise updating the firmware on your drive : > at scbus0 target 6 lun 0 (pass2,cd0) > > Other than that, I've done nothing special, and it all works > perfectly on a two month old -current writing at both 2x and 1x. > --- > Khetan Gajjar (!kg1779) * khetan@iafrica.com ; khetan@os.org.za > http://www.os.org.za/~khetan * Talk/Finger khetan@chain.freebsd.os.org.za > FreeBSD enthusiast * http://www2.za.freebsd.org/ > Security-wise, NT is a OS with a "kick me" sign taped to it > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message -- "Nuclear war can ruin your whole compile." -- Karl Lehenbauer http://www.nacamar.de - http://www.nacamar.net - http://www.webmonster.de http://www.apache.de - http://www.quakeforum.de - finger rohrbach@nacamar.net PGP Key fingerprint = F9 A0 DF 91 74 07 6A 1C 5F 0B E0 6B 4D CD 8C 44 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 20:15:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA09050 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 20:15:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id UAA09045 for ; Fri, 22 Jan 1999 20:15:29 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 27760 invoked from network); 23 Jan 1999 04:15:12 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 23 Jan 1999 04:15:12 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id XAA62055; Fri, 22 Jan 1999 23:15:10 -0500 (EST) Message-Id: <199901230415.XAA62055@y.dyson.net> Subject: Re: Error in vm_fault change In-Reply-To: <199901230331.UAA18297@psf.Pinyon.ORG> from "Russell L. Carter" at "Jan 22, 99 08:31:38 pm" To: rcarter@pinyon.org (Russell L. Carter) Date: Fri, 22 Jan 1999 23:15:10 -0500 (EST) Cc: dyson@iquest.net, dufault@hda.com, dillon@apollo.backplane.com, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Russell L. Carter said: > %> > %Your comments about "goals" are correct. The obsolete notion of priority > %is specious. > > No, it isn't. > > People (or rather organizations) are now using "OSS unix" stuff to > do things like control flight and targeting and other interesting > stuff. The lingo is based on "priority". Who gives a shit > about interactive users ;-). Meeting deadlines is probably > orthogonal to system throughput. > Deadlines are a major parameter. Even responsiveness to users is a form of deadline. Priority is only a short term scheduling hint, and doesn't really describe the resource requirements. Priority is a snapshot of what needs to run at an instant in time. Priority as a time invariant scalar (or even as the unix style slowly changing priority) isn't flexible enough anymore. Since we are talking here about resource mgmt, constraining ourselves to thinking about "priority" is just too inflexible. When looking into alternative scheduling mechanisms, priority just doesn't describe an adequate solution to the new range of problems (multimedia scheduling, realtime data, timesharing), that need to be solved concurrently (perhaps with the same resources.) -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 20:26:15 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA10117 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 20:26:15 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA10112 for ; Fri, 22 Jan 1999 20:26:13 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id UAA58213; Fri, 22 Jan 1999 20:25:56 -0800 (PST) (envelope-from dillon) Date: Fri, 22 Jan 1999 20:25:56 -0800 (PST) From: Matthew Dillon Message-Id: <199901230425.UAA58213@apollo.backplane.com> To: "John S. Dyson" Cc: rcarter@pinyon.org (Russell L. Carter), dufault@hda.com, hackers@FreeBSD.ORG Subject: Re: Error in vm_fault change References: <199901230415.XAA62055@y.dyson.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Guys, guys... when I said 'priority' I simply meant 'some sort of scheduling mechanism'. I didn't mean 'priority' in the sense of some arbitrary static number, nor do I infer that we intentionally block any processes when memory *is* available. And when I said 'scheduler' I didn't mean scheduling for cpu, ok? I meant scheduling who the available memory is given to. As in deciding intelligently. There are lots of ways to do this. The easiest is to change FreeBSD's notion of when to block waiting for memory. Right now it's notion is ( from vm_page_alloc() ): case VM_ALLOC_NORMAL: if (cnt.v_free_count >= cnt.v_free_reserved) { m = vm_page_select_free(object, pindex, PQ_FREE); KASSERT(m != NULL, ("vm_page_alloc(NORMAL): missing page on free queue\n")); } else { m = vm_page_select_cache(object, pindex); ... } So, for example, one way to schedule memory is to adjust the notion of cnt.v_free_reserved based on some dynamic entity associated with the process: if (cnt.v_free_count >= cnt.v_free_reserved + curproc->fubar) { And then make curproc->fubar a function of something. That is ALL I am saying here. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 20:56:21 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA13902 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 20:56:21 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA13891 for ; Fri, 22 Jan 1999 20:56:18 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id UAA58423; Fri, 22 Jan 1999 20:56:07 -0800 (PST) (envelope-from dillon) Date: Fri, 22 Jan 1999 20:56:07 -0800 (PST) From: Matthew Dillon Message-Id: <199901230456.UAA58423@apollo.backplane.com> To: "John S. Dyson" Cc: hackers@FreeBSD.ORG Subject: Re: Error in vm_fault change References: <199901220831.DAA00487@y.dyson.net> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :hoggy process. However, thrashing by a hoggy process should be managed by :limits. :-(. You are breaking any notion of the pageout daemon keeping stats :in normal low memory conditions, but thrashing is hopeless anyway without :limits (am I repeating myself?) Being realistic, *nobody* manages the RSS limits this tightly. As much as I like RSS limits, their lack of any sort of dynamic feedback makes them mostly unuseable in my view. They were almost entirely unuseable at BEST on every machine from the lowliest mail server to the most heavily loaded shell/web machine. On early machines with significantly less memory then the machines have now, all I got for my efforts were user complaints. The problem is that by the time an RSS limit kicks in, the damage has already been done. If RSS limits were metrics rather then absolute values, they would be MUCH more useful. :John | Never try to teach a pig to sing, :dyson@iquest.net | it makes one look stupid -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 21:00:07 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA14368 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 21:00:07 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from home.dragondata.com (home.dragondata.com [204.137.237.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA14331 for ; Fri, 22 Jan 1999 21:00:02 -0800 (PST) (envelope-from toasty@home.dragondata.com) Received: (from toasty@localhost) by home.dragondata.com (8.9.2/8.9.2) id WAA06844; Fri, 22 Jan 1999 22:59:27 -0600 (CST) From: Kevin Day Message-Id: <199901230459.WAA06844@home.dragondata.com> Subject: Re: Error in vm_fault change In-Reply-To: <199901230415.XAA62055@y.dyson.net> from "John S. Dyson" at "Jan 22, 1999 11:15:10 pm" To: dyson@iquest.net Date: Fri, 22 Jan 1999 22:59:27 -0600 (CST) Cc: rcarter@pinyon.org, dyson@iquest.net, dufault@hda.com, dillon@apollo.backplane.com, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Russell L. Carter said: > > %> > > %Your comments about "goals" are correct. The obsolete notion of priority > > %is specious. > > > > No, it isn't. > > > > People (or rather organizations) are now using "OSS unix" stuff to > > do things like control flight and targeting and other interesting > > stuff. The lingo is based on "priority". Who gives a shit > > about interactive users ;-). Meeting deadlines is probably > > orthogonal to system throughput. > > > Deadlines are a major parameter. Even responsiveness to users > is a form of deadline. Priority is only a short term scheduling > hint, and doesn't really describe the resource requirements. Priority > is a snapshot of what needs to run at an instant in time. Priority > as a time invariant scalar (or even as the unix style slowly changing > priority) isn't flexible enough anymore. Since we are talking here > about resource mgmt, constraining ourselves to thinking about "priority" > is just too inflexible. > > When looking into alternative scheduling mechanisms, priority > just doesn't describe an adequate solution to the new range > of problems (multimedia scheduling, realtime data, timesharing), > that need to be solved concurrently (perhaps with the same > resources.) > I can agree here.... I've got a somewhat unique embedded system I'm working on, that it's goals aren't too different from a desktop PC, but very 'deadline' oriented. Just boosting artificial priorities up and down doesn't really help. I end up cutting off processes needlessly, or missing events that I can't afford to miss. I've modified FreeBSD's scheduler a bit to work for my case, but what I'd really love to see is something that I can tell the scheduler that "I need to execute again in x ms (or even ns)". Possibly setting a range of acceptible sleeping. I also want to be able to say that a process, while not going to sleep, if it's going to get execution taken away, it needs to be brought back, and finish something before x amount of time. Simply dinking with rtprio is really inadequate for a true realtime system. (It does help having it there, though) Also being able to temporarily change things on the fly in reaction to some kind of input would be ideal, then transparently resume it's previous settings. My system has one process that blocks on a read() on an input device, who then places the data it just read into a shared memory queue, then signals processes who are consumers of this data that there's new data there, then, if any of those need to react to what they just learned, they wake up the another process to give it their output. All three processes need to execute in as close as possible order, within a short amount of time, to ensure the input/output delay doesn't seem sluggish. Some way to schedule this would be nice, so I don't have to roll completely seperate things into one big process, or somehow make one process be able to set a 'run next' flag on another process in the scheduler. Another feature that would be nice would be highly accurate timers or alarms. Trying to sync a movie playback to vsync on a display is very difficult if you don't have access to a vblank interrupt. This also could be used for waiting for somewhat slow devices, that nanosleep(1)'s resolution is still too large for. (nanosleep(1) seems to sleep about 2-10ms on an idle system) But... This is deviating quite a bit from what you guys are talking about, and I'm probably quite an exception to what is normally done with fbsd, than the majority. Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 22:01:21 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA19299 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 22:01:21 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA19294 for ; Fri, 22 Jan 1999 22:01:20 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id WAA36792; Fri, 22 Jan 1999 22:01:08 -0800 (PST) (envelope-from dillon) Date: Fri, 22 Jan 1999 22:01:08 -0800 (PST) From: Matthew Dillon Message-Id: <199901230601.WAA36792@apollo.backplane.com> To: Terry Lambert Cc: dyson@iquest.net, hackers@FreeBSD.ORG Subject: Re: Error in vm_fault change References: <199901222344.QAA12241@usr09.primenet.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've reenabled John's low memory code in vm_fault, and commented it as best as I could. But I don't like it at all. Terry's idea about recycling pages within a vnode ( I think he meant vm_object ) is an interesting one, but I don't know how we would determine the point at which a vm_object has too many resident pages. -Matt :--- :Any opinions in this posting are my own and not those of my present :or previous employers. : Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Fri Jan 22 22:20:17 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA20932 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 22:20:17 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from psf.Pinyon.ORG (ppp1-141.presc.dialup.futureone.com [209.250.11.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA20909 for ; Fri, 22 Jan 1999 22:20:12 -0800 (PST) (envelope-from rcarter@psf.Pinyon.ORG) Received: from psf.Pinyon.ORG (localhost [127.0.0.1]) by psf.Pinyon.ORG (8.9.2/8.9.2) with ESMTP id XAA21124 for ; Fri, 22 Jan 1999 23:16:40 -0700 (MST) (envelope-from rcarter@psf.Pinyon.ORG) Message-Id: <199901230616.XAA21124@psf.Pinyon.ORG> X-Mailer: exmh version 2.0.2 2/24/98 To: hackers@FreeBSD.ORG Subject: Re: Error in vm_fault change In-reply-to: Your message of "Fri, 22 Jan 1999 22:59:27 CST." <199901230459.WAA06844@home.dragondata.com> Mime-Version: 1.0 Content-Type: text/plainTo: current@freebsd.org Date: Fri, 22 Jan 1999 23:16:40 -0700 From: "Russell L. Carter" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG toasty@home.dragondata.com said: %Just boosting artificial priorities up and down doesn't really help. I end %up cutting off processes needlessly, or missing events that I can't afford %to miss. In FreeBSD priorities are mutable. Not sufficient, theoretically. *But*, I am amazed at what runs some of the more ah heavyweight arsenal we (the U.S.) fund. dillon@apollo.backplane.com said: % Guys, guys... when I said 'priority' I simply meant 'some sort % of scheduling mechanism'. I didn't mean 'priority' in the % sense of some arbitrary static number, nor do I infer that % we intentionally block any processes when memory *is* available. Well, why didn't you say so! :-) [...] dyson@iquest.net said: %When looking into alternative scheduling mechanisms, priority just %doesn't describe an adequate solution to the new range of problems %(multimedia scheduling, realtime data, timesharing), that need to be %solved concurrently (perhaps with the same resources.) Why not? :-) Of course not. A single parameter like "priority" won't do it. Application domains need scheduling partitions too. And there is no "GOD" algorithm that fits all. I would suggest that if the scheduler needs to be reworked, to fit at a minimum the kinds of work John lists, that people think about how to provide a framework to plug in various scheduling (process|memory) implementations. uhhhh, ye olde "strategy pattern". Russell To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 23 02:16:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA09351 for freebsd-hackers-outgoing; Sat, 23 Jan 1999 02:16:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA09345 for ; Sat, 23 Jan 1999 02:16:26 -0800 (PST) (envelope-from tlambert@usr08.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id DAA06119; Sat, 23 Jan 1999 03:16:16 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp01.primenet.com, id smtpd006106; Sat Jan 23 03:16:06 1999 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id DAA14533; Sat, 23 Jan 1999 03:16:05 -0700 (MST) From: Terry Lambert Message-Id: <199901231016.DAA14533@usr08.primenet.com> Subject: Re: Error in vm_fault change To: dillon@apollo.backplane.com (Matthew Dillon) Date: Sat, 23 Jan 1999 10:16:05 +0000 (GMT) Cc: tlambert@primenet.com, dyson@iquest.net, hackers@FreeBSD.ORG In-Reply-To: <199901230601.WAA36792@apollo.backplane.com> from "Matthew Dillon" at Jan 22, 99 10:01:08 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I've reenabled John's low memory code in vm_fault, and commented > it as best as I could. But I don't like it at all. > > Terry's idea about recycling pages within a vnode ( I think he > meant vm_object ) is an interesting one, but I don't know how > we would determine the point at which a vm_object has too many > resident pages. I meant the vm_object_t associated with the vnode, and the limit as enforced by an addition to the vnode pager. This is very file oriented. In general, the largest VM objects you will have to deal with are file mappings. You could also limit dirty data mappings the same way; however, this leads to a couple of nasty problems. The first is that if a dirty page is not in core, it has to be in swap; the act of forcing it out of core forces it into swap. The second is that there is really no choke point at which a callback on a new data page allocation can result in a dirty data page being forced to swap. The COW based implementation is mildly difficult, needing to upcall across what are, effectively, two stack frames (function calls, each with context), but even if you did this, the new data page allocation issue is a bear. It would involve, at a minimum, forcing a pageout in the page not present fault handler. I think that the second issue is a little specious; it's an argument that boils down to "it's hard". But the first argument is very, very hard to address without bloating your swap significantly, or without considering swap utilization before deciding about enforcement. Down this road lies madness. There's no way to do this that wouldn't have to be reexamined in terms of the tradeoff vs. minor variations in processor architecture (even between Intel processor revisions), CPU vs. memory bus multiplier, L2 wait states, main memory bus waits, and, eventually, I/O bus speed for cards with memory mapped into the KVA space. As I said, madness; I think it would be impossible to get a set of parameters that worked optimally on more than one piece of hardware. Trying to derive the attractors to make this parametric in the first place would probably kill some poor hacker. I think the only way to avoid the issue is to, well, avoid the issue, and trust that swap is going to continue to be so hideously expensive that it's worth taking the thrashing hit for intentionally bad programs as a poor man's hysteresis limitation on bad behaviour, and just assume hat the datasize and memorysize limits will save you. This assumption might change if swap became essentially free, but the time to examine the issue is then, not now. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 23 06:53:39 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA08489 for freebsd-hackers-outgoing; Sat, 23 Jan 1999 06:53:39 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA08480 for ; Sat, 23 Jan 1999 06:53:32 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 2.10 #1) id 1044Qs-0008hb-00 for hackers@freebsd.org; Sat, 23 Jan 1999 16:53:06 +0200 From: Sheldon Hearn To: hackers@FreeBSD.ORG Subject: Clobbering includes during ``make world'' Date: Sat, 23 Jan 1999 16:53:06 +0200 Message-ID: <33454.917103186@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi folks, I'm looking into teaching ``make world'' to clobber _all_ targets, including include files and perl5 modules. This will ease the task of finding stale crap with ``find -ctime''. Dealing with perl5 modules was easy, and I'm confident that there are no adverse side-effects involved. However, I'd like some feedback on whether it's safe to clobber FreeBSD include files. Currently, it looks like most include files are installed with ``install -C''. Are there any reasons why it'd be an incredibly bad idea to use ``install -c'' instead? Thanks, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 23 07:04:36 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA09668 for freebsd-hackers-outgoing; Sat, 23 Jan 1999 07:04:36 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from mail.harenet.com ([207.244.238.6]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA09663 for ; Sat, 23 Jan 1999 07:04:35 -0800 (PST) (envelope-from SimsS@IBM.Net) Received: from hobbes (207-172-61-239.s239.tnt1.rcm.erols.com [207.172.61.239]) by mail.harenet.com (Post.Office MTA v3.1 release PO203a ID# LEGENDS-1997LS) with SMTP id AAA67 for ; Sat, 23 Jan 1999 10:04:46 -0500 Reply-To: From: "Steve Sims" To: Subject: 3.0-STABLE cvsup tag Date: Sat, 23 Jan 1999 10:04:18 -0500 Message-ID: <000201be46e1$a6db2c00$ebacf9c7@hobbes.RatsNest.VaBeach.Va.US> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG OK - I give up - What's the CVSup tag for the stable version of the 3.x tree. I've look, really, but I'm stumped. Thanks in advance for your help. ...sjs... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 23 07:06:21 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA09879 for freebsd-hackers-outgoing; Sat, 23 Jan 1999 07:06:21 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA09866 for ; Sat, 23 Jan 1999 07:06:15 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 2.10 #1) id 1044cr-00017e-00; Sat, 23 Jan 1999 17:05:29 +0200 From: Sheldon Hearn To: SimsS@IBM.Net cc: freebsd-hackers@FreeBSD.ORG Subject: Re: 3.0-STABLE cvsup tag In-reply-to: Your message of "Sat, 23 Jan 1999 10:04:18 EST." <000201be46e1$a6db2c00$ebacf9c7@hobbes.RatsNest.VaBeach.Va.US> Date: Sat, 23 Jan 1999 17:05:29 +0200 Message-ID: <4316.917103929@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 23 Jan 1999 10:04:18 EST, "Steve Sims" wrote: > OK - I give up - What's the CVSup tag for the stable version of the 3.x > tree. RELENG_3 Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 23 07:18:38 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA10914 for freebsd-hackers-outgoing; Sat, 23 Jan 1999 07:18:38 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA10907 for ; Sat, 23 Jan 1999 07:18:34 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 2.10 #1) id 1044pI-0001Z9-00 for hackers@freebsd.org; Sat, 23 Jan 1999 17:18:20 +0200 From: Sheldon Hearn To: hackers@FreeBSD.ORG Subject: Re: Clobbering includes during ``make world'' In-reply-to: Your message of "Sat, 23 Jan 1999 16:53:06 +0200." <33454.917103186@axl.noc.iafrica.com> Date: Sat, 23 Jan 1999 17:18:20 +0200 Message-ID: <6022.917104700@axl.noc.iafrica.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 23 Jan 1999 16:53:06 +0200, Sheldon Hearn wrote: > Currently, it looks like most include files are installed with ``install > -C''. Are there any reasons why it'd be an incredibly bad idea to use > ``install -c'' instead? I've received via private mail a suggestion that has the desired effect: make -DCLOBBER includes Thanks, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 23 07:22:33 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA11235 for freebsd-hackers-outgoing; Sat, 23 Jan 1999 07:22:33 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from shale.csir.co.za (shale.csir.co.za [146.64.46.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA11230 for ; Sat, 23 Jan 1999 07:22:29 -0800 (PST) (envelope-from reg@shale.csir.co.za) Received: (from reg@localhost) by shale.csir.co.za (8.9.2/8.9.2) id RAA41915; Sat, 23 Jan 1999 17:21:43 +0200 (SAT) (envelope-from reg) Date: Sat, 23 Jan 1999 17:21:43 +0200 From: Jeremy Lea To: Sheldon Hearn Cc: hackers@FreeBSD.ORG Subject: Re: Clobbering includes during ``make world'' Message-ID: <19990123172141.A33428@shale.csir.co.za> References: <33454.917103186@axl.noc.iafrica.com> <6022.917104700@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <6022.917104700@axl.noc.iafrica.com>; from Sheldon Hearn on Sat, Jan 23, 1999 at 05:18:20PM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, On Sat, Jan 23, 1999 at 05:18:20PM +0200, Sheldon Hearn wrote: > I've received via private mail a suggestion that has the desired effect: > > make -DCLOBBER includes It would be nice if you could extend this to work with the perl modules. Regards, -Jeremy -- | "In this world of temptation, I will stand for what is right. --+-- With a heart of salvation, I will hold up the light. | If I live or if I die, if I laugh or if I cry, | in this world of temptation, I will stand." -Pam Thum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 23 09:05:46 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA22796 for freebsd-hackers-outgoing; Sat, 23 Jan 1999 09:05:46 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dream.demos.su (dream.demos.su [194.87.2.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA22781 for ; Sat, 23 Jan 1999 09:05:44 -0800 (PST) (envelope-from apg@demos.net) Received: (from uucp@localhost) by dream.demos.su (8.9.1/8.9.1) with UUCP id UAA27416 for hackers@freebsd.org; Sat, 23 Jan 1999 20:14:05 +0300 (MSK) (envelope-from apg@demos.net) Received: from localhost (apg@localhost) by caesar.corp.syntext.com (8.9.1/8.9.1) with ESMTP id UAA06784 for ; Sat, 23 Jan 1999 20:05:18 +0300 (MSK) (envelope-from apg@demos.net) X-Authentication-Warning: caesar.corp.syntext.com: apg owned process doing -bs Date: Sat, 23 Jan 1999 20:05:18 +0300 (MSK) From: Paul Antonov X-Sender: apg@caesar.corp.syntext.com To: hackers@FreeBSD.ORG Subject: pthreads memory leak in 3.0R ? 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 Greetings, while developing some application using ACE I discovered that program leaks memory when creating/destroying ACE tasks. I've tried to create/delete plain threads with ACE Thread_Manager, and effect is the same. Finally, I wrote the following program, and it consumes lots of memory during run. Something is wrong, I suppose? #include static void* func() { volatile int i; for(i = 0; i < 100; i++) ; } main() { pthread_t handle; int i; for(i = 0; i < 1000000; i++) { pthread_create(&handle, 0, func, 0); pthread_join(handle, 0); } } -- Paul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 23 11:06:04 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA03843 for freebsd-hackers-outgoing; Sat, 23 Jan 1999 11:06:04 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA03834 for ; Sat, 23 Jan 1999 11:06:03 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 16227 invoked from network); 23 Jan 1999 19:05:48 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 23 Jan 1999 19:05:48 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id OAA04877; Sat, 23 Jan 1999 14:05:47 -0500 (EST) Message-Id: <199901231905.OAA04877@y.dyson.net> Subject: Re: Error in vm_fault change In-Reply-To: <199901230456.UAA58423@apollo.backplane.com> from Matthew Dillon at "Jan 22, 99 08:56:07 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Sat, 23 Jan 1999 14:05:47 -0500 (EST) Cc: dyson@iquest.net, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Dillon said: > :hoggy process. However, thrashing by a hoggy process should be managed by > :limits. :-(. You are breaking any notion of the pageout daemon keeping stats > :in normal low memory conditions, but thrashing is hopeless anyway without > :limits (am I repeating myself?) > > Being realistic, *nobody* manages the RSS limits this tightly. As > much as I like RSS limits, their lack of any sort of dynamic feedback > makes them mostly unuseable in my view. They were almost entirely > unuseable at BEST on every machine from the lowliest mail server to the > most heavily loaded shell/web machine. On early machines with > significantly less memory then the machines have now, all I got for my > efforts were user complaints. > > The problem is that by the time an RSS limit kicks in, the damage > has already been done. > > If RSS limits were metrics rather then absolute values, they would > be MUCH more useful. > The existing RSS limit code did have a terrible lag, and therefore (really evil) processes could do their damage before the RSS limit helps. The RSS limit code that I provided delays the limit until memory conditions are low (and perhaps that still isn't good enough.) The new (proposed) RSS limit code does have a slight negative feedback (in that the code doesn't do anything unless memory is low.) My guess is that the RSS (hard) limit needs to be larger than the soft limit. Also, the RSS limiting needs to come into play when the cache queue is being attacked too much by the *evil* process. My demo code doesn't do that, but it is easy to add in. By adding the cache queue into the current version of my code (that I am running), it would look even more like the code previously elided in some ways. (I am going to add cache/inactive queue damage sensing to my local codebase to see if it works well.) The RSS limit needs to be a limit, and not a guideline, and shouldn't be used as such (the way the code is today.) Maybe a calculation could be added (similar to the systat -vmstat info) for a guideline. It is important to compare "peak" info with a "peak" limit, along with "average" or "trend" info with an "average" or "trend" limit. By using a "peak" limit (with the RSS limit code as is) as an "average", that is misuse. I guarantee you that an average limit would be MUCH more costly to calculate with any time resolution. (Remember, I know numerical methods and DSP type design fairly well -- there has always been an attempt to avoid too much cost in the FreeBSD VM code, and DG has always been on the side of sanity in my algorithmic complexity tendancies.) On reflection, I think that keeping the code simple has been a benefit, because it could have been even more subtile. By trying to create "guidelines", then processes using memory heavily, will see degradation. That degradation will take more in-common resources. The resource limit mechanism will be costly to system performance, when it comes into play. It ends up being the lesser of two evils. Note also, there are two kinds of "evil" processes: DOS type processes as might be run on BEST shell machines. Just big processes as might be run on workstations. With a few mods (which I really don't have time to code), I suggest that the peak RSS limits with some sensing of cache queue damage will help control the damage from both kinds of proceses. The DOS type process is problematical, and the average (or trend) limiting would allow for better control, but would also cost more. Machines today can do lots of damage to their memory profile, very quickly. The peak limit is probably a reasonable tradeoff of cost to calculate vs. benefit. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 23 11:58:29 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA09552 for freebsd-hackers-outgoing; Sat, 23 Jan 1999 11:58:29 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from TomQNX.tomqnx.com (cpu2745.adsl.bellglobal.com [207.236.55.214]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA09547 for ; Sat, 23 Jan 1999 11:58:27 -0800 (PST) (envelope-from freebsd@tomqnx.com) Received: by TomQNX.tomqnx.com (Smail3.2 #1) id m1049CC-000I5qC; Sat, 23 Jan 1999 14:58:16 -0500 (EST) Message-Id: From: freebsd@tomqnx.com (Tom Torrance) Subject: USB drivers To: hackers@FreeBSD.ORG Date: Sat, 23 Jan 1999 14:58:16 -0500 (EST) 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 Is anyone working on a driver for digital video-conferencing camera? I am debating whether to buy a Logitech VC or a Kodak DVC 323. It would be great to have support under FreeBSD! Regards, Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 23 12:03:41 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA10123 for freebsd-hackers-outgoing; Sat, 23 Jan 1999 12:03:41 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from iquest3.iquest.net (iquest3.iquest.net [209.43.20.203]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA10112 for ; Sat, 23 Jan 1999 12:03:35 -0800 (PST) (envelope-from toor@y.dyson.net) Received: (qmail 3736 invoked from network); 23 Jan 1999 20:03:23 -0000 Received: from dyson.iquest.net (HELO y.dyson.net) (198.70.144.127) by iquest3.iquest.net with SMTP; 23 Jan 1999 20:03:23 -0000 Received: (from root@localhost) by y.dyson.net (8.9.1/8.9.1) id PAA04978; Sat, 23 Jan 1999 15:03:17 -0500 (EST) Message-Id: <199901232003.PAA04978@y.dyson.net> Subject: Re: Error in vm_fault change In-Reply-To: <199901230459.WAA06844@home.dragondata.com> from Kevin Day at "Jan 22, 99 10:59:27 pm" To: toasty@home.dragondata.com (Kevin Day) Date: Sat, 23 Jan 1999 15:03:17 -0500 (EST) Cc: dyson@iquest.net, rcarter@pinyon.org, dufault@hda.com, dillon@apollo.backplane.com, hackers@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kevin Day said: > > But... This is deviating quite a bit from what you guys are talking about, > and I'm probably quite an exception to what is normally done with fbsd, than > the majority. > Realtime and multimedia is becoming more predominant. (In fact, isn't multimedia more predominant than anything else now -- if you count games, etc.) Schedulers have been researched fairly well, but it seems that some of the research really needs to be brought into free software. Your observations/application types seem to be exactly the kind of thing that need to be supported by future OSes. -- John | Never try to teach a pig to sing, dyson@iquest.net | it makes one look stupid jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 23 12:47:45 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA13209 for freebsd-hackers-outgoing; Sat, 23 Jan 1999 12:47:45 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from net177138.hcv.com (net177138.hcv.com [209.153.177.138]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA13202 for ; Sat, 23 Jan 1999 12:47:33 -0800 (PST) (envelope-from matthew@wolfepub.com) Received: from thunder ([10.0.0.12]) by net177138.hcv.com (8.8.8/8.8.8) with SMTP id PAA07171 for ; Sat, 23 Jan 1999 15:42:53 -0500 (EST) (envelope-from matthew@wolfepub.com) Message-Id: <4.1.19990123153652.00a257b0@firebat.wolfepub.com> X-Sender: matthew@firebat.wolfepub.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sat, 23 Jan 1999 15:48:17 -0500 To: hackers@FreeBSD.ORG From: Matthew Hagerty Subject: 3.0-Release /boot/loader for ELF kernel Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greetings, I was under the impression that 3.0-Release was an ELF system? I was just compiling a custom kernel and received a message that said I should ensure my /boot/loader can handle the ELF kernel. I cannot boot from the kernel I compiled but I can boot from kernel.GENERIC, so should I do the ELF /boot/loader upgrade on my 3.0-Release system? Thanks, Matthew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 23 13:17:14 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA16761 for freebsd-hackers-outgoing; Sat, 23 Jan 1999 13:17:14 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA16756 for ; Sat, 23 Jan 1999 13:17:09 -0800 (PST) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id UAA21954; Sat, 23 Jan 1999 20:05:15 +0100 From: Luigi Rizzo Message-Id: <199901231905.UAA21954@labinfo.iet.unipi.it> Subject: Re: USB drivers To: freebsd@tomqnx.com (Tom Torrance) Date: Sat, 23 Jan 1999 20:05:15 +0100 (MET) Cc: hackers@FreeBSD.ORG In-Reply-To: from "Tom Torrance" at Jan 23, 99 02:57:57 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Is anyone working on a driver for digital video-conferencing > camera? I am debating whether to buy a Logitech VC or > a Kodak DVC 323. It would be great to have support under FreeBSD! unless you have other constraints (e.g. want to use this on a laptop which only has a USB port) I still strongly recommend a standard (composite-video output) camera and a video capture card. The camera costs the same or marginally less than the corresponding USB unit, the card will cost you more than the 0$ for an embedded USB port, but you can have it working _now_ and have the bonus of being able to watch TV, digitize from tapes and select multiple video sources with a 2$ rotary switch! cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO . EMAIL: luigi@iet.unipi.it . Dip. di Ing. dell'Informazione HTTP://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 23 14:32:51 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA25759 for freebsd-hackers-outgoing; Sat, 23 Jan 1999 14:32:51 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ceia.nordier.com (m1-35-dbn.dial-up.net [196.34.155.35]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA25746 for ; Sat, 23 Jan 1999 14:32:45 -0800 (PST) (envelope-from rnordier@nordier.com) Received: (from rnordier@localhost) by ceia.nordier.com (8.8.7/8.6.12) id AAA14600; Sun, 24 Jan 1999 00:31:21 +0200 (SAT) From: Robert Nordier Message-Id: <199901232231.AAA14600@ceia.nordier.com> Subject: Re: 3.0-Release /boot/loader for ELF kernel In-Reply-To: <4.1.19990123153652.00a257b0@firebat.wolfepub.com> from Matthew Hagerty at "Jan 23, 99 03:48:17 pm" To: matthew@wolfepub.com (Matthew Hagerty) Date: Sun, 24 Jan 1999 00:31:19 +0200 (SAT) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Matthew Hagerty wrote: > Greetings, > > I was under the impression that 3.0-Release was an ELF system? I was just > compiling a custom kernel and received a message that said I should ensure > my /boot/loader can handle the ELF kernel. I cannot boot from the kernel I > compiled but I can boot from kernel.GENERIC, so should I do the ELF > /boot/loader upgrade on my 3.0-Release system? > > Thanks, > Matthew Yes, you should. The default 3.0R bootstrap was capable of handling only kernels in a.out format. For information about updating your boot blocks see http://www.freebsd.org/~rnordier/boot.txt and there's information about a transition to ELF-format kernels at http://www.freebsd.org/~peter/elfday.html -- Robert Nordier To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message From owner-freebsd-hackers Sat Jan 23 15:06:43 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA29463 for freebsd-hackers-outgoing; Sat, 23 Jan 1999 15:06:43 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from net177138.hcv.com (net177138.hcv.com [209.153.177.138]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA29456 for ; Sat, 23 Jan 1999 15:06:42 -0800 (PST) (envelope-from matthew@wolfepub.com) Received: from thunder ([10.0.0.12]) by net177138.hcv.com (8.8.8/8.8.8) with SMTP id SAA07288; Sat, 23 Jan 1999 18:01:41 -0500 (EST) (envelope-from matthew@wolfepub.com) Message-Id: <4.1.19990123180400.009ee250@firebat.wolfepub.com> X-Sender: matthew@firebat.wolfepub.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sat, 23 Jan 1999 18:07:04 -0500 To: Robert Nordier From: Matthew Hagerty Subject: Thank you (was Re: 3.0-Release /boot/loader for ELF kernel) Cc: hackers@FreeBSD.ORG In-Reply-To: <199901232231.AAA14600@ceia.nordier.com> References: <4.1.19990123153652.00a257b0@firebat.wolfepub.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thank you for the information, I am now securely running 3.0-Stable ELF with the new bootblocks. :) Thanks, Matthew At 12:31 AM 1/24/99 +0200, Robert Nordier wrote: >Matthew Hagerty wrote: > >> Greetings, >> >> I was under the impression that 3.0-Release was an ELF system? I was just >> compiling a custom kernel and received a message that said I should ensure >> my /boot/loader can handle the ELF kernel. I cannot boot from the kernel I >> compiled but I can boot from kernel.GENERIC, so should I do the ELF >> /boot/loader upgrade on my 3.0-Release system? >> >> Thanks, >> Matthew > >Yes, you should. The default 3.0R bootstrap was capable of handling >only kernels in a.out format. For information about updating your >boot blocks see > > http://www.freebsd.org/~rnordier/boot.txt > >and there's information about a transition to ELF-format kernels at > > http://www.freebsd.org/~peter/elfday.html > >-- >Robert Nordier > >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 Jan 23 21:43:41 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA14508 for freebsd-hackers-outgoing; Sat, 23 Jan 1999 21:43:41 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (castles94.castles.com [208.214.165.94]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA14498 for ; Sat, 23 Jan 1999 21:43:37 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id VAA00591; Sat, 23 Jan 1999 21:39:57 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901240539.VAA00591@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd@tomqnx.com (Tom Torrance) cc: hackers@FreeBSD.ORG Subject: Re: USB drivers In-reply-to: Your message of "Sat, 23 Jan 1999 14:58:16 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 23 Jan 1999 21:39:56 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Is anyone working on a driver for digital video-conferencing > camera? I am debating whether to buy a Logitech VC or > a Kodak DVC 323. It would be great to have support under FreeBSD! It would be great if you were to write support for FreeBSD! Seriously, we have the basic infrastructure in place now; you'd just have to do the specifically camera-related bits, which in the presence of the USB docs and vendor specification would be an SMOP. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ 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 Sat Jan 23 23:45:34 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA26345 for freebsd-hackers-outgoing; Sat, 23 Jan 1999 23:45:34 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA26336 for ; Sat, 23 Jan 1999 23:45:22 -0800 (PST) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.2/8.8.5) id AAA07177; Sun, 24 Jan 1999 00:44:52 -0700 (MST) From: "Kenneth D. Merry" Message-Id: <199901240744.AAA07177@panzer.plutotech.com> Subject: Re: SCSI question... and some enum idea In-Reply-To: <19990123041739.G4581@nacamar.net> from "Karsten W. Rohrbach" at "Jan 23, 99 04:17:39 am" To: rohrbach@nacamar.net Date: Sun, 24 Jan 1999 00:44:52 -0700 (MST) Cc: freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (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 Karsten W. Rohrbach wrote... > i got a box with 2940u2w(aic789x) and raid array on an infortrend ift3102 > running here. the ift does create multiple luns for the different logical > disks - and it works excellent for me. > > btw, what came to my mind in this context was the enumeration of disk > devices (da?)... on some $$$ un*x boxes you got a scheme where the device > inode enumeration is fixed to the bus, scsi id and lun of the device > (pretty good idea that) so that if you sometimes add or remove your second > disk the third doesnt get the second and gets a mount error with wrong > filesystem type... so you would use /dev/disk/bus0id0lun0a or something as > root device... is this a good idea or is it rather nasty? i am often > swapping in/out our cd toaster of my department which is jumpered to id4 > and i'm a lazy bastard, so my drive on id5 and the cdrom on id6 change > device numbers sometimes... You can hardwire devices in your kernel config file to achieve the same effect, with more flexibility. You can do things like: controller ahc0 controller scbus0 at ahc0 device da0 at scbus0 target 0 unit 0 device cd0 at scbus0 target 5 unit 0 device cd1 at scbus0 target 6 unit 0 device cd2 at scbus0 target 4 unit 0 See LINT, or cam(4) for more details. [ which reminds me of a PR I need to fix and close ] Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message