From owner-freebsd-arch@FreeBSD.ORG Sun Oct 30 10:48:15 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A502E16A41F for ; Sun, 30 Oct 2005 10:48:15 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DD5443D46 for ; Sun, 30 Oct 2005 10:48:15 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 39E491A3C1A; Sun, 30 Oct 2005 02:48:15 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id AB2A151376; Sun, 30 Oct 2005 05:48:14 -0500 (EST) Date: Sun, 30 Oct 2005 05:48:14 -0500 From: Kris Kennaway To: "M. Warner Losh" Message-ID: <20051030104814.GA32477@xor.obsecurity.org> References: <12768156.1130520253107.JavaMail.root@vms073.mailsrvcs.net> <200510281435.41700.jhb@freebsd.org> <4362B611.B4A12AF8@verizon.net> <20051028.215049.102576958.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW" Content-Disposition: inline In-Reply-To: <20051028.215049.102576958.imp@bsdimp.com> User-Agent: Mutt/1.4.2.1i Cc: gbergling@0xfce3.net, babkin@users.sourceforge.net, babkin@verizon.net, phk@phk.freebsd.dk, freebsd-arch@freebsd.org Subject: Re: wscons for FreeBSD? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2005 10:48:15 -0000 --ew6BAiZeqk4r7MaW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 28, 2005 at 09:50:49PM -0600, M. Warner Losh wrote: > In message: <4362B611.B4A12AF8@verizon.net> > Sergey Babkin writes: > : John Baldwin wrote: > : >=20 > : > On Friday 28 October 2005 01:24 pm, Sergey Babkin wrote: > : > > >From: John Baldwin > : > > > > :=20 > : > > * When entering panic/debugger mode the console > : > > should reset its video mode to the one where > : > > the panic information is visible. > : >=20 > : > I think this might be kind of hard since you really don't know what X= has done > : > to the hardware unless you make X talk to the console driver to do > : > everything. > :=20 > : Can you re-initialize the device from scratch? My knowledge > : about the video hardware dates to SVGA times and even that > : is not too deep. > :=20 > : Maybe provide a basic SVGA re-initialization routine on x86 and have > : an interface for the third-party in-kernel drivers that > : would contain the re-initialization routine. >=20 > When this has come up in the past, those in the know say that it takes > card specific registers and knowledge to reset these cards' video > modes. Even if it doesn't work on all cards, if there's some method that will at least work for a subset of configurations it may be worth investigating: by that point the machine has panicked anyway, so what's the worst that can happen? Kris --ew6BAiZeqk4r7MaW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDZKTuWry0BWjoQKURAi+4AKD2Dn4NElcm2UoiJ89tgr5xNla5mACg3QPc cApA2hb9fnvMD7dNeVIEdUs= =GwCl -----END PGP SIGNATURE----- --ew6BAiZeqk4r7MaW-- From owner-freebsd-arch@FreeBSD.ORG Sun Oct 30 16:45:22 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FD1D16A41F for ; Sun, 30 Oct 2005 16:45:22 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3220D43D46 for ; Sun, 30 Oct 2005 16:45:22 +0000 (GMT) (envelope-from babkin@verizon.net) Received: from verizon.net ([138.89.161.30]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0IP6002M8MJECXA5@vms044.mailsrvcs.net> for freebsd-arch@freebsd.org; Sun, 30 Oct 2005 10:45:18 -0600 (CST) Date: Sun, 30 Oct 2005 11:45:14 -0500 From: Sergey Babkin Sender: root To: Kris Kennaway Message-id: <4364F89A.29B607B4@verizon.net> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.7-RELEASE i386) Content-type: text/plain; charset=koi8-r Content-transfer-encoding: 7bit X-Accept-Language: en, ru References: <12768156.1130520253107.JavaMail.root@vms073.mailsrvcs.net> <200510281435.41700.jhb@freebsd.org> <4362B611.B4A12AF8@verizon.net> <20051028.215049.102576958.imp@bsdimp.com> <20051030104814.GA32477@xor.obsecurity.org> Cc: gbergling@0xfce3.net, babkin@users.sourceforge.net, phk@phk.freebsd.dk, freebsd-arch@freebsd.org Subject: Re: wscons for FreeBSD? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: babkin@users.sf.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2005 16:45:22 -0000 Kris Kennaway wrote: > > On Fri, Oct 28, 2005 at 09:50:49PM -0600, M. Warner Losh wrote: > > In message: <4362B611.B4A12AF8@verizon.net> > > Sergey Babkin writes: > > : John Baldwin wrote: > > : > > > : > On Friday 28 October 2005 01:24 pm, Sergey Babkin wrote: > > : > > >From: John Baldwin > > : > > > > > : > > : > > * When entering panic/debugger mode the console > > : > > should reset its video mode to the one where > > : > > the panic information is visible. > > : > > > : > I think this might be kind of hard since you really don't know what X has done > > : > to the hardware unless you make X talk to the console driver to do > > : > everything. > > : > > : Can you re-initialize the device from scratch? My knowledge > > : about the video hardware dates to SVGA times and even that > > : is not too deep. > > : > > : Maybe provide a basic SVGA re-initialization routine on x86 and have > > : an interface for the third-party in-kernel drivers that > > : would contain the re-initialization routine. > > > > When this has come up in the past, those in the know say that it takes > > card specific registers and knowledge to reset these cards' video > > modes. > > Even if it doesn't work on all cards, if there's some method that will > at least work for a subset of configurations it may be worth > investigating: by that point the machine has panicked anyway, so > what's the worst that can happen? I think that if there are no endless busy waits, nothing should make the situation any worse. I guess for VESA-compatible cards the VESA BIOS couls be used too, but that's much more complicated to do and much more prone to things going wrong during resets. But I guess in any case providing an interface for the in-kernel reset drivers would solve the problem as long as there are those drivers. Their implementation can probably be extracted from XF86, though of course it would need extra work. -SB From owner-freebsd-arch@FreeBSD.ORG Tue Nov 1 00:32:51 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9687916A41F; Tue, 1 Nov 2005 00:32:51 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1F2243D6B; Tue, 1 Nov 2005 00:32:48 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.33] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id jA10Wkxq023865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 31 Oct 2005 16:32:47 -0800 Message-ID: <4366999B.4070005@root.org> Date: Mon, 31 Oct 2005 14:24:27 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: KTR changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2005 00:32:51 -0000 I've done a quick audit of the tree and found this number of KTR uses for each label. Label Count ---- ----- KTR_GEN 30 KTR_NET 0 KTR_DEV 1 KTR_LOCK 36 KTR_SMP 55 KTR_FS 0 KTR_PMAP 28 KTR_MALLOC 0 KTR_TRAP 31 KTR_INTR 35 KTR_SIG 21 KTR_CLK 1 KTR_PROC 31 KTR_SYSC 27 KTR_INIT 10 KTR_KGDB 0 KTR_IO 0 KTR_EVH 9 KTR_VFS 19 KTR_VOP 102 (Due to dynamically generated vop files) KTR_VM 5 KTR_WITNESS 10 KTR_RUNQ 30 KTR_CONTENTION 2 KTR_UMA 2 KTR_CALLOUT 3 KTR_GEOM 23 KTR_BUSDMA 56 KTR_CRITICAL 2 KTR_SCHED 25 KTR_BUF 26 As such, I'd like to mark the following unused and free for allocation: KTR_NET, KTR_FS, KTR_MALLOC, KTR_KGDB, KTR_IO These should be merged the following under KTR_MALLOC (KTR_MEM?): KTR_UMA: uma_zalloc_arg, uma_zfree_arg KTR_VM: vmspace_alloc, vmspace_free, vm_map_create, vm_map_entry_unlink Merge under KTR_SYNCH (KTR_LOCK?): KTR_CRITICAL: critical enter/exit KTR_CONTENTION: mutex contention start/end Merge under KTR_TIMER: KTR_CLK: hard clock firing KTR_CALLOUT: Giant or mutex-based callout run Also, it appears that we overran into KTR_CTx space with KTR_UMA (rwatson). Is this something that needs to be changed or should we reduce KTR_CTx? Last, I'd like to add a new level, KTR_POWER, for use with power management events. Since we only have 32 bits of KTR levels, it's important to use them carefully. Comments on all this are welcome. -Nate From owner-freebsd-arch@FreeBSD.ORG Tue Nov 1 01:24:00 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF80916A41F for ; Tue, 1 Nov 2005 01:24:00 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from speedfactory.net (mail5.speedfactory.net [66.23.216.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C52343D49 for ; Tue, 1 Nov 2005 01:23:59 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 1136723 for multiple; Mon, 31 Oct 2005 20:21:57 -0500 Received: from [192.168.0.15] (osx.baldwin.cx [192.168.0.15]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jA11NsiY039477; Mon, 31 Oct 2005 20:23:54 -0500 (EST) (envelope-from jhb@FreeBSD.org) In-Reply-To: <4366999B.4070005@root.org> References: <4366999B.4070005@root.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2BFF6EA7-F684-4DFB-8821-2DC5EBEB2181@FreeBSD.org> Content-Transfer-Encoding: 7bit From: John Baldwin Date: Mon, 31 Oct 2005 20:23:45 -0500 To: Nate Lawson X-Mailer: Apple Mail (2.734) X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=100 Cc: arch@FreeBSD.org Subject: Re: KTR changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2005 01:24:00 -0000 On Oct 31, 2005, at 5:24 PM, Nate Lawson wrote: > KTR_WITNESS 10 This is isolated to one file and should probably be aliased to some other bit kind of like how I made KTR_TULIP map to KTR_DEV when it was enabled and 0 otherwise based on #ifdef's in if_de.c. We might should have one generic bit for subsystems to use similar to how device drivers can use KTR_DEV. > As such, I'd like to mark the following unused and free for > allocation: > KTR_NET, KTR_FS, KTR_MALLOC, KTR_KGDB, KTR_IO I'd rather someone add KTR_MALLOC traces than get rid of it. :) If we fleshed out our more general logging for in-kernel facilities that helps to get a general feel of what the system is doing when debugging. I think some traces are for debugging specific subsystems such as KTR_WITNESS or KTR_TULIP where as some are more general to tell you what the kernel is doing (KTR_PROC, KTR_INTR, and KTR_LOCK fall into this category as probably would KTR_MALLOC and KTR_CONTENTION). I think subsystem trace classes should be mapped to generic bits where as kernel-wide tracing should get their own bits if possible. > These should be merged the following under KTR_MALLOC (KTR_MEM?): > KTR_UMA: uma_zalloc_arg, uma_zfree_arg > KTR_VM: vmspace_alloc, vmspace_free, vm_map_create, > vm_map_entry_unlink Well, I'm not sure about those as the KTR_VM ones aren't related to kernel malloc at all. vmspaces are the user virtual address mappings with vm_map being individual mappings. :) That's like saying that mmap() should be part of malloc(). :) I also think KTR_UMA is probably useful for getting a general feel for memory allocation activity in the kernel. > Merge under KTR_SYNCH (KTR_LOCK?): > KTR_CRITICAL: critical enter/exit > KTR_CONTENTION: mutex contention start/end Perhaps default KTR_CRITICAL to off and let people who want it map it to a generic bit. It's very expensive and I'm not sure it's very useful for all but a few people. Then I would leave KTR_CONTENTION alone. > Merge under KTR_TIMER: > KTR_CLK: hard clock firing KTR_CLK is useless, just drop it. Instead, maybe add KTR_INTR traces for clock interrupts where they are missing. > KTR_CALLOUT: Giant or mutex-based callout run Then you can leave KTR_CALLOUT as is. :) > Also, it appears that we overran into KTR_CTx space with KTR_UMA > (rwatson). Is this something that needs to be changed or should we > reduce KTR_CTx? I don't think anyone uses KTR_CTx currently? > Last, I'd like to add a new level, KTR_POWER, for use with power > management events. Since we only have 32 bits of KTR levels, it's > important to use them carefully. Comments on all this are welcome. Is this for debugging stuff inside ACPI or is it supposed to record general system-wide activity? Another option is to dispense with the whole bitmask idea altogether and give each compiled in KTR class its own boolean char with an associoted sysctl and loader tunable. You could then allow users to specify each class they want to compile in via a separate kernel option (KTR_CLASS_FOO) with a special case that KTR_CLASS_ALL would #define all of the classes in sys/ktr.h. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Tue Nov 1 01:36:17 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88D8B16A41F; Tue, 1 Nov 2005 01:36:15 +0000 (GMT) (envelope-from frank@exit.com) Received: from tinker.exit.com (tinker.exit.com [206.223.0.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC1B243D45; Tue, 1 Nov 2005 01:36:14 +0000 (GMT) (envelope-from frank@exit.com) Received: from realtime.exit.com (realtime [206.223.0.5]) by tinker.exit.com (8.13.4/8.13.4) with ESMTP id jA11aAW9088173; Mon, 31 Oct 2005 17:36:10 -0800 (PST) (envelope-from frank@exit.com) Received: from realtime.exit.com (localhost [127.0.0.1]) by realtime.exit.com (8.13.4/8.13.4) with ESMTP id jA11a9uc016575; Mon, 31 Oct 2005 17:36:09 -0800 (PST) (envelope-from frank@exit.com) Received: (from frank@localhost) by realtime.exit.com (8.13.4/8.13.4/Submit) id jA11a7JB016563; Mon, 31 Oct 2005 17:36:07 -0800 (PST) (envelope-from frank@exit.com) X-Authentication-Warning: realtime.exit.com: frank set sender to frank@exit.com using -f From: Frank Mayhar To: John Baldwin In-Reply-To: <2BFF6EA7-F684-4DFB-8821-2DC5EBEB2181@FreeBSD.org> References: <4366999B.4070005@root.org> <2BFF6EA7-F684-4DFB-8821-2DC5EBEB2181@FreeBSD.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Exit Consulting Date: Mon, 31 Oct 2005 17:36:06 -0800 Message-Id: <1130808966.14387.3.camel@realtime.exit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port X-Virus-Scanned: ClamAV 0.86.2/1151/Mon Oct 31 10:34:04 2005 on tinker.exit.com X-Virus-Status: Clean Cc: arch@freebsd.org, Nate Lawson Subject: Re: KTR changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: frank@exit.com List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2005 01:36:17 -0000 On Mon, 2005-10-31 at 20:23 -0500, John Baldwin wrote: > I don't think anyone uses KTR_CTx currently? Odd that this should come up at just this time, since I'm just now using the KTR_CTx set to debug the iir driver. (This is in reference to my possibly iir-related panic recently.) Not that this will ever find its way into the tree, and even if it did it should probably use KTR_DEV, but it was certainly convenient for my purposes. -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ From owner-freebsd-arch@FreeBSD.ORG Tue Nov 1 11:08:28 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7DCF16A41F for ; Tue, 1 Nov 2005 11:08:28 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 050C443D45 for ; Tue, 1 Nov 2005 11:08:27 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jA1B8PMs076523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Nov 2005 14:08:25 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jA1B8O6N076522; Tue, 1 Nov 2005 14:08:24 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 1 Nov 2005 14:08:24 +0300 From: Gleb Smirnoff To: Nate Lawson Message-ID: <20051101110824.GB76140@cell.sick.ru> References: <4366999B.4070005@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4366999B.4070005@root.org> User-Agent: Mutt/1.5.6i Cc: arch@FreeBSD.org Subject: Re: KTR changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2005 11:08:28 -0000 On Mon, Oct 31, 2005 at 02:24:27PM -0800, Nate Lawson wrote: N> As such, I'd like to mark the following unused and free for allocation: N> KTR_NET, KTR_FS, KTR_MALLOC, KTR_KGDB, KTR_IO Please don't touch KTR_NET. Network stack is a big subsystem that should make a use of ktr(4) someday. I use KTR_NET in my testing patches, when I work on chasing bugs. May be I will eventually commit parts of them. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-arch@FreeBSD.ORG Tue Nov 1 20:25:48 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 089C216A41F; Tue, 1 Nov 2005 20:25:48 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id A643443D45; Tue, 1 Nov 2005 20:25:47 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.33] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id jA1KPkxq006217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Nov 2005 12:25:46 -0800 Message-ID: <4367CF1E.2020809@root.org> Date: Tue, 01 Nov 2005 12:25:02 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <4366999B.4070005@root.org> <2BFF6EA7-F684-4DFB-8821-2DC5EBEB2181@FreeBSD.org> In-Reply-To: <2BFF6EA7-F684-4DFB-8821-2DC5EBEB2181@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: KTR changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2005 20:25:48 -0000 John Baldwin wrote: > > On Oct 31, 2005, at 5:24 PM, Nate Lawson wrote: > >> KTR_WITNESS 10 > > > This is isolated to one file and should probably be aliased > to some other bit kind of like how I made KTR_TULIP map to > KTR_DEV when it was enabled and 0 otherwise based on #ifdef's > in if_de.c. We might should have one generic bit for > subsystems to use similar to how device drivers can use > KTR_DEV. Sounds good. KTR_KERN? >> As such, I'd like to mark the following unused and free for allocation: >> KTR_NET, KTR_FS, KTR_MALLOC, KTR_KGDB, KTR_IO > > I'd rather someone add KTR_MALLOC traces than get rid of > it. :) If we fleshed out our more general logging for > in-kernel facilities that helps to get a general feel of what > the system is doing when debugging. I think some traces are > for debugging specific subsystems such as KTR_WITNESS or > KTR_TULIP where as some are more general to tell you what the > kernel is doing (KTR_PROC, KTR_INTR, and KTR_LOCK fall into > this category as probably would KTR_MALLOC and KTR_CONTENTION). > I think subsystem trace classes should be mapped to generic > bits where as kernel-wide tracing should get their own bits if > possible. So since no one defended KTR_FS, KGDB, and IO, I'll reclaim those. I'm out of bits and need one for KTR_POWER. >> These should be merged the following under KTR_MALLOC (KTR_MEM?): >> KTR_UMA: uma_zalloc_arg, uma_zfree_arg >> KTR_VM: vmspace_alloc, vmspace_free, vm_map_create, vm_map_entry_unlink > > Well, I'm not sure about those as the KTR_VM ones aren't related > to kernel malloc at all. vmspaces are the user virtual address > mappings with vm_map being individual mappings. :) That's like > saying that mmap() should be part of malloc(). :) I also think > KTR_UMA is probably useful for getting a general feel for memory > allocation activity in the kernel. What I'm trying to achieve is a general "KTR_MEMORY_STUFF" key. If you're interested in allocations, getting info about mappings wouldn't hurt either. >> Merge under KTR_SYNCH (KTR_LOCK?): >> KTR_CRITICAL: critical enter/exit >> KTR_CONTENTION: mutex contention start/end > > Perhaps default KTR_CRITICAL to off and let people who want it > map it to a generic bit. It's very expensive and I'm not sure > it's very useful for all but a few people. Then I would leave > KTR_CONTENTION alone. Ok, so KTR_CRITICAL can be reclaimed also. >> Merge under KTR_TIMER: >> KTR_CLK: hard clock firing > > KTR_CLK is useless, just drop it. Instead, maybe add KTR_INTR > traces for clock interrupts where they are missing. Ok. > I don't think anyone uses KTR_CTx currently? > >> Last, I'd like to add a new level, KTR_POWER, for use with power >> management events. Since we only have 32 bits of KTR levels, it's >> important to use them carefully. Comments on all this are welcome. > > Is this for debugging stuff inside ACPI or is it supposed to record > general system-wide activity? System-wide power activity. Devices being powered up or down, suspend/resume methods, ACPI control of mosfets, etc. > Another option is to dispense with the whole bitmask idea altogether > and give each compiled in KTR class its own boolean char with an > associoted sysctl and loader tunable. You could then allow users to > specify each class they want to compile in via a separate kernel option > (KTR_CLASS_FOO) with a special case that KTR_CLASS_ALL would #define > all of the classes in sys/ktr.h. I think that would increase the overhead in checking each boolean in a loop vs. just a bitmask &, right? -- Nate From owner-freebsd-arch@FreeBSD.ORG Tue Nov 1 20:27:01 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 657D616A42C; Tue, 1 Nov 2005 20:27:01 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E6BA43D66; Tue, 1 Nov 2005 20:27:00 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.33] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id jA1KQxxq006328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Nov 2005 12:26:59 -0800 Message-ID: <4367CF67.3010505@root.org> Date: Tue, 01 Nov 2005 12:26:15 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gleb Smirnoff References: <4366999B.4070005@root.org> <20051101110824.GB76140@cell.sick.ru> In-Reply-To: <20051101110824.GB76140@cell.sick.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: KTR changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2005 20:27:01 -0000 Gleb Smirnoff wrote: > On Mon, Oct 31, 2005 at 02:24:27PM -0800, Nate Lawson wrote: > N> As such, I'd like to mark the following unused and free for allocation: > N> KTR_NET, KTR_FS, KTR_MALLOC, KTR_KGDB, KTR_IO > > Please don't touch KTR_NET. Network stack is a big subsystem that should > make a use of ktr(4) someday. I use KTR_NET in my testing patches, when > I work on chasing bugs. May be I will eventually commit parts of them. Ok, I'll leave that one. However, I'm very unsympathetic to the general argument of "leave that for the future" when it's been unused since version 1.1 in 2000. It looks like I'll be able to reclaim enough to leave this one. -- Nate From owner-freebsd-arch@FreeBSD.ORG Tue Nov 1 21:06:22 2005 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAABE16A41F for ; Tue, 1 Nov 2005 21:06:22 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 711EF43D49 for ; Tue, 1 Nov 2005 21:06:22 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from [10.50.41.234] (Not Verified[10.50.41.234]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Tue, 01 Nov 2005 16:22:36 -0500 From: John Baldwin To: Nate Lawson Date: Tue, 1 Nov 2005 16:05:33 -0500 User-Agent: KMail/1.8.2 References: <4366999B.4070005@root.org> <2BFF6EA7-F684-4DFB-8821-2DC5EBEB2181@FreeBSD.org> <4367CF1E.2020809@root.org> In-Reply-To: <4367CF1E.2020809@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511011605.34317.jhb@freebsd.org> Cc: arch@freebsd.org Subject: Re: KTR changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2005 21:06:23 -0000 On Tuesday 01 November 2005 03:25 pm, Nate Lawson wrote: > John Baldwin wrote: > > On Oct 31, 2005, at 5:24 PM, Nate Lawson wrote: > >> KTR_WITNESS 10 > > > > This is isolated to one file and should probably be aliased > > to some other bit kind of like how I made KTR_TULIP map to > > KTR_DEV when it was enabled and 0 otherwise based on #ifdef's > > in if_de.c. We might should have one generic bit for > > subsystems to use similar to how device drivers can use > > KTR_DEV. > > Sounds good. KTR_KERN? Maybe KTR_SUBSYS or something. It's all in the kernel. :) If we go with the non-bitmask route this doesn't matter though. > > Another option is to dispense with the whole bitmask idea altogether > > and give each compiled in KTR class its own boolean char with an > > associoted sysctl and loader tunable. You could then allow users to > > specify each class they want to compile in via a separate kernel option > > (KTR_CLASS_FOO) with a special case that KTR_CLASS_ALL would #define > > all of the classes in sys/ktr.h. > > I think that would increase the overhead in checking each boolean in a > loop vs. just a bitmask &, right? Huh? Each check does a bitmask and taht wouldn't change, you'd just be checking the boolean instead. Actually, we do two checks, one is a compile time check, and the other is a runtime check. Here's the CTR() macro: #define CTR6(m, format, p1, p2, p3, p4, p5, p6) do { \ if (KTR_COMPILE & (m)) \ ktr_tracepoint((m), __FILE__, __LINE__, format, \ (u_long)(p1), (u_long)(p2), (u_long)(p3), \ (u_long)(p4), (u_long)(p5), (u_long)(p6)); \ } while(0) So you have one & test there and basically the same thing in the function against the run-time mask. What I'm suggesting would be something like this: #define CTR6(m, format, p1, p2, p3, p4, p5, p6) do { \ if (KTR_COMPILED(m)) \ ktr_tracepoint(KTR_RUNTIME(m), __FILE__, __LINE__, format, \ (u_long)(p1), (u_long)(p2), (u_long)(p3), \ (u_long)(p4), (u_long)(p5), (u_long)(p6)); \ } while(0) Where KTR_COMPILED is a macro that works something like this: #ifdef KTR_ALL #define KTR_COMPILED(x) 1 #else #define KTR_COMPILED(m) m #endif Then for each KTR class, we'd have to have something in sys/ktr.h that did: #ifdef KTR_CLASS_FOO #define KTR_FOO 1 #else #define KTR_FOO 0 #endif (It would be nice if we could hide that in a macro, but I'm not sure cpp will let us do something like: #define KTR_CLASS(m) \ #ifdef KTR_CLASS_##m \ #define KTR_##m 1 \ extern int ktr_class_##m; \ #else \ #define KTR_##m 0 \ #endif ) For the runtime check, you would have: #define KTR_RUNTIME(m) ktr_class_##m // m has to be FOO though, not KTR_FOO You can have some more helper macros ala MALLOC_DEFINE() and MALLOC_DECLARE() for setting up KTR classes to hide as much of this as possible. This should give you the general idea though of what could be done. KTR_DEFINE() would setup the loader tunable and sysctl if the class was enabled, etc. This would get us away from the 32-bit limit with the caveat that you can no longer have a trace be used for multiple classes. That is, you can't do: CTR6(KTR_INTR | KTR_PROC, "blah blah"); If you wanted to do that (I'm not sure we do that every often anyway) you'd now have to have two different trace events for the different classes. We might even be able to store the names of the ktr type in KTR_DEFINE() and make it available in 'show ktr' in ddb as well. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Tue Nov 1 21:55:51 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D40816A41F; Tue, 1 Nov 2005 21:55:51 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1397543D48; Tue, 1 Nov 2005 21:55:50 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 0561646B85; Tue, 1 Nov 2005 16:55:50 -0500 (EST) Date: Tue, 1 Nov 2005 21:55:49 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Nate Lawson In-Reply-To: <4367CF1E.2020809@root.org> Message-ID: <20051101215412.U18382@fledge.watson.org> References: <4366999B.4070005@root.org> <2BFF6EA7-F684-4DFB-8821-2DC5EBEB2181@FreeBSD.org> <4367CF1E.2020809@root.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@FreeBSD.org, John Baldwin Subject: Re: KTR changes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2005 21:55:51 -0000 On Tue, 1 Nov 2005, Nate Lawson wrote: >>> These should be merged the following under KTR_MALLOC (KTR_MEM?): >>> KTR_UMA: uma_zalloc_arg, uma_zfree_arg >>> KTR_VM: vmspace_alloc, vmspace_free, vm_map_create, vm_map_entry_unlink >> >> Well, I'm not sure about those as the KTR_VM ones aren't related >> to kernel malloc at all. vmspaces are the user virtual address >> mappings with vm_map being individual mappings. :) That's like >> saying that mmap() should be part of malloc(). :) I also think >> KTR_UMA is probably useful for getting a general feel for memory >> allocation activity in the kernel. > > What I'm trying to achieve is a general "KTR_MEMORY_STUFF" key. If > you're interested in allocations, getting info about mappings wouldn't > hurt either. I'm not entirely sure I agree -- I think combining malloc and zone allocation makes sense, but I think keeping vm tracking separate also makes sense, as one tends not to be interested in both VM pieces and explicit kernel allocation simultaneously. Just like one probably doesn't want VFS events and device driver operations at the same time -- you can combine them, but since both at the same time tend not to be desirable... :-) Robert N M Watson From owner-freebsd-arch@FreeBSD.ORG Fri Nov 4 12:52:37 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C5D516A431 for ; Fri, 4 Nov 2005 12:52:37 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from speedfactory.net (mail5.speedfactory.net [66.23.216.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 086CF43D48 for ; Fri, 4 Nov 2005 12:52:36 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 1360008 for ; Fri, 04 Nov 2005 07:54:32 -0500 Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jA4CqVcw081545 for ; Fri, 4 Nov 2005 07:52:32 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: arch@FreeBSD.org Date: Fri, 4 Nov 2005 07:52:29 -0500 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200511040752.29724.jhb@FreeBSD.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=100 Cc: Subject: ether_ifdetach() races round 3(?) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2005 12:52:37 -0000 I had another moment of inspiration regarding the ether_ifdetach() races=20 during my shower this morning. Maybe this will gives us a viable solution= =20 this time. The reason we are having races is that once we call foo_stop(), the driver= =20 state is out of sync with the ifnet state because IFF_UP is still set even= =20 though the driver effectively has marked the interface down. The obvious=20 solution to that is to have the ifnet code "officially" mark the driver dow= n=20 by clearing IFF_UP. This would result in foo_ioctl() calling foo_stop()=20 rather than foo_detach() calling it explicitly. I think this is actually=20 cleaner in that drivers already rely on the ifnet layer calling foo_init()= =20 and don't call foo_init() in foo_attach(). Moving foo_stop() out of=20 foo_detach() and into the ifnet layer would thus be more consistent. =20 foo_detach() would go from: if (device_is_attached(sc)) { FOO_LOCK(sc); foo_stop(sc); FOO_UNLOCK(sc); callout_drain(&sc->sc_stat_callout); ether_ifdetach(sc->sc_ifp); } to just: if (device_is_attached(sc)) { ether_ifdetach(sc->sc_ifp); callout_drain(&sc->sc_stat_callout); } The only question then is when should ether_ifdetach() mark the interface a= s=20 down, and this actually ends up nice as it lets us fix all the other races= =20 with BPF and userland ioctls. Basically, we should detach the ifnet from=20 userland so no more userland requests can come in, then tear down kernel=20 consumers such as BPF, and mark the interface down resulting in an ioctl()= =20 that clears IFF_UP and calls foo_stop(). =2D-=20 John Baldwin =A0<>< =A0http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =A0=3D =A0http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Sat Nov 5 03:19:07 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D94E16A41F for ; Sat, 5 Nov 2005 03:19:07 +0000 (GMT) (envelope-from fierykylin@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBB6343D48 for ; Sat, 5 Nov 2005 03:19:06 +0000 (GMT) (envelope-from fierykylin@gmail.com) Received: by xproxy.gmail.com with SMTP id t14so30163wxc for ; Fri, 04 Nov 2005 19:19:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=qETl+dcCMjTEir1PxYZ23r1m4w+a7ltV5LXQiUMcU7X+CNm5OOiDTJRTWbgo1Q2dc2uCT1w4LSpdEZtBn+TyG5RepWEsvh3O1sB4A5Mla+QxpdoQNnnyBmbSzcWYkZh8pmlKlGry40MxD/DgVTRnwmTpnFmTbDvCY/p8hIa1pP4= Received: by 10.70.7.20 with SMTP id 20mr2692805wxg; Fri, 04 Nov 2005 18:21:51 -0800 (PST) Received: by 10.70.18.16 with HTTP; Fri, 4 Nov 2005 18:21:51 -0800 (PST) Message-ID: <87ab37ab0511041821l611d4d2fkb22db7328920b4d2@mail.gmail.com> Date: Sat, 5 Nov 2005 10:21:51 +0800 From: kylin To: freebsd-questions@freebsd.org, "freebsd-hackers@freebsd.org" , freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: 3 quizz about the freebsd DD arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2005 03:19:07 -0000 hello every one :) good day! i have list the 3 puzzle coming to me in my recent coding reading of freebs= d 0 /////////////// pci bridge dynamic resize ///////////// it seems that the device arch of freebsd is similar to what is revealed in window OS. i have read the pcie hotplug tps of windows longhorn ,it is said that with some hardware mechanisms the pci bridge driver can do global pci resource window reconfiguration.so good to the hotplugin pci device for it avoid prelocating resource for the device . i wonder ,if the mem /io/irq reconfiguration possible under freebsd .:) 1 ////////////// is bus_data_generation ///////// what idoes bus_data_generation for, is it the generation count for the device manager tree? void bus_data_generation_update(void) { bus_data_generation++; } 2 ////////////// pci_write_config vs pci_write_config_method ////////////// under the source code /dev/pci .there are functions name pci_write_config ( pcivar.h) and pci_write_config_method(pci.c) they both call the parent method ,though the content is different ,but does that a liitle overlap whit each other? From owner-freebsd-arch@FreeBSD.ORG Sat Nov 5 10:12:26 2005 Return-Path: X-Original-To: arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E20616A41F; Sat, 5 Nov 2005 10:12:26 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mrout2-b.corp.dcn.yahoo.com (mrout2-b.corp.dcn.yahoo.com [216.109.112.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id E198F43D45; Sat, 5 Nov 2005 10:12:25 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from p061198128224.ppp.prin.ne.jp.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout2-b.corp.dcn.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id jA5AC7sZ009377; Sat, 5 Nov 2005 02:12:07 -0800 (PST) Date: Sat, 05 Nov 2005 19:12:09 +0900 Message-ID: From: gnn@FreeBSD.org To: John Baldwin In-Reply-To: <200511040752.29724.jhb@FreeBSD.org> References: <200511040752.29724.jhb@FreeBSD.org> User-Agent: Wanderlust/2.12.2 (99 Luftballons) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin8.1.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: arch@FreeBSD.org Subject: Re: ether_ifdetach() races round 3(?) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2005 10:12:26 -0000 At Fri, 4 Nov 2005 07:52:29 -0500, John Baldwin wrote: > > I had another moment of inspiration regarding the ether_ifdetach() races > during my shower this morning. Maybe this will gives us a viable solution > this time. > You need to shower more often. My first pass read of this makes sense to me. Later, George From owner-freebsd-arch@FreeBSD.ORG Sat Nov 5 16:27:47 2005 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C0F416A41F; Sat, 5 Nov 2005 16:27:47 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from speedfactory.net (mail5.speedfactory.net [66.23.216.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1407443D45; Sat, 5 Nov 2005 16:27:46 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 1425288 for multiple; Sat, 05 Nov 2005 11:29:48 -0500 Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id jA5GRg10092221; Sat, 5 Nov 2005 11:27:43 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Sat, 5 Nov 2005 11:23:10 -0500 User-Agent: KMail/1.8 References: <200511040752.29724.jhb@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200511051123.10954.jhb@FreeBSD.org> X-Spam-Status: No, score=-2.8 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=100 Cc: gnn@FreeBSD.org Subject: Re: ether_ifdetach() races round 3(?) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2005 16:27:47 -0000 On Saturday 05 November 2005 05:12 am, gnn@freebsd.org wrote: > At Fri, 4 Nov 2005 07:52:29 -0500, > > John Baldwin wrote: > > I had another moment of inspiration regarding the ether_ifdetach() races > > during my shower this morning. Maybe this will gives us a viable > > solution this time. > > You need to shower more often. My first pass read of this makes sense > to me. Heh, I shower every day. :) td_ucred was the result of one such shower as= =20 well. :) =2D-=20 John Baldwin =A0<>< =A0http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =A0=3D =A0http://www.FreeBSD.org