From owner-freebsd-arch@FreeBSD.ORG Sun Oct 26 01:08:27 2003 Return-Path: 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 1BD3416A4DE for ; Sun, 26 Oct 2003 01:08:27 -0800 (PST) Received: from dixie.svsecure.net (dixie.svsecure.net [64.247.1.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4C9843FE3 for ; Sun, 26 Oct 2003 01:08:03 -0800 (PST) (envelope-from info@bardic.com) Received: from nobody by dixie.svsecure.net with local (Exim 4.24) id 1ADgsU-00054L-Kd for freebsd-arch@freebsd.org; Sun, 26 Oct 2003 04:08:02 -0500 To: FREEBSD-ARCH From: Roger Barnette Date: Sun, 26 Oct 2003 3:46:24 EST MIME-Version: 1.0 Message-Id: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dixie.svsecure.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [99 99] / [47 12] X-AntiAbuse: Sender Address Domain - bardic.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: DigiTales newsletter: Last call... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 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 Oct 2003 09:08:27 -0000 DigiTales newsletter: Last call... The newsletters will start flowing again next week. I am now gainfully employed full-time and it has indeed been the answer to 2 years of fervent prayer. The website is being reworked to just be fun and to capture these newsletter tips for future reference. A number of people confirmed their subscriptions in June. If you have already done that no further action is required to remain on the DigiTales newsletter email list. See the newly converted archive of DigiTales at: http://www.bardic.com/blog/blogger.html If you didn't confirm to remain on the list but have changed your mind visit the new registration page. http://bardic.com/mailman/listinfo/digitales_bardic.com Thank you for your patience as I have stuggled through self and under employment and into full employment. Your prayers and patronage has truly been a blessing to myself and my family. Thank you so very much! Blessings, Roger. From owner-freebsd-arch@FreeBSD.ORG Mon Oct 27 02:11:55 2003 Return-Path: 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 A6DBA16A4B3 for ; Mon, 27 Oct 2003 02:11:55 -0800 (PST) Received: from ws9.cdotb.ernet.in (fw.cdotb.ernet.in [202.41.72.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 507A743F85 for ; Mon, 27 Oct 2003 02:11:49 -0800 (PST) (envelope-from saye@cdotb.ernet.in) Received: from localhost (saye@localhost) by ws9.cdotb.ernet.in (8.12.9/8.12.9) with ESMTP id h9RAFm8O018655 for ; Mon, 27 Oct 2003 15:15:48 +0500 (GMT+0500) Date: Mon, 27 Oct 2003 15:15:48 +0500 (GMT+0500) From: "Saye Balasubramaniam.S" To: freebsd-arch@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Adding a new field into mbuf pkthdr structure X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 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 Oct 2003 10:11:55 -0000 Hi, We are using FreeBsd stack in our new product. I am planning to add a new field (integer)into the pkthdr struct used in mbuf. I am worried about the side-effects of this. Will there be any side-effects? Please give your valuable feedback. regards saye ------------------------------------------------------------------ From owner-freebsd-arch@FreeBSD.ORG Mon Oct 27 06:50:57 2003 Return-Path: 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 7B7F516A4B3 for ; Mon, 27 Oct 2003 06:50:57 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1981D43F85 for ; Mon, 27 Oct 2003 06:50:56 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.9p2/8.12.9) with ESMTP id h9REndMg099603; Mon, 27 Oct 2003 09:49:39 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)h9REncXc099599; Mon, 27 Oct 2003 09:49:39 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 27 Oct 2003 09:49:38 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: "Saye Balasubramaniam.S" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org Subject: Re: Adding a new field into mbuf pkthdr structure X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 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 Oct 2003 14:50:57 -0000 On Mon, 27 Oct 2003, Saye Balasubramaniam.S wrote: > We are using FreeBsd stack in our new product. > I am planning to add a new field (integer)into the pkthdr struct > used in mbuf. I am worried about the side-effects of this. > Will there be any side-effects? Please give your > valuable feedback. The primary issue is binary compatibility, which may not be an issue at all for your product. By changing the size of struct mbuf, all kernel components using mbufs typically need to be recompiled, as the offset of data in an M_PKTHDR mbuf is located using the size of struct pkthdr. If you don't care about binary compatibility: i.e., you don't plan to use third party binary-only drivers, then this is not an issue. In our first pass at adding MAC labels to mbuf headers, we stored them directly in "struct pkthdr". The consequence was a slight reduction in the size of the data that could be held in an mbuf + M_PKTHDR without using a cluster. In practice this wasn't measurable in any normal benchmarks, although it you carefully sized test packets above and below that threshold size, it was noticeable. In addition, because "struct mac" is fairly large, you could measure an additional cost to zero the field even in systems without MAC enabled--again, fairly small, but measurable. The final problem we had to address in adding fields to the mbuf header was making sure that the value was properly managed when mbufs were copied. We found that, in earlier versions of FreeBSD, mbuf headers were relatively frequently allocated to hold copies of existing mbufs, but that the mbuf header fields (such as size, flags) were manually copied by calling code. In more recent versions of FreeBSD, header-copying and moving primitives, such as M_MOVE_PKTHDR() and m_dup_pkthdr() are used, which make it easier to maintain header values due to their central implementation. I would not be surprised if there are a couple of lurking places where packet header routines still need to be used to make sure that header entries are properly propagated, but most of them are handled. For example, I believe we may still need to modify the IP fragmentation code for outgoing packets to properly copy additional header fields and tags. One of the pieces of infrastructure introduced to support IPsec better was m_tags, a list of "tags" hung off of the mbuf header. This allows you to extend the contents of a header in a binary-compatible manner, although at a slight increase in cost in infrastructure due to additional memory allocation and pointer values. Tags are automatically maintained and copied over various mbuf operations, so you might want to give them a spin and see how the performance compares for your application. Hope this is helpful, Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories From owner-freebsd-arch@FreeBSD.ORG Tue Oct 28 05:15:00 2003 Return-Path: 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 315AA16A4CE; Tue, 28 Oct 2003 05:15:00 -0800 (PST) Received: from cheer.mahoroba.org (flets19-227.kamome.or.jp [218.45.19.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A6A743FE0; Tue, 28 Oct 2003 05:14:56 -0800 (PST) (envelope-from ume@mahoroba.org) Received: from mille.mahoroba.org (IDENT:2DsfpExvzajADC+7WO+s7MEpc9vDUSEiMXHEiEsE1eNJ8LzW0t3ryGTbe/XMr4GH@mille.mahoroba.org [IPv6:3ffe:501:185b:8010:202:2dff:fe41:8630]) (user=ume mech=CRAM-MD5 bits=0)h9SDEkJR063790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2003 22:14:46 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 28 Oct 2003 22:14:46 +0900 Message-ID: From: Hajimu UMEMOTO To: current@FreeBSD.org, net@FreeBSD.org, arch@FreeBSD.org References: <20031028063802.GC10818@canolog.ninthwonder.com> User-Agent: Wanderlust/2.11.0 (Wonderwall) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 4.8-RELEASE-p13 MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: multipart/mixed; boundary="Multipart_Tue_Oct_28_22:14:46_2003-1" X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on cheer.mahoroba.org Subject: Forward: HEADS UP! Default value of ip6_v6only changed X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2003 13:15:00 -0000 --Multipart_Tue_Oct_28_22:14:46_2003-1 Content-Type: text/plain; charset=US-ASCII Hi, Our default of net.inet6.ip6.v6only was off in 4.X, and was changed to on on 5.X to follow NetBSD's practice. This behavior on 5.X breaks RFC2553/3493, and the change was intentional from security consideration. But, NetBSD changed it off by default. How do you think our default of on? --Multipart_Tue_Oct_28_22:14:46_2003-1 Content-Type: message/rfc822 X-Sieve: CMU Sieve 2.2 Delivered-To: tech-net@netbsd.org Date: Tue, 28 Oct 2003 01:38:02 -0500 From: NetBSD OS PMC To: tech-net@netbsd.org, current-users@netbsd.org Subject: HEADS UP! Default value of ip6_v6only changed Message-ID: <20031028063802.GC10818@canolog.ninthwonder.com> Mail-Followup-To: tech-net@netbsd.org, current-users@netbsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: tech-net-owner@NetBSD.org Precedence: list X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on cheer.mahoroba.org The default value of ip6_v6only (sysctl net.inet6.ip6.v6only) has been changed. The new value brings us closer in line with current RFC-defined behavior and practices. Itojun still has significant concerns about the new default behavior. His concerns have been well-documented in ftp://ftp.itojun.org/pub/paper/draft-cmetz-v6ops-v4mapped-api-harmful-00.txt Best Regards, NetBSD OS PMC (core) -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ --Multipart_Tue_Oct_28_22:14:46_2003-1-- From owner-freebsd-arch@FreeBSD.ORG Tue Oct 28 07:40:23 2003 Return-Path: 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 2B36F16A4CF; Tue, 28 Oct 2003 07:40:23 -0800 (PST) Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38E3543F85; Tue, 28 Oct 2003 07:40:22 -0800 (PST) (envelope-from boote@internet2.edu) Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id A36353F8; Tue, 28 Oct 2003 10:40:21 -0500 (EST) Received: from internet2.edu (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 2B8AC32A; Tue, 28 Oct 2003 10:40:20 -0500 (EST) Message-ID: <3F9E8DE3.61A5D814@internet2.edu> Date: Tue, 28 Oct 2003 08:40:19 -0700 From: "Jeff W. Boote" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hajimu UMEMOTO References: <20031028063802.GC10818@canolog.ninthwonder.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by mail.internet2.edu virus scanner cc: arch@FreeBSD.org cc: current@FreeBSD.org cc: net@FreeBSD.org Subject: Re: Forward: HEADS UP! Default value of ip6_v6only changed X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2003 15:40:23 -0000 Hajimu UMEMOTO wrote: > > Hi, > > Our default of net.inet6.ip6.v6only was off in 4.X, and was changed to > on on 5.X to follow NetBSD's practice. This behavior on 5.X breaks > RFC2553/3493, and the change was intentional from security > consideration. But, NetBSD changed it off by default. > How do you think our default of on? As long as it is documented well, and the workaround (setting the IPV6_V6ONLY sockopt "off") is referenced, I don't think it really matters. Application programmers realize they have *some* work to do when porting applications to V6. A single sockopt call is not unreasonable. I think "on" for the security reasons outlined is the right call - it will at least make people think about those issues, and most would not without something bringing it up. (That said, it would be nice if NetBSD would pick a direction and keep it.) jeff From owner-freebsd-arch@FreeBSD.ORG Thu Oct 30 14:34:53 2003 Return-Path: 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 7DAB516A4CE for ; Thu, 30 Oct 2003 14:34:53 -0800 (PST) Received: from mail.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5473943F93 for ; Thu, 30 Oct 2003 14:34:52 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 8840 invoked from network); 30 Oct 2003 22:34:51 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 30 Oct 2003 22:34:51 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h9UMYlce040430 for ; Thu, 30 Oct 2003 17:34:48 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Thu, 30 Oct 2003 17:34:47 -0500 (EST) From: John Baldwin To: arch@FreeBSD.org X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: HEADSUP: New i386 interrupt and SMP code.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 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 Oct 2003 22:34:53 -0000 Coming very soon to a CVS tree near you are some very large changes to the i386 interrupt and SMP code. New features include: - Runtime selection of using the I/O APICs or the AT PICs to route interrupts. - I/O APICs can be used in a UP kernel or on a UP system that supplies either an MP Table or ACPI APIC Table. - An SMP kernel can run on a UP machine. This means that SMP can now be enabled in GENERIC and the SMP kernel config can die. - The ACPI MADT table can be used to enumerate CPUs instead of the MP Table if ACPI is enabled. This will add true HT support in that we will finally support the BIOS setting for HT. - I/O APIC interrupts are now longer forced into 8 IRQs. Thus, when using APICs, each PCI interrupt really gets its own IRQ and isn't shared with anyone else. - Multiple fast interrupt handlers can be attached to a given interrupt source provided that all of the handlers are fast. (Note: at this point, fast is a poor name, INTR_DIRECT might be a better name.) - Logical APIC IDs are used to route APIC interrupts from the I/O APICs to CPUs. In theory the APIC interrupt code can now support 60 CPUs. The hardware is still limited to 16 however. - We now correctly route PCI interrupts when using APICs using the PCI interrupt routing infrastructure instead of a gross hack in pci_cfgregread(). This means that we can route interrupts across bridges, support mp tables that only list interrupts for chassis devices, etc. We also correctly route PCI interrupts when using APICs and ACPI. - The new interrupt source abstraction should make it substantially easier to add support for MSI interrupts. - We properly support mixed mode by EOI'ing the AT PIC and not EOI'ing the local APIC for mixed mode interrupts (just irq 0: clk right now). - This code can largely be pulled over to amd64 to support APICs and SMP on that arch. Some implementation details include: - APIC interrupt entry points only use one entry point per 32 vectors and use the APIC ISR registers to determine which interrupt triggered in that range. This means that the APIC code only has to provide 5 entry points instead of 159. - Because we now support up to 159 different IRQs, the critical section optimization code no longer scales well. Especially since the new APIC code does not use a separate entry point for each IRQ. Thus, for the time being at least, critical sections have been reverted back to disabling interrupts for now. I do have a WIP for optimizing critical sections using a more scalable algorithm should the need arise. - Each IRQ is actually a cookie tied to an interrupt source. Each interrupt source is tied to a PIC driver. The PIC driver supports several operations on each interrupt source including disabling the source, enabling it for the first time, etc. Each PIC driver is free to store private per-source data with each source and private per-pic data with each PIC. - APICs (both I/O and local (CPUs)) are enumerated by APIC enumerator drivers of which 2 are provided: one to use the ACPI MADT table and one to use the MP Table. - The SMP code no longer knows anything specific to the MP table. Instead, the APIC enumerators inform the SMP code of CPUs via a simple cpu_add() interface and the SMP code takes it from there. The SMP code is now much easier to read. Also, all of the APIC code has been split out into separate IO and local APIC files aiding in the cleanup. - Almost all of the interrupt dispatch code now happens in C rather than assembly. Notably, fast interrupt handlers no longer have a separate entry point. Downsides: - ACPI will no longer work as a module for know. The reason for this is that ACPI's APIC enumerator needs to be able to hook into a SI_SUB_TUNABLES - 1 SYSINIT() due to existing code that wants to know the available CPUs in the system very early (specifically, UMA). However, code in kernel modules cannot be executed until SI_SUB_KLD, which is much too late. This might be able to be addressed later with some creative hacking. - I haven't ported the changes over to PC98 yet. Code: The code lives in p4 under //depot/user/jhb/acpipci/... Note that several files have moved around so you might want to check the 'notes' file and 'setup.sh' file. If you want to try it out you can check out the tree using p4 and build a kernel. Just be sure to: 1) Run setup.sh first to create needed symlinks for moved files. 2) Use 'device apic' instead of 'options APIC_IO'. I'm sure there's more details that I've forgotten, but that's a start at least. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ From owner-freebsd-arch@FreeBSD.ORG Thu Oct 30 14:53:50 2003 Return-Path: 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 CAD0516A4CE; Thu, 30 Oct 2003 14:53:50 -0800 (PST) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1066A43FE3; Thu, 30 Oct 2003 14:53:50 -0800 (PST) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.9/8.12.3) with ESMTP id h9UMrkip017714; Thu, 30 Oct 2003 14:53:46 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.9/8.12.3/Submit) id h9UMrkJu017713; Thu, 30 Oct 2003 14:53:46 -0800 Date: Thu, 30 Oct 2003 14:53:46 -0800 From: Brooks Davis To: John Baldwin Message-ID: <20031030225346.GB5173@Odin.AC.HMC.Edu> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="K8nIJk4ghYZn606h" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-milter (http://amavis.org/) on odin.ac.hmc.edu cc: arch@freebsd.org Subject: Re: HEADSUP: New i386 interrupt and SMP code.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 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 Oct 2003 22:53:50 -0000 --K8nIJk4ghYZn606h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Oct 30, 2003 at 05:34:47PM -0500, John Baldwin wrote: > - The ACPI MADT table can be used to enumerate CPUs instead of > the MP Table if ACPI is enabled. This will add true HT support > in that we will finally support the BIOS setting for HT. Will there be an option to ignore the BIOS and do something like the current system? I'm all for paying attention to the BIOS, but I've got over 75 Xeons in my cluster and if they have the wrong BIOS settings, this is going to hurt when we switch to 5.x. Overall, I'm looking forward to this change. The death of the SMP kernel is something I've been looking forward to for a long time. -- Brooks --K8nIJk4ghYZn606h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/oZZ4XY6L6fI4GtQRArrWAJ0fO2s8f27vKtBnqTb2MZbW4TtJMQCeO9uX Ibrx4lJcw6fJElvGn/3+H0g= =m6YL -----END PGP SIGNATURE----- --K8nIJk4ghYZn606h-- From owner-freebsd-arch@FreeBSD.ORG Thu Oct 30 15:10:57 2003 Return-Path: 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 B0AD816A4CE; Thu, 30 Oct 2003 15:10:57 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C52843FBD; Thu, 30 Oct 2003 15:10:47 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id B3D4F65414; Thu, 30 Oct 2003 23:10:43 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10975-01-3; Thu, 30 Oct 2003 23:10:43 +0000 (GMT) Received: from saboteur.dek.spc.org (unknown [81.3.72.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 4DD5F65211; Thu, 30 Oct 2003 23:10:43 +0000 (GMT) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 2186654; Thu, 30 Oct 2003 23:10:41 +0000 (GMT) Date: Thu, 30 Oct 2003 23:10:41 +0000 From: Bruce M Simpson To: John Baldwin Message-ID: <20031030231041.GB40973@saboteur.dek.spc.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: freebsd-arch@freebsd.org Subject: Re: HEADSUP: New i386 interrupt and SMP code.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 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 Oct 2003 23:10:57 -0000 On Thu, Oct 30, 2003 at 05:34:47PM -0500, John Baldwin wrote: > I'm sure there's more details that I've forgotten, but that's > a start at least. Can I use the LAPIC on a UP system with no I/O APIC? :-) BMS From owner-freebsd-arch@FreeBSD.ORG Thu Oct 30 17:17:02 2003 Return-Path: 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 8F99516A4CF; Thu, 30 Oct 2003 17:17:02 -0800 (PST) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6442443FD7; Thu, 30 Oct 2003 17:17:01 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id h9V1H0JC031571; Thu, 30 Oct 2003 17:17:00 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h9V1H0s7031570; Thu, 30 Oct 2003 17:17:00 -0800 (PST) (envelope-from obrien) Date: Thu, 30 Oct 2003 17:16:59 -0800 From: "David O'Brien" To: John Baldwin Message-ID: <20031031011659.GA31439@dragon.nuxi.com> Mail-Followup-To: David O'Brien , John Baldwin , arch@FreeBSD.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 5.1-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: arch@FreeBSD.org Subject: Re: HEADSUP: New i386 interrupt and SMP code.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: arch@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 01:17:02 -0000 On Thu, Oct 30, 2003 at 05:34:47PM -0500, John Baldwin wrote: > Downsides: > - ACPI will no longer work as a module for know. The reason > for this is that ACPI's APIC enumerator needs to be able > to hook into a SI_SUB_TUNABLES - 1 SYSINIT() due to existing > code that wants to know the available CPUs in the system > very early (specifically, UMA). How will one not have to deal with fscked-up AML BIOS code, when one wants to use MADT rather than mptable's to use the APIC? I.E., the ACPI-AML bits should be seperatable from the ACPI-MADT bits. From owner-freebsd-arch@FreeBSD.ORG Fri Oct 31 07:20:39 2003 Return-Path: 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 5151616A4CE for ; Fri, 31 Oct 2003 07:20:39 -0800 (PST) Received: from mail.speakeasy.net (mail8.speakeasy.net [216.254.0.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id 814CE43FD7 for ; Fri, 31 Oct 2003 07:20:38 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 21927 invoked from network); 31 Oct 2003 15:20:38 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 31 Oct 2003 15:20:38 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h9VFKYce044578; Fri, 31 Oct 2003 10:20:34 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20031030225346.GB5173@Odin.AC.HMC.Edu> Date: Fri, 31 Oct 2003 10:20:34 -0500 (EST) From: John Baldwin To: Brooks Davis X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: arch@freebsd.org Subject: Re: HEADSUP: New i386 interrupt and SMP code.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 15:20:39 -0000 On 30-Oct-2003 Brooks Davis wrote: > On Thu, Oct 30, 2003 at 05:34:47PM -0500, John Baldwin wrote: >> - The ACPI MADT table can be used to enumerate CPUs instead of >> the MP Table if ACPI is enabled. This will add true HT support >> in that we will finally support the BIOS setting for HT. > > Will there be an option to ignore the BIOS and do something like the > current system? I'm all for paying attention to the BIOS, but I've got > over 75 Xeons in my cluster and if they have the wrong BIOS settings, > this is going to hurt when we switch to 5.x. It's actually not safe to ignore the BIOS. We have one 750x based system here at work that doesn't boot a 4.x kernel with HTT enabled (the logical CPUs don't ack the IPI) unless HTT is also enabled in the BIOS. > Overall, I'm looking forward to this change. The death of the SMP > kernel is something I've been looking forward to for a long time. It was a question asked of Jordan at the first Usenix BSD BoF I attended back in 2000 in San Diego. :) -- 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 Oct 31 07:21:04 2003 Return-Path: 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 0A18F16A4CE for ; Fri, 31 Oct 2003 07:21:04 -0800 (PST) Received: from mail.speakeasy.net (mail8.speakeasy.net [216.254.0.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29BF143FA3 for ; Fri, 31 Oct 2003 07:21:03 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 22128 invoked from network); 31 Oct 2003 15:21:02 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 31 Oct 2003 15:21:02 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h9VFKxce044592; Fri, 31 Oct 2003 10:20:59 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20031030231041.GB40973@saboteur.dek.spc.org> Date: Fri, 31 Oct 2003 10:20:59 -0500 (EST) From: John Baldwin To: Bruce M Simpson X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-arch@freebsd.org Subject: Re: HEADSUP: New i386 interrupt and SMP code.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 15:21:04 -0000 On 30-Oct-2003 Bruce M Simpson wrote: > On Thu, Oct 30, 2003 at 05:34:47PM -0500, John Baldwin wrote: >> I'm sure there's more details that I've forgotten, but that's >> a start at least. > > Can I use the LAPIC on a UP system with no I/O APIC? :-) No, except for MSI interrupts at some point perhaps. -- 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 Oct 31 07:21:25 2003 Return-Path: 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 EBDE316A4CE for ; Fri, 31 Oct 2003 07:21:25 -0800 (PST) Received: from mail.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3520843FAF for ; Fri, 31 Oct 2003 07:21:25 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 13154 invoked from network); 31 Oct 2003 15:21:24 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 31 Oct 2003 15:21:24 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h9VFLLce044602 for ; Fri, 31 Oct 2003 10:21:21 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20031031011659.GA31439@dragon.nuxi.com> Date: Fri, 31 Oct 2003 10:21:21 -0500 (EST) From: John Baldwin To: arch@FreeBSD.org X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Subject: Re: HEADSUP: New i386 interrupt and SMP code.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 15:21:26 -0000 On 31-Oct-2003 David O'Brien wrote: > On Thu, Oct 30, 2003 at 05:34:47PM -0500, John Baldwin wrote: >> Downsides: >> - ACPI will no longer work as a module for know. The reason >> for this is that ACPI's APIC enumerator needs to be able >> to hook into a SI_SUB_TUNABLES - 1 SYSINIT() due to existing >> code that wants to know the available CPUs in the system >> very early (specifically, UMA). > > How will one not have to deal with fscked-up AML BIOS code, when one > wants to use MADT rather than mptable's to use the APIC? > > I.E., the ACPI-AML bits should be seperatable from the ACPI-MADT bits. It can't. The MP Table provides PCI interrupt routing information in addition to enumerating APICs. Just look at some 'mptable' output for comparison. ACPI's PCI interrupt routing information is not listed in the MADT, but in _PRT objects in the ACPI namespace. You could use the MADT w/o ACPI, but then you would have to use no PCI interrupts. -- 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 Oct 31 12:19:36 2003 Return-Path: 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 8ABFE16A4CF for ; Fri, 31 Oct 2003 12:19:36 -0800 (PST) Received: from smtp-send.myrealbox.com (smtp-send.myrealbox.com [192.108.102.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCCD543F3F for ; Fri, 31 Oct 2003 12:19:35 -0800 (PST) (envelope-from atici@myrealbox.com) Received: from prometheus atici@smtp-send.myrealbox.com [160.39.40.115] $ on Novell NetWare via secured & encrypted transport (TLS); Fri, 31 Oct 2003 13:19:39 -0700 To: arch@FreeBSD.org From: Alp ATICI Content-Type: text/plain; format=flowed; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Fri, 31 Oct 2003 15:19:31 -0500 Message-ID: User-Agent: Opera7.21/Win32 M2 build 3218 Subject: Re: HEADSUP: New i386 interrupt and SMP code.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 20:19:36 -0000 What about the non-i386 architectures? Are they going to be included in this work in the near future? From owner-freebsd-arch@FreeBSD.ORG Fri Oct 31 12:29:04 2003 Return-Path: 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 36C8916A4CE for ; Fri, 31 Oct 2003 12:29:04 -0800 (PST) Received: from mail.speakeasy.net (mail8.speakeasy.net [216.254.0.208]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72C4143FBF for ; Fri, 31 Oct 2003 12:29:03 -0800 (PST) (envelope-from jhb@FreeBSD.org) Received: (qmail 17408 invoked from network); 31 Oct 2003 20:29:02 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 31 Oct 2003 20:29:02 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.9/8.12.9) with ESMTP id h9VKSwce046543; Fri, 31 Oct 2003 15:28:58 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 31 Oct 2003 15:28:58 -0500 (EST) From: John Baldwin To: Alp ATICI X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: arch@FreeBSD.org Subject: Re: HEADSUP: New i386 interrupt and SMP code.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 20:29:04 -0000 On 31-Oct-2003 Alp ATICI wrote: > What about the non-i386 architectures? Are they going to be included > in this work in the near future? All the other non-i386 architectures that support SMP at the moment already do so cleanly in that an SMP kernel works on a UP system. The amd64 architecture will probably be reusing a bunch of this code to implement APIC and SMP support on that arch 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 Sat Nov 1 16:09:37 2003 Return-Path: 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 17CCB16A4CE; Sat, 1 Nov 2003 16:09:37 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id F139D43F75; Sat, 1 Nov 2003 16:09:35 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id hA209ZE49419; Sat, 1 Nov 2003 19:09:35 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Sat, 1 Nov 2003 19:09:35 -0500 (EST) From: Jeff Roberson To: John Baldwin In-Reply-To: Message-ID: <20031101190722.M10222-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org Subject: Re: HEADSUP: New i386 interrupt and SMP code.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Nov 2003 00:09:37 -0000 On Thu, 30 Oct 2003, John Baldwin wrote: > Coming very soon to a CVS tree near you are some very large changes to > the i386 interrupt and SMP code. New features include: > > - Runtime selection of using the I/O APICs or the AT PICs to route > interrupts. > - I/O APICs can be used in a UP kernel or on a UP system that > supplies either an MP Table or ACPI APIC Table. > - An SMP kernel can run on a UP machine. This means that SMP > can now be enabled in GENERIC and the SMP kernel config can die. The lock prefix is extremely expensive on the P4 systems that I have measured. It makes lock cmpxchg 150 cycles vs 12. On athlon this is not such a big deal since it goes to 25 cycles from 12. We should measure the impact of compiling in the lock prefix on UP P4 systems before making this the default. Otherwise, this all sounds good. Thanks, Jeff > - The ACPI MADT table can be used to enumerate CPUs instead of > the MP Table if ACPI is enabled. This will add true HT support > in that we will finally support the BIOS setting for HT. > - I/O APIC interrupts are now longer forced into 8 IRQs. Thus, > when using APICs, each PCI interrupt really gets its own IRQ > and isn't shared with anyone else. > - Multiple fast interrupt handlers can be attached to a given > interrupt source provided that all of the handlers are fast. > (Note: at this point, fast is a poor name, INTR_DIRECT might > be a better name.) > - Logical APIC IDs are used to route APIC interrupts from the > I/O APICs to CPUs. In theory the APIC interrupt code can > now support 60 CPUs. The hardware is still limited to 16 > however. > - We now correctly route PCI interrupts when using APICs > using the PCI interrupt routing infrastructure instead of > a gross hack in pci_cfgregread(). This means that we can > route interrupts across bridges, support mp tables that > only list interrupts for chassis devices, etc. We also > correctly route PCI interrupts when using APICs and ACPI. > - The new interrupt source abstraction should make it substantially > easier to add support for MSI interrupts. > - We properly support mixed mode by EOI'ing the AT PIC and > not EOI'ing the local APIC for mixed mode interrupts (just > irq 0: clk right now). > - This code can largely be pulled over to amd64 to support > APICs and SMP on that arch. > > Some implementation details include: > > - APIC interrupt entry points only use one entry point per 32 > vectors and use the APIC ISR registers to determine which > interrupt triggered in that range. This means that the APIC > code only has to provide 5 entry points instead of 159. > - Because we now support up to 159 different IRQs, the critical > section optimization code no longer scales well. Especially > since the new APIC code does not use a separate entry point > for each IRQ. Thus, for the time being at least, critical > sections have been reverted back to disabling interrupts for > now. I do have a WIP for optimizing critical sections using > a more scalable algorithm should the need arise. > - Each IRQ is actually a cookie tied to an interrupt source. > Each interrupt source is tied to a PIC driver. The PIC driver > supports several operations on each interrupt source including > disabling the source, enabling it for the first time, etc. > Each PIC driver is free to store private per-source data with > each source and private per-pic data with each PIC. > - APICs (both I/O and local (CPUs)) are enumerated by APIC > enumerator drivers of which 2 are provided: one to use > the ACPI MADT table and one to use the MP Table. > - The SMP code no longer knows anything specific to the MP > table. Instead, the APIC enumerators inform the SMP code > of CPUs via a simple cpu_add() interface and the SMP code > takes it from there. The SMP code is now much easier to > read. Also, all of the APIC code has been split out into > separate IO and local APIC files aiding in the cleanup. > - Almost all of the interrupt dispatch code now happens in C > rather than assembly. Notably, fast interrupt handlers no > longer have a separate entry point. > > Downsides: > > - ACPI will no longer work as a module for know. The reason > for this is that ACPI's APIC enumerator needs to be able > to hook into a SI_SUB_TUNABLES - 1 SYSINIT() due to existing > code that wants to know the available CPUs in the system > very early (specifically, UMA). However, code in kernel > modules cannot be executed until SI_SUB_KLD, which is much > too late. This might be able to be addressed later with > some creative hacking. > - I haven't ported the changes over to PC98 yet. > > Code: > > The code lives in p4 under //depot/user/jhb/acpipci/... > Note that several files have moved around so you might want to > check the 'notes' file and 'setup.sh' file. If you want to > try it out you can check out the tree using p4 and build a > kernel. Just be sure to: > > 1) Run setup.sh first to create needed symlinks for moved > files. > 2) Use 'device apic' instead of 'options APIC_IO'. > > I'm sure there's more details that I've forgotten, but that's > a start at least. > > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > _______________________________________________ > 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" >