From owner-freebsd-arch@FreeBSD.ORG Sun Aug 1 01:37:18 2004 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 55B9716A4CE for ; Sun, 1 Aug 2004 01:37:17 +0000 (GMT) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCA9343D58 for ; Sun, 1 Aug 2004 01:37:16 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.13.0/8.13.0) with ESMTP id i711bFlk026945 for ; Sat, 31 Jul 2004 21:37:16 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: Date: Sat, 31 Jul 2004 21:37:15 -0400 To: freebsd-arch@FreeBSD.ORG From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: Random-ness when booting into single-user 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, 01 Aug 2004 01:37:18 -0000 When I was at the devsummit, a few developers remarked at the annoying situation one can get into when booting into single- user mode. Something about various operations which can hang because they need some random number(s), but at that point /dev/random (or whatever the key thing is) has not been seeded with enough entropy to give random numbers. Apparently once you get into this state, you have to start typing a lot of random gibberish to get past the problem. Something about "dancing the fandango", if I remember right. Happily I have not run into this, and I think I would like to make sure that I don't run into it -- even though I obviously don't remember any of the details... I have been looking at sbin/init/init.c, and I was wondering if it might be fairly easy to provide a fix to this situation. Let's say you request single-user mode. If you asked for single-user mode, init.c is what will ask you which shell you want use. Once it knows the shell, couldn't it just do something like first execute: ${SHELL} -c /etc/rc.d/preseedrandom (and ignore any failures) And *then* execute the standard ${SHELL} for single-user mode? Or maybe it would execute some other script to seed the entropy, if /etc/rc.d/preseedrandom is not appropriate under those circumstances. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Sun Aug 1 01:47:58 2004 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 6C44116A4CE for ; Sun, 1 Aug 2004 01:47:58 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB6FB43D70 for ; Sun, 1 Aug 2004 01:47:57 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) i711lueK009490; Sat, 31 Jul 2004 18:47:56 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)i711lump009489; Sat, 31 Jul 2004 18:47:56 -0700 (PDT) (envelope-from sgk) Date: Sat, 31 Jul 2004 18:47:56 -0700 From: Steve Kargl To: Garance A Drosihn Message-ID: <20040801014756.GA9457@troutmask.apl.washington.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: freebsd-arch@freebsd.org Subject: Re: Random-ness when booting into single-user 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, 01 Aug 2004 01:47:58 -0000 On Sat, Jul 31, 2004 at 09:37:15PM -0400, Garance A Drosihn wrote: > > Happily I have not run into this, and I think I would like to > make sure that I don't run into it -- even though I obviously > don't remember any of the details... http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/random/randomdev.c -- Steve From owner-freebsd-arch@FreeBSD.ORG Sun Aug 1 02:02:34 2004 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 F018116A4CE for ; Sun, 1 Aug 2004 02:02:34 +0000 (GMT) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0F0B43D5D for ; Sun, 1 Aug 2004 02:02:34 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.13.0/8.13.0) with ESMTP id i7122VXh008293; Sat, 31 Jul 2004 22:02:33 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20040801014756.GA9457@troutmask.apl.washington.edu> References: <20040801014756.GA9457@troutmask.apl.washington.edu> Date: Sat, 31 Jul 2004 22:02:30 -0400 To: Steve Kargl From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: freebsd-arch@freebsd.org Subject: Re: Random-ness when booting into single-user 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, 01 Aug 2004 02:02:35 -0000 At 6:47 PM -0700 7/31/04, Steve Kargl wrote: >On Sat, Jul 31, 2004 at 09:37:15PM -0400, Garance A Drosihn wrote: >> >> Happily I have not run into this, and I think I would like to >> make sure that I don't run into it -- even though I obviously >> don't remember any of the details... > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/random/randomdev.c Ah. I see that says Start the entropy device insecure/unblocked. I'll be handing over responsibility for critical randomness requirements (like sshd)to rc.d/* Has rc.d/* been changed to match? Thanks for the pointer. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Sun Aug 1 02:27:20 2004 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 105A116A4CE for ; Sun, 1 Aug 2004 02:27:20 +0000 (GMT) Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB84643D1D for ; Sun, 1 Aug 2004 02:27:19 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp4.server.rpi.edu (8.13.0/8.13.0) with ESMTP id i712RHbH011975 for ; Sat, 31 Jul 2004 22:27:18 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: <20040801014756.GA9457@troutmask.apl.washington.edu> Date: Sat, 31 Jul 2004 22:27:17 -0400 To: freebsd-arch@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: Re: Random-ness when booting into single-user 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, 01 Aug 2004 02:27:20 -0000 At 10:02 PM -0400 7/31/04, Garance A Drosihn wrote: >At 6:47 PM -0700 7/31/04, Steve Kargl wrote: >>On Sat, Jul 31, 2004 at 09:37:15PM -0400, Garance A Drosihn wrote: >>> >>> Happily I have not run into this, and I think I would like to >>> make sure that I don't run into it -- even though I obviously >>> don't remember any of the details... >> >>http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/random/randomdev.c Which had the companion change at: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/random/randomdev_soft.c This suggests another tactic. randomdev_soft.c could go back to having random.sys.seeded default to 0, and maybe init.c could change it to 1 (if it is 0) before dropping into single-user mode, and then change it back (if it had been 0) before coming up in multi-user mode. [assuming that can be done] That way we wouldn't have to change anything in /etc/rc.d, and we have something safer than my previous suggestion. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Sun Aug 1 02:27:58 2004 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 C18D616A4CF for ; Sun, 1 Aug 2004 02:27:58 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F4B243D48 for ; Sun, 1 Aug 2004 02:27:58 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.0.12] (g4.samsco.home [192.168.0.12]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i712ZC2O028581; Sat, 31 Jul 2004 20:35:12 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <410C54E6.80500@freebsd.org> Date: Sat, 31 Jul 2004 20:26:46 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Garance A Drosihn References: <20040801014756.GA9457@troutmask.apl.washington.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: Steve Kargl cc: freebsd-arch@freebsd.org Subject: Re: Random-ness when booting into single-user 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, 01 Aug 2004 02:27:58 -0000 Garance A Drosihn wrote: > At 6:47 PM -0700 7/31/04, Steve Kargl wrote: > >> On Sat, Jul 31, 2004 at 09:37:15PM -0400, Garance A Drosihn wrote: >> >>> >>> Happily I have not run into this, and I think I would like to >>> make sure that I don't run into it -- even though I obviously >>> don't remember any of the details... >> >> >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/random/randomdev.c > > > Ah. I see that says > > Start the entropy device insecure/unblocked. I'll be > handing over responsibility for critical randomness > requirements (like sshd)to rc.d/* > > Has rc.d/* been changed to match? > > Thanks for the pointer. > I believe that Mark is still finishing this part of the work. See the 5.3 TODO list for more details. Scott From owner-freebsd-arch@FreeBSD.ORG Sun Aug 1 18:03:19 2004 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 3AB0E16A4CE for ; Sun, 1 Aug 2004 18:03:19 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DB0643D5D for ; Sun, 1 Aug 2004 18:03:18 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.201] ([192.168.0.201]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i71IAZSW031053 for ; Sun, 1 Aug 2004 12:10:36 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <410D2FEA.5050504@samsco.org> Date: Sun, 01 Aug 2004 12:01:14 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.1) Gecko/20040801 X-Accept-Language: en-us, en MIME-Version: 1.0 To: arch@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org Subject: PCI-Express support 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, 01 Aug 2004 18:03:19 -0000 All, I've emailed before about supporting various aspects of PCI-Express and especially MSI, but haven't really gotten too far with it due to lack of resources. I now how access to a system that can do PCI-Express (PCI-E) so I'd like to revisit it and see what can be added for 5-STABLE. There are three general areas that need to be addressed in some form or another: Enhanced Configuration Space: PCI-E introduces an enhanced PCI Configuration space that allows for each function to have 4096 bytes of space instead of just 256. The Intel Lindenhurst chipset exposes this space via a memory-mapped window instead of the old slow type 1/2 ioport configuration methods. It appears that if the northbridge supports the enhanced config space then all PCI, PCI-X, and PCI-E devices will show up in it as well as in the legacy space. Proper support likely entails splitting up the pci host-bridge drivers so that a given ACPI or legacy front-end can plug into a given enhanced or legacy configuration layer. This definitely is not going to happen in time for 5.3, though. A hack that could work for 5-STABLE would be to provide pcie_[read|write]_config() methods that would compliment the existing pci methods and be available for drivers that want to access the >255 configuration addresses. Devices are already showing up that want to use these registers, btw. The mechanics of doing this would involve using pmap_mapdev() to map in the range that is specific to each function, and then hang this information off of the pcicfg structure. It's a bit hackish, yes, but it does seem to work in tests that a colleague of mine has done. MSI: I've bantered around different suggestions for an API that will support this. The basic thing that a driver needs from this is to know exactly how many message interrupt vectors are available to it. It can't just register vectors and handlers blindly since the purpose of MSI is to assign special meanings to each vector and allow the driver to handle each one in specifically. In order to keep the API as consistent as possible between classic interrupt sources and MSI sources, I'd like to add a new bus method: int bus_reserve_resource(device_t, int *start, int *end, int *count, int flags); start, end, and count would be passed is as the desired range and would map to the per-function interrupt index in MSI. On return, the range supported and negotiated by the OS, bus, and function would be filled into these values. flags would be something like SYS_RES_MESSAGE. Internal failure of the function would be given in the return value. Whether failure to support MSI should be given as an error code return value can be debated. This function will also program the MSI configuration registers on the device to use the correct message cookie and number of messages. Interrupt registration would then proceed as normal with paired calls to bus_alloc_resource() and bus_setup_intr() for each desired interrupt index. The individual function interrupt index would be used as the start and end parameters to bus_alloc_resource(), and the type parameter would be SYS_RES_MESSAGE instead of SYS_RES_IRQ. bus_setup_intr() would unmask the source in the MSI APIC just like normal. Adding this for 5.3 is feasible, I think, and doesn't add a whole lot of risk. PCI-E provides a legacy mde for interrupts that simulates PCI interrupt lines, so drivers can choose whether to use MSI or the legacy interrupt methods. Hot-Plug, lane status, lane bonding: We don't have the infrastructure to support PCI or PCI-E hot-plug. It's also debatable whether this information will actually be available in a standard form. The PCI-E spec defines a new extended capabilities structure in the config space that can provide some of this information, but these kinds of things have a history of the vendors choosing their own proprietary methods and ignoring the standard. In short, we can't deal with this in the short term at all, and likely not in the long term without significant work to the bus and device infrastructure. From owner-freebsd-arch@FreeBSD.ORG Sun Aug 1 18:42:38 2004 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 DFFB316A4CE for ; Sun, 1 Aug 2004 18:42:38 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C8C443D41 for ; Sun, 1 Aug 2004 18:42:38 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i71Ieu8q011692; Sun, 1 Aug 2004 12:40:56 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 01 Aug 2004 12:41:25 -0600 (MDT) Message-Id: <20040801.124125.27781564.imp@bsdimp.com> To: scottl@samsco.org From: "M. Warner Losh" In-Reply-To: <410D2FEA.5050504@samsco.org> References: <410D2FEA.5050504@samsco.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: PCI-Express support 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, 01 Aug 2004 18:42:39 -0000 In message: <410D2FEA.5050504@samsco.org> Scott Long writes: : In order to keep the API as consistent as possible between classic : interrupt sources and MSI sources, I'd like to add a new bus method: : : int : bus_reserve_resource(device_t, int *start, int *end, int *count, int flags); : : start, end, and count would be passed is as the desired range and would : map to the per-function interrupt index in MSI. On return, the range : supported and negotiated by the OS, bus, and function would be filled : into these values. flags would be something like SYS_RES_MESSAGE. : Internal failure of the function would be given in the return value. : Whether failure to support MSI should be given as an error code return : value can be debated. This function will also program the MSI : configuration registers on the device to use the correct message cookie : and number of messages. How is this different than bus_alloc_resource and adding SYS_RES_MESSAGE to the list of resources? You can get the same information using bus_alloc_resource w/o the RF_ACTIVE flag. bus_alloc_resource also has two args, one for the type, and another for the flags (which is a different type). start/end should be u_long to match newbus' other use of this stuff (actually, they should be a typedef, but that's a bigger change). You then would just trap the SYS_RES_MESSAGE at the right places to configure things. In this case, the right places would be the pci bridge code. There would be no need to have separate drivers for PCI-Express for the short term, since you could easily flag things as failures for non express bridges. Warner From owner-freebsd-arch@FreeBSD.ORG Sun Aug 1 18:45:46 2004 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 B491316A4D1 for ; Sun, 1 Aug 2004 18:45:46 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2498C43D2D for ; Sun, 1 Aug 2004 18:45:46 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i71Ii3uD011713; Sun, 1 Aug 2004 12:44:03 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 01 Aug 2004 12:44:33 -0600 (MDT) Message-Id: <20040801.124433.26964640.imp@bsdimp.com> To: scottl@samsco.org From: "M. Warner Losh" In-Reply-To: <410D2FEA.5050504@samsco.org> References: <410D2FEA.5050504@samsco.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: PCI-Express support 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, 01 Aug 2004 18:45:46 -0000 [[ replying to different aspects of this in different threads ]] In message: <410D2FEA.5050504@samsco.org> Scott Long writes: : Adding this for 5.3 is feasible, I think, and doesn't add a whole lot : of risk. PCI-E provides a legacy mde for interrupts that simulates : PCI interrupt lines, so drivers can choose whether to use MSI or the : legacy interrupt methods. Code freeze is in 2 weeks. I don't think it reasonable to have things cooked enough by then to add this. We've got enough going into 5.3 already, and these changes will be at the heart of the pci system, which is a very big risk if it is done slightly badly. Given the large number of systems out there, I'd imagine that we'll have lots of problems with this. Smaller risk changes that Matt Dodd and I have made over the years have resulted in big trouble. I'd recommend that we give it a pass for 5.3. Warner From owner-freebsd-arch@FreeBSD.ORG Sun Aug 1 18:54:35 2004 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 ED24716A4CE for ; Sun, 1 Aug 2004 18:54:35 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 902CD43D48 for ; Sun, 1 Aug 2004 18:54:35 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i71IrY4s011848; Sun, 1 Aug 2004 12:53:34 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 01 Aug 2004 12:54:03 -0600 (MDT) Message-Id: <20040801.125403.13772512.imp@bsdimp.com> To: scottl@samsco.org From: "M. Warner Losh" In-Reply-To: <410D2FEA.5050504@samsco.org> References: <410D2FEA.5050504@samsco.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: PCI-Express support 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, 01 Aug 2004 18:54:36 -0000 In message: <410D2FEA.5050504@samsco.org> Scott Long writes: : Proper support likely entails splitting up the pci host-bridge drivers : so that a given ACPI or legacy front-end can plug into a given enhanced : or legacy configuration layer. This definitely is not going to happen : in time for 5.3, though. A hack that could work for 5-STABLE would be : to provide pcie_[read|write]_config() methods that would compliment the : existing pci methods and be available for drivers that want to access : the >255 configuration addresses. Devices are already showing up that : want to use these registers, btw. The mechanics of doing this would : involve using pmap_mapdev() to map in the range that is specific to each : function, and then hang this information off of the pcicfg structure. : It's a bit hackish, yes, but it does seem to work in tests that a : colleague of mine has done. Why not just have the bridge do a bus_alloc_resource for those things? That would cause the pmap_mamdev() to happen behind the scenes. We already do a number of things like this in the CardBus driver, but on a smaller scale. But is there really a reason we need pcie_*_config routines? wouldn't the pcib_* routines do the same job nicely? They are already virtualized so that we can plug in the pcie bridge functionality to the existing bridge drivers if there is a pcie structure allocated to the pcicfg. Why invent an interface that we know we're going to deprecate in short order when the existing interface can be used. In the pci_pci.c code, we could add a couple of ifs in pcib_{read,write}_config if the bridge supports it, for example. Warner From owner-freebsd-arch@FreeBSD.ORG Sun Aug 1 20:16:43 2004 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 5225C16A4CE for ; Sun, 1 Aug 2004 20:16:43 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id B183B43D55 for ; Sun, 1 Aug 2004 20:16:42 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i71KGbY2058752; Sun, 1 Aug 2004 22:16:41 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Scott Long From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 01 Aug 2004 12:01:14 MDT." <410D2FEA.5050504@samsco.org> Date: Sun, 01 Aug 2004 22:16:37 +0200 Message-ID: <58751.1091391397@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: PCI-Express support 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, 01 Aug 2004 20:16:43 -0000 In message <410D2FEA.5050504@samsco.org>, Scott Long writes: >All, > >I've emailed before about supporting various aspects of PCI-Express and >especially MSI, but haven't really gotten too far with it due to lack of >resources. I now how access to a system that can do PCI-Express (PCI-E) >so I'd like to revisit it and see what can be added for 5-STABLE. There >are three general areas that need to be addressed in some form or another: > [...] > >Adding this for 5.3 is feasible, I think, and doesn't add a whole lot >of risk. OK, who are you and what have you done to Scott Long ? Scott would never even think about suggesting something like this two weeks before we lock down the tree for a -stable branching. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sun Aug 1 20:27:25 2004 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 2B7C516A4D1 for ; Sun, 1 Aug 2004 20:27:25 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CE3743D39 for ; Sun, 1 Aug 2004 20:27:24 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.201] ([192.168.0.201]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i71KYfkK031456; Sun, 1 Aug 2004 14:34:41 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <410D51AF.4070708@samsco.org> Date: Sun, 01 Aug 2004 14:25:19 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.1) Gecko/20040801 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <410D2FEA.5050504@samsco.org> <20040801.124125.27781564.imp@bsdimp.com> In-Reply-To: <20040801.124125.27781564.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: arch@freebsd.org Subject: Re: PCI-Express support 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, 01 Aug 2004 20:27:25 -0000 M. Warner Losh wrote: > In message: <410D2FEA.5050504@samsco.org> > Scott Long writes: > : In order to keep the API as consistent as possible between classic > : interrupt sources and MSI sources, I'd like to add a new bus method: > : > : int > : bus_reserve_resource(device_t, int *start, int *end, int *count, int flags); > : > : start, end, and count would be passed is as the desired range and would > : map to the per-function interrupt index in MSI. On return, the range > : supported and negotiated by the OS, bus, and function would be filled > : into these values. flags would be something like SYS_RES_MESSAGE. > : Internal failure of the function would be given in the return value. > : Whether failure to support MSI should be given as an error code return > : value can be debated. This function will also program the MSI > : configuration registers on the device to use the correct message cookie > : and number of messages. > > How is this different than bus_alloc_resource and adding > SYS_RES_MESSAGE to the list of resources? You can get the same > information using bus_alloc_resource w/o the RF_ACTIVE flag. > bus_alloc_resource also has two args, one for the type, and another > for the flags (which is a different type). start/end should be u_long > to match newbus' other use of this stuff (actually, they should be a > typedef, but that's a bigger change). bus_alloc_resource can only allocate one resource at a time. With MSI, you can potentially allocate up to 64 interrupt vectors. You also need to know up-front how many you can allocate. The point of bus_reserve_resource is to give you this information before you make your first allocation. It also will do the initial MSI function configuration that is needed. > > You then would just trap the SYS_RES_MESSAGE at the right places to > configure things. In this case, the right places would be the pci > bridge code. There would be no need to have separate drivers for > PCI-Express for the short term, since you could easily flag things as > failures for non express bridges. > > Warner MSI support will be mostly in the PIC/APIC abstraction that exists now. I don't expect the upper-level bus code to change much. Scott From owner-freebsd-arch@FreeBSD.ORG Sun Aug 1 20:31:40 2004 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 D6FF016A4CE for ; Sun, 1 Aug 2004 20:31:40 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 761C443D5A for ; Sun, 1 Aug 2004 20:31:40 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.201] ([192.168.0.201]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i71Kcxi5031477; Sun, 1 Aug 2004 14:38:59 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <410D52B1.2010807@samsco.org> Date: Sun, 01 Aug 2004 14:29:37 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.1) Gecko/20040801 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <58751.1091391397@critter.freebsd.dk> In-Reply-To: <58751.1091391397@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: arch@freebsd.org Subject: Re: PCI-Express support 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, 01 Aug 2004 20:31:40 -0000 Poul-Henning Kamp wrote: > In message <410D2FEA.5050504@samsco.org>, Scott Long writes: > >>All, >> >>I've emailed before about supporting various aspects of PCI-Express and >>especially MSI, but haven't really gotten too far with it due to lack of >>resources. I now how access to a system that can do PCI-Express (PCI-E) >>so I'd like to revisit it and see what can be added for 5-STABLE. There >>are three general areas that need to be addressed in some form or another: >> > > [...] > >>Adding this for 5.3 is feasible, I think, and doesn't add a whole lot >>of risk. > > > OK, who are you and what have you done to Scott Long ? > > Scott would never even think about suggesting something like this two > weeks before we lock down the tree for a -stable branching. > To answer you and Warner, this is functionality that is optional and has little risk to the existing infrastructure. John has done a great job with abstracting the low-level interrupt drivers, and this would just be another one of those. The support would be marked as *experimental*, but with the API in place it would give us more freedom to make it happen. Intel is pushing really hard to get adoption of this stuff in the small/medium size server area, and 5.x is going to suffer if it's not there. Scott From owner-freebsd-arch@FreeBSD.ORG Sun Aug 1 20:35:40 2004 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 DBC4C16A4CE for ; Sun, 1 Aug 2004 20:35:40 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6307A43D5C for ; Sun, 1 Aug 2004 20:35:40 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.201] ([192.168.0.201]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i71KgwOr031505; Sun, 1 Aug 2004 14:42:58 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <410D53A0.5080909@samsco.org> Date: Sun, 01 Aug 2004 14:33:36 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.1) Gecko/20040801 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <410D2FEA.5050504@samsco.org> <20040801.125403.13772512.imp@bsdimp.com> In-Reply-To: <20040801.125403.13772512.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: arch@freebsd.org Subject: Re: PCI-Express support 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, 01 Aug 2004 20:35:41 -0000 M. Warner Losh wrote: > In message: <410D2FEA.5050504@samsco.org> > Scott Long writes: > : Proper support likely entails splitting up the pci host-bridge drivers > : so that a given ACPI or legacy front-end can plug into a given enhanced > : or legacy configuration layer. This definitely is not going to happen > : in time for 5.3, though. A hack that could work for 5-STABLE would be > : to provide pcie_[read|write]_config() methods that would compliment the > : existing pci methods and be available for drivers that want to access > : the >255 configuration addresses. Devices are already showing up that > : want to use these registers, btw. The mechanics of doing this would > : involve using pmap_mapdev() to map in the range that is specific to each > : function, and then hang this information off of the pcicfg structure. > : It's a bit hackish, yes, but it does seem to work in tests that a > : colleague of mine has done. > > Why not just have the bridge do a bus_alloc_resource for those things? > That would cause the pmap_mamdev() to happen behind the scenes. We > already do a number of things like this in the CardBus driver, but on > a smaller scale. > > But is there really a reason we need pcie_*_config routines? wouldn't > the pcib_* routines do the same job nicely? They are already > virtualized so that we can plug in the pcie bridge functionality to > the existing bridge drivers if there is a pcie structure allocated to > the pcicfg. Why invent an interface that we know we're going to > deprecate in short order when the existing interface can be used. > > In the pci_pci.c code, we could add a couple of ifs in > pcib_{read,write}_config if the bridge supports it, for example. > > Warner First, doing this the Right Way is not going to happen for 5.x. I'm just trying to define an API to bridge us over for the short term. There is no emulation shim defined for the extended config space, so either we support it or we don't. As as I said, there are already devices showing up that want to use the extended registers. Second, I'm trying to approach this in the least disruptive manner. Yes, it could be abstracted so that pci_config_read|write() would do the right things, but that would add risk to a whole lot of code that we don't want to rototill at the moment. Scott From owner-freebsd-arch@FreeBSD.ORG Sun Aug 1 20:42:40 2004 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 B496816A4CE for ; Sun, 1 Aug 2004 20:42:40 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AEE643D41 for ; Sun, 1 Aug 2004 20:42:40 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i71Kf1ok012747; Sun, 1 Aug 2004 14:41:01 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 01 Aug 2004 14:41:30 -0600 (MDT) Message-Id: <20040801.144130.31235788.imp@bsdimp.com> To: scottl@samsco.org From: "M. Warner Losh" In-Reply-To: <410D51AF.4070708@samsco.org> References: <410D2FEA.5050504@samsco.org> <20040801.124125.27781564.imp@bsdimp.com> <410D51AF.4070708@samsco.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: PCI-Express support 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, 01 Aug 2004 20:42:40 -0000 In message: <410D51AF.4070708@samsco.org> Scott Long writes: : M. Warner Losh wrote: : > In message: <410D2FEA.5050504@samsco.org> : > Scott Long writes: : > : In order to keep the API as consistent as possible between classic : > : interrupt sources and MSI sources, I'd like to add a new bus method: : > : : > : int : > : bus_reserve_resource(device_t, int *start, int *end, int *count, int flags); : > : : > : start, end, and count would be passed is as the desired range and would : > : map to the per-function interrupt index in MSI. On return, the range : > : supported and negotiated by the OS, bus, and function would be filled : > : into these values. flags would be something like SYS_RES_MESSAGE. : > : Internal failure of the function would be given in the return value. : > : Whether failure to support MSI should be given as an error code return : > : value can be debated. This function will also program the MSI : > : configuration registers on the device to use the correct message cookie : > : and number of messages. : > : > How is this different than bus_alloc_resource and adding : > SYS_RES_MESSAGE to the list of resources? You can get the same : > information using bus_alloc_resource w/o the RF_ACTIVE flag. : > bus_alloc_resource also has two args, one for the type, and another : > for the flags (which is a different type). start/end should be u_long : > to match newbus' other use of this stuff (actually, they should be a : > typedef, but that's a bigger change). : : bus_alloc_resource can only allocate one resource at a time. With MSI, : you can potentially allocate up to 64 interrupt vectors. You also need : to know up-front how many you can allocate. The point of : bus_reserve_resource is to give you this information before you make : your first allocation. It also will do the initial MSI function : configuration that is needed. bus_alloc_resource can allocate a range of things, so it is not entirely true that you can allocate only one resource at a time. You can put the count in != 1 and have the same information in the reserve API. Then you can ask the resource how big it is and base your decisions on that. You'd then need to have some way of associating subranage of the range you allocated easily, which presently isn't that easy to do, but is needed for a lot of other things. Doing that would solve the issues for msi, as well as having potential benefit to other bus drivers that need to be able to allocate a large range, and then give out subranges to its children. Warner From owner-freebsd-arch@FreeBSD.ORG Sun Aug 1 20:45:21 2004 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 E083316A4CE for ; Sun, 1 Aug 2004 20:45:20 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7814A43D45 for ; Sun, 1 Aug 2004 20:45:20 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.201] ([192.168.0.201]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i71KqcVD031550; Sun, 1 Aug 2004 14:52:38 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <410D55E4.40101@samsco.org> Date: Sun, 01 Aug 2004 14:43:16 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.1) Gecko/20040801 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <410D2FEA.5050504@samsco.org> <20040801.124125.27781564.imp@bsdimp.com> <410D51AF.4070708@samsco.org> <20040801.144130.31235788.imp@bsdimp.com> In-Reply-To: <20040801.144130.31235788.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: arch@freebsd.org Subject: Re: PCI-Express support 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, 01 Aug 2004 20:45:21 -0000 M. Warner Losh wrote: > In message: <410D51AF.4070708@samsco.org> > Scott Long writes: > : M. Warner Losh wrote: > : > In message: <410D2FEA.5050504@samsco.org> > : > Scott Long writes: > : > : In order to keep the API as consistent as possible between classic > : > : interrupt sources and MSI sources, I'd like to add a new bus method: > : > : > : > : int > : > : bus_reserve_resource(device_t, int *start, int *end, int *count, int flags); > : > : > : > : start, end, and count would be passed is as the desired range and would > : > : map to the per-function interrupt index in MSI. On return, the range > : > : supported and negotiated by the OS, bus, and function would be filled > : > : into these values. flags would be something like SYS_RES_MESSAGE. > : > : Internal failure of the function would be given in the return value. > : > : Whether failure to support MSI should be given as an error code return > : > : value can be debated. This function will also program the MSI > : > : configuration registers on the device to use the correct message cookie > : > : and number of messages. > : > > : > How is this different than bus_alloc_resource and adding > : > SYS_RES_MESSAGE to the list of resources? You can get the same > : > information using bus_alloc_resource w/o the RF_ACTIVE flag. > : > bus_alloc_resource also has two args, one for the type, and another > : > for the flags (which is a different type). start/end should be u_long > : > to match newbus' other use of this stuff (actually, they should be a > : > typedef, but that's a bigger change). > : > : bus_alloc_resource can only allocate one resource at a time. With MSI, > : you can potentially allocate up to 64 interrupt vectors. You also need > : to know up-front how many you can allocate. The point of > : bus_reserve_resource is to give you this information before you make > : your first allocation. It also will do the initial MSI function > : configuration that is needed. > > bus_alloc_resource can allocate a range of things, so it is not > entirely true that you can allocate only one resource at a time. You > can put the count in != 1 and have the same information in the reserve > API. Then you can ask the resource how big it is and base your > decisions on that. You'd then need to have some way of associating > subranage of the range you allocated easily, which presently isn't > that easy to do, but is needed for a lot of other things. Doing that > would solve the issues for msi, as well as having potential benefit to > other bus drivers that need to be able to allocate a large range, and > then give out subranges to its children. > > Warner Well, this is exactly the problem that I'm trying to solve. What is your suggestion? Also, I'm trying to keep from modifying the bus_setup_intr() API, so it seemed logical to keep bus_alloc_resource and bus_setup_intr functioning exactly as they are today but still provide the added information to the driver in an optional and non-obtrusive way. Scott From owner-freebsd-arch@FreeBSD.ORG Sun Aug 1 20:47:36 2004 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 C5BEE16A4CE for ; Sun, 1 Aug 2004 20:47:36 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BFDA43D1D for ; Sun, 1 Aug 2004 20:47:36 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i71KlY6E061726; Sun, 1 Aug 2004 22:47:34 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Scott Long From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 01 Aug 2004 14:29:37 MDT." <410D52B1.2010807@samsco.org> Date: Sun, 01 Aug 2004 22:47:34 +0200 Message-ID: <61725.1091393254@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: arch@freebsd.org Subject: Re: PCI-Express support 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, 01 Aug 2004 20:47:36 -0000 In message <410D52B1.2010807@samsco.org>, Scott Long writes: >>>Adding this for 5.3 is feasible, I think, and doesn't add a whole lot >>>of risk. >> >> >> OK, who are you and what have you done to Scott Long ? >> >> Scott would never even think about suggesting something like this two >> weeks before we lock down the tree for a -stable branching. > >To answer you and Warner, this is functionality that is optional and has >little risk to the existing infrastructure. John has done a great job >with abstracting the low-level interrupt drivers, and this would just be >another one of those. The support would be marked as *experimental*, >but with the API in place it would give us more freedom to make it >happen. Intel is pushing really hard to get adoption of this stuff in >the small/medium size server area, and 5.x is going to suffer if it's >not there. I *really* want us to get 5-stable branched and moving. If it is as optional as you say now, it can be added downstream once it has been baked out in -current. Please, Let us concentrate on getting 5-stable branched and made sensible. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Sun Aug 1 20:48:53 2004 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 890DC16A4CF for ; Sun, 1 Aug 2004 20:48:53 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCFEC43D48 for ; Sun, 1 Aug 2004 20:48:52 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i71KkIPA012829; Sun, 1 Aug 2004 14:46:18 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 01 Aug 2004 14:46:48 -0600 (MDT) Message-Id: <20040801.144648.102436632.imp@bsdimp.com> To: scottl@samsco.org From: "M. Warner Losh" In-Reply-To: <410D53A0.5080909@samsco.org> References: <410D2FEA.5050504@samsco.org> <20040801.125403.13772512.imp@bsdimp.com> <410D53A0.5080909@samsco.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: PCI-Express support 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, 01 Aug 2004 20:48:53 -0000 In message: <410D53A0.5080909@samsco.org> Scott Long writes: : M. Warner Losh wrote: : > In message: <410D2FEA.5050504@samsco.org> : > Scott Long writes: : > : Proper support likely entails splitting up the pci host-bridge drivers : > : so that a given ACPI or legacy front-end can plug into a given enhanced : > : or legacy configuration layer. This definitely is not going to happen : > : in time for 5.3, though. A hack that could work for 5-STABLE would be : > : to provide pcie_[read|write]_config() methods that would compliment the : > : existing pci methods and be available for drivers that want to access : > : the >255 configuration addresses. Devices are already showing up that : > : want to use these registers, btw. The mechanics of doing this would : > : involve using pmap_mapdev() to map in the range that is specific to each : > : function, and then hang this information off of the pcicfg structure. : > : It's a bit hackish, yes, but it does seem to work in tests that a : > : colleague of mine has done. : > : > Why not just have the bridge do a bus_alloc_resource for those things? : > That would cause the pmap_mamdev() to happen behind the scenes. We : > already do a number of things like this in the CardBus driver, but on : > a smaller scale. : > : > But is there really a reason we need pcie_*_config routines? wouldn't : > the pcib_* routines do the same job nicely? They are already : > virtualized so that we can plug in the pcie bridge functionality to : > the existing bridge drivers if there is a pcie structure allocated to : > the pcicfg. Why invent an interface that we know we're going to : > deprecate in short order when the existing interface can be used. : > : > In the pci_pci.c code, we could add a couple of ifs in : > pcib_{read,write}_config if the bridge supports it, for example. : > : > Warner : : First, doing this the Right Way is not going to happen for 5.x. I'm : just trying to define an API to bridge us over for the short term. : There is no emulation shim defined for the extended config space, so : either we support it or we don't. As as I said, there are already : devices showing up that want to use the extended registers. : : Second, I'm trying to approach this in the least disruptive manner. : Yes, it could be abstracted so that pci_config_read|write() would : do the right things, but that would add risk to a whole lot of code : that we don't want to rototill at the moment. You asked how it should be done. I provided an opinion on how do to it. There's no reason to get grumpy when the opinion differs from what you wanted to hear. I offered my opinion about how to do this right. Maybe if you were to provide a more fleshed out design of what you are trying to achieve, it would be easier to provide feedback. Otherwise, I'm left to guess at what you have in mind and have you get mad at me when I don't do a good job at it. Warner From owner-freebsd-arch@FreeBSD.ORG Sun Aug 1 21:25:20 2004 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 D899F16A4CE for ; Sun, 1 Aug 2004 21:25:20 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8094243D55 for ; Sun, 1 Aug 2004 21:25:20 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.201] ([192.168.0.201]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i71LWdeB031727; Sun, 1 Aug 2004 15:32:39 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <410D5F45.1060902@samsco.org> Date: Sun, 01 Aug 2004 15:23:17 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.1) Gecko/20040801 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <61725.1091393254@critter.freebsd.dk> In-Reply-To: <61725.1091393254@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: arch@freebsd.org Subject: Re: PCI-Express support 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, 01 Aug 2004 21:25:21 -0000 Poul-Henning Kamp wrote: > In message <410D52B1.2010807@samsco.org>, Scott Long writes: > > >>>>Adding this for 5.3 is feasible, I think, and doesn't add a whole lot >>>>of risk. >>> >>> >>>OK, who are you and what have you done to Scott Long ? >>> >>>Scott would never even think about suggesting something like this two >>>weeks before we lock down the tree for a -stable branching. >> >>To answer you and Warner, this is functionality that is optional and has >>little risk to the existing infrastructure. John has done a great job >>with abstracting the low-level interrupt drivers, and this would just be >>another one of those. The support would be marked as *experimental*, >>but with the API in place it would give us more freedom to make it >>happen. Intel is pushing really hard to get adoption of this stuff in >>the small/medium size server area, and 5.x is going to suffer if it's >>not there. > > > I *really* want us to get 5-stable branched and moving. If it is as > optional as you say now, it can be added downstream once it has been > baked out in -current. > > Please, Let us concentrate on getting 5-stable branched and made > sensible. > Agreed, and I'm looking for things besides stability that are going to bite us in the near future. 6.0 likely won't happen for 12-months after 5.3 at an absolute minimum, and I don't want PCI-E support to turn into something like Cardbus is with 4.x vs 5.x. Please trust me that I'll abort this if it turns too ugly. I'm just trying to solicit technical advice right now so that if it does happen, it happens right. Scott From owner-freebsd-arch@FreeBSD.ORG Mon Aug 2 01:27:19 2004 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 C0D4C16A4CE for ; Mon, 2 Aug 2004 01:27:19 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35CED43D4C for ; Mon, 2 Aug 2004 01:27:19 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i721OYs9001230; Sun, 1 Aug 2004 19:24:39 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 01 Aug 2004 19:25:04 -0600 (MDT) Message-Id: <20040801.192504.98673359.imp@bsdimp.com> To: scottl@samsco.org From: "M. Warner Losh" In-Reply-To: <410D5F45.1060902@samsco.org> References: <61725.1091393254@critter.freebsd.dk> <410D5F45.1060902@samsco.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: phk@phk.freebsd.dk Subject: Re: PCI-Express support 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, 02 Aug 2004 01:27:19 -0000 In message: <410D5F45.1060902@samsco.org> Scott Long writes: : Agreed, and I'm looking for things besides stability that are going to : bite us in the near future. 6.0 likely won't happen for 12-months : after 5.3 at an absolute minimum, and I don't want PCI-E support to : turn into something like Cardbus is with 4.x vs 5.x. A big part of why CardBus evolved the way it did was because it depended on pci extensions that Mike Smith explicitly said he wasn't going to back port. Later, it was because of the acpi support in current that wasn't in stable (most modern laptops do not operate correctly with cardbus cards if you don't use acpi). Since the changes were extensive and all over the tree, it was hard to back port. Also, there was much optimism about the possibility of a quick 5.0, which evolved the way we all know. I think that we should learn from this history that we should be less afraid to back port when there's a highly anticipated feature. We should be as pessimistic as possible when guessing the date for 6.0 for the purposes of deciding if something should go into the tree. Eg, if we think that we can do 6.0 on a certain date, we should add a year or two to that when deciding to back port or not. Had we applied that rule with the CardBus code, we'd have back ported things w/o hesitation. In fact, there was a preliminary port to -stable at the time we branched, and that just wasn't kept up to date. We started doing major changes too quickly, which made it harder to back port. Anyway, I just wanted to speak up from my perspective from CardBus. Warner From owner-freebsd-arch@FreeBSD.ORG Wed Aug 4 18:13:28 2004 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 EE64216A4CE for ; Wed, 4 Aug 2004 18:13:28 +0000 (GMT) Received: from web14828.mail.yahoo.com (web14828.mail.yahoo.com [216.136.225.230]) by mx1.FreeBSD.org (Postfix) with SMTP id CC0EB43D45 for ; Wed, 4 Aug 2004 18:13:28 +0000 (GMT) (envelope-from rosti_bsd@yahoo.com) Message-ID: <20040804181328.64586.qmail@web14828.mail.yahoo.com> Received: from [212.143.154.227] by web14828.mail.yahoo.com via HTTP; Wed, 04 Aug 2004 11:13:28 PDT Date: Wed, 4 Aug 2004 11:13:28 -0700 (PDT) From: Rostislav Krasny To: freebsd-arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: again question about "IRQ 2 problem" 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: Wed, 04 Aug 2004 18:13:29 -0000 Hello all. My question is about "IRQ 2 problem" that have been already discussed here. You can find that discussion in the "IRQ 2 problem" thread there: http://lists.freebsd.org/pipermail/freebsd-arch/2003-December/thread.html http://lists.freebsd.org/pipermail/freebsd-arch/2004-January/thread.html This problem wasn't fixed in the 5.2-RELEASE and in the 5.2.1-RELEASE. In recently installed 5.2-CURRENT-20040804-SESNAP snapshot this problem isn't fixed as well. Would this problem be fixed in the 5.3-RELEASE? I'm asking about that also because the 5.2-CURRENT will be freezed in about 2 weeks from now. Forgive me if my question (that I already asked here) annoys you. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail From owner-freebsd-arch@FreeBSD.ORG Wed Aug 4 18:23:23 2004 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 6EBBD16A4CE for ; Wed, 4 Aug 2004 18:23:23 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A2BC43D41 for ; Wed, 4 Aug 2004 18:23:23 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 1075 invoked from network); 4 Aug 2004 18:23:23 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail1.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 4 Aug 2004 18:23:22 -0000 Received: from hydrogen.funkthat.com (gxwfwn@localhost.funkthat.com [127.0.0.1])i74INMuU057941 for ; Wed, 4 Aug 2004 11:23:22 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i74INMUU057940 for freebsd-arch@freebsd.org; Wed, 4 Aug 2004 11:23:22 -0700 (PDT) Date: Wed, 4 Aug 2004 11:23:21 -0700 From: John-Mark Gurney To: freebsd-arch@freebsd.org Message-ID: <20040804182321.GY991@funkthat.com> Mail-Followup-To: freebsd-arch@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Subject: install_and_reboot target for kernel's... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2004 18:23:23 -0000 I propose to add a install_and_reboot (if someone has a better name I'm open to suggestions). It installs the kernel, and then using nextboot will set to boot the freshly installed kernel, and then reboot the machine. I normally use it as: make install_and_reboot KERNEL=kernel.test Patch follows: Index: conf/kern.post.mk =================================================================== RCS file: /usr/src/FreeBSD/src/sys/conf/kern.post.mk,v retrieving revision 1.68 diff -u -r1.68 kern.post.mk --- conf/kern.post.mk 27 Jun 2004 23:03:43 -0000 1.68 +++ conf/kern.post.mk 4 Aug 2004 17:14:55 -0000 @@ -29,6 +29,9 @@ .ORDER: kernel-install modules-install +install_and_reboot: install + nextboot -k ${KERNEL} && shutdown -r now + kernel-all: ${KERNEL_KO} kernel-cleandir: kernel-clean -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Wed Aug 4 19:05:41 2004 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 CA2F716A4CE for ; Wed, 4 Aug 2004 19:05:41 +0000 (GMT) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DE0043D2F for ; Wed, 4 Aug 2004 19:05:41 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.13.0/8.13.0) with ESMTP id i74J5dsn014699; Wed, 4 Aug 2004 15:05:40 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20040804182321.GY991@funkthat.com> References: <20040804182321.GY991@funkthat.com> Date: Wed, 4 Aug 2004 15:05:38 -0400 To: John-Mark Gurney , freebsd-arch@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: Re: install_and_reboot target for kernel's... 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: Wed, 04 Aug 2004 19:05:41 -0000 At 11:23 AM -0700 8/4/04, John-Mark Gurney wrote: >I propose to add a install_and_reboot (if someone has a better name I'm >open to suggestions). It installs the kernel, and then using nextboot >will set to boot the freshly installed kernel, and then reboot the machine. > >I normally use it as: >make install_and_reboot KERNEL=kernel.test > >Patch follows: >Index: conf/kern.post.mk >=================================================================== >RCS file: /usr/src/FreeBSD/src/sys/conf/kern.post.mk,v >retrieving revision 1.68 >diff -u -r1.68 kern.post.mk >--- conf/kern.post.mk 27 Jun 2004 23:03:43 -0000 1.68 >+++ conf/kern.post.mk 4 Aug 2004 17:14:55 -0000 >@@ -29,6 +29,9 @@ > > .ORDER: kernel-install modules-install > >+install_and_reboot: install >+ nextboot -k ${KERNEL} && shutdown -r now >+ Hardly seems worth it. Create a script "iark": #!/bin/sh cd /usr/src && make installkernel KERNEL=$1 && nextboot -k ${KERNEL} && reboot (aside: I remember someone telling me that it makes more sense to just type 'reboot' than 'shutdown -r now'. If you do add the target, don't you want it to depend on "installkernel" and not "install"?) This way you end up with even less typing: iark kernel.test I'd actually spruce up the script a bit more than that, if it were me... Just my 2 cents. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Wed Aug 4 20:05:42 2004 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 54C2916A4CF for ; Wed, 4 Aug 2004 20:05:41 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D5AA43D45 for ; Wed, 4 Aug 2004 20:05:38 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 27863 invoked from network); 4 Aug 2004 20:05:37 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 4 Aug 2004 20:05:37 -0000 Received: from hydrogen.funkthat.com (sxeryj@localhost.funkthat.com [127.0.0.1])i74K5auU059472; Wed, 4 Aug 2004 13:05:37 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i74K5a9X059471; Wed, 4 Aug 2004 13:05:36 -0700 (PDT) Date: Wed, 4 Aug 2004 13:05:35 -0700 From: John-Mark Gurney To: Garance A Drosihn Message-ID: <20040804200535.GZ991@funkthat.com> Mail-Followup-To: Garance A Drosihn , freebsd-arch@freebsd.org References: <20040804182321.GY991@funkthat.com> 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 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: freebsd-arch@freebsd.org Subject: Re: install_and_reboot target for kernel's... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2004 20:05:42 -0000 Garance A Drosihn wrote this message on Wed, Aug 04, 2004 at 15:05 -0400: > Hardly seems worth it. Create a script "iark": > #!/bin/sh > cd /usr/src && make installkernel KERNEL=$1 && nextboot -k > ${KERNEL} && reboot > > (aside: I remember someone telling me that it makes more sense > to just type 'reboot' than 'shutdown -r now'. If you do add > the target, don't you want it to depend on "installkernel" and > not "install"?) > > This way you end up with even less typing: > iark kernel.test > > I'd actually spruce up the script a bit more than that, if it > were me... Just my 2 cents. a) not everyone knows about nextboot, putting it in the makefile and documenting it will allow more people to know about it b) there are lots of doesn't seem worth it scripts that exist in the base system.. we don't require people to do: make installkernel installmodules instead of make install do we? the reason it depends upon install and not just installkernel is that we want the modules installed too... reboot vs. shutdown: I don't care, I just normally use shutdown, and we could even automate the shutdown message that gets logged to specify that we are rebooting to a new test kernel, which reboot doesn't.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Wed Aug 4 20:20:22 2004 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 3ED4116A4D1 for ; Wed, 4 Aug 2004 20:20:22 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EC7043D58 for ; Wed, 4 Aug 2004 20:20:20 +0000 (GMT) (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.10/8.12.10) with ESMTP id i74KKJOF030454; Wed, 4 Aug 2004 13:20:19 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i74KKJ9B030453; Wed, 4 Aug 2004 13:20:19 -0700 Date: Wed, 4 Aug 2004 13:20:19 -0700 From: Brooks Davis To: Garance A Drosihn Message-ID: <20040804202019.GD10063@Odin.AC.HMC.Edu> References: <20040804182321.GY991@funkthat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hxkXGo8AKqTJ+9QI" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i cc: John-Mark Gurney cc: freebsd-arch@freebsd.org Subject: Re: install_and_reboot target for kernel's... 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: Wed, 04 Aug 2004 20:20:22 -0000 --hxkXGo8AKqTJ+9QI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 04, 2004 at 03:05:38PM -0400, Garance A Drosihn wrote: > (aside: I remember someone telling me that it makes more sense > to just type 'reboot' than 'shutdown -r now'. Not if you actually like your data. "reboot" kills all your processes with a blunt object while "shutdown -r now" allows processes that things like databases to shut down correctly before wacking the remaining hangers on with a blunt object. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --hxkXGo8AKqTJ+9QI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBEUUCXY6L6fI4GtQRAvacAJ9urTR40huvaC92P8pTUthorvE2kwCgjsYu XnbRxlA9oVTbDa7MtZIZFtw= =jUuP -----END PGP SIGNATURE----- --hxkXGo8AKqTJ+9QI-- From owner-freebsd-arch@FreeBSD.ORG Wed Aug 4 21:10:53 2004 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 06A3316A4CE for ; Wed, 4 Aug 2004 21:10:53 +0000 (GMT) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E6A243D60 for ; Wed, 4 Aug 2004 21:10:52 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.13.0/8.13.0) with ESMTP id i74LAoKn009853; Wed, 4 Aug 2004 17:10:51 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20040804200535.GZ991@funkthat.com> References: <20040804182321.GY991@funkthat.com> <20040804200535.GZ991@funkthat.com> Date: Wed, 4 Aug 2004 17:10:50 -0400 To: John-Mark Gurney From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: freebsd-arch@freebsd.org Subject: Re: install_and_reboot target for kernel's... 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: Wed, 04 Aug 2004 21:10:53 -0000 At 1:05 PM -0700 8/4/04, John-Mark Gurney wrote: >b) there are lots of doesn't seem worth it scripts that exist > in the base system.. we don't require people to do: > make installkernel installmodules > instead of make install do we? > >the reason it depends upon install and not just installkernel >is that we want the modules installed too... Hmm. 'make install' does a lot more than just installing modules, does it not? Besides, aren't modules installed as part of installkernel? (I always thought they were, but I guess I do not really know for sure, and I do not feel like checking into it right now). Make install is more like installworld combined with installkernel, since it will do: for entry in share/info include lib libexec bin \ games gnu kerberos5 rescue sbin secure share sys \ usr.bin usr.sbin etc; do [...] make install DIRPRFX=$edir/; done I personally don't really care what targets you add, so do not take my comments too seriously. I am just trying to think up some questions to make sure the right steps are being proposed. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Wed Aug 4 21:12:47 2004 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 31B9916A549 for ; Wed, 4 Aug 2004 21:12:47 +0000 (GMT) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0467F43D5E for ; Wed, 4 Aug 2004 21:12:47 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 10853 invoked from network); 4 Aug 2004 21:12:46 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 4 Aug 2004 21:12:46 -0000 Received: from 10.50.40.208 (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i74LCeQH036297; Wed, 4 Aug 2004 17:12:43 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org, John-Mark Gurney Date: Wed, 4 Aug 2004 17:11:33 -0400 User-Agent: KMail/1.6 References: <20040804182321.GY991@funkthat.com> <20040804200535.GZ991@funkthat.com> In-Reply-To: <20040804200535.GZ991@funkthat.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408041711.33217.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Garance A Drosihn Subject: Re: install_and_reboot target for kernel's... 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: Wed, 04 Aug 2004 21:12:48 -0000 On Wednesday 04 August 2004 04:05 pm, John-Mark Gurney wrote: > Garance A Drosihn wrote this message on Wed, Aug 04, 2004 at 15:05 -0400: > > Hardly seems worth it. Create a script "iark": > > #!/bin/sh > > cd /usr/src && make installkernel KERNEL=$1 && nextboot -k > > ${KERNEL} && reboot > > > > (aside: I remember someone telling me that it makes more sense > > to just type 'reboot' than 'shutdown -r now'. If you do add > > the target, don't you want it to depend on "installkernel" and > > not "install"?) > > > > This way you end up with even less typing: > > iark kernel.test > > > > I'd actually spruce up the script a bit more than that, if it > > were me... Just my 2 cents. > > a) not everyone knows about nextboot, putting it in the makefile and > documenting it will allow more people to know about it That I debate. :) Having a bikeshed on arch@ might let more people know about it, but documenting things doesn't always make them more widely known. There's a reason they are called FAQs. Also, the intended audience for this target is mostly developers, and they probably already know about nextboot. > b) there are lots of doesn't seem worth it scripts that exist in the > base system.. we don't require people to do: > make installkernel installmodules instead of make install do we? > > the reason it depends upon install and not just installkernel is that > we want the modules installed too... The confusion there is that he is using installkernel from /usr/src/Makefile which does a full kernel install including modules if needed. I'm not sure that this target is really a good idea given reboot vs. shutdown as well as using nextboot options (I would probably want to use nextboot -o "-s" -k test most of the time since I usually like to boot test kernels into single user so I can do simple testing before I unleash it on multiuser) means that by the time you add tweaks and hooks for the various different options you really haven't saved much typing. -- 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 Aug 5 15:50:44 2004 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 EAB7616A57D for ; Thu, 5 Aug 2004 15:50:44 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5CA943D70 for ; Thu, 5 Aug 2004 15:50:25 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 30516 invoked from network); 5 Aug 2004 15:50:25 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 5 Aug 2004 15:50:24 -0000 Received: from 10.50.40.208 (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i75Fo4Yu042446; Thu, 5 Aug 2004 11:50:12 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-arch@FreeBSD.org Date: Thu, 5 Aug 2004 11:50:08 -0400 User-Agent: KMail/1.6 References: <20040804181328.64586.qmail@web14828.mail.yahoo.com> In-Reply-To: <20040804181328.64586.qmail@web14828.mail.yahoo.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200408051149.35872.jhb@FreeBSD.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Rostislav Krasny Subject: Re: again question about "IRQ 2 problem" 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, 05 Aug 2004 15:50:45 -0000 On Wednesday 04 August 2004 02:13 pm, Rostislav Krasny wrote: > Hello all. > > My question is about "IRQ 2 problem" that have been already discussed > here. You can find that discussion in the "IRQ 2 problem" thread there: > http://lists.freebsd.org/pipermail/freebsd-arch/2003-December/thread.html > http://lists.freebsd.org/pipermail/freebsd-arch/2004-January/thread.html > > This problem wasn't fixed in the 5.2-RELEASE and in the 5.2.1-RELEASE. > In recently installed 5.2-CURRENT-20040804-SESNAP snapshot this problem > isn't fixed as well. Would this problem be fixed in the 5.3-RELEASE? > I'm asking about that also because the 5.2-CURRENT will be freezed in > about 2 weeks from now. > > Forgive me if my question (that I already asked here) annoys you. This should be fixed in rev 1.35 of sys/kern/subr_rman.c Please let me know if it is not, thanks! -- 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 Aug 5 20:39:35 2004 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 951ED16A4CE; Thu, 5 Aug 2004 20:39:35 +0000 (GMT) Received: from spiff.melthusia.org (spiff.melthusia.org [207.67.244.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FD1E43D1F; Thu, 5 Aug 2004 20:39:35 +0000 (GMT) (envelope-from gtetlow@spiff.melthusia.org) Received: from spiff.melthusia.org (gtetlow@localhost [127.0.0.1]) by spiff.melthusia.org (8.12.10/8.12.10) with ESMTP id i75KapGc093642; Thu, 5 Aug 2004 13:36:51 -0700 (PDT) (envelope-from gtetlow@spiff.melthusia.org) Received: (from gtetlow@localhost) by spiff.melthusia.org (8.12.10/8.12.10/Submit) id i75Kap4d093641; Thu, 5 Aug 2004 13:36:51 -0700 (PDT) (envelope-from gtetlow) Date: Thu, 5 Aug 2004 13:36:51 -0700 From: Gordon Tetlow To: John Baldwin Message-ID: <20040805203650.GN27045@spiff.melthusia.org> References: <20040804182321.GY991@funkthat.com> <20040804200535.GZ991@funkthat.com> <200408041711.33217.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RNRUMt0ZF5Yaq/Aq" Content-Disposition: inline In-Reply-To: <200408041711.33217.jhb@FreeBSD.org> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . User-Agent: Mutt/1.5.6i cc: John-Mark Gurney cc: Garance A Drosihn cc: freebsd-arch@freebsd.org Subject: nextboot(8) was Re: install_and_reboot target for kernel's... 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, 05 Aug 2004 20:39:35 -0000 --RNRUMt0ZF5Yaq/Aq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 04, 2004 at 05:11:33PM -0400, John Baldwin wrote: > On Wednesday 04 August 2004 04:05 pm, John-Mark Gurney wrote: > > > > a) not everyone knows about nextboot, putting it in the makefile and > > documenting it will allow more people to know about it >=20 > That I debate. :) Having a bikeshed on arch@ might let more people know = about=20 > it, but documenting things doesn't always make them more widely known. = =20 > There's a reason they are called FAQs. Also, the intended audience for t= his=20 > target is mostly developers, and they probably already know about nextboo= t. As the author of the current incarnation of nextboot, I was surprised with the number of people on IRC that said things like "I wish I could boot a kernel for a single run, and if it crashed it would automagically revert to the previous kernel." Well, this is exactly what nexboot does since we have write support in the loader. So I think there are a fair number of developers that aren't familiar with what nextboot does. -gordon --RNRUMt0ZF5Yaq/Aq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBEppiRu2t9DV9ZfsRArf9AJ4+32m+7BbyJyfmevKW5GNrdkkcbQCgsZuC KBofVxJUeCHvi+QE5TvdqiE= =Gq5/ -----END PGP SIGNATURE----- --RNRUMt0ZF5Yaq/Aq-- From owner-freebsd-arch@FreeBSD.ORG Fri Aug 6 18:48:11 2004 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 CF56D16A4F5 for ; Fri, 6 Aug 2004 18:48:11 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E44143D2F for ; Fri, 6 Aug 2004 18:48:09 +0000 (GMT) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mailhost.stack.nl (Postfix) with ESMTP id 1A7CA1F173 for ; Fri, 6 Aug 2004 20:48:08 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id EBEA52286E; Fri, 6 Aug 2004 20:48:07 +0200 (CEST) Date: Fri, 6 Aug 2004 20:48:07 +0200 From: Jilles Tjoelker To: freebsd-arch@freebsd.org Message-ID: <20040806184807.GB4675@stack.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 5.2.1-RELEASE-p9 i386 User-Agent: Mutt/1.5.6i Subject: _PATH_DEFPATH, _PATH_STDPATH, etc. 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, 06 Aug 2004 18:48:12 -0000 In $FreeBSD: src/include/paths.h,v 1.24 2003/06/29 18:35:36 gordon Exp $, the following PATHs are defined: /* Default search path. */ #define _PATH_DEFPATH "/usr/bin:/bin" /* All standard utilities path. */ #define _PATH_STDPATH \ "/usr/bin:/bin:/usr/sbin:/sbin:" /* Locate system binaries */ #define _PATH_SYSPATH \ "/sbin:/usr/sbin" and #ifdef RESCUE #define _PATH_DEFPATH "/rescue:/usr/bin:/bin" #define _PATH_STDPATH "/rescue:/usr/bin:/bin:/usr/sbin:/sbin" #define _PATH_SYSPATH "/rescue:/sbin:/usr/sbin" I think it is not a good idea to have the current directory in _PATH_STDPATH, which is returned by confstr(_CS_PATH) and getconf PATH. Those are defined by POSIX to return a path that will find all standard utilities. Also, _PATH_STDPATH is used in many places as a default path for the root user, although in most of those cases, it is overwritten by explicit PATH assignments in files like /etc/crontab and /etc/login.conf. NetBSD cleared up the difference between _PATH_DEFPATH and _PATH_STDPATH in 1998: http://cvsweb.netbsd.org/bsdweb.cgi/src/include/paths.h.diff?r1=1.10&r2=1.11 and NetBSD PR #4304 _PATH_SYSPATH is used by fsck(8) and mount(8) to find filesystem-specific versions. On a related note, why is md5(1) in /sbin? -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Fri Aug 6 22:43:18 2004 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 D1B9B16A4CF for ; Fri, 6 Aug 2004 22:43:18 +0000 (GMT) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CF5343D49 for ; Fri, 6 Aug 2004 22:43:18 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 20215 invoked from network); 6 Aug 2004 22:43:18 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail4.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 6 Aug 2004 22:43:17 -0000 Received: from hydrogen.funkthat.com (mrgrip@localhost.funkthat.com [127.0.0.1])i76MhGuU002172; Fri, 6 Aug 2004 15:43:17 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i76MhGp3002170; Fri, 6 Aug 2004 15:43:16 -0700 (PDT) Date: Fri, 6 Aug 2004 15:43:16 -0700 From: John-Mark Gurney To: freebsd-arch@freebsd.org Message-ID: <20040806224316.GB991@funkthat.com> Mail-Followup-To: freebsd-arch@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Subject: valid dup lock logic for witness X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2004 22:43:19 -0000 --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I have been working on kqueue, and to support kq in kq, I need to obtain two kq locks (both of the same type) at the same time. Normally this can cause a deadlock, but using a proper lock ordering strategy, it can be avoided. In the kq case, I chose to aquire a kq global lock before acquiring multiple kq locks. (In the proc case, jhb said you aquire the child's before the parents.) Mutexs have the flag MTX_DUPOK that notify witness that duplicate locks are ok, but this can hide other problems (and in fact would have in my testing). I have created a patch that lets you inform witness the a duplicate lock is valid as long as you hold another lock. The only run time change is that when a duplicate lock is found, it will run through another table to verify it's ok before printing out the back trace. Anyone have objections to this? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="subr_witness.diff" Index: subr_witness.c =================================================================== RCS file: /usr/src/FreeBSD/src/sys/kern/subr_witness.c,v retrieving revision 1.176 diff -u -r1.176 subr_witness.c --- subr_witness.c 10 Jul 2004 21:42:16 -0000 1.176 +++ subr_witness.c 5 Aug 2004 21:22:22 -0000 @@ -155,6 +155,13 @@ struct lock_class *w_class; }; +struct witness_order_dup_list_entry { + const char *w_name_dup; + struct lock_class *w_class_dup; + const char *w_name_parent; + struct lock_class *w_class_parent; +}; + #ifdef BLESSING static int blessed(struct witness *, struct witness *); #endif @@ -183,6 +190,7 @@ static void witness_lock_list_free(struct lock_list_entry *lle); static struct lock_instance *find_instance(struct lock_list_entry *lock_list, struct lock_object *lock); +static int dup_lock_ok(struct lock_list_entry *lock_list); static void witness_list_lock(struct lock_instance *instance); #ifdef DDB static void witness_list(struct thread *td); @@ -366,6 +374,11 @@ { NULL, NULL } }; +static struct witness_order_dup_list_entry dup_order_lists[] = { + { "kqueue", &lock_class_mtx_sleep, + "kqueue order", &lock_class_mtx_sleep }, +}; + #ifdef BLESSING /* * Pairs of locks which have been blessed @@ -764,6 +777,8 @@ if (w1 == w) { if (w->w_same_squawked || (lock->lo_flags & LO_DUPOK)) return; + if (dup_lock_ok(*lock_list)) + return; w->w_same_squawked = 1; printf("acquiring duplicate lock of same type: \"%s\"\n", lock->lo_type); @@ -1692,6 +1707,32 @@ return (instance); } return (NULL); +} + +static int +dup_lock_ok(struct lock_list_entry *lock_list) +{ + struct lock_instance *lock; + struct lock_object *lo; + struct witness_order_dup_list_entry *wdup; + int i, j; + + for (i = 0; i < sizeof dup_order_lists / sizeof *dup_order_lists; i++) { + lock = &lock_list->ll_children[lock_list->ll_count - 1]; + wdup = &dup_order_lists[i]; + lo = lock->li_lock; + if (strcmp(lo->lo_type, wdup->w_name_dup) == 0 && + lo->lo_class == wdup->w_class_dup) { + for (j = lock_list->ll_count - 1; j >= 0; j--) { + lo = lock_list->ll_children[j].li_lock; + if (strcmp(lo->lo_type, wdup->w_name_parent) == + 0 && lo->lo_class == wdup->w_class_parent) + return 1; + } + } + } + + return 0; } static void --T4sUOijqQbZv57TR-- From owner-freebsd-arch@FreeBSD.ORG Sat Aug 7 10:55:22 2004 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 0696F16A4CE for ; Sat, 7 Aug 2004 10:55:22 +0000 (GMT) Received: from lakermmtao06.cox.net (lakermmtao06.cox.net [68.230.240.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A0A743D31 for ; Sat, 7 Aug 2004 10:55:21 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.71.51]) by lakermmtao06.cox.net (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709) with ESMTP id <20040807105520.FODV8791.lakermmtao06.cox.net@dolphin.local.net>; Sat, 7 Aug 2004 06:55:20 -0400 Received: from dolphin.local.net (localhost.local.net [127.0.0.1]) by dolphin.local.net (8.13.1/8.13.1) with ESMTP id i77AtKXw022925; Sat, 7 Aug 2004 05:55:20 -0500 (CDT) (envelope-from conrads@dolphin.local.net) Received: (from conrads@localhost) by dolphin.local.net (8.13.1/8.13.1/Submit) id i77AtKQO022912; Sat, 7 Aug 2004 05:55:20 -0500 (CDT) (envelope-from conrads) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20040804182321.GY991@funkthat.com> Date: Sat, 07 Aug 2004 05:55:20 -0500 (CDT) Organization: A Rag-Tag Band of Drug-Crazed Hippies From: "Conrad J. Sabatier" To: John-Mark Gurney cc: freebsd-arch@freebsd.org Subject: Re: install_and_reboot target for kernel's... X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: conrads@cox.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2004 10:55:22 -0000 On 04-Aug-2004 John-Mark Gurney wrote: > I propose to add a install_and_reboot (if someone has a better name > I'm > open to suggestions). It installs the kernel, and then using > nextboot > will set to boot the freshly installed kernel, and then reboot the > machine. > > I normally use it as: > make install_and_reboot KERNEL=kernel.test > > Patch follows: > Index: conf/kern.post.mk > =================================================================== > RCS file: /usr/src/FreeBSD/src/sys/conf/kern.post.mk,v > retrieving revision 1.68 > diff -u -r1.68 kern.post.mk > --- conf/kern.post.mk 27 Jun 2004 23:03:43 -0000 1.68 > +++ conf/kern.post.mk 4 Aug 2004 17:14:55 -0000 > @@ -29,6 +29,9 @@ > > .ORDER: kernel-install modules-install > > +install_and_reboot: install > + nextboot -k ${KERNEL} && shutdown -r now > + > kernel-all: ${KERNEL_KO} > > kernel-cleandir: kernel-clean Wouldn't it be a good idea to also include '-o "-s"' in the nextboot command line? -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-arch@FreeBSD.ORG Sat Aug 7 15:35:44 2004 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 18D8916A4D1 for ; Sat, 7 Aug 2004 15:35:44 +0000 (GMT) Received: from web14828.mail.yahoo.com (web14828.mail.yahoo.com [216.136.225.230]) by mx1.FreeBSD.org (Postfix) with SMTP id C750743D5E for ; Sat, 7 Aug 2004 15:35:43 +0000 (GMT) (envelope-from rosti_bsd@yahoo.com) Message-ID: <20040807153543.34382.qmail@web14828.mail.yahoo.com> Received: from [212.143.154.227] by web14828.mail.yahoo.com via HTTP; Sat, 07 Aug 2004 08:35:43 PDT Date: Sat, 7 Aug 2004 08:35:43 -0700 (PDT) From: Rostislav Krasny To: John Baldwin In-Reply-To: <200408051149.35872.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-arch@FreeBSD.org Subject: Re: again question about "IRQ 2 problem" 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: Sat, 07 Aug 2004 15:35:44 -0000 --- John Baldwin wrote: > This should be fixed in rev 1.35 of sys/kern/subr_rman.c Please let > me know if it is not, thanks! Thank you very much! The "IRQ 2 problem" is fixed now and that device (ed1) is working. The only strange thing is what I see in 'dmesg -a' output after booting in verbose mode (the first "adv1:..." line): isa_probe_children: probing PnP devices adv1: Invalid baseport of 0x200 specified. Nearest valid baseport is 0x210. Failing probe. ed1: at port 0x200-0x21f irq 5 on isa0 ed1: [GIANT-LOCKED] ed1: bpf attached ed1: Ethernet address: 00:00:21:82:25:03 type NE2000 (16 bit) adv1: Invalid baseport of 0x0 specified. Nearest valid baseport is 0x100. Failing probe. adv1: Invalid baseport of 0x40 specified. Nearest valid baseport is 0x100. Failing probe. adv1: Invalid baseport of 0x70 specified. Nearest valid baseport is 0x100. Failing probe. unknown: can't assign resources (port) unknown: at port 0x60 on isa0 adv1: Invalid baseport of 0x61 specified. Nearest valid baseport is 0x100. Failing probe. unknown: failed to probe at port 0x61 on isa0 adv1: Invalid baseport of 0xf0 specified. Nearest valid baseport is 0x100. Failing probe. unknown: can't assign resources (port) unknown: at port 0x4d0-0x4d1 on isa0 unknown: can't assign resources (port) unknown: at port 0x208-0x20f on isa0 unknown: can't assign resources (port) unknown: at port 0x3f8-0x3ff on isa0 unknown: can't assign resources (port) unknown: at port 0x3f2-0x3f5 on isa0 unknown: can't assign resources (port) unknown: at port 0x378-0x37f on isa0 unknown: can't assign resources (port) unknown: at port 0x2f8-0x2ff on isa0 Device configuration finished. procfs registered The 0x200 port is used by the ed1 device. Is there any potential problem? Why probing of that port is failed? I can send you the full 'dmesg -a' output if you need it. Thanks again for your work. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail