From owner-freebsd-arch@FreeBSD.ORG Sun Jun 26 18:34:08 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 2C7CC16A41C for ; Sun, 26 Jun 2005 18:34:08 +0000 (GMT) (envelope-from brian@box201.com) Received: from host78.ipowerweb.com (host78.ipowerweb.com [66.235.200.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFAAD43D58 for ; Sun, 26 Jun 2005 18:34:07 +0000 (GMT) (envelope-from brian@box201.com) Received: from c-67-190-22-43.hsd1.co.comcast.net ([67.190.22.43] helo=electricblue) by host78.ipowerweb.com with esmtp (Exim 4.43) id 1DmbxH-0000FM-EA for freebsd-arch@FreeBSD.org; Sun, 26 Jun 2005 11:34:07 -0700 From: "Brian Duke" To: Date: Sun, 26 Jun 2005 12:33:14 -0600 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcV6fYMKxMhMijbrQ7mzOfkv9GrT9g== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host78.ipowerweb.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - box201.com X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20050626183407.EFAAD43D58@mx1.FreeBSD.org> Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Gateway ALR 9200 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, 26 Jun 2005 18:34:08 -0000 I picked up one of these and would like to run FreeBSD this beast. =20 The BTX loader fails right after the initial setup screen. I press any option except install prompt and it fails. =20 I have : Gateway ALR 9200 4 processor xeon 500's=20 1 gig ram=20 1 adaptec 3200S scsi card running modified raid 5 6 drives. 2 sets of striped 3 and mirrored. =20 I am having a difficult time finding anything that will load in this = box.=20 I prefer FreeBSD if possible. I've googled for a couple days and didn't = find much help. Can someone help me get past this first hurdle? =20 The OS I am loading is currently FreeBSD 5.3=20 I went to adaptec and found some information about FreeBSD 4.11 and = tried that version as well.=20 I can get Solaris 10 to load but it fails to find the raid as a valid = drive. Fedora Core 2 also boots and says it can't find a drive. The Raid boots up fine and builds with no faults.=20 I have an adaptec driver for FeeBSD but I need to install enough OS to pkg_add the file. =20 When I install a little 850 meg IDE drive and set that to master, Still = the btx loader dies. Here is what the final screen says: =20 /boot/kernel/acpi.ko text=3D0x3fbfc data=3D0x1c04+0x112c syms=3D[0x4+0x72f0+0x4+0x97c7]=20 /=20 int=3D0000000d err=3D00000000 efl=3D00030002 eip=3D00005755 eax=3D00000001 ebx=3D00000008 ecx=3D000039ff edx=3D00000082=20 esi=3D0000579c edi=3D0000e873 edi=3D000003ba esp=3D0000037e=20 cs=3Df000 ds=3D0040 es=3Df000 fs=3D9dc0 gs=3Df000 ss=3D9c46=20 cs:eip=3D2e 0f 01 14 0f 20 c0 0c-01 0f 22 c0 eb 00 8e db 8e c3 8e e3 8e eb 0f 20-c0 24 fc 0f 22 c0 ea 78 ss:esp=3D11 64 08 00 01 00 00 00-00 f0 c0 9d 02 02 51 e8 05 00 c2 ee 05 00 00 f0-00 00 1a 7d c4 5e dd e6=20 BTX Halted =20 I think I copied all that correctly. =20 Has anyone got a quick idea why this fails right off? =20 Brian Duke 303-952-4983 Blue Incorporated. -=3D-_-=3D=3D--=3D_-=3D=83=20 =20 From owner-freebsd-arch@FreeBSD.ORG Mon Jun 27 18:26:14 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 227E416A41C for ; Mon, 27 Jun 2005 18:26:14 +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 D18E343D1F for ; Mon, 27 Jun 2005 18:26:13 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.231] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Mon, 27 Jun 2005 14:39:53 -0400 From: John Baldwin To: freebsd-arch@freebsd.org Date: Mon, 27 Jun 2005 10:54:30 -0400 User-Agent: KMail/1.8 References: <20050626183407.EFAAD43D58@mx1.FreeBSD.org> In-Reply-To: <20050626183407.EFAAD43D58@mx1.FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506271054.31084.jhb@FreeBSD.org> Cc: Brian Duke Subject: Re: Gateway ALR 9200 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: Mon, 27 Jun 2005 18:26:14 -0000 On Sunday 26 June 2005 02:33 pm, Brian Duke wrote: > /boot/kernel/acpi.ko text=0x3fbfc data=0x1c04+0x112c > syms=[0x4+0x72f0+0x4+0x97c7] > > / > > int=0000000d err=00000000 efl=00030002 eip=00005755 > > eax=00000001 ebx=00000008 ecx=000039ff edx=00000082 > > esi=0000579c edi=0000e873 edi=000003ba esp=0000037e > > cs=f000 ds=0040 es=f000 fs=9dc0 gs=f000 ss=9c46 > > cs:eip=2e 0f 01 14 0f 20 c0 0c-01 0f 22 c0 eb 00 8e db > > 8e c3 8e e3 8e eb 0f 20-c0 24 fc 0f 22 c0 ea 78 > > ss:esp=11 64 08 00 01 00 00 00-00 f0 c0 9d 02 02 51 e8 > > 05 00 c2 ee 05 00 00 f0-00 00 1a 7d c4 5e dd e6 > > BTX Halted Int 0d is a general protection fault. 00000000 2E0F0114 lgdt [cs:si] 00000004 0F20C0 mov eax,cr0 00000007 0C01 or al,0x1 00000009 0F22C0 mov cr0,eax 0000000C EB00 jmp short 0xe 0000000E 8EDB mov ds,bx 00000010 8EC3 mov es,bx 00000012 8EE3 mov fs,bx 00000014 8EEB mov gs,bx 00000016 0F20C0 mov eax,cr0 00000019 24FC and al,0xfc 0000001B 0F22C0 mov cr0,eax 0000001E EA db 0xEA 0000001F 78 db 0x78 Your BIOS is misbehaving such that it isn't going to work well with FreeBSD. Try changing the BIOS to not use DMA with the IDE hard drives and see if that gets farther. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Wed Jun 29 17:34:25 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 927D416A41C for ; Wed, 29 Jun 2005 17:34:25 +0000 (GMT) (envelope-from danny280279@hotmail.com) Received: from hotmail.com (bay104-f27.bay104.hotmail.com [65.54.175.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 747E343D1F for ; Wed, 29 Jun 2005 17:34:25 +0000 (GMT) (envelope-from danny280279@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 29 Jun 2005 10:33:44 -0700 Message-ID: Received: from 65.54.175.200 by by104fd.bay104.hotmail.msn.com with HTTP; Wed, 29 Jun 2005 17:33:43 GMT X-Originating-IP: [65.54.175.200] X-Originating-Email: [danny280279@hotmail.com] X-Sender: danny280279@hotmail.com In-Reply-To: From: "DANIEL hoggan" To: freebsd-arch@freebsd.org Date: Wed, 29 Jun 2005 17:33:43 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 29 Jun 2005 17:33:44.0312 (UTC) FILETIME=[B2B42780:01C57CD0] X-Mailman-Approved-At: Thu, 30 Jun 2005 11:55:40 +0000 Subject: mach microkernel 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: Wed, 29 Jun 2005 17:34:25 -0000 I am using mach4 as my os for my project i just wanted to know, if mach uses a lot of bsd code to emulate unix funcionality, then would porting bsd code be a simple case of just dropping it in, or does it actually require some rewrite, i mean according to the mach4 page netbsd is capbable of just dropping in mach4 microkernel: http://www.cs.utah.edu/flux/mach4/html/projects.html Easy-to-install Mach distribution: In order to attract more people from the Linux/BSD crowd, we really need someone to put together an easy-to-install Mach+Lites or (when it's mature enough) Mach+Hurd binary distribution. This distribution might be just an add-on supplement to an existing monolithic-kernel distribution, or it could be an entirely separate distribution with a whole new set of binaries. Of course, a simple add-on to an existing distribution is likely to be simpler and more popular, so we should try to go with that approach if at all possible. (Mach+Lites on the i386 is already pretty close to being a drop-in NetBSD kernel replacement.) _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/ From owner-freebsd-arch@FreeBSD.ORG Thu Jun 30 12:50:52 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 9BF6716A41C for ; Thu, 30 Jun 2005 12:50:52 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DFA043D49 for ; Thu, 30 Jun 2005 12:50:52 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id AF1BC46B6B; Thu, 30 Jun 2005 08:50:49 -0400 (EDT) Date: Thu, 30 Jun 2005 13:55:03 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: DANIEL hoggan In-Reply-To: Message-ID: <20050630134655.A87930@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@freebsd.org Subject: Re: mach microkernel 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: Thu, 30 Jun 2005 12:50:52 -0000 On Wed, 29 Jun 2005, DANIEL hoggan wrote: > I am using mach4 as my os for my project i just wanted to know, if mach > uses a lot of bsd code to emulate unix funcionality, then would porting > bsd code be a simple case of just dropping it in, or does it actually > require some rewrite, i mean according to the mach4 page netbsd is > capbable of just dropping in mach4 microkernel: > > http://www.cs.utah.edu/flux/mach4/html/projects.html > > Easy-to-install Mach distribution: In order to attract more people from > the Linux/BSD crowd, we really need someone to put together an > easy-to-install Mach+Lites or (when it's mature enough) Mach+Hurd binary > distribution. This distribution might be just an add-on supplement to an > existing monolithic-kernel distribution, or it could be an entirely > separate distribution with a whole new set of binaries. Of course, a > simple add-on to an existing distribution is likely to be simpler and > more popular, so we should try to go with that approach if at all > possible. (Mach+Lites on the i386 is already pretty close to being a > drop-in NetBSD kernel replacement.) I'm not specifically familiar with Mach4, but the blending of Mach and BSD is non-trivial in several areas: (1) BSD processes are layered on top of Mach tasks. In the new world order, threads are also important, so you'd want to layer BSD threads on top of Mach threads. there's a bunch of important-to-get-right stuff here, including synchronizing between the micro-kernel task state and the UNIX server process state, which grows more complicated if you're using a mature multi-thread/multi-processor BSD kernel (such as FreeBSD), but maybe easier with a Giant-locked kernel (NetBSD). Another interesting area here is the handling of asynchronous traps and signals. And another interesting area is debugging. (2) NetBSD also used a Mach-derived VM model, but as with everyone else, has gone their own way on merging their VM and buffer cache. In traditional Mach, the VM primitives are provided by the micro-kernel, but higher level VFS concepts are implemented in the BSD server, in particular, vnode pagers, etc. The merging of Mach and BSD here is highly non-trivial, and basically involves throwing away the BSD side VM stuff, and then re-merging the BSD VFS with Mach VM. (3) Device drivers. Of particular importance here is that BSD device drivers assume they're running in ring 0, although with busspace/busdma, it's easier to indirect. You'll need to decide what functionality will go where. You may want device drivers to run in the BSD server, due to integration with the BSD ifnet, storage, etc, concepts. On the other hand, it's hard for a micro-kernel to bootstrap without access to storage... (4) Once you have BSD running on top of Mach, you'll observe there are some significant redundancies between Mach and BSD. For example, shared memory and synchronization primitives for applications. Apple has chosen to implement some of these primitives wrapped around Mach primitives, such as semaphores in Mach. Others, they have redundant implementations due to semantic differences that are harder to paper over. You'll probably also need to think hard about things like kernel linking, kernel modules, kernel debuggers, and so on. So I'd say "drop in" is probably a bit off-the-mark. However, it's probably true that you could update a number of the BSD components in Lites fairly easily, especially if you already understand the changes going on in BSD over the last ten years. An interesting reference here is Apple's Darwin work. While they run the whole kernel in a single address space, they have maintained a code-wise separation and layering between the Mach pieces and the BSD pieces. This falls apart if you look closely, due to assumptions about vnode pointers and ports, in the device driver code, etc, but still shows a lot of the important points. Robert N M Watson From owner-freebsd-arch@FreeBSD.ORG Fri Jul 1 00:13:35 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 BAE5616A41C for ; Fri, 1 Jul 2005 00:13:35 +0000 (GMT) (envelope-from danny280279@hotmail.com) Received: from hotmail.com (bay104-f17.bay104.hotmail.com [65.54.175.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9693843D49 for ; Fri, 1 Jul 2005 00:13:35 +0000 (GMT) (envelope-from danny280279@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 30 Jun 2005 17:13:35 -0700 Message-ID: Received: from 65.54.175.200 by by104fd.bay104.hotmail.msn.com with HTTP; Fri, 01 Jul 2005 00:13:35 GMT X-Originating-IP: [65.54.175.200] X-Originating-Email: [danny280279@hotmail.com] X-Sender: danny280279@hotmail.com From: "DANIEL hoggan" To: freebsd-arch@freebsd.org Date: Fri, 01 Jul 2005 00:13:35 +0000 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_5aab_cbc_6d9e" X-OriginalArrivalTime: 01 Jul 2005 00:13:35.0478 (UTC) FILETIME=[B8F75160:01C57DD1] X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: mach microkernel 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, 01 Jul 2005 00:13:35 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_5aab_cbc_6d9e Content-Type: text/plain; format=flowed >I'm not specifically familiar with Mach4, but the blending of Mach and BSD >is non-trivial in several areas: > >(1) BSD processes are layered on top of Mach tasks. In the new world >order, threads are also important, so you'd want to layer BSD threads on >top of Mach threads. there's a bunch of important-to-get-right stuff here, >including synchronizing between the micro-kernel task state and the UNIX >server process state, which grows more complicated if you're using a mature >multi-thread/multi-processor BSD kernel (such as FreeBSD), but maybe easier >with a Giant-locked kernel (NetBSD). > Another interesting area here is the handling of asynchronous traps and >signals. And another interesting area is debugging. > I want to put most of this code into user space, I'm not so much worried about actually replacing the BSD kernel, I want to use the code on top of the mach kernel, ie Mach would be the actual OS, If I could use the Mach Kernel in the same way as NeXt did when they created Nextstep then I would have achieved my goal, similarities can be drawn between the way Rocklyte systems created their Athenyx OS out of Linux. Have you heard of Mach-US it was the Multiserver OS created out of the Mach microkernel, anyway this project has gone the way that old things go, So I basically wanted to know if I could rip out the guts of the BSD code-base, you know Mach4 microkernel, ufs, debians autoinstallation and dpkg code, drivers based upon the opendarwin codebase and their documentation (mainly documentation), and fill in the gaps in the code with the BSD code base? Now would it be possible to do this? >(2) NetBSD also used a Mach-derived VM model, but as with everyone else, >has gone their own way on merging their VM and buffer cache. In >traditional Mach, the VM primitives are provided by the micro-kernel, but >higher level VFS concepts are implemented in the BSD server, in particular, >vnode pagers, etc. The merging of Mach and BSD here is highly non-trivial, >and basically involves throwing away the BSD side VM stuff, and then >re-merging the BSD VFS with Mach VM. > >(3) Device drivers. Of particular importance here is that BSD device >drivers assume they're running in ring 0, although with > busspace/busdma, it's easier to indirect. You'll need to decide what >functionality will go where. You may want device drivers to run in the BSD >server, due to integration with the BSD ifnet, storage, etc, concepts. On >the other hand, it's hard for a micro-kernel to > bootstrap without access to storage... Storage would be implemented by UFS being written to Mach itself. > >(4) Once you have BSD running on top of Mach, you'll observe there are some >significant redundancies between Mach and BSD. For example, shared memory >and synchronization primitives for applications. Apple has chosen to >implement some of these primitives wrapped around Mach primitives, such as >semaphores in Mach. Others, they have redundant implementations due to >semantic differences that are harder to paper over. I really wouldn't be papering over anything, I'd be totally rewriting so that Mach would be the operative kernel source. >You'll probably also need to think hard about things like kernel linking, >kernel modules, kernel debuggers, and so on. So I'd say "drop in" is >probably a bit off-the-mark. However, it's probably true that you could >update a number of the BSD components in Lites fairly easily, especially if >you already understand the changes going on in BSD over the last ten years. > And if I don't? Could I try to link the modules, debuggers, directly to Mach or would that be asking too much? >An interesting reference here is Apple's Darwin work. While they run the >whole kernel in a single address space, they have maintained a code-wise >separation and layering between the Mach pieces and the BSD pieces. This >falls apart if you look closely, due to assumptions about vnode pointers >and ports, in the device driver code, etc, but still shows a lot of the >important points. > Here I really would Like to implement them in Mach space, I'm wanting the kernel small for a reason. I want it to be elegent, and simple to maintain, I don't wan't a monolithic design if I can get away with it. If I have to port it all over to Mach then I will, can that be done? I wouldn't be using bsd's drivers, I'd be using Apples. I would be using ufs (albeit with as much as I could manage to implement of the idea of recording data so that you actually didn't have to save your work, It's supposed to work in the sameway that you remember things but none of the functionality of that is available at this moment so basically I've got to stick with just being able to autosave data through a recording mechanism.) and probably adding in some of BSD server code as libs running on top of Mach, does any of this make sense, It would be based on the BSD code-base but not the BSD kernel if you see what I mean, the debugging devices, the kernel modules would be implemented as componants of user-space. >_______________________________________________ >freebsd-arch@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-arch >To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" _________________________________________________________________ Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters ------=_NextPart_000_5aab_cbc_6d9e-- From owner-freebsd-arch@FreeBSD.ORG Fri Jul 1 11:11:16 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 3824A16A41C; Fri, 1 Jul 2005 11:11:16 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB77A43D1F; Fri, 1 Jul 2005 11:11:15 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id E4AC4EB2698; Fri, 1 Jul 2005 19:11:11 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 0EFD513281E; Fri, 1 Jul 2005 19:11:10 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48036-01; Fri, 1 Jul 2005 19:11:04 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id 01D21132487; Fri, 1 Jul 2005 19:11:03 +0800 (CST) Date: Fri, 1 Jul 2005 19:11:03 +0800 From: Xin LI To: freebsd-arch@FreeBSD.org, re@FreeBSD.org Message-ID: <20050701111103.GA48039@frontfree.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.4-RELEASE-p3 FreeBSD 5.4-RELEASE-p3 #2: Thu Jun 30 11:05:45 CST 2005 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: amavisd-new at frontfree.net Cc: Subject: [PATCH] Remove ENABLE_SSE option from i386 and pc98 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, 01 Jul 2005 11:11:16 -0000 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Here is a patch for review, which removes ENABLE_SSE from i386 and pc98 platforms. I think we should have it before we branch RELENG_6. The reason why the option should be removed: - ENABLE_SSE was turned on by default 2 years and 9 months ago, for I686_CPU. It makes few sense to "enable" something that is already enabled (No I586_CPUs supports SSE so far as I am aware) - We have DISABLE_SSE to disable SSE, having both ENABLE_SSE and DISABLE_SSE is quite confusing, since DISABLE_SSE always overrides ENABLE_SSE. Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --8t9RHnE3ZwKMSgU+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCxSTH/cVsHxFZiIoRAokAAJ9NM1/Jptt8toeKtk9KXQx+Vxk0hQCfXj+Z YwJzwgKifWep5ZqcetmoJxI= =YHTE -----END PGP SIGNATURE----- --8t9RHnE3ZwKMSgU+-- From owner-freebsd-arch@FreeBSD.ORG Fri Jul 1 13:21:04 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 B448516A41C; Fri, 1 Jul 2005 13:21:04 +0000 (GMT) (envelope-from peadar@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97ABE43D1F; Fri, 1 Jul 2005 13:21:04 +0000 (GMT) (envelope-from peadar@FreeBSD.org) Received: from freefall.freebsd.org (peadar@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j61DL4tr000562; Fri, 1 Jul 2005 13:21:04 GMT (envelope-from peadar@freefall.freebsd.org) Received: (from peadar@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j61DL4sx000561; Fri, 1 Jul 2005 13:21:04 GMT (envelope-from peadar) Date: Fri, 1 Jul 2005 13:21:04 +0000 From: Peter Edwards To: arch@freebsd.org Message-ID: <20050701132104.GA95135@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: ktrace and KTR_DROP 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, 01 Jul 2005 13:21:04 -0000 Y'all, Ever since the introduction of a separate ktrace worker thread for writing output, there's the distinct possibility that ktrace output will drop requests. For some proceses, it's actually inevitable: as long as the traced processes can sustain a rate of generating ktrace events faster than the ktrace thread can write them, you'll eventually run out of ktrace requests. I'd like to propose that rather than just dropping the request on the floor, we at least configurably allow ktraced threads to block until there are resources available to satisfy their requests. My rationale is that previously, requests would never get lost: each thread would serialise on the vnode used to write the requests out. The current FIFO cushions the extra latency of writing the requests from a separate thread. Anything beyond that is really just acting as a low pass filter to stop applications that sporadically generate more traffic for the ktrace thread than it can handle. Making processes wait for free requests will still allow the queue to deal with the latency, and revert to the original model of flow controling the traced threads to the rate the trace file can be written. Anytime I use ktrace, I really don't care if I penalize the performance of the traced process: I _want_ the trace output, above all else. I'm not saying that's a universal constant, but I imagine its most often the desired behaviour, and currently no matter how high you set kern.ktrace.request_pool, "for (;;) { getpid(); }" will exhaust its capacity in a second. The following patch is making my debugging a much more productive experience. Index: sys/kern/kern_ktrace.c =================================================================== RCS file: /usr/cvs/FreeBSD/src/sys/kern/kern_ktrace.c,v retrieving revision 1.101 diff -u -r1.101 kern_ktrace.c --- sys/kern/kern_ktrace.c 24 Jun 2005 12:05:24 -0000 1.101 +++ sys/kern/kern_ktrace.c 1 Jul 2005 12:48:32 -0000 @@ -100,9 +100,15 @@ SYSCTL_UINT(_kern_ktrace, OID_AUTO, genio_size, CTLFLAG_RW, &ktr_geniosize, 0, "Maximum size of genio event payload"); +static int ktr_neverdrop = 0; +SYSCTL_UINT(_kern_ktrace, OID_AUTO, neverdrop, CTLFLAG_RW, &ktr_neverdrop, + 0, "Wait for free resources rather than dropping events "); + static int print_message = 1; struct mtx ktrace_mtx; -static struct cv ktrace_cv; +static struct cv ktrace_todo_cv; /* service thread waiting for work */ +static struct cv ktrace_freeq_cv; /* threads waiting for free requests */ +static int ktrace_free_waiters = 0; /* No. of threads waiting on freeq_cv */ static void ktrace_init(void *dummy); static int sysctl_kern_ktrace_request_pool(SYSCTL_HANDLER_ARGS); @@ -123,7 +129,8 @@ int i; mtx_init(&ktrace_mtx, "ktrace", NULL, MTX_DEF | MTX_QUIET); - cv_init(&ktrace_cv, "ktrace"); + cv_init(&ktrace_todo_cv, "ktrace.todo"); + cv_init(&ktrace_freeq_cv, "ktrace.freeq"); STAILQ_INIT(&ktr_todo); STAILQ_INIT(&ktr_free); for (i = 0; i < ktr_requestpool; i++) { @@ -200,6 +207,8 @@ M_WAITOK); mtx_lock(&ktrace_mtx); STAILQ_INSERT_HEAD(&ktr_free, req, ktr_list); + if (ktrace_free_waiters) + cv_signal(&ktrace_freeq_cv); ktr_requestpool++; } return (ktr_requestpool); @@ -220,7 +229,16 @@ td->td_pflags &= ~TDP_INKTRACE; return (NULL); } - req = STAILQ_FIRST(&ktr_free); + + for (;;) { + req = STAILQ_FIRST(&ktr_free); + if (req != 0 || ktr_neverdrop == 0) + break; + ktrace_free_waiters++; + cv_wait(&ktrace_freeq_cv, &ktrace_mtx); + ktrace_free_waiters--; + } + if (req != NULL) { STAILQ_REMOVE_HEAD(&ktr_free, ktr_list); req->ktr_header.ktr_type = type; @@ -257,7 +275,7 @@ mtx_lock(&ktrace_mtx); STAILQ_INSERT_TAIL(&ktr_todo, req, ktr_list); - cv_signal(&ktrace_cv); + cv_signal(&ktrace_todo_cv); mtx_unlock(&ktrace_mtx); curthread->td_pflags &= ~TDP_INKTRACE; } @@ -276,6 +294,8 @@ free(req->ktr_header.ktr_buffer, M_KTRACE); mtx_lock(&ktrace_mtx); STAILQ_INSERT_HEAD(&ktr_free, req, ktr_list); + if (ktrace_free_waiters) + cv_signal(&ktrace_freeq_cv); mtx_unlock(&ktrace_mtx); } @@ -292,7 +312,7 @@ for (;;) { mtx_lock(&ktrace_mtx); while (STAILQ_EMPTY(&ktr_todo)) - cv_wait(&ktrace_cv, &ktrace_mtx); + cv_wait(&ktrace_todo_cv, &ktrace_mtx); req = STAILQ_FIRST(&ktr_todo); STAILQ_REMOVE_HEAD(&ktr_todo, ktr_list); KASSERT(req != NULL, ("got a NULL request")); Index: lib/libc/sys/ktrace.2 =================================================================== RCS file: /usr/cvs/FreeBSD/src/lib/libc/sys/ktrace.2,v retrieving revision 1.24 diff -u -r1.24 ktrace.2 --- lib/libc/sys/ktrace.2 14 Dec 2003 14:54:53 -0000 1.24 +++ lib/libc/sys/ktrace.2 1 Jul 2005 12:28:42 -0000 @@ -146,6 +146,13 @@ to the trace file. .It Va kern.ktrace.request_pool bounds the number of trace events being logged at a time. +.It Va kern.ktrace.neverdrop +When non-zero, make processes wait for resources to become available +rather than dropping trace requests. This makes the tracing more +reliable at the possible expense of slowing down the traced thread(s). +This will avoid events being flagged with KTR_DROP (see +.Sx ERRORS +) .El .Pp Sysctl tunables that control process debuggability (as determined by From owner-freebsd-arch@FreeBSD.ORG Fri Jul 1 13:24:48 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 6768816A41C for ; Fri, 1 Jul 2005 13:24:48 +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 252A043D1F for ; Fri, 1 Jul 2005 13:24:48 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.231] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 01 Jul 2005 09:38:35 -0400 From: John Baldwin To: freebsd-arch@freebsd.org Date: Fri, 1 Jul 2005 08:44:45 -0400 User-Agent: KMail/1.8 References: <20050701111103.GA48039@frontfree.net> In-Reply-To: <20050701111103.GA48039@frontfree.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507010844.46187.jhb@FreeBSD.org> Cc: Subject: Re: [PATCH] Remove ENABLE_SSE option from i386 and pc98 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, 01 Jul 2005 13:24:48 -0000 [ re@ dropped from cc, they get enough e-mails during a release cycle as it is ] On Friday 01 July 2005 07:11 am, Xin LI wrote: > Hi, > > Here is a patch for review, which removes ENABLE_SSE from i386 and > pc98 platforms. I think we should have it before we branch RELENG_6. > > The reason why the option should be removed: > > - ENABLE_SSE was turned on by default 2 years and 9 months > ago, for I686_CPU. It makes few sense to "enable" something > that is already enabled (No I586_CPUs supports SSE so far > as I am aware) > - We have DISABLE_SSE to disable SSE, having both ENABLE_SSE > and DISABLE_SSE is quite confusing, since DISABLE_SSE > always overrides ENABLE_SSE. > > Cheers, Kill it dead. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Fri Jul 1 13:44:11 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 25C9716A41C; Fri, 1 Jul 2005 13:44:11 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEB6743D1D; Fri, 1 Jul 2005 13:44:10 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 2A8881F0D0; Fri, 1 Jul 2005 15:43:56 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id F16E263CE; Fri, 1 Jul 2005 15:43:55 +0200 (CEST) Date: Fri, 1 Jul 2005 15:43:55 +0200 From: Marc Olzheim To: Peter Edwards Message-ID: <20050701134355.GC2172@stack.nl> References: <20050701132104.GA95135@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline In-Reply-To: <20050701132104.GA95135@freefall.freebsd.org> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: arch@freebsd.org Subject: Re: ktrace and KTR_DROP 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, 01 Jul 2005 13:44:11 -0000 --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jul 01, 2005 at 01:21:04PM +0000, Peter Edwards wrote: > The following patch is making my debugging a much more productive > experience. Woohoo, thanks a LOT! Just what I was starting to type a mail about... ;-) Marc --+QahgC5+KEYLbs62 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCxUibezjnobFOgrERAr6bAKCrn+657ZjcoIB5tTlyBAgxp/S5QACffpKi mUt9Ui04TiNigJXiWkmvsfg= =lb+L -----END PGP SIGNATURE----- --+QahgC5+KEYLbs62-- From owner-freebsd-arch@FreeBSD.ORG Fri Jul 1 14:08:18 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 8BDF516A422; Fri, 1 Jul 2005 14:08:18 +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 4A8E243EFB; Fri, 1 Jul 2005 14:05:45 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.231] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 01 Jul 2005 10:19:33 -0400 From: John Baldwin To: Peter Edwards Date: Fri, 1 Jul 2005 10:05:20 -0400 User-Agent: KMail/1.8 References: <20050701132104.GA95135@freefall.freebsd.org> In-Reply-To: <20050701132104.GA95135@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200507011005.21343.jhb@FreeBSD.org> Cc: arch@FreeBSD.org Subject: Re: ktrace and KTR_DROP 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, 01 Jul 2005 14:08:18 -0000 On Friday 01 July 2005 09:21 am, Peter Edwards wrote: > Y'all, > > Ever since the introduction of a separate ktrace worker thread for > writing output, there's the distinct possibility that ktrace output > will drop requests. For some proceses, it's actually inevitable: > as long as the traced processes can sustain a rate of generating > ktrace events faster than the ktrace thread can write them, you'll > eventually run out of ktrace requests. The patch looks good to me, and I'd even be ok with having neverdrop on by default. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-arch@FreeBSD.ORG Fri Jul 1 14:09:59 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 9063716A41C for ; Fri, 1 Jul 2005 14:09:59 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B15C43D4C for ; Fri, 1 Jul 2005 14:09:59 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by rproxy.gmail.com with SMTP id i8so256202rne for ; Fri, 01 Jul 2005 07:09:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=i/Ew5Vx9B9LI3/w6hTNxhjTPNVoA0gFK37nzNpp1Nm2GSiwlMSHx5SyXSXf+/BlTATAC55kr080pFOlvo+A4fQRF3dhlnnJmHAxdmW8jopg+T6OFnRbgSY8DIt8H1t1C3AozZlX10PUr/RqlT/8nPElxx7ohPfxn47PVu+ODiLM= Received: by 10.38.92.36 with SMTP id p36mr1029060rnb; Fri, 01 Jul 2005 07:09:58 -0700 (PDT) Received: by 10.38.209.73 with HTTP; Fri, 1 Jul 2005 07:09:58 -0700 (PDT) Message-ID: <84dead7205070107093d8fc26e@mail.gmail.com> Date: Fri, 1 Jul 2005 19:39:58 +0530 From: Joseph Koshy To: Peter Edwards In-Reply-To: <20050701132104.GA95135@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050701132104.GA95135@freefall.freebsd.org> Cc: arch@freebsd.org Subject: Re: ktrace and KTR_DROP X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joseph Koshy List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2005 14:09:59 -0000 > The following patch is making my debugging a much more=20 > productive experience. Thanks. --=20 FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-arch@FreeBSD.ORG Fri Jul 1 14:11:41 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 7F06616A446 for ; Fri, 1 Jul 2005 14:11:41 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4691643D49 for ; Fri, 1 Jul 2005 14:11:41 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: by zproxy.gmail.com with SMTP id 8so168257nzo for ; Fri, 01 Jul 2005 07:11:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fC0tNAwvJdr0T3gBEC97gx7puUUvRAxLRL0Dr3Hmkj2hua3uCt3LZATKL3MqxnaftB0OSNnYFf8LAFnED1CuMSuxKFIDy/K78drFGu2vSsOLpzj2ETvyD9HA26/JLOF4p030/uBfWHXfy+vhtcO1lvLbP4oXN/H4/5KGw+FEDNU= Received: by 10.36.222.33 with SMTP id u33mr810409nzg; Fri, 01 Jul 2005 07:11:40 -0700 (PDT) Received: by 10.36.68.15 with HTTP; Fri, 1 Jul 2005 07:11:40 -0700 (PDT) Message-ID: <34cb7c8405070107112ac9de26@mail.gmail.com> Date: Fri, 1 Jul 2005 15:11:40 +0100 From: Peter Edwards To: John Baldwin In-Reply-To: <200507011005.21343.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050701132104.GA95135@freefall.freebsd.org> <200507011005.21343.jhb@FreeBSD.org> Cc: Peter Edwards , arch@freebsd.org Subject: Re: ktrace and KTR_DROP X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Peter Edwards List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2005 14:11:41 -0000 On 7/1/05, John Baldwin wrote: > On Friday 01 July 2005 09:21 am, Peter Edwards wrote: > > Y'all, > > > > Ever since the introduction of a separate ktrace worker thread for > > writing output, there's the distinct possibility that ktrace output > > will drop requests. For some proceses, it's actually inevitable: > > as long as the traced processes can sustain a rate of generating > > ktrace events faster than the ktrace thread can write them, you'll > > eventually run out of ktrace requests. >=20 > The patch looks good to me, and I'd even be ok with having neverdrop on b= y > default. FWIW, that would also be my preference, I was just being conservative. From owner-freebsd-arch@FreeBSD.ORG Fri Jul 1 14:38:51 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 5B79416A41C; Fri, 1 Jul 2005 14:38:51 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1726443D48; Fri, 1 Jul 2005 14:38:48 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j61EkB31086711; Fri, 1 Jul 2005 08:46:11 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42C554C2.5050304@samsco.org> Date: Fri, 01 Jul 2005 08:35:46 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Xin LI References: <20050701111103.GA48039@frontfree.net> In-Reply-To: <20050701111103.GA48039@frontfree.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: re@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: [PATCH] Remove ENABLE_SSE option from i386 and pc98 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, 01 Jul 2005 14:38:51 -0000 Xin LI wrote: > Hi, > > Here is a patch for review, which removes ENABLE_SSE from i386 and > pc98 platforms. I think we should have it before we branch RELENG_6. > > The reason why the option should be removed: > > - ENABLE_SSE was turned on by default 2 years and 9 months > ago, for I686_CPU. It makes few sense to "enable" something > that is already enabled (No I586_CPUs supports SSE so far > as I am aware) > - We have DISABLE_SSE to disable SSE, having both ENABLE_SSE > and DISABLE_SSE is quite confusing, since DISABLE_SSE > always overrides ENABLE_SSE. > > Cheers, Approved. Please commit it today if possible. Scott From owner-freebsd-arch@FreeBSD.ORG Fri Jul 1 14:40:24 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 2A41816A41F; Fri, 1 Jul 2005 14:40:24 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id D571843D4C; Fri, 1 Jul 2005 14:40:23 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 4BEE81F0D1; Fri, 1 Jul 2005 16:40:22 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 1B98963CE; Fri, 1 Jul 2005 16:40:22 +0200 (CEST) Date: Fri, 1 Jul 2005 16:40:21 +0200 From: Marc Olzheim To: Peter Edwards Message-ID: <20050701144021.GA2428@stack.nl> References: <20050701132104.GA95135@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: <20050701132104.GA95135@freefall.freebsd.org> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: arch@freebsd.org Subject: Re: ktrace and KTR_DROP 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, 01 Jul 2005 14:40:24 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Jul 01, 2005 at 01:21:04PM +0000, Peter Edwards wrote: > The following patch is making my debugging a much more productive > experience. login: panic: ktrace: no trace vnode cpuid = 1 KDB: stack backtrace: kdb_backtrace(100,c6c0b000,c65e08d4,c5d4ae80,c6c0b000) at 0xc053efa9 = kdb_backtrace+0x29 panic(c06bec25,8,2,c717e180,ec519cd8) at 0xc0529174 = panic+0x114 ktr_getrequest(1,0,c6c0b000,c65e08d4,ec519d30) at 0xc051aa7b = ktr_getrequest+0xf3 ktrsyscall(bd,2,ec519d04) at 0xc051ad7f = ktrsyscall+0x3b syscall(2f,2f,2f,280ee000,0) at 0xc0680329 = syscall+0x155 Xint0x80_syscall() at 0xc066fcff = Xint0x80_syscall+0x1f --- syscall (189, FreeBSD ELF32, fstat), eip = 0x280cea23, esp = 0xbfbfe9f0, ebp = 0xbfbfea8c --- boot() called on cpu#0 Uptime: 17m39s Dumping 3967 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008 1024 1040 1056 1072 1088 1104 1120 1136 1152 1168 1184 1200 1216 ... Marc --AqsLC8rIMeq19msA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCxVXVezjnobFOgrERAuBkAKDOb9OqUFfQsW52jM2lWEyR6TjEkwCgryA/ jizia6iVjG+oZcSWrQPzwpM= =hC60 -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- From owner-freebsd-arch@FreeBSD.ORG Fri Jul 1 14:53:38 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 8386516A41C; Fri, 1 Jul 2005 14:53:38 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 010C143D48; Fri, 1 Jul 2005 14:53:37 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 16CCF1F0D6; Fri, 1 Jul 2005 16:53:37 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id DA73463CE; Fri, 1 Jul 2005 16:53:36 +0200 (CEST) Date: Fri, 1 Jul 2005 16:53:36 +0200 From: Marc Olzheim To: Peter Edwards Message-ID: <20050701145336.GC2428@stack.nl> References: <20050701132104.GA95135@freefall.freebsd.org> <20050701144021.GA2428@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VrqPEDrXMn8OVzN4" Content-Disposition: inline In-Reply-To: <20050701144021.GA2428@stack.nl> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: arch@freebsd.org Subject: Re: ktrace and KTR_DROP 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, 01 Jul 2005 14:53:38 -0000 --VrqPEDrXMn8OVzN4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 01, 2005 at 04:40:21PM +0200, Marc Olzheim wrote: > On Fri, Jul 01, 2005 at 01:21:04PM +0000, Peter Edwards wrote: > > The following patch is making my debugging a much more productive > > experience. >=20 > login: panic: ktrace: no trace vnode > cpuid =3D 1 > KDB: stack backtrace: > kdb_backtrace(100,c6c0b000,c65e08d4,c5d4ae80,c6c0b000) at 0xc053efa9 =3D = kdb_backtrace+0x29 > panic(c06bec25,8,2,c717e180,ec519cd8) at 0xc0529174 =3D panic+0x114 > ktr_getrequest(1,0,c6c0b000,c65e08d4,ec519d30) at 0xc051aa7b =3D ktr_getr= equest+0xf3 > ktrsyscall(bd,2,ec519d04) at 0xc051ad7f =3D ktrsyscall+0x3b > syscall(2f,2f,2f,280ee000,0) at 0xc0680329 =3D syscall+0x155 > Xint0x80_syscall() at 0xc066fcff =3D Xint0x80_syscall+0x1f > --- syscall (189, FreeBSD ELF32, fstat), eip =3D 0x280cea23, esp =3D 0xbf= bfe9f0, ebp =3D 0xbfbfea8c --- > boot() called on cpu#0 > Uptime: 17m39s > Dumping 3967 MB > 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 32= 0 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 6= 24 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 = 928 944 960 976 992 1008 1024 1040 1056 1072 1088 1104 1120 1136 1152 1168 = 1184 1200 1216 ... This was with the sysctl set to 1 of course. (kgdb) fra 3 #3 0xc051aa7b in ktr_getrequest (type=3D1) at /usr/src/sys/kern/kern_ktrace.c:249 249 KASSERT(p->p_tracevp !=3D NULL, ("ktrace: no trace = vnode")); (kgdb) l 244 req->ktr_header.ktr_type =3D type; 245 if (p->p_traceflag & KTRFAC_DROP) { 246 req->ktr_header.ktr_type |=3D KTR_DROP; 247 p->p_traceflag &=3D ~KTRFAC_DROP; 248 } 249 KASSERT(p->p_tracevp !=3D NULL, ("ktrace: no trace = vnode")); 250 KASSERT(p->p_tracecred !=3D NULL, ("ktrace: no trac= e cred")); 251 req->ktr_vp =3D p->p_tracevp; 252 VREF(p->p_tracevp); 253 req->ktr_cred =3D crhold(p->p_tracecred); (kgdb) info locals req =3D (struct ktr_request *) 0xc5d4ae80 td =3D (struct thread *) 0xc6c0b000 p =3D (struct proc *) 0xc65e08d4 pm =3D -966915884 (kgdb) info registers=20 eax 0x0 0 ecx 0x0 0 edx 0x0 0 ebx 0xc65e08d4 -966915884 esp 0xec519cb0 0xec519cb0 ebp 0xec519cc0 0xec519cc0 esi 0xc5d4ae80 -975917440 edi 0xc6c0b000 -960450560 eip 0xc051aa7b 0xc051aa7b eflags 0x0 0 cs 0x0 0 ss 0x0 0 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (kgdb) p *p $1 =3D {p_list =3D {le_next =3D 0xc728f710, le_prev =3D 0xc6bcc1c4}, p_kseg= rps =3D { tqh_first =3D 0xc5fc3e00, tqh_last =3D 0xc5fc3e04}, p_threads =3D { tqh_first =3D 0xc6c0b000, tqh_last =3D 0xc6c0b008}, p_suspended =3D { tqh_first =3D 0x0, tqh_last =3D 0xc65e08ec}, p_ucred =3D 0xc6354e80,=20 p_fd =3D 0xc6ebbb00, p_fdtol =3D 0x0, p_stats =3D 0xc65d9000,=20 p_limit =3D 0xc5d0d000, p_unused1 =3D 0x0, p_sigacts =3D 0xc6bfb000,=20 p_flag =3D 16386, p_sflag =3D 1, p_state =3D PRS_NORMAL, p_pid =3D 5780, = p_hash =3D { le_next =3D 0x0, le_prev =3D 0xc563aa50}, p_pglist =3D {le_next =3D 0xc= 7240388,=20 le_prev =3D 0xc65fa3dc}, p_pptr =3D 0xc65fa388, p_sibling =3D {le_next = =3D 0x0,=20 le_prev =3D 0xc65fa3f0}, p_children =3D {lh_first =3D 0x0}, p_mtx =3D { mtx_object =3D {lo_class =3D 0xc06fca7c, lo_name =3D 0xc06c0315 "proces= s lock",=20 lo_type =3D 0xc06c0315 "process lock", lo_flags =3D 4390912, lo_list = =3D { tqe_next =3D 0x0, tqe_prev =3D 0x0}, lo_witness =3D 0x0}, mtx_lock = =3D 4,=20 mtx_recurse =3D 0}, p_oppid =3D 0, p_vmspace =3D 0xc6a46a8c, p_swtime = =3D 20,=20 p_realtimer =3D {it_interval =3D {tv_sec =3D 0, tv_usec =3D 0}, it_value = =3D { tv_sec =3D 0, tv_usec =3D 0}}, p_runtime =3D {sec =3D 0,=20 frac =3D 12428108932415044484}, p_uu =3D 0, p_su =3D 0, p_iu =3D 0, p_u= ticks =3D 0,=20 p_sticks =3D 40187, p_iticks =3D 0, p_profthreads =3D 0, p_maxthrwaits = =3D 0,=20 p_traceflag =3D 0, p_tracevp =3D 0x0, p_tracecred =3D 0x0, p_textvp =3D 0= xc69e6b58,=20 p_siglist =3D {__bits =3D {0, 0, 0, 0}}, p_lock =3D 0 '\0', p_sigiolst = =3D { slh_first =3D 0x0}, p_sigparent =3D 20, p_sig =3D 0, p_code =3D 0, p_st= ops =3D 0,=20 p_stype =3D 0, p_step =3D 0 '\0', p_pfsflags =3D 0 '\0', p_nlminfo =3D 0x= 0,=20 p_aioinfo =3D 0x0, p_singlethread =3D 0x0, p_suspcount =3D 0, p_xthread = =3D 0x0,=20 p_boundary_count =3D 0, p_magic =3D 3203398350,=20 p_comm =3D "patgen", '\0' , p_pgrp =3D 0xc7658200,=20 p_sysent =3D 0xc07153c0, p_args =3D 0xc711eb80,=20 p_cpulimit =3D 9223372036854775807, p_nice =3D 0 '\0', p_xstat =3D 0, p_k= list =3D { kl_lock =3D 0xc65e0940, kl_list =3D {slh_first =3D 0x0}}, p_numthreads = =3D 1,=20 p_numksegrps =3D 1, p_md =3D {md_ldt =3D 0x0}, p_itcallout =3D {c_links = =3D {sle =3D { sle_next =3D 0x0}, tqe =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}}, c= _time =3D 0,=20 c_arg =3D 0x0, c_func =3D 0, c_flags =3D 8}, p_unused2 =3D 0x0, p_acfla= g =3D 0,=20 p_ru =3D 0x0, p_peers =3D 0x0, p_leader =3D 0xc65e08d4, p_emuldata =3D 0x= 0,=20 p_label =3D 0x0, p_sched =3D 0xc65e0a98} (kgdb)=20 If you need any more info, just ask. Marc --VrqPEDrXMn8OVzN4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCxVjwezjnobFOgrERAol1AKDFdUTeuc2Kt+WxWjSpJUVwMryI3gCgx7RG /2lN7REMMd8PgfSpJYsmBkk= =IFUg -----END PGP SIGNATURE----- --VrqPEDrXMn8OVzN4-- From owner-freebsd-arch@FreeBSD.ORG Fri Jul 1 15:00: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 3E80916A41C; Fri, 1 Jul 2005 15:00:01 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08DEE43D49; Fri, 1 Jul 2005 15:00:01 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 1316F46B46; Fri, 1 Jul 2005 11:00:00 -0400 (EDT) Date: Fri, 1 Jul 2005 16:04:23 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Peter Edwards In-Reply-To: <20050701132104.GA95135@freefall.freebsd.org> Message-ID: <20050701155757.A36905@fledge.watson.org> References: <20050701132104.GA95135@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: ktrace and KTR_DROP 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, 01 Jul 2005 15:00:01 -0000 On Fri, 1 Jul 2005, Peter Edwards wrote: > Ever since the introduction of a separate ktrace worker thread for > writing output, there's the distinct possibility that ktrace output will > drop requests. For some proceses, it's actually inevitable: as long as > the traced processes can sustain a rate of generating ktrace events > faster than the ktrace thread can write them, you'll eventually run out > of ktrace requests. > > I'd like to propose that rather than just dropping the request on the > floor, we at least configurably allow ktraced threads to block until > there are resources available to satisfy their requests. There are two benefits to the current ktrace dispatch model: (1) Avoiding untimely sleeping in the execution paths of threads that are being traced. (2) Allowing the traced thread to run ahead asynchronously, hopefully impacting performance less. One of the things I've been thinking for a few years is that I think I actually preferred the old model better, there processes (now threads) would hang a "current record" off of their process (now thread) structure, and fill it in as they went along. The upsides of this have to do with the downsides of the current model: that you don't allow fully asynchronous execition of the threads with respect to queueing the records to disk, so you don't run into "drop" scenarios, instead slowing down the process. Likewise, the downsides. In the audit code, we pull from a common record queue, but we allocate the record when the system call starts for each process -- if there aren't records available (or various other reliability-related conditions fail, such as adequate disk space), we stall the thread entering the kernel until we can satisfy its record allocation requirements. There are two cases where I really run into problems with the current model: (1) When I'm interacting with a slow file system, such as NFS over 100mbps, I will always lose records, because it doesn't take long for the process to get quite ahead of the write-behind. (2) When I trace more than one process at a time, the volume of records overwhelms the write-behind. Write coalescing/etc is already provided "for free" by pushing the writes down into the file system, so other than slowing down the traced process a little, I think we don't lose much by moving back to this model. And if we pre-commit the record storage on system call entry (with the exception of paths, which generally require potential sleeps anyway), we probably won't hurt performance all that much, and avoid sleeping in bad places. Robert N M Watson From owner-freebsd-arch@FreeBSD.ORG Sat Jul 2 05:41:32 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 BCCCA16A41C for ; Sat, 2 Jul 2005 05:41:32 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B00143D1D for ; Sat, 2 Jul 2005 05:41:32 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id BAB4AEB1970 for ; Sat, 2 Jul 2005 13:41:29 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id B46C81329E3 for ; Sat, 2 Jul 2005 13:41:27 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72067-08 for ; Sat, 2 Jul 2005 13:41:16 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id 68549131299; Sat, 2 Jul 2005 13:41:15 +0800 (CST) Date: Sat, 2 Jul 2005 13:41:15 +0800 From: Xin LI To: freebsd-arch@FreeBSD.org Message-ID: <20050702054115.GA73667@frontfree.net> References: <20050701111103.GA48039@frontfree.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mojUlQ0s9EVzWg2t" Content-Disposition: inline In-Reply-To: <20050701111103.GA48039@frontfree.net> User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.4-RELEASE-p3 FreeBSD 5.4-RELEASE-p3 #2: Thu Jun 30 11:05:45 CST 2005 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: amavisd-new at frontfree.net Cc: Subject: Re: [PATCH] Remove ENABLE_SSE option from i386 and pc98 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, 02 Jul 2005 05:41:32 -0000 --mojUlQ0s9EVzWg2t Content-Type: multipart/mixed; boundary="RnlQjJ0d97Da+TV1" Content-Disposition: inline --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable (re@ has been removed to reduce their mail load) Seems I need to have more sleep before sending patches... Here it is. Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch-enablesse-removal Index: conf/options.i386 =================================================================== RCS file: /home/ncvs/src/sys/conf/options.i386,v retrieving revision 1.224 diff -u -r1.224 options.i386 --- conf/options.i386 29 Jun 2005 23:23:16 -0000 1.224 +++ conf/options.i386 1 Jul 2005 10:59:44 -0000 @@ -51,7 +51,6 @@ CPU_ELAN_PPS opt_cpu.h CPU_ELAN_XTAL opt_cpu.h CPU_ENABLE_LONGRUN opt_cpu.h -CPU_ENABLE_SSE opt_cpu.h CPU_FASTER_5X86_FPU opt_cpu.h CPU_GEODE opt_cpu.h CPU_I486_ON_386 opt_cpu.h Index: conf/options.pc98 =================================================================== RCS file: /home/ncvs/src/sys/conf/options.pc98,v retrieving revision 1.188 diff -u -r1.188 options.pc98 --- conf/options.pc98 29 Jun 2005 23:23:16 -0000 1.188 +++ conf/options.pc98 1 Jul 2005 10:59:30 -0000 @@ -41,7 +41,6 @@ CPU_DISABLE_5X86_LSSER opt_cpu.h CPU_DISABLE_CMPXCHG opt_global.h # XXX global, unlike other CPU_* CPU_DISABLE_SSE opt_cpu.h -CPU_ENABLE_SSE opt_cpu.h CPU_FASTER_5X86_FPU opt_cpu.h CPU_GEODE opt_cpu.h CPU_I486_ON_386 opt_cpu.h Index: i386/conf/NOTES =================================================================== RCS file: /home/ncvs/src/sys/i386/conf/NOTES,v retrieving revision 1.1201 diff -u -r1.1201 NOTES --- i386/conf/NOTES 21 Jun 2005 10:17:55 -0000 1.1201 +++ i386/conf/NOTES 1 Jul 2005 11:00:22 -0000 @@ -116,9 +116,6 @@ # technology which allows to restrict power consumption of the CPU by # using group of hw.crusoe.* sysctls. # -# CPU_ENABLE_SSE enables SSE/MMX2 instructions support. This is default -# on I686_CPU and above. -# # CPU_FASTER_5X86_FPU enables faster FPU exception handler. # # CPU_GEODE is for the SC1100 Geode embedded processor. This option @@ -194,7 +191,6 @@ options CPU_ELAN_PPS options CPU_ELAN_XTAL=32768000 options CPU_ENABLE_LONGRUN -options CPU_ENABLE_SSE options CPU_FASTER_5X86_FPU options CPU_GEODE options CPU_I486_ON_386 Index: pc98/conf/NOTES =================================================================== RCS file: /home/ncvs/src/sys/pc98/conf/NOTES,v retrieving revision 1.58 diff -u -r1.58 NOTES --- pc98/conf/NOTES 21 Jun 2005 12:59:53 -0000 1.58 +++ pc98/conf/NOTES 1 Jul 2005 11:00:53 -0000 @@ -88,9 +88,6 @@ # # CPU_DISABLE_SSE explicitly prevents I686_CPU from turning on SSE. # -# CPU_ENABLE_SSE enables SSE/MMX2 instructions support. This is default -# on I686_CPU and above. -# # CPU_FASTER_5X86_FPU enables faster FPU exception handler. # # CPU_I486_ON_386 enables CPU cache on i486 based CPU upgrade products @@ -156,7 +153,6 @@ options CPU_DISABLE_5X86_LSSER options CPU_DISABLE_CMPXCHG #options CPU_DISABLE_SSE -options CPU_ENABLE_SSE options CPU_FASTER_5X86_FPU options CPU_I486_ON_386 options CPU_IORT --RnlQjJ0d97Da+TV1-- --mojUlQ0s9EVzWg2t Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCxij7/cVsHxFZiIoRAtu6AJwPrbYuSQJRnZUP3P75fl6arVZmtQCfU3gg 8Q0Bo4J6rEy2JBR0rMI8cxk= =9oQt -----END PGP SIGNATURE----- --mojUlQ0s9EVzWg2t-- From owner-freebsd-arch@FreeBSD.ORG Sat Jul 2 07:29:53 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 13A4B16A41C for ; Sat, 2 Jul 2005 07:29:53 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83EC843D1F for ; Sat, 2 Jul 2005 07:29:52 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j627Tp6W008657; Sat, 2 Jul 2005 10:29:51 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 86434-09; Sat, 2 Jul 2005 10:29:50 +0300 (EEST) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j627TntQ008654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Jul 2005 10:29:50 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j627TqnF026347; Sat, 2 Jul 2005 10:29:52 +0300 (EEST) (envelope-from ru) Date: Sat, 2 Jul 2005 10:29:52 +0300 From: Ruslan Ermilov To: Xin LI Message-ID: <20050702072952.GB26276@ip.net.ua> References: <20050701111103.GA48039@frontfree.net> <20050702054115.GA73667@frontfree.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CUfgB8w4ZwR/yMy5" Content-Disposition: inline In-Reply-To: <20050702054115.GA73667@frontfree.net> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: freebsd-arch@freebsd.org Subject: Re: [PATCH] Remove ENABLE_SSE option from i386 and pc98 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, 02 Jul 2005 07:29:53 -0000 --CUfgB8w4ZwR/yMy5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 02, 2005 at 01:41:15PM +0800, Xin LI wrote: > (re@ has been removed to reduce their mail load) >=20 > Seems I need to have more sleep before sending patches... Here it > is. >=20 No, you want to unifdef(1) it in all sources, i.e.: /sys/conf/options.i386 /sys/conf/options.pc98 /sys/i386/conf/NOTES /sys/i386/i386/initcpu.c /sys/i386/i386/machdep.c /sys/i386/i386/pmap.c /sys/i386/i386/ptrace_machdep.c /sys/i386/isa/npx.c /sys/i386/linux/linux_ptrace.c /sys/pc98/conf/NOTES /sys/pc98/pc98/machdep.c Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --CUfgB8w4ZwR/yMy5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCxkJwqRfpzJluFF4RAqsAAJ0S6uf2DZI0TKVKEX2vFOFd2dFP5QCeIWOE nIwVnj64FRvEgriyMVFWJPU= =ZRZZ -----END PGP SIGNATURE----- --CUfgB8w4ZwR/yMy5-- From owner-freebsd-arch@FreeBSD.ORG Sat Jul 2 21:05:20 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 4E9C516A41C; Sat, 2 Jul 2005 21:05:20 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE4EF43D4C; Sat, 2 Jul 2005 21:05:19 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout2.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j62L5DVu028005; Sun, 3 Jul 2005 07:05:13 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3) with ESMTP id j62L5BAA006144; Sun, 3 Jul 2005 07:05:12 +1000 Date: Sun, 3 Jul 2005 07:05:12 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Ruslan Ermilov In-Reply-To: <20050702072952.GB26276@ip.net.ua> Message-ID: <20050703065051.V2554@epsplex.bde.org> References: <20050701111103.GA48039@frontfree.net> <20050702054115.GA73667@frontfree.net> <20050702072952.GB26276@ip.net.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-arch@FreeBSD.org Subject: Re: [PATCH] Remove ENABLE_SSE option from i386 and pc98 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, 02 Jul 2005 21:05:20 -0000 On Sat, 2 Jul 2005, Ruslan Ermilov wrote: > On Sat, Jul 02, 2005 at 01:41:15PM +0800, Xin LI wrote: >> (re@ has been removed to reduce their mail load) >> >> Seems I need to have more sleep before sending patches... Here it >> is. >> > No, you want to unifdef(1) it in all sources, i.e.: > > /sys/conf/options.i386 > /sys/conf/options.pc98 > ... unifdef(1) is even less suitable than usual for removing ifdefs. Normally the main problem with unifdef(1) is that it mangles the vertical whitespace, but for CPU_ENABLE_SSE the ifdefs are tangled so they all need to be adjusted manually in a context-specific way, and the correct untangling isn't clear. The current condition for configuring SSE is normally "#ifdef I686_CPU" after compile-time untangling, but SSE doesn't really depend on 686'ness so the condition shouldn't be written that way in the source code. Bruce