From owner-freebsd-smp Mon Mar 25 8:31:46 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mail.hiwaay.net (fly.hiwaay.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id BDD6037B416 for ; Mon, 25 Mar 2002 08:31:40 -0800 (PST) Received: from hlwatts (rbn1-216-180-76-148.adsl.HiWAAY.net [216.180.76.148]) by mail.hiwaay.net (8.12.2/8.12.2) with SMTP id g2PGVbYd030693 for ; Mon, 25 Mar 2002 10:31:38 -0600 (CST) Message-ID: <000b01c1d41b$6bdaee40$944cb4d8@hiwaay.net> From: "Ed Watts" To: Subject: SGI Visual Workstation 330 Date: Sun, 24 Mar 2002 14:45:31 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C1D342.8C6954A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C1D342.8C6954A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I have a SGI M25D motherboard taken from a discontinued Visual Workstation 330. Does FreeBSD support SMP on this motherboard? I was looking for your HTML / FTP archive to no avail so I e-mailed the link. Hope that was right. ------=_NextPart_000_0007_01C1D342.8C6954A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have a SGI M25D motherboard taken from a = discontinued Visual=20 Workstation 330.
Does FreeBSD support SMP on this = motherboard?
I  was looking for your HTML / FTP archive = to no=20 avail so I e-mailed the link.
Hope that was right.
------=_NextPart_000_0007_01C1D342.8C6954A0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Mar 25 8:40:33 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mail14.speakeasy.net (mail14.speakeasy.net [216.254.0.214]) by hub.freebsd.org (Postfix) with ESMTP id 6DE7637B426 for ; Mon, 25 Mar 2002 08:40:17 -0800 (PST) Received: (qmail 20855 invoked from network); 25 Mar 2002 16:40:16 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail14.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 25 Mar 2002 16:40:16 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g2PGeuv82719; Mon, 25 Mar 2002 11:40:56 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 25 Mar 2002 11:40:18 -0500 (EST) From: John Baldwin To: Robert Watson Subject: Re: Giant instrumentation Cc: smp@FreeBSD.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 23-Mar-2002 Robert Watson wrote: > > On Thu, 21 Mar 2002, John Baldwin wrote: > >> Kelly Yancey implemented most of the syscall Giant instrumentation stuff >> I outlined in an earlier e-mail. I have since mostly finished it and >> changed a few things. Most of the changes were design changes so that >> the instrumentation stuff was as separated from the rest of the kernel >> (and thus easily condionitionally compiled out with minimal impact) as >> possible. Also, it now provides better support for handling other ABIs. >> It's not complete yet (it only has instrumentation for the native ABI at >> the moment) but I wanted to post this patch for feedback. I have tested >> it some and it is being tested some more on alpha and x86 at the moment. >> The patch can be found at: >> >> http://www.FreeBSD.org/~jhb/patches/giantvars.patch > > (2) Question: how easily does this framework extend to trap handling, such > as VM traps where we might similarly want to be able to instrument > entry to traps that might or might not want Giant? The current stuff > is pretty system-call specific in my reading, at least, in where it > gets the information. Similarly, could this framework be adapted for > use with interrupt/driver entry points? For trap handling, one could either use a static array in the various trap.c filfes or just use the earlier mtx_lock_giant/mtx_unlock_giant API directly in the code. Trap handlers are not very wide spread and already have a single point of exit for user traps. > (4) One down-side to this approach is that it's not possible to push the > instrumentation point down below the system call level. For example, > suppose we're confident that the first level code in the various > generic file descriptor-based calls is correct, but we want to > continue to instrument Giant over the VFS but not over pipes. In such > a scenario, you could imagine something like the following: Since this code is for debugging, it is my opinion that it does not need to be as fine-grained and that a per-syscall granularity is sufficient. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Mar 25 8:40:39 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mail15.speakeasy.net (mail15.speakeasy.net [216.254.0.215]) by hub.freebsd.org (Postfix) with ESMTP id 324DC37B41B for ; Mon, 25 Mar 2002 08:40:23 -0800 (PST) Received: (qmail 8211 invoked from network); 25 Mar 2002 16:40:22 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail15.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 25 Mar 2002 16:40:22 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g2PGf2v82728; Mon, 25 Mar 2002 11:41:02 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020323041624.S90182@locore.ca> Date: Mon, 25 Mar 2002 11:40:24 -0500 (EST) From: John Baldwin To: Jake Burkholder Subject: Re: FreeBSD 4.5: Second CPU Not Working on Dell PowerEdge 1650 Cc: freebsd-smp@FreeBSD.ORG, Andy Isaacson Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 23-Mar-2002 Jake Burkholder wrote: > Apparently, On Fri, Mar 22, 2002 at 10:05:27AM -0500, > John Baldwin said words to the effect of; > >> >> On 22-Mar-2002 Andy Isaacson wrote: >> > On Thu, Mar 21, 2002 at 05:35:58PM -0800, Lars Eggert wrote: >> >> Barney Wolff wrote: >> >> > Remember that in computing, counting begins at 0. :) >> >> > You have 2 cpu's running fine. >> >> >> >> Since this has come up a few times already, maybe we should change the >> >> message to read: >> >> >> >> SMP: Another CPU (AP CPU #1) Launched! >> > >> > How about >> > SMP: AP CPU #1 Launched, 2 running >> > >> > Or just stick a "%d CPUs running" at the end of the launch loop. >> >> In current you get a 'FreeBSD/SMP: Multiprocessor system: X cpus' message >> during startup that is identical on all platforms. > > How about we remove both of these messages altogether and print identify > lines for all cpus in the system. They can even look something like > newbus device probes. Some folks would like CPU's to be proper new-bus devices. I wouldn't mind these types of messages. > cpu0: Sun Microsystems UltraSparc-II Processor (450.07 MHZ CPU) > cpu1: Sun Microsystems UltraSparc-II Processor (450.07 MHZ CPU) > cpu2: Sun Microsystems UltraSparc-II Processor (450.07 MHZ CPU) > cpu3: Sun Microsystems UltraSparc-II Processor (450.07 MHZ CPU) > nexus0: > > The SMP: AP CPU #%d Launched! message is dangerous because it is printed > before the non-boot cpus can safely acquire Giant; most architectures do > it wrong. Hmmmm. Well, we really need proper printf locking (which probably shouldn't use blocking locks). > Jake -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Mar 25 9:43:35 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mailhub.yumyumyum.org (dsl092-171-091.wdc1.dsl.speakeasy.net [66.92.171.91]) by hub.freebsd.org (Postfix) with SMTP id 9E36837B404 for ; Mon, 25 Mar 2002 09:43:32 -0800 (PST) Received: (qmail 15970 invoked from network); 25 Mar 2002 17:43:18 -0000 Received: from dsl092-171-091.wdc1.dsl.speakeasy.net (66.92.171.91) by dsl092-171-091.wdc1.dsl.speakeasy.net with SMTP; 25 Mar 2002 17:43:18 -0000 Date: Mon, 25 Mar 2002 12:43:18 -0500 (EST) From: Kenneth Culver To: Ed Watts Cc: freebsd-smp@FreeBSD.ORG Subject: Re: SGI Visual Workstation 330 In-Reply-To: <000b01c1d41b$6bdaee40$944cb4d8@hiwaay.net> Message-ID: <20020325124253.E15966-100000@alpha.yumyumyum.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > I have a SGI M25D motherboard taken from a discontinued Visual Workstation > 330. > Does FreeBSD support SMP on this motherboard? > I was looking for your HTML / FTP archive to no avail so I e-mailed the > link. > Hope that was right. > I don't even think FreeBSD supports running at all on this motherboard... Ken To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Mar 25 9:45:23 2002 Delivered-To: freebsd-smp@freebsd.org Received: from absinthe.carnagecopia.com (absinthe.carnagecopia.com [216.187.87.246]) by hub.freebsd.org (Postfix) with SMTP id 3FCCE37B417 for ; Mon, 25 Mar 2002 09:45:18 -0800 (PST) Received: (qmail 89409 invoked by uid 85); 25 Mar 2002 17:45:12 -0000 Received: from random@carnagecopia.com by absinthe.carnagecopia.com with qmail-scanner-1.03 (uvscan: v4.0.50/v4193. . Clean. Processed in 0.158406 secs); 25 Mar 2002 17:45:12 -0000 Received: from firewall-vancouver.goblinstudios.com (HELO workstation-61) (204.244.192.2) by absinthe.carnagecopia.com with SMTP; 25 Mar 2002 17:45:12 -0000 Date: Mon, 25 Mar 2002 09:44:40 -0800 From: Vincent Janelle To: Kenneth Culver Cc: hlwatts@hiwaay.net, freebsd-smp@FreeBSD.ORG Subject: Re: SGI Visual Workstation 330 Message-Id: <20020325094440.3bec515f.random@carnagecopia.com> In-Reply-To: <20020325124253.E15966-100000@alpha.yumyumyum.org> References: <000b01c1d41b$6bdaee40$944cb4d8@hiwaay.net> <20020325124253.E15966-100000@alpha.yumyumyum.org> Organization: Goblin Studios X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=.6x25ZQEsbuxugO" Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --=.6x25ZQEsbuxugO Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit This motherboard is not technically an IBM compatible PC, its more along the lines of an SGI workstation powered by intel processors. NT has to use a custom HAL to support it under windows, and linux has special support for it. Your best bet will probably be linux. On Mon, 25 Mar 2002 12:43:18 -0500 (EST) Kenneth Culver wrote: > > I have a SGI M25D motherboard taken from a discontinued Visual Workstation > > 330. > > Does FreeBSD support SMP on this motherboard? > > I was looking for your HTML / FTP archive to no avail so I e-mailed the > > link. > > Hope that was right. > > > I don't even think FreeBSD supports running at all on this motherboard... > > Ken > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message --=.6x25ZQEsbuxugO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) iD8DBQE8n2ILT+ow5T/THzQRAuuhAJ9DwfP4MGtjvzFkaBysAeGa3hnn5QCfX8Td k/nlMT8T5ZBc3ptEKufLaHs= =b+EG -----END PGP SIGNATURE----- --=.6x25ZQEsbuxugO-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Mar 25 9:50:14 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mailhub.yumyumyum.org (dsl092-171-091.wdc1.dsl.speakeasy.net [66.92.171.91]) by hub.freebsd.org (Postfix) with SMTP id F14C837B416 for ; Mon, 25 Mar 2002 09:50:06 -0800 (PST) Received: (qmail 16021 invoked from network); 25 Mar 2002 17:49:54 -0000 Received: from dsl092-171-091.wdc1.dsl.speakeasy.net (66.92.171.91) by dsl092-171-091.wdc1.dsl.speakeasy.net with SMTP; 25 Mar 2002 17:49:54 -0000 Date: Mon, 25 Mar 2002 12:49:54 -0500 (EST) From: Kenneth Culver To: Vincent Janelle Cc: hlwatts@hiwaay.net, Subject: Re: SGI Visual Workstation 330 In-Reply-To: <20020325094440.3bec515f.random@carnagecopia.com> Message-ID: <20020325124907.R15999-100000@alpha.yumyumyum.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > This motherboard is not technically an IBM compatible PC, its more along > the lines of an SGI workstation powered by intel processors. NT has to > use a custom HAL to support it under windows, and linux has special > support for it. Your best bet will probably be linux. Oh ok, I was under the impression that this was one of their MIPS machines... IT couldn't hurt to try FreeBSD on it... Ken > > On Mon, 25 Mar 2002 12:43:18 -0500 (EST) > Kenneth Culver wrote: > > > > I have a SGI M25D motherboard taken from a discontinued Visual Workstation > > > 330. > > > Does FreeBSD support SMP on this motherboard? > > > I was looking for your HTML / FTP archive to no avail so I e-mailed the > > > link. > > > Hope that was right. > > > > > I don't even think FreeBSD supports running at all on this motherboard... > > > > Ken > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-smp" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Mar 25 10: 2:46 2002 Delivered-To: freebsd-smp@freebsd.org Received: from pirx.hexapodia.org (pirx.hexapodia.org [208.42.114.113]) by hub.freebsd.org (Postfix) with ESMTP id 8688A37B41A for ; Mon, 25 Mar 2002 10:02:42 -0800 (PST) Received: by pirx.hexapodia.org (Postfix, from userid 22448) id E561EB404; Mon, 25 Mar 2002 12:02:39 -0600 (CST) Date: Mon, 25 Mar 2002 12:02:39 -0600 From: Andy Isaacson To: Vincent Janelle Cc: Kenneth Culver , hlwatts@hiwaay.net, freebsd-smp@FreeBSD.ORG Subject: Re: SGI Visual Workstation 330 Message-ID: <20020325120239.B9675@hexapodia.org> References: <000b01c1d41b$6bdaee40$944cb4d8@hiwaay.net> <20020325124253.E15966-100000@alpha.yumyumyum.org> <20020325094440.3bec515f.random@carnagecopia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020325094440.3bec515f.random@carnagecopia.com>; from random@carnagecopia.com on Mon, Mar 25, 2002 at 09:44:40AM -0800 X-PGP-Fingerprint: 48 01 21 E2 D4 E4 68 D1 B8 DF 39 B2 AF A3 16 B9 X-PGP-Key-URL: http://web.hexapodia.org/~adi/pgp.txt Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Mar 25, 2002 at 09:44:40AM -0800, Vincent Janelle wrote: > On Mon, 25 Mar 2002 12:43:18 -0500 (EST) > Kenneth Culver wrote: > > > > I have a SGI M25D motherboard taken from a discontinued Visual Workstation > > > 330. > > This motherboard is not technically an IBM compatible PC, its more > along the lines of an SGI workstation powered by intel processors. NT > has to use a custom HAL to support it under windows, and linux has > special support for it. > > Your best bet will probably be linux. The SGI VW series is confusing, fer sure. Vincent is thinking of the VW 540 and 320, which were truly amazing non-standard boxes that died their deserved death. (Their internal design was more like the O2 than like a standard PC.) You will have poor luck running anything but NT on the VW 540/320, even Linux doesn't have all the necessary hacks (and it doesn't have accelerated drivers for the graphics, which are the only thing that makes the machine special). The 330, on the other hand, is a much more standard PC-like box with AGP graphics and a fairly standard BIOS (I believe). These boxes didn't require any freaky special HAL, they run bog-standard NT and Linux. You will probably have decent luck getting this board running under FreeBSD. You say "motherboard", though -- watch out, it may have special power supply requirements. J. Random ATX power supply might not cut it. More info on SGI PC-class "workstations" at http://support.sgi.com/nt/ Good luck... -andy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Mar 25 10:24:29 2002 Delivered-To: freebsd-smp@freebsd.org Received: from absinthe.carnagecopia.com (absinthe.carnagecopia.com [216.187.87.246]) by hub.freebsd.org (Postfix) with SMTP id 3F9F337B404 for ; Mon, 25 Mar 2002 10:24:22 -0800 (PST) Received: (qmail 91577 invoked by uid 85); 25 Mar 2002 18:24:21 -0000 Received: from random@carnagecopia.com by absinthe.carnagecopia.com with qmail-scanner-1.03 (uvscan: v4.0.50/v4193. . Clean. Processed in 0.146552 secs); 25 Mar 2002 18:24:21 -0000 Received: from firewall-vancouver.goblinstudios.com (HELO workstation-61) (204.244.192.2) by absinthe.carnagecopia.com with SMTP; 25 Mar 2002 18:24:21 -0000 Date: Mon, 25 Mar 2002 10:23:50 -0800 From: Vincent Janelle To: Andy Isaacson Cc: culverk@alpha.yumyumyum.org, hlwatts@hiwaay.net, freebsd-smp@FreeBSD.ORG Subject: Re: SGI Visual Workstation 330 Message-Id: <20020325102350.3c00430d.random@carnagecopia.com> In-Reply-To: <20020325120239.B9675@hexapodia.org> References: <000b01c1d41b$6bdaee40$944cb4d8@hiwaay.net> <20020325124253.E15966-100000@alpha.yumyumyum.org> <20020325094440.3bec515f.random@carnagecopia.com> <20020325120239.B9675@hexapodia.org> Organization: Goblin Studios X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=.6BDWsCclQSYw,I" Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --=.6BDWsCclQSYw,I Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Yeah, after spending the required 10 seconds to look on the internet, this motherboard appears to be powered by the VIA apollo chipset. I've got a couple of machines running these and they appear to be stable, but they're not exactly high-use machines. On Mon, 25 Mar 2002 12:02:39 -0600 Andy Isaacson wrote: > The SGI VW series is confusing, fer sure. Vincent is thinking of the VW > 540 and 320, which were truly amazing non-standard boxes that died > their deserved death. (Their internal design was more like the O2 than > like a standard PC.) You will have poor luck running anything but NT on > the VW 540/320, even Linux doesn't have all the necessary hacks (and it > doesn't have accelerated drivers for the graphics, which are the only > thing that makes the machine special). > > The 330, on the other hand, is a much more standard PC-like box with AGP > graphics and a fairly standard BIOS (I believe). These boxes didn't > require any freaky special HAL, they run bog-standard NT and Linux. You > will probably have decent luck getting this board running under FreeBSD. --=.6BDWsCclQSYw,I Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) iD8DBQE8n2s4T+ow5T/THzQRAraNAKCYfrhazzRZVObPGR7e81XlaFIpMACfemvl 6ah4r+JP1Qc0lm8CMi9SlKQ= =karA -----END PGP SIGNATURE----- --=.6BDWsCclQSYw,I-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Mar 25 10:38:17 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mail3.home.nl (mail3.home.nl [213.51.129.227]) by hub.freebsd.org (Postfix) with ESMTP id 91EAA37B417 for ; Mon, 25 Mar 2002 10:38:11 -0800 (PST) Received: from cp35173a ([217.120.58.27]) by mail3.home.nl (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20020325183636.EWRG24978.mail3.home.nl@cp35173a> for ; Mon, 25 Mar 2002 19:36:36 +0100 Message-ID: <001a01c1d42d$930d6530$0200a8c0@cp35173a> From: "Piet Schipper" To: Subject: smp on supermicro p4dce Date: Mon, 25 Mar 2002 19:47:54 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01C1D435.F49C3E40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C1D435.F49C3E40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi there, I am thinking of purchasing a Supermicro P4DCE msp mobo, running FreeBSD = 4.5 on it. But i am not sure if this board is well-supported. Is there anyone in this list who can help me with this question. Thank you Piet Schipper ------=_NextPart_000_0017_01C1D435.F49C3E40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi there,
 
I am thinking of purchasing a = Supermicro P4DCE msp=20 mobo, running FreeBSD 4.5 on it.
But i am not sure if this board is=20 well-supported.
 
Is there anyone in this list who can = help me with=20 this question.
 
Thank you
 
Piet Schipper
 
 
 
 
------=_NextPart_000_0017_01C1D435.F49C3E40-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Mar 25 11:15:54 2002 Delivered-To: freebsd-smp@freebsd.org Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by hub.freebsd.org (Postfix) with ESMTP id 0559B37B64A; Mon, 25 Mar 2002 11:15:12 -0800 (PST) Received: from mailgate.nlsystems.com ([62.49.251.130] helo=herring.nlsystems.com) by anchor-post-32.mail.demon.net with esmtp (Exim 3.35 #1) id 16pZvy-000DUn-0W; Mon, 25 Mar 2002 19:15:10 +0000 Received: from salmon.nlsystems.com (salmon [10.0.0.3]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id g2PJDt948041; Mon, 25 Mar 2002 19:13:55 GMT (envelope-from dfr@nlsystems.com) Date: Mon, 25 Mar 2002 19:10:22 +0000 (GMT) From: Doug Rabson To: John Baldwin Cc: Jake Burkholder , , Andy Isaacson Subject: printf locking (was Re: FreeBSD 4.5: Second CPU Not Working on Dell PowerEdge 1650) In-Reply-To: Message-ID: <20020325190742.B99274-100000@salmon.nlsystems.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 25 Mar 2002, John Baldwin wrote: > > Hmmmm. Well, we really need proper printf locking (which probably shouldn't > use blocking locks). Weren't there some patches (from chuckp?) floating around to do this. Something along the lines of a trylock which buffers characters somewhere if it fails. I wanted this (again) recently - I couldn't work out why syscons kept wedging until I remembered there were no locks on the console. In the end, I just switched to a serial console. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Mar 25 11:31:46 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mail15.speakeasy.net (mail15.speakeasy.net [216.254.0.215]) by hub.freebsd.org (Postfix) with ESMTP id 77C5A37B419 for ; Mon, 25 Mar 2002 11:31:42 -0800 (PST) Received: (qmail 27403 invoked from network); 25 Mar 2002 19:31:41 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail15.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 25 Mar 2002 19:31:41 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g2PJWKv83280; Mon, 25 Mar 2002 14:32:21 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020325190742.B99274-100000@salmon.nlsystems.com> Date: Mon, 25 Mar 2002 14:31:42 -0500 (EST) From: John Baldwin To: Doug Rabson Subject: RE: printf locking (was Re: FreeBSD 4.5: Second CPU Not Working Cc: Andy Isaacson , freebsd-smp@FreeBSD.ORG, Jake Burkholder Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 25-Mar-2002 Doug Rabson wrote: > On Mon, 25 Mar 2002, John Baldwin wrote: > >> >> Hmmmm. Well, we really need proper printf locking (which probably shouldn't >> use blocking locks). > > Weren't there some patches (from chuckp?) floating around to do this. > Something along the lines of a trylock which buffers characters > somewhere if it fails. I wanted this (again) recently - I couldn't work > out why syscons kept wedging until I remembered there were no locks on the > console. In the end, I just switched to a serial console. I don't think I ever received the patches to do this when I asked for them. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Mon Mar 25 16:39:46 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 82FFE37B400; Mon, 25 Mar 2002 16:39:40 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id LAA22807; Tue, 26 Mar 2002 11:39:32 +1100 Date: Tue, 26 Mar 2002 11:39:59 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Doug Rabson Cc: John Baldwin , Jake Burkholder , , Andy Isaacson Subject: Re: printf locking (was Re: FreeBSD 4.5: Second CPU Not Working on Dell PowerEdge 1650) In-Reply-To: <20020325190742.B99274-100000@salmon.nlsystems.com> Message-ID: <20020326112755.P3192-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, 25 Mar 2002, Doug Rabson wrote: > On Mon, 25 Mar 2002, John Baldwin wrote: > > > > > Hmmmm. Well, we really need proper printf locking (which probably shouldn't > > use blocking locks). > > Weren't there some patches (from chuckp?) floating around to do this. > Something along the lines of a trylock which buffers characters > somewhere if it fails. I wanted this (again) recently - I couldn't work > out why syscons kept wedging until I remembered there were no locks on the > console. In the end, I just switched to a serial console. Message buffer locking also broken. It apparently never even used splhigh() except for addlog() and log(). I think cp's patch was to fix this and not to fix syscons. kvprintf() and console output routines are not permitted to block or delay console output, since they may be called from ddb from almost anywhere. syscons has 2 types of locking bugs: - it sometimes wanders into the scheduling code for things related to delayed screen updates - it doesn't have any locking for its screen pointer or data structure updates. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Mar 26 2:42:28 2002 Delivered-To: freebsd-smp@freebsd.org Received: from klima.physik.uni-mainz.de (klima.Physik.Uni-Mainz.DE [134.93.180.162]) by hub.freebsd.org (Postfix) with ESMTP id DBAA637B405 for ; Tue, 26 Mar 2002 02:42:18 -0800 (PST) Received: from klima.Physik.Uni-Mainz.DE (administrator@klima.Physik.Uni-Mainz.DE [134.93.180.162]) by klima.physik.uni-mainz.de (8.11.6/8.11.6) with ESMTP id g2QAg1d09762; Tue, 26 Mar 2002 11:42:01 +0100 (CET) (envelope-from administrator@klima.physik.uni-mainz.de) Date: Tue, 26 Mar 2002 11:42:01 +0100 (CET) From: Administrator IPA To: "Dreamtime.net Inc." Cc: Terry Lambert , =?iso-8859-1?B?ocKhTWFv?= , Subject: RE: SMP Error in VIA 694 based bord In-Reply-To: Message-ID: <20020326113111.R9369-100000@klima.physik.uni-mainz.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 20 Mar 2002, Dreamtime.net Inc. wrote: > The board we have is the Thunder LE S2510 using a serverworks chipset. > > S > > > -----Original Message----- > > From: Terry Lambert [mailto:tlambert2@mindspring.com] > > Sent: Wednesday, March 20, 2002 4:40 PM > > To: Dreamtime.net Inc. > > Cc: ¡Â¡Mao; freebsd-smp@FreeBSD.ORG > > Subject: Re: SMP Error in VIA 694 based bord > > > > > > Neither of you say a thing about what the actual crash is. > > > > If it's a trap 12, try adding "option DISABLE_PSE" to your > > config file. > > > > The Tyan Tiger is a bit more sensitive to coherency problems > > than most SMP motherboards. It's the VIA chipset, not the > > motherboard itself, I think. > > > > -- Terry > > > > "Dreamtime.net Inc." wrote: > > > > > > Part 1.1 Type: Plain Text (text/plain) > > > Encoding: 8bit > > Hello. Well, we use two SMP motherboards of the 'accused' typ you mentioned above, one is a ASUS CUV4X-D (VIA Chipset) and one is a TYAN Thunder 2500/Slot 1 technique mainboard. With the VIA chipset based mobo we never have had any kind of problem, but a lot with the TYAN, but those problems were 'selfmade'. IRQ routing on the mobo backplain seems to be a focus of the board designer, not the chipset itself. Our TYAN 2500 has a lot of problems when using an additional fxp-type NIC (Intel EtherExpress Server NIC in addition to the built-in one) and when I did a firmware update of the AMI Enterprise 1600 MegaRAID controller. Moving it to its appropriate 66MHz/64Bit PCI slot and 'juggling' with the slot for the second NIC solves the problems, this machine is one of the stablest machines around here, no spontanous reboot within the last 6 months and I keep on track with 4.5-STABLE (update this day). Yes, I HAD a lot of problems with the TYAN, but these problems were solveable problems. Maybe the VIA chipset based TYAN boards has the same problems like the ServerWorks chipsets and a 'relatively sure' behaviour is to detect this: spontanous reboots or a reboot when heavy network duty is a factor or when massive SCSI/ATA activities are given. Crashing like a clockwork sounds like that: check your /etc/crontab to see what jobs are done regularyliy at this time the system crashes ... I checked this also and I found out, that our reboots were done always within a 'narrow defined' time window ... Hope this is not a heap of trash what I said ... Oliver -- MfG O. Hartmann ohartman@klima.physik.uni-mainz.de ---------------------------------------------------------------- IT-Administration des Institut fuer Physik der Atmosphaere (IPA) ---------------------------------------------------------------- Johannes Gutenberg Universitaet Mainz Becherweg 21 55099 Mainz Tel: +496131/3924662 (Maschinensaal) Tel: +496131/3924144 FAX: +496131/3923532 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Mar 26 11:52:58 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mail16.speakeasy.net (mail16.speakeasy.net [216.254.0.216]) by hub.freebsd.org (Postfix) with ESMTP id 91E2F37B419 for ; Tue, 26 Mar 2002 11:52:50 -0800 (PST) Received: (qmail 29439 invoked from network); 26 Mar 2002 19:52:08 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail16.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 26 Mar 2002 19:52:08 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g2QJqmv87346 for ; Tue, 26 Mar 2002 14:52:48 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Tue, 26 Mar 2002 14:52:10 -0500 (EST) From: John Baldwin To: smp@FreeBSD.org Subject: suser() API change patch Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The patch at the URL below changes the suser() API as follows. Currently we have four suser() functions that take the following args: suser(proc) suser_td(thread) suser_xxx(cred, proc, flag) suser_xxx_td(cred, thread, flag) In the new scheme (which has been approved by Robert Watson and is really his design) we go back to only two functions like so: suser(thread, flag) suser_cred(cred, flag) The changes are mostly mechanical but the patch is a bit big (about 111k) and touches 139 files. It is at http://www.FreeBSD.org/~jhb/patches/ucred.patch I'd like to commit it tomorrow barring any comments, objections, etc. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Mar 26 12:21:28 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id D4EB637B420 for ; Tue, 26 Mar 2002 12:21:09 -0800 (PST) Received: (qmail 6285 invoked from network); 26 Mar 2002 20:21:09 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 26 Mar 2002 20:21:09 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g2QKLnv87487; Tue, 26 Mar 2002 15:21:49 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 26 Mar 2002 15:21:10 -0500 (EST) From: John Baldwin To: John Baldwin Subject: RE: suser() API change patch Cc: smp@FreeBSD.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 26-Mar-2002 John Baldwin wrote: > The changes are mostly mechanical but the patch is a bit big (about 111k) and > touches 139 files. It is at http://www.FreeBSD.org/~jhb/patches/ucred.patch > I'd like to commit it tomorrow barring any comments, objections, etc. Doh, s/ucred.patch/suser.patch/ :-P -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Mar 26 14: 0:17 2002 Delivered-To: freebsd-smp@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id AAF5637B417; Tue, 26 Mar 2002 14:00:12 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020326220012.BHKH2626.rwcrmhc51.attbi.com@InterJet.elischer.org>; Tue, 26 Mar 2002 22:00:12 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA43358; Tue, 26 Mar 2002 13:42:44 -0800 (PST) Date: Tue, 26 Mar 2002 13:42:42 -0800 (PST) From: Julian Elischer To: John Baldwin Cc: smp@FreeBSD.org Subject: Re: suser() API change patch In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org suser_td was always a temporary step towards suser(thread, flag) My aim was always to move suser(proc), suser_td(thread) to suser(thread, ...) and suser_xxx(cred, proc, flag) and suser_xxx_td(cred, thread, flag) to something that was not dependent on thread or proc. I whole heartedly agree with this change and see no problems that can't be fixed on the fly.. I've been watchint the P4 commits and haven't seen any problems. I think this is "non controversial" Julian On Tue, 26 Mar 2002, John Baldwin wrote: > The patch at the URL below changes the suser() API as follows. Currently we > have four suser() functions that take the following args: > > suser(proc) > suser_td(thread) > suser_xxx(cred, proc, flag) > suser_xxx_td(cred, thread, flag) > > In the new scheme (which has been approved by Robert Watson and is really > his design) we go back to only two functions like so: > > suser(thread, flag) > suser_cred(cred, flag) > > The changes are mostly mechanical but the patch is a bit big (about 111k) and > touches 139 files. It is at http://www.FreeBSD.org/~jhb/patches/ucred.patch > I'd like to commit it tomorrow barring any comments, objections, etc. > > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Mar 26 19:19: 1 2002 Delivered-To: freebsd-smp@freebsd.org Received: from n26.grp.scd.yahoo.com (n26.grp.scd.yahoo.com [66.218.66.82]) by hub.freebsd.org (Postfix) with SMTP id 8917937B404 for ; Tue, 26 Mar 2002 19:18:59 -0800 (PST) X-eGroups-Return: ipoiraroa@yahoo.com Received: from [66.218.67.130] by n26.grp.scd.yahoo.com with NNFMP; 27 Mar 2002 03:18:59 -0000 Date: Wed, 27 Mar 2002 03:18:59 -0000 From: "ipoiraroa" To: freebsd-smp@freebsd.org Subject: Get a Credit Card in 30 seconds, Message-ID: User-Agent: eGroups-EW/0.82 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Yahoo Groups Message Poster X-Originating-IP: 208.49.145.98 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org You have to check out this cool site I found. There's a bunch of different cards to choose from. I couldn't get a card anywhere else on the web. I found this site and was approved in 30 seconds. Now I got a visa and a mastercard. http://apply4creditcard.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Mar 26 21:32:24 2002 Delivered-To: freebsd-smp@freebsd.org Received: from 12-234-96-171.client.attbi.com (12-234-96-171.client.attbi.com [12.234.96.171]) by hub.freebsd.org (Postfix) with ESMTP id 23E7537B405 for ; Tue, 26 Mar 2002 21:32:22 -0800 (PST) Received: by 12-234-96-171.client.attbi.com (Postfix, from userid 1000) id 3445C5E54; Fri, 26 Apr 2002 21:32:14 -0700 (PDT) Date: Fri, 26 Apr 2002 21:32:14 -0700 From: Jon Mini To: freebsd-smp@freebsd.org Subject: Patch to "Lock struct pargs" Message-ID: <20020426213214.B405@stylus.haikugeek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The patch below locks the process argument (struct pargs) reference count with a mutex: http://people.freebsd.org/~imp/smp.pargs.diff Please commit. Thanks, -- Jonathan Mini mini@haikugeek.com Yersterday, I was ashamed of myself. Today, I am just hungry. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Tue Mar 26 23:58: 6 2002 Delivered-To: freebsd-smp@freebsd.org Received: from 12-234-96-171.client.attbi.com (12-234-96-171.client.attbi.com [12.234.96.171]) by hub.freebsd.org (Postfix) with ESMTP id 690DC37B405 for ; Tue, 26 Mar 2002 23:58:03 -0800 (PST) Received: by 12-234-96-171.client.attbi.com (Postfix, from userid 1000) id 8F0A95E61; Fri, 26 Apr 2002 23:57:56 -0700 (PDT) Date: Fri, 26 Apr 2002 23:57:56 -0700 From: Jon Mini To: freebsd-smp@FreeBSD.ORG Subject: Re: Patch to "Lock struct pargs" Message-ID: <20020426235756.C405@stylus.haikugeek.com> References: <20020426213214.B405@stylus.haikugeek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020426213214.B405@stylus.haikugeek.com>; from mini@haikugeek.com on Fri, Apr 26, 2002 at 09:32:14PM -0700 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This version passes the struct being locked to the locking macro, even though currenctly there is only one lock for all struct pargs (as recommended by Alfred) : http://www.efn.org/~j_mini/smp.pargs.diff Jon Mini [mini@haikugeek.com] wrote : > The patch below locks the process argument (struct pargs) reference > count with a mutex: > > http://people.freebsd.org/~imp/smp.pargs.diff > > Please commit. > > Thanks, > -- > Jonathan Mini > mini@haikugeek.com > > Yersterday, I was ashamed of myself. Today, I am just hungry. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message -- Jonathan Mini mini@haikugeek.com Yersterday, I was ashamed of myself. Today, I am just hungry. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Mar 27 2:43:47 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id A6C9537B400; Wed, 27 Mar 2002 02:43:44 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA30333; Wed, 27 Mar 2002 21:43:42 +1100 Date: Wed, 27 Mar 2002 21:44:14 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: John Baldwin Cc: smp@FreeBSD.ORG Subject: Re: suser() API change patch In-Reply-To: Message-ID: <20020327213629.S3808-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, 26 Mar 2002, John Baldwin wrote: > The patch at the URL below changes the suser() API as follows. Currently we > have four suser() functions that take the following args: > > suser(proc) > suser_td(thread) > suser_xxx(cred, proc, flag) > suser_xxx_td(cred, thread, flag) > > In the new scheme (which has been approved by Robert Watson and is really > his design) we go back to only two functions like so: > > suser(thread, flag) > suser_cred(cred, flag) The former should be suser(thread). In the patch, the flag is nonzero in less than 10% of the calls. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Mar 27 11:12: 1 2002 Delivered-To: freebsd-smp@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 729ED37B404; Wed, 27 Mar 2002 11:11:53 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g2RJBYw38484; Wed, 27 Mar 2002 14:11:35 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 27 Mar 2002 14:11:34 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Bruce Evans Cc: John Baldwin , smp@FreeBSD.ORG Subject: Re: suser() API change patch In-Reply-To: <20020327213629.S3808-100000@gamplex.bde.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 27 Mar 2002, Bruce Evans wrote: > On Tue, 26 Mar 2002, John Baldwin wrote: > > > The patch at the URL below changes the suser() API as follows. Currently we > > have four suser() functions that take the following args: > > > > suser(proc) > > suser_td(thread) > > suser_xxx(cred, proc, flag) > > suser_xxx_td(cred, thread, flag) > > > > In the new scheme (which has been approved by Robert Watson and is really > > his design) we go back to only two functions like so: > > > > suser(thread, flag) > > suser_cred(cred, flag) > > The former should be suser(thread). In the patch, the flag is nonzero > in less than 10% of the calls. This nice thing about the suser(thread) model, pointed out I think by Julian a few months ago, is that it hides the structure contents of thread and proc from the caller. suser_cred() requires that the caller not only include proc.h, but also that it dereference proc.h, meaning that if struct thread or struct proc changes, binary compatibility is broken for any precompiled code. Originally, my preference was to always expose the credential selection decision in the calling code, but in light of this argument, I fell back to using suser() in all places a specific credential decision wasn't made. This also had the advantage of hiding whether suser(thread) was extracting the credential from the thread or the process structure, during the migration. Other than the fact that the flag is frequently 0, is there another rationale you have in mind for this? The API is still changing (from proc to thread) regardless, so there's no compatibility throw-away. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Mar 27 11:20:20 2002 Delivered-To: freebsd-smp@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id C7F2A37B421 for ; Wed, 27 Mar 2002 11:20:08 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020327192007.JXFY2951.rwcrmhc53.attbi.com@InterJet.elischer.org>; Wed, 27 Mar 2002 19:20:07 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA47943; Wed, 27 Mar 2002 11:05:55 -0800 (PST) Date: Wed, 27 Mar 2002 11:05:55 -0800 (PST) From: Julian Elischer To: Jon Mini Cc: freebsd-smp@freebsd.org Subject: Re: Patch to "Lock struct pargs" In-Reply-To: <20020426213214.B405@stylus.haikugeek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org BTW struct pargs { - u_int ar_ref; /* Reference count. */ - u_int ar_length; /* Length. */ - u_char ar_args[0]; /* Arguments. */ + u_int ar_ref; /* Reference count. */ + u_int ar_length; /* Length. */ + u_char ar_args[0]; /* Arguments. */ }; style(9) says that you should use 2 tabs only if you need to.. the original is fine, because u_char fits in 1 tab.. On Fri, 26 Apr 2002, Jon Mini wrote: > The patch below locks the process argument (struct pargs) reference > count with a mutex: > > http://people.freebsd.org/~imp/smp.pargs.diff > > Please commit. > > Thanks, > -- > Jonathan Mini > mini@haikugeek.com > > Yersterday, I was ashamed of myself. Today, I am just hungry. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Mar 27 11:20:34 2002 Delivered-To: freebsd-smp@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 5007837B404 for ; Wed, 27 Mar 2002 11:20:15 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020327192015.JXJD2951.rwcrmhc53.attbi.com@InterJet.elischer.org>; Wed, 27 Mar 2002 19:20:15 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id LAA47935; Wed, 27 Mar 2002 11:02:02 -0800 (PST) Date: Wed, 27 Mar 2002 11:02:01 -0800 (PST) From: Julian Elischer To: Jon Mini Cc: freebsd-smp@freebsd.org Subject: Re: Patch to "Lock struct pargs" In-Reply-To: <20020426213214.B405@stylus.haikugeek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org My first thought was "shouldn't the args be covered by th eproc lock" and then I noticed the ref-count.. obviously shared between processes. Then I thought "well why not an sx lock? I presume most processes access these read-only. THEN I thought.. hey hang on.. processes access their args from user space.. what are we storing here? so the comments in exec() etc seem to suggest that these are not the actual args that are given to the process, but instead some small subset used for (maybe) debugging.. if this is so then once again it's really only read-only when used.. any exec with a NEW set of args will create a new one. so this is similar to the ucreds.. The only item we are protecting is the reference count. Everything else should be read-only. You should only need to lock this when you are changing the reference count. Once again an smp safe reference counting scheme would save this locking stuff.... John, can you resurect your ref-counting code so we can look at it again? I think we could use it inteh ucred case too. On Fri, 26 Apr 2002, Jon Mini wrote: > The patch below locks the process argument (struct pargs) reference > count with a mutex: > > http://people.freebsd.org/~imp/smp.pargs.diff > > Please commit. > > Thanks, > -- > Jonathan Mini > mini@haikugeek.com > > Yersterday, I was ashamed of myself. Today, I am just hungry. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Mar 27 11:25: 5 2002 Delivered-To: freebsd-smp@freebsd.org Received: from 12-234-96-171.client.attbi.com (12-234-96-171.client.attbi.com [12.234.96.171]) by hub.freebsd.org (Postfix) with ESMTP id B2B9937B41B for ; Wed, 27 Mar 2002 11:24:59 -0800 (PST) Received: by 12-234-96-171.client.attbi.com (Postfix, from userid 1000) id 58AFA5E54; Sat, 27 Apr 2002 11:24:53 -0700 (PDT) Date: Sat, 27 Apr 2002 11:24:53 -0700 From: Jon Mini To: Julian Elischer Cc: freebsd-smp@freebsd.org Subject: Re: Patch to "Lock struct pargs" Message-ID: <20020427112453.D20741@stylus.haikugeek.com> References: <20020426213214.B405@stylus.haikugeek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from julian@elischer.org on Wed, Mar 27, 2002 at 11:05:55AM -0800 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Julian Elischer [julian@elischer.org] wrote : > > > > BTW > > struct pargs { > - u_int ar_ref; /* Reference count. */ > - u_int ar_length; /* Length. */ > - u_char ar_args[0]; /* Arguments. */ > + u_int ar_ref; /* Reference count. */ > + u_int ar_length; /* Length. */ > + u_char ar_args[0]; /* Arguments. */ > }; > > style(9) says that you should use 2 tabs only if you need to.. > the original is fine, because u_char fits in 1 tab.. > This was needless whitespace diff that was caused by accident. Note that the structure isn't even changed. I removed it in an updated version, but I didn't have access to bsdimp's account, so I couldn't take the old one down. -- Jonathan Mini mini@haikugeek.com Yersterday, I was ashamed of myself. Today, I am just hungry. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Wed Mar 27 12:20:52 2002 Delivered-To: freebsd-smp@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 111C737B425; Wed, 27 Mar 2002 12:20:10 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020327202009.WPNJ1147.rwcrmhc52.attbi.com@InterJet.elischer.org>; Wed, 27 Mar 2002 20:20:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA48226; Wed, 27 Mar 2002 12:10:37 -0800 (PST) Date: Wed, 27 Mar 2002 12:10:36 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Cc: smp@freeBSD.org Subject: SMP safe reference counting Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org [please remove -smp from your reply] Once again on the SMP list a lock is being used to make a reference count safe. I'd like to re-raise the issue of a safe reference counting fascility. what would be the semantics? typedef volatile u_int ref_cnt; typedef void ref_free(void *); reference_add(ref_cnt *); reference_drop(ref_cnt *, ref_free *, void *); __inline void reference_add(ref_cnt *cnt) { atomic_inc(cnt); } /* Note I use the non-existing "atomic_inc()". I think we should have this as its SO COMMONLY used. */ __inline void reference_drop(ref_cnt *cnt, ref_free *fn. void * arg) { int newcount; int oldcount; do { newcount = (oldcount = *cnt) - 1; } while (atomic_cmp_and_set(cnt, oldcount, newcount) == ACS_FAILED); } /* I can't remember off the top of my head the cmp-and-set command */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Mar 28 2:42: 3 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 9132337B404; Thu, 28 Mar 2002 02:41:57 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA31525; Thu, 28 Mar 2002 21:41:55 +1100 Date: Thu, 28 Mar 2002 21:42:30 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Robert Watson Cc: John Baldwin , Subject: Re: suser() API change patch In-Reply-To: Message-ID: <20020328211326.P7433-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 27 Mar 2002, Robert Watson wrote: > On Wed, 27 Mar 2002, Bruce Evans wrote: > > > On Tue, 26 Mar 2002, John Baldwin wrote: > > > > > The patch at the URL below changes the suser() API as follows. Currently we > > > have four suser() functions that take the following args: > > > > > > suser(proc) > > > suser_td(thread) > > > suser_xxx(cred, proc, flag) > > > suser_xxx_td(cred, thread, flag) > > > > > > In the new scheme (which has been approved by Robert Watson and is really > > > his design) we go back to only two functions like so: > > > > > > suser(thread, flag) > > > suser_cred(cred, flag) > > > > The former should be suser(thread). In the patch, the flag is nonzero > > in less than 10% of the calls. > > This nice thing about the suser(thread) model, pointed out I think by > Julian a few months ago, is that it hides the structure contents of thread > and proc from the caller. suser_cred() requires that the caller not only > include proc.h, but also that it dereference proc.h, meaning that if > struct thread or struct proc changes, binary compatibility is broken for > any precompiled code. Originally, my preference was to always expose the > credential selection decision in the calling code, but in light of this > argument, I fell back to using suser() in all places a specific credential > decision wasn't made. This also had the advantage of hiding whether > suser(thread) was extracting the credential from the thread or the process > structure, during the migration. Other than the fact that the flag is > frequently 0, is there another rationale you have in mind for this? The > API is still changing (from proc to thread) regardless, so there's no > compatibility throw-away. suser(thread, flag) could still exist (named somthing like suser_flag()) if it is used enough to justify it. My main point is that the flag is rarely used, so the interface shouldn't be bloated to pass it. Another point: td->td_ucred can only be safely used without locking if td is curthread. Our current code mostly assumes this. suser(td) can easily check that td is curthread, but this is a silly reason to use a bloated interface. It is just bug for bug compatible with passing thread pointers around a lot. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Mar 28 7: 8:12 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 4193D37B416 for ; Thu, 28 Mar 2002 07:07:39 -0800 (PST) Received: (qmail 17549 invoked from network); 28 Mar 2002 15:07:37 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 28 Mar 2002 15:07:37 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g2SF8Jv95923; Thu, 28 Mar 2002 10:08:20 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020328211326.P7433-100000@gamplex.bde.org> Date: Thu, 28 Mar 2002 10:07:39 -0500 (EST) From: John Baldwin To: Bruce Evans Subject: Re: suser() API change patch Cc: smp@FreeBSD.ORG, Robert Watson Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 28-Mar-2002 Bruce Evans wrote: > On Wed, 27 Mar 2002, Robert Watson wrote: > >> On Wed, 27 Mar 2002, Bruce Evans wrote: >> >> > On Tue, 26 Mar 2002, John Baldwin wrote: >> > >> > > The patch at the URL below changes the suser() API as follows. >> > > Currently we >> > > have four suser() functions that take the following args: >> > > >> > > suser(proc) >> > > suser_td(thread) >> > > suser_xxx(cred, proc, flag) >> > > suser_xxx_td(cred, thread, flag) >> > > >> > > In the new scheme (which has been approved by Robert Watson and is >> > > really >> > > his design) we go back to only two functions like so: >> > > >> > > suser(thread, flag) >> > > suser_cred(cred, flag) >> > >> > The former should be suser(thread). In the patch, the flag is nonzero >> > in less than 10% of the calls. >> >> This nice thing about the suser(thread) model, pointed out I think by >> Julian a few months ago, is that it hides the structure contents of thread >> and proc from the caller. suser_cred() requires that the caller not only >> include proc.h, but also that it dereference proc.h, meaning that if >> struct thread or struct proc changes, binary compatibility is broken for >> any precompiled code. Originally, my preference was to always expose the >> credential selection decision in the calling code, but in light of this >> argument, I fell back to using suser() in all places a specific credential >> decision wasn't made. This also had the advantage of hiding whether >> suser(thread) was extracting the credential from the thread or the process >> structure, during the migration. Other than the fact that the flag is >> frequently 0, is there another rationale you have in mind for this? The >> API is still changing (from proc to thread) regardless, so there's no >> compatibility throw-away. > > suser(thread, flag) could still exist (named somthing like suser_flag()) > if it is used enough to justify it. My main point is that the flag is > rarely used, so the interface shouldn't be bloated to pass it. I don't think it's very much bloat and it avoids having to complicate the API by adding a suser_flag() or some such. Originally Robert wanted to just have suser() as what is now suser_cred(). suser() exists for the reasons Robert highlighted above so that a thread can be passed in. > Another point: td->td_ucred can only be safely used without locking > if td is curthread. Our current code mostly assumes this. suser(td) > can easily check that td is curthread, but this is a silly reason to > use a bloated interface. It is just bug for bug compatible with passing > thread pointers around a lot. Actually, td_ucred can be safely used w/o locking for any thread which is guaranteed to not leave the kernel while it is being read. The easiest one to guarantee that for is curthread. Locks would never help since none protect writing to td_ucred. As far as the more general notion of passing thread pointers rather than using curthread, I'll just ignore that issue for now. It would need its own bikeshed. :) > Bruce -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Mar 28 11: 0:27 2002 Delivered-To: freebsd-smp@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 269BB37B416; Thu, 28 Mar 2002 11:00:16 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020328190015.WHEW2951.rwcrmhc53.attbi.com@InterJet.elischer.org>; Thu, 28 Mar 2002 19:00:15 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id KAA53393; Thu, 28 Mar 2002 10:45:13 -0800 (PST) Date: Thu, 28 Mar 2002 10:45:11 -0800 (PST) From: Julian Elischer To: Bruce Evans Cc: Robert Watson , John Baldwin , smp@FreeBSD.ORG Subject: Re: suser() API change patch In-Reply-To: <20020328211326.P7433-100000@gamplex.bde.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 28 Mar 2002, Bruce Evans wrote: > suser(thread, flag) could still exist (named somthing like suser_flag()) > if it is used enough to justify it. My main point is that the flag is > rarely used, so the interface shouldn't be bloated to pass it. > > Another point: td->td_ucred can only be safely used without locking > if td is curthread. Our current code mostly assumes this. suser(td) > can easily check that td is curthread, but this is a silly reason to > use a bloated interface. It is just bug for bug compatible with passing > thread pointers around a lot. Bruce does have a point.. > > Bruce > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-smp" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Mar 28 17: 1:59 2002 Delivered-To: freebsd-smp@freebsd.org Received: from ns.burnet.ru (ns.burnet.ru [212.0.65.2]) by hub.freebsd.org (Postfix) with ESMTP id E719C37B417 for ; Thu, 28 Mar 2002 17:01:55 -0800 (PST) Received: from ppi (ppi.burnet.ru [212.0.65.30]) by ns.burnet.ru (8.11.6/8.11.6) with ESMTP id g2T11sf69580 for ; Fri, 29 Mar 2002 09:01:54 +0800 (IRKT) (envelope-from ppi@burnet.ru) Date: Fri, 29 Mar 2002 09:01:51 +0800 From: "Pavel I. Popov " X-Mailer: The Bat! (v1.53bis) Reply-To: "Pavel I. Popov " Organization: JSC "Mobiltelecom" X-Priority: 3 (Normal) Message-ID: <861947940.20020329090151@burnet.ru> To: freebsd-smp@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org úÄÒÁ×ÓÔ×ÕÊÔÅ! freebsd-smp, -- ó Õ×ÁÖÅÎÉÅÍ, ðÏÐÏ× ðÁ×ÅÌ mailto:ppi@burnet.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Mar 28 17: 3: 9 2002 Delivered-To: freebsd-smp@freebsd.org Received: from ns.burnet.ru (ns.burnet.ru [212.0.65.2]) by hub.freebsd.org (Postfix) with ESMTP id 70D1037B419 for ; Thu, 28 Mar 2002 17:03:04 -0800 (PST) Received: from ppi (ppi.burnet.ru [212.0.65.30]) by ns.burnet.ru (8.11.6/8.11.6) with ESMTP id g2T133f69700 for ; Fri, 29 Mar 2002 09:03:03 +0800 (IRKT) (envelope-from ppi@burnet.ru) Date: Fri, 29 Mar 2002 09:03:01 +0800 From: "Pavel I. Popov " X-Mailer: The Bat! (v1.53bis) Reply-To: "Pavel I. Popov " Organization: JSC "Mobiltelecom" X-Priority: 3 (Normal) Message-ID: <1072017591.20020329090301@burnet.ru> To: freebsd-smp@FreeBSD.org Subject: subscribe freebsd-smp MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org subscribe freebsd-smp end -- ó Õ×ÁÖÅÎÉÅÍ, ðÏÐÏ× ðÁ×ÅÌ mailto:ppi@burnet.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Thu Mar 28 20:38:56 2002 Delivered-To: freebsd-smp@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 169D737B417; Thu, 28 Mar 2002 20:38:52 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g2T4bLw62152; Thu, 28 Mar 2002 23:37:21 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Thu, 28 Mar 2002 23:37:20 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Julian Elischer Cc: Bruce Evans , John Baldwin , smp@FreeBSD.ORG Subject: Re: suser() API change patch In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 28 Mar 2002, Julian Elischer wrote: > On Thu, 28 Mar 2002, Bruce Evans wrote: > > suser(thread, flag) could still exist (named somthing like suser_flag()) > > if it is used enough to justify it. My main point is that the flag is > > rarely used, so the interface shouldn't be bloated to pass it. > > > > Another point: td->td_ucred can only be safely used without locking > > if td is curthread. Our current code mostly assumes this. suser(td) > > can easily check that td is curthread, but this is a silly reason to > > use a bloated interface. It is just bug for bug compatible with passing > > thread pointers around a lot. > > Bruce does have a point.. I'll be the first to admit that. It actually suggests the API should be: int suser(void); /* implicitly curthread */ int suser_flags(int flags); /* implicitly curthread */ int suser_cred(struct ucred *cred, int flags); Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Mar 29 6:56:41 2002 Delivered-To: freebsd-smp@freebsd.org Received: from 12-234-96-171.client.attbi.com (12-234-96-171.client.attbi.com [12.234.96.171]) by hub.freebsd.org (Postfix) with ESMTP id 0D28037B404 for ; Fri, 29 Mar 2002 06:56:38 -0800 (PST) Received: by 12-234-96-171.client.attbi.com (Postfix, from userid 1000) id B12325EC5; Fri, 29 Mar 2002 03:14:13 -0800 (PST) Date: Fri, 29 Mar 2002 03:14:13 -0800 From: Jon Mini To: freebsd-smp@freebsd.org Subject: [PATCH] Hold PROC lock while accessing proc's pargs Message-ID: <20020329031413.A413@stylus.haikugeek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > alfred 2002/03/27 13:36:18 PST > > Modified files: > sys/sys proc.h > sys/compat/svr4 svr4_misc.c > sys/kern kern_exec.c kern_exit.c kern_fork.c > kern_proc.c > Log: > Make the reference counting of 'struct pargs' SMP safe. > > There is still some locations where the PROC lock should be held > in order to prevent inconsistent views from outside (like the > proc->p_fd fix for kern/vfs_syscalls.c:checkdirs()) that can be > fixed later. > > Submitted by: Jonathan Mini > > Revision Changes Path > 1.43 +1 -2 src/sys/compat/svr4/svr4_misc.c > 1.158 +2 -6 src/sys/kern/kern_exec.c > 1.153 +1 -2 src/sys/kern/kern_exit.c > 1.142 +1 -2 src/sys/kern/kern_fork.c > 1.122 +5 -7 src/sys/kern/kern_proc.c > 1.213 +51 -0 src/sys/sys/proc.h This patch does that: http://www.haikugeek.com/freebsd/pargs.diff -- Jonathan Mini mini@haikugeek.com Yersterday, I was ashamed of myself. Today, I am just hungry. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Mar 29 8:34: 4 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 377C537B419 for ; Fri, 29 Mar 2002 08:33:50 -0800 (PST) Received: (qmail 20421 invoked from network); 29 Mar 2002 16:33:48 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 29 Mar 2002 16:33:48 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g2TGYav00653; Fri, 29 Mar 2002 11:34:36 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020329031413.A413@stylus.haikugeek.com> Date: Fri, 29 Mar 2002 11:33:50 -0500 (EST) From: John Baldwin To: Jon Mini Subject: RE: [PATCH] Hold PROC lock while accessing proc's pargs Cc: freebsd-smp@freebsd.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 29-Mar-2002 Jon Mini wrote: >> alfred 2002/03/27 13:36:18 PST >> >> Modified files: >> sys/sys proc.h >> sys/compat/svr4 svr4_misc.c >> sys/kern kern_exec.c kern_exit.c kern_fork.c >> kern_proc.c >> Log: >> Make the reference counting of 'struct pargs' SMP safe. >> >> There is still some locations where the PROC lock should be held >> in order to prevent inconsistent views from outside (like the >> proc->p_fd fix for kern/vfs_syscalls.c:checkdirs()) that can be >> fixed later. >> >> Submitted by: Jonathan Mini >> >> Revision Changes Path >> 1.43 +1 -2 src/sys/compat/svr4/svr4_misc.c >> 1.158 +2 -6 src/sys/kern/kern_exec.c >> 1.153 +1 -2 src/sys/kern/kern_exit.c >> 1.142 +1 -2 src/sys/kern/kern_fork.c >> 1.122 +5 -7 src/sys/kern/kern_proc.c >> 1.213 +51 -0 src/sys/sys/proc.h > > > This patch does that: > > http://www.haikugeek.com/freebsd/pargs.diff You don't need PROC_LOCK for p_comm, so you can drop it prior to the sbuf_printf. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Mar 29 8:34:10 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mail14.speakeasy.net (mail14.speakeasy.net [216.254.0.214]) by hub.freebsd.org (Postfix) with ESMTP id E990537B423 for ; Fri, 29 Mar 2002 08:33:55 -0800 (PST) Received: (qmail 25684 invoked from network); 29 Mar 2002 16:33:54 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail14.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 29 Mar 2002 16:33:54 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g2TGYgv00662; Fri, 29 Mar 2002 11:34:42 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 29 Mar 2002 11:33:56 -0500 (EST) From: John Baldwin To: Robert Watson Subject: Re: suser() API change patch Cc: smp@FreeBSD.ORG, Bruce Evans , Julian Elischer Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 29-Mar-2002 Robert Watson wrote: > > On Thu, 28 Mar 2002, Julian Elischer wrote: > >> On Thu, 28 Mar 2002, Bruce Evans wrote: >> > suser(thread, flag) could still exist (named somthing like suser_flag()) >> > if it is used enough to justify it. My main point is that the flag is >> > rarely used, so the interface shouldn't be bloated to pass it. >> > >> > Another point: td->td_ucred can only be safely used without locking >> > if td is curthread. Our current code mostly assumes this. suser(td) >> > can easily check that td is curthread, but this is a silly reason to >> > use a bloated interface. It is just bug for bug compatible with passing >> > thread pointers around a lot. >> >> Bruce does have a point.. > > I'll be the first to admit that. It actually suggests the API should be: > > int suser(void); /* implicitly curthread */ > int suser_flags(int flags); /* implicitly curthread */ > int suser_cred(struct ucred *cred, int flags); Well, is this what everyone wants then? I can change it if this is what everyone agrees to. In a similar vein, should I get rid of the first argument for all the p_canfoo() functions when I change that API as well? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Mar 29 8:52: 1 2002 Delivered-To: freebsd-smp@freebsd.org Received: from 12-234-96-171.client.attbi.com (12-234-96-171.client.attbi.com [12.234.96.171]) by hub.freebsd.org (Postfix) with ESMTP id 3C22637B400; Fri, 29 Mar 2002 08:51:56 -0800 (PST) Received: by 12-234-96-171.client.attbi.com (Postfix, from userid 1000) id A38E05E51; Fri, 29 Mar 2002 08:50:56 -0800 (PST) Date: Fri, 29 Mar 2002 08:50:56 -0800 From: Jon Mini To: John Baldwin Cc: freebsd-smp@FreeBSD.ORG Subject: Re: [PATCH] Hold PROC lock while accessing proc's pargs Message-ID: <20020329085056.B413@stylus.haikugeek.com> References: <20020329031413.A413@stylus.haikugeek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jhb@FreeBSD.ORG on Fri, Mar 29, 2002 at 11:33:50AM -0500 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org John Baldwin [jhb@FreeBSD.ORG] wrote : > > > This patch does that: > > > > http://www.haikugeek.com/freebsd/pargs.diff > > You don't need PROC_LOCK for p_comm, so you can drop it prior to the > sbuf_printf. Ahh. Changed. -- Jonathan Mini mini@haikugeek.com Yersterday, I was ashamed of myself. Today, I am just hungry. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Mar 29 11:29:39 2002 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 5189E37B405; Fri, 29 Mar 2002 11:29:18 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g2TJTIi59785; Fri, 29 Mar 2002 11:29:18 -0800 (PST) (envelope-from dillon) Date: Fri, 29 Mar 2002 11:29:18 -0800 (PST) From: Matthew Dillon Message-Id: <200203291929.g2TJTIi59785@apollo.backplane.com> To: freebsd-smp@freebsd.org Cc: John Baldwin Subject: Syscall contention tests return, userret() bugs/issues. Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Ok, now that the last mess has been dealt with I have resumed my examination of the critical path. NOTE!!!!! While I do want to fix this stuff, the patch included below is *NOT* a fix, it exists for testing purposes only and is missing things like, oh, necessary memory barriers for certain architectures. This examination has also turned up two possible bugs in userret(), which I describe later. CONTENTION TESTS My main goal is to try to remove all memory contention from the syscall, interrupt, and trap critical paths for two processes on an SMP build. I am focusing on the syscall path right now. The recent td_ucred stuff fixed some of this. We still have three pieces of contended memory in the standard syscall path. These are fairly important because the contention occurs in the critical path for every system call made. * the syscall counter * userret() / CURSIG handling * userret() / NEEDRESCHED handling I have rerun my contention tests with the most recent kernel + some hacks (FOR TESTING PURPOSES ONLY RIGHT NOW!). The kernel was compiled *without* WITNESS or DIAGNOSTIC. [------- SMP build -----] 1-Process 2-Process atomic syscall counter 860836 699591 -18.7% NOTE A no syscall counter 862822 768512 -10.9% NOTE A per-cpu syscall counter 882311 786000 -10.9% NOTE A per-cpu syscall counter 1004050 1001611 -0.2% NOTE B NOTE A: locking removed from userret for CURSIG case NOTE B: locking removed from userret for CURSIG *and* NEEDRESCHED test There are two interesting pieces of information I get out of this test. First, the difference between the atomic-locked syscall counter and the per-cpu syscall counter in the one-process case is fairly minor, but that it blows up in our faces the moment one runs more then one process. Specifically, that one atomic op results in a 8.5% loss in performance when two cpu's are contending for the global. This loss is cumulative so you can imagine the loss in a 4-cpu system. For some odd reason completely unknown to me, performance actually increased when I went from *NO* syscall counter to the per-cpu syscall counter! I have no clue as to why. I tested it several times! The second interesting piece of information is the performance gain that occurs when I don't get the sched_lock in userret() to do the initial NEEDRESCHED test (I'm already not getting Giant in the CURSIG code in userret() for all of the tests). Performance increases radically, by almost 16.3%, in the single-process case and, more importantly, the two-process case shows that there is no longer any contention between the processors. Not only that, but I think we can be proud of the fact that it is possible to achieve sub-1uS syscall overheads under SMP (well, the test box is a 1.1GHz machine :-)) It means that we are doing something right. WORKING ON THE ISSUE My conclusion is that it should be possible for us to remove critical path contention at least for system calls in fairly short order. I would like to persue this - that is, find real solutions for the three areas that my hacks show to be an issue (in regards to system calls). So I am opening up debate on how to fix these areas: * system call counter (and counters in the kernel in general) My current hack does not properly protect the counter. Properly speaking, due to not being a single instruction, the per-cpu must be protected by critical_enter()/critical_exit(). I am thinking of adding a PCPU_ADD_INT() macro to all architectures and putting all 'global' system counters in the per-cpu area, i.e. embed the struct vmmeter structure in the per-cpu area. sysctl would combine the information from all the per-cpu areas (i.e. for systat / vmstat reporting). ( I am not covering things like interface counters here, just global system counters ). Comments? * userret / CURSIG case. My current hack is somewhat messy. Presumably we will eventually be able to remove Giant from this path. The question is: When? And what is the current state of work in that area? Also, it seems to me that a signal can come in after the check (with or without my hack) and not get recognized until the next system call or interrupt. This is bad. Comments? John? * userret / NEEDRESCHED case. This case seems rather odd to me. I understand why we might need to obtain the sched_lock as a memory barrier but what happens if NEEDRESCHED is set after we release the sched_lock? Interrupts are enabled at the point where userret() is called, there is nothing preventing either a signal or a NEEDRESCHED from occuring after we've tested it but before we've returned to usermode, causing us to not honor either until the next interrupt or syscall. Has anyone grappled with this issue yet? -Matt Matthew Dillon (PATCH USED TO REPRODUCE THE ABOVE TESTS) Index: i386/i386/trap.c =================================================================== RCS file: /home/ncvs/src/sys/i386/i386/trap.c,v retrieving revision 1.220 diff -u -r1.220 trap.c --- i386/i386/trap.c 21 Mar 2002 19:27:15 -0000 1.220 +++ i386/i386/trap.c 29 Mar 2002 19:02:16 -0000 @@ -941,7 +941,14 @@ int args[8]; u_int code; + /* + * WARNING! FOR TESTING ONLY, per-cpu increment is not protected by + * critical_*() (add PCPU_INCR_INT macro?) + */ +#if 0 atomic_add_int(&cnt.v_syscall, 1); +#endif + ++*PCPU_PTR(v_syscall); #ifdef DIAGNOSTIC if (ISPL(frame.tf_cs) != SEL_UPL) { Index: kern/subr_trap.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_trap.c,v retrieving revision 1.212 diff -u -r1.212 subr_trap.c --- kern/subr_trap.c 21 Mar 2002 06:11:08 -0000 1.212 +++ kern/subr_trap.c 29 Mar 2002 18:43:43 -0000 @@ -72,13 +72,33 @@ struct ksegrp *kg = td->td_ksegrp; int sig; +#if 0 mtx_lock(&Giant); PROC_LOCK(p); while ((sig = CURSIG(p)) != 0) postsig(sig); PROC_UNLOCK(p); mtx_unlock(&Giant); +#else + PROC_LOCK(p); + if ((sig = CURSIG(p)) != 0) { + PROC_UNLOCK(p); + mtx_lock(&Giant); + PROC_LOCK(p); + while ((sig = CURSIG(p)) != 0) + postsig(sig); + PROC_UNLOCK(p); + mtx_unlock(&Giant); + } else { + PROC_UNLOCK(p); + } +#endif +#if 1 + if (td->td_priority != kg->kg_user_pri || + (ke->ke_flags & KEF_NEEDRESCHED) || + (p->p_sflag & PS_PROFIL)) { +#endif mtx_lock_spin(&sched_lock); td->td_priority = kg->kg_user_pri; if (ke->ke_flags & KEF_NEEDRESCHED) { @@ -106,8 +126,12 @@ ticks = ke->ke_sticks - oticks; mtx_unlock_spin(&sched_lock); addupc_task(ke, TRAPF_PC(frame), (u_int)ticks * psratio); - } else + } else { mtx_unlock_spin(&sched_lock); + } +#if 1 + } +#endif } /* Index: sys/pcpu.h =================================================================== RCS file: /home/ncvs/src/sys/sys/pcpu.h,v retrieving revision 1.7 diff -u -r1.7 pcpu.h --- sys/pcpu.h 20 Mar 2002 18:01:52 -0000 1.7 +++ sys/pcpu.h 29 Mar 2002 19:26:39 -0000 @@ -58,6 +58,10 @@ u_int pc_cpuid; /* This cpu number */ u_int pc_cpumask; /* This cpu mask */ u_int pc_other_cpus; /* Mask of all other cpus */ + /* + * XXX embedd vmmeter structure here? + */ + u_int pc_v_syscall; /* system calls counter */ SLIST_ENTRY(pcpu) pc_allcpu; struct lock_list_entry *pc_spinlocks; #ifdef KTR_PERCPU To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Mar 29 11:48:57 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 8902437B417 for ; Fri, 29 Mar 2002 11:48:52 -0800 (PST) Received: (qmail 11343 invoked from network); 29 Mar 2002 19:48:49 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 29 Mar 2002 19:48:49 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g2TJnJv01284; Fri, 29 Mar 2002 14:49:20 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200203291929.g2TJTIi59785@apollo.backplane.com> Date: Fri, 29 Mar 2002 14:48:30 -0500 (EST) From: John Baldwin To: Matthew Dillon Subject: RE: Syscall contention tests return, userret() bugs/issues. Cc: freebsd-smp@freebsd.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 29-Mar-2002 Matthew Dillon wrote: > * system call counter (and counters in the kernel in general) > > My current hack does not properly protect the counter. Properly > speaking, due to not being a single instruction, the per-cpu > must be protected by critical_enter()/critical_exit(). > > I am thinking of adding a PCPU_ADD_INT() macro to all architectures > and putting all 'global' system counters in the per-cpu area, i.e. > embed the struct vmmeter structure in the per-cpu area. sysctl > would combine the information from all the per-cpu areas (i.e. for > systat / vmstat reporting). > > ( I am not covering things like interface counters here, just global > system counters ). PCPU_SET(foo, PCPU_GET(foo) + 1) would work w/o a critical section actually. To be honest, stats such as these don't have to be perfect, so using a simple non-atomic increment is probably ok. :) > * userret / CURSIG case. > > My current hack is somewhat messy. Presumably we will eventually be > able to remove Giant from this path. The question is: When? And > what is the current state of work in that area? Also, it seems to > me that a signal can come in after the check (with or without my > hack) and not get recognized until the next system call or interrupt. > This is bad. > > Comments? John? The only reason Giant is in that path right now is for ktrace. :) When ktrace is fixed (coming as soon as I get all of td_ucred cleared and out of the way) then this won't need Giant anymore. Alternatively, could tweak it right now to make the Giant lock/unlock #ifdef KTRACE. > * userret / NEEDRESCHED case. > > This case seems rather odd to me. I understand why we might need to > obtain the sched_lock as a memory barrier but what happens if > NEEDRESCHED is set after we release the sched_lock? Interrupts > are enabled at the point where userret() is called, there is > nothing preventing either a signal or a NEEDRESCHED from occuring > after we've tested it but before we've returned to usermode, > causing us to not honor either until the next interrupt or syscall. > > Has anyone grappled with this issue yet? Yes, that is what the interrupt disable stuff in the old version of ast() (that is now MD) is about. If another process or thread on another CPU triggers an AST on this process, it will send an IPI when it does so. Thus, if we don't see the flag being set here, we will get the IPI via an interrupt after resuming in user mode. If you don't lock the access to ASTPENDING and NEEDRESCHED there is a small race on archs w/ weaker memory models (i.e. !i386) and SMP where you could miss the flag, however, since we always send the IPI in that case and interrupts usually implicitly enforce the equivalence of membars it will probably never occur. Also, if it did, all it would mean is possibly missing a reschedule or signal (the only AST's we get async) until the next kernel entry which really isn't that big of a deal. All of the MD code currently checks NEEDRESCHED and ASTPENDING w/o a lock right now anyways thanks to Jake's changes. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Mar 29 12:17:44 2002 Delivered-To: freebsd-smp@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 3B16037B41B; Fri, 29 Mar 2002 12:17:38 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g2TKHcD59955; Fri, 29 Mar 2002 12:17:38 -0800 (PST) (envelope-from dillon) Date: Fri, 29 Mar 2002 12:17:38 -0800 (PST) From: Matthew Dillon Message-Id: <200203292017.g2TKHcD59955@apollo.backplane.com> To: John Baldwin Cc: freebsd-smp@FreeBSD.org Subject: Re: RE: Syscall contention tests return, userret() bugs/issues. References: Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org :PCPU_SET(foo, PCPU_GET(foo) + 1) would work w/o a critical section actually. :To be honest, stats such as these don't have to be perfect, so using a simple :non-atomic increment is probably ok. :) I'm fairly sure that wouldn't work. The counter on one cpu will be different from another, so if you read one cpu's counter and write it to the other cpu's space the stats will not just be wrong, they will be blown to bits. I agree in regards to simply using a non-atomic increment for a stats counter. We would still have to use PCPU_PTR to keep it within a single cpu's per-cpu structure (even if we can't guarentee that it's OUR cpu's per-cpu structure), but C does not guarentee a single instruction for ++*ptr even though it generates it most of the time. Hence, a PCPU_ADD_INT() macro would be useful (non-locking, non-atomic, single-instruction add to the current cpu's BLAH counter). I could whip this up in about 10 seconds for i386 but would need help on the other architectures. What do you think about possibly embedding struct vmmeter in the per-cpu data? I haven't researched what kind of #include reordering would be necessary but I expect it would be fairly simple to do. :> My current hack is somewhat messy. Presumably we will eventually be :> able to remove Giant from this path. The question is: When? And :> what is the current state of work in that area? Also, it seems to :> me that a signal can come in after the check (with or without my :> hack) and not get recognized until the next system call or interrupt. :> This is bad. :> :> Comments? John? : :The only reason Giant is in that path right now is for ktrace. :) When ktrace :is fixed (coming as soon as I get all of td_ucred cleared and out of the way) :then this won't need Giant anymore. Alternatively, could tweak it right now to :make the Giant lock/unlock #ifdef KTRACE. Most people like to compile KTRACE into the kernel so I do not think we would gain much by #ifdef'ing around KTRACE just to optimize the path. I haven't looked into how much work is required re: ktrace but nothing else here would take me more then a day. I'm not in a huge rush so if you get bogged down on the ktrace stuff (e.g. 3-4 week timeframe) and need help just ring me up. I'll remind you then. In the mean time I would like to work on the stats counter and NEEDRESCHED userret issue. :> :> This case seems rather odd to me. I understand why we might need to :> obtain the sched_lock as a memory barrier but what happens if :> NEEDRESCHED is set after we release the sched_lock? Interrupts :> are enabled at the point where userret() is called, there is :> nothing preventing either a signal or a NEEDRESCHED from occuring :> after we've tested it but before we've returned to usermode, :> causing us to not honor either until the next interrupt or syscall. :> :> Has anyone grappled with this issue yet? : :Yes, that is what the interrupt disable stuff in the old version of ast() (that :is now MD) is about. If another process or thread on another CPU triggers an :AST on this process, it will send an IPI when it does so. Thus, if we don't :see the flag being set here, we will get the IPI via an interrupt after :resuming in user mode. If you don't lock the access to ASTPENDING and :NEEDRESCHED there is a small race on archs w/ weaker memory models (i.e. !i386) :and SMP where you could miss the flag, however, since we always send the IPI in :that case and interrupts usually implicitly enforce the equivalence of membars :it will probably never occur. Also, if it did, all it would mean is possibly :missing a reschedule or signal (the only AST's we get async) until the next :kernel entry which really isn't that big of a deal. : :All of the MD code currently checks NEEDRESCHED and ASTPENDING w/o a lock right :now anyways thanks to Jake's changes. : :-- : :John Baldwin <>< http://www.FreeBSD.org/~jhb/ Hmm. Ok, I see how it works. int0x80_syscall calls syscall() and then jumps to doreti, which checks for KEF_ASTPENDING or KEF_NEEDRESCHED with interrupts disabled prior to the iret. In that case, why is userret() checking KEF_NEEDRESCHED at all? Is it needed for non-i386 architectures or is it simply a lazy optimization? (lazy == technical term). It looks like the rescheduling code could be moved out of userret() and into ast() directly. Are signals dealt with the same way? If not we have a race in the signal handling code. If so we can probably move that to a KEF flag / ast() as well (which would either move the CURSIG/postsig loop from userret() or ast(), or move it and retain it in userret() as a lazy optimization whos initial CURSIG() check can be done without a lock. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Mar 29 12:40:15 2002 Delivered-To: freebsd-smp@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id B3BB037B416; Fri, 29 Mar 2002 12:40:08 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020329204008.WFFB1214.rwcrmhc54.attbi.com@InterJet.elischer.org>; Fri, 29 Mar 2002 20:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA00825; Fri, 29 Mar 2002 12:29:00 -0800 (PST) Date: Fri, 29 Mar 2002 12:28:59 -0800 (PST) From: Julian Elischer To: John Baldwin Cc: Robert Watson , smp@FreeBSD.ORG, Bruce Evans Subject: Re: suser() API change patch In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 29 Mar 2002, John Baldwin wrote: > > On 29-Mar-2002 Robert Watson wrote: > > > > On Thu, 28 Mar 2002, Julian Elischer wrote: > > > >> On Thu, 28 Mar 2002, Bruce Evans wrote: > >> > suser(thread, flag) could still exist (named somthing like suser_flag()) > >> > if it is used enough to justify it. My main point is that the flag is > >> > rarely used, so the interface shouldn't be bloated to pass it. > >> > > >> > Another point: td->td_ucred can only be safely used without locking > >> > if td is curthread. Our current code mostly assumes this. suser(td) > >> > can easily check that td is curthread, but this is a silly reason to > >> > use a bloated interface. It is just bug for bug compatible with passing > >> > thread pointers around a lot. > >> > >> Bruce does have a point.. > > > > I'll be the first to admit that. It actually suggests the API should be: > > > > int suser(void); /* implicitly curthread */ > > int suser_flags(int flags); /* implicitly curthread */ > > int suser_cred(struct ucred *cred, int flags); > > Well, is this what everyone wants then? I can change it if this is what > everyone agrees to. In a similar vein, should I get rid of the first argument > for all the p_canfoo() functions when I change that API as well? I think that Bruce is right.. td->td_ucred is only defined for td == curthread. By removing the argument we stop it being misused.. unless of course you add a KASSERT() instead.. Which is better? To get curthread in the function or to pass it in as an argument? Peter said that the former is quite a bit slower, but I have no information on that. There is nothing to stop people using suser_cred() to do the wrong thing.. e.g. suser_cred(other_thread->td_ucred, ....) I like that interface if it can be shown to be efficient.. > > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Mar 29 12:56:30 2002 Delivered-To: freebsd-smp@freebsd.org Received: from mail13.speakeasy.net (mail13.speakeasy.net [216.254.0.213]) by hub.freebsd.org (Postfix) with ESMTP id BFAFB37B41B for ; Fri, 29 Mar 2002 12:56:23 -0800 (PST) Received: (qmail 30666 invoked from network); 29 Mar 2002 20:56:22 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail13.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 29 Mar 2002 20:56:22 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g2TKvAv01540; Fri, 29 Mar 2002 15:57:10 -0500 (EST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200203292017.g2TKHcD59955@apollo.backplane.com> Date: Fri, 29 Mar 2002 15:56:22 -0500 (EST) From: John Baldwin To: Matthew Dillon Subject: Re: RE: Syscall contention tests return, userret() bugs/issues. Cc: freebsd-smp@FreeBSD.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 29-Mar-2002 Matthew Dillon wrote: >:PCPU_SET(foo, PCPU_GET(foo) + 1) would work w/o a critical section actually. >:To be honest, stats such as these don't have to be perfect, so using a simple >:non-atomic increment is probably ok. :) > > I'm fairly sure that wouldn't work. The counter on one cpu will be > different from another, so if you read one cpu's counter and write it > to the other cpu's space the stats will not just be wrong, they will > be blown to bits. Ah, doh, nm. > I agree in regards to simply using a non-atomic increment for a stats > counter. We would still have to use PCPU_PTR to keep it within a single > cpu's per-cpu structure (even if we can't guarentee that it's OUR cpu's > per-cpu structure), but C does not guarentee a single instruction for > ++*ptr even though it generates it most of the time. Hence, a > PCPU_ADD_INT() macro would be useful (non-locking, non-atomic, > single-instruction add to the current cpu's BLAH counter). I could > whip this up in about 10 seconds for i386 but would need help on the > other architectures. Actually, I was thinking of just using a single counter but only doing unlocked increments on it. It's just stats so it's not that important. If people really want to make it important then we should worry about getting it perfect, but if it doesn't need to be perfect I wouldn't worry about it. >:> My current hack is somewhat messy. Presumably we will eventually be >:> able to remove Giant from this path. The question is: When? And >:> what is the current state of work in that area? Also, it seems to >:> me that a signal can come in after the check (with or without my >:> hack) and not get recognized until the next system call or interrupt. >:> This is bad. >:> >:> Comments? John? >: >:The only reason Giant is in that path right now is for ktrace. :) When >:ktrace >:is fixed (coming as soon as I get all of td_ucred cleared and out of the way) >:then this won't need Giant anymore. Alternatively, could tweak it right now >:to >:make the Giant lock/unlock #ifdef KTRACE. > > Most people like to compile KTRACE into the kernel so I do not think > we would gain much by #ifdef'ing around KTRACE just to optimize the path. Yeah, tha thad occured to me. > I haven't looked into how much work is required re: ktrace but nothing > else here would take me more then a day. I'm not in a huge rush so if > you > get bogged down on the ktrace stuff (e.g. 3-4 week timeframe) and need > help just ring me up. I'll remind you then. In the mean time I would > like to work on the stats counter and NEEDRESCHED userret issue. The ktrace stuff is done, I just want to get the td_ucred stuff done first since it will include some slight changes to the ktrace stuff as far as arguments passed around to make suser and friends happier. Once that is done I'll update the ktrace stuff polish it up (the ktrgenio case still needs some work to make sure records still stay in order) and then it can be committed. >:> This case seems rather odd to me. I understand why we might need to >:> obtain the sched_lock as a memory barrier but what happens if >:> NEEDRESCHED is set after we release the sched_lock? Interrupts >:> are enabled at the point where userret() is called, there is >:> nothing preventing either a signal or a NEEDRESCHED from occuring >:> after we've tested it but before we've returned to usermode, >:> causing us to not honor either until the next interrupt or syscall. >:> >:> Has anyone grappled with this issue yet? >: >:Yes, that is what the interrupt disable stuff in the old version of ast() >:(that >:is now MD) is about. If another process or thread on another CPU triggers an >:AST on this process, it will send an IPI when it does so. Thus, if we don't >:see the flag being set here, we will get the IPI via an interrupt after >:resuming in user mode. If you don't lock the access to ASTPENDING and >:NEEDRESCHED there is a small race on archs w/ weaker memory models (i.e. >:!i386) >:and SMP where you could miss the flag, however, since we always send the IPI >:in >:that case and interrupts usually implicitly enforce the equivalence of >:membars >:it will probably never occur. Also, if it did, all it would mean is possibly >:missing a reschedule or signal (the only AST's we get async) until the next >:kernel entry which really isn't that big of a deal. >: >:All of the MD code currently checks NEEDRESCHED and ASTPENDING w/o a lock >:right >:now anyways thanks to Jake's changes. >: >:-- >: >:John Baldwin <>< http://www.FreeBSD.org/~jhb/ > > Hmm. Ok, I see how it works. int0x80_syscall calls syscall() and > then jumps to doreti, which checks for KEF_ASTPENDING or KEF_NEEDRESCHED > with interrupts disabled prior to the iret. Right. > In that case, why is userret() checking KEF_NEEDRESCHED at all? Is it > needed for non-i386 architectures or is it simply a lazy optimization? > (lazy == technical term). It looks like the rescheduling code could be > moved out of userret() and into ast() directly. Yes, it could. In fact, most of userret() probably could just move into ast() now. Part of this is due to the fact that ast() used to be an actual trap of type T_AST and relied on the fact that the trap return called userret(). The new ast() should only be checking NEEDRESCHED now inside of userret(). Either that or we merge ast() and userret() and call them userret() (I think userret() is the more sensible name personally.) > Are signals dealt with the same way? If not we have a race in the signal > handling code. If so we can probably move that to a KEF flag / ast() > as well (which would either move the CURSIG/postsig loop from userret() > or ast(), or move it and retain it in userret() as a lazy optimization > whos initial CURSIG() check can be done without a lock. Signals set ASTPENDING. Bruce does want to use a separate flag for signals so that we don't have to call CURSIG() except when a signal is actually pending. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message From owner-freebsd-smp Fri Mar 29 14: 3:18 2002 Delivered-To: freebsd-smp@freebsd.org Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by hub.freebsd.org (Postfix) with ESMTP id 86D9C37B419; Fri, 29 Mar 2002 14:02:46 -0800 (PST) Received: from sunfin.Finland.Sun.COM ([129.159.101.10]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14272; Fri, 29 Mar 2002 15:02:44 -0700 (MST) Received: from ultrahot.Finland.Sun.COM (ultrahot [129.159.101.87]) by sunfin.Finland.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id g2TM2h025754; Sat, 30 Mar 2002 00:02:43 +0200 (EET) Received: (from tomppa@localhost) by ultrahot.Finland.Sun.COM (8.11.6+Sun/8.11.6) id g2TM2gH00966; Sat, 30 Mar 2002 00:02:42 +0200 (EET) From: Tomi Vainio - Sun Finland - MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15524.58498.368763.510910@gargle.gargle.HOWL> Date: Sat, 30 Mar 2002 00:02:42 +0200 To: freebsd-smp@freebsd.org Cc: freebsd-current@freebsd.org Subject: Current SMP status with Intel PR440FX? X-Mailer: VM 7.00 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid Reply-To: Tomi.Vainio@Sun.COM Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, We've tried to get my brothers dual cpu intel pr440fx up with current cvsupped two days ago. This machine has worked just fine couple years with stable but we had some problems with latest X so we also updated system to current. We've been booting this system whole day just trying different kernels but didn't have any luck. Mostly system just freezes when it tries to lauch cpu1 so bad that we can't enter debugger. Last thing to do was GENERIC kernel with SMP+APIC_IO and with this we could access debugger the first time ever. Second boot using this same kernel succeeded but now we don't have enough courage to boot it again. CPU1 apic init message looks messy. I haven't seen any problems reported smp or current mailing lists. Tomppa Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #4: Fri Mar 29 22:55:16 EET 2002 ramppa@atom.kpnqwest.fi:/u/FreeBSD/obj/u/FreeBSD/src/sys/ATOM Preloaded elf kernel "/boot/kernel/kernel" at 0xc054a000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc054a0a8. Preloaded elf module "/boot/kernel/splash_bmp.ko" at 0xc054a0f8. Preloaded elf module "/boot/kernel/vesa.ko" at 0xc054a1a8. Calibrating clock(s) ... TSC clock: 198660631 Hz, i8254 clock: 1193158 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium Pro (198.67-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x619 Stepping = 9 Features=0xfbff real memory = 268435456 (262144K bytes) Physical memory chunk(s): 0x00001000 - 0x0009efff, 647168 bytes (158 pages) 0x00574000 - 0x0fff7fff, 262684672 bytes (64132 pages) avail memory = 255340544 (249356K bytes) Programming 24 pins in IOAPIC #0 SMP: CPU0 apic_initialize(): lint0: 0x00000700 lint1: 0x00010400 TPR: 0x00000010 SVR: 0x000001ff FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfec08000 cpu1 (AP): apic id: 12, version: 0x00040011, at 0xfec08000 io0 (APIC): apic id: 13, version: 0x00170011, at 0xfec00000 bios32: Found BIOS32 Service Directory header at 0xc00fd9e0 bios32: Entry = 0xfd9f0 (c00fd9f0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xda11 pnpbios: Found PnP BIOS data at 0xc00fa000 pnpbios: Entry = f0000:a100 Rev = 1.0 Other BIOS signatures found: null: random: mem: Pentium Pro MTRR support enabled VESA: information block 56 45 53 41 00 02 d7 74 00 c0 01 00 00 00 22 00 00 01 40 00 05 02 ec 74 00 c0 f3 74 00 c0 fe 74 00 c0 00 01 01 01 02 01 03 01 05 01 07 01 08 01 09 01 0b 01 0c 01 10 01 11 01 12 01 13 01 14 01 VESA: 24 mode(s) found VESA: v2.0, 4096k memory, flags:0x1, mode table:0xc05472a2 (1000022) VESA: Matrox Graphics Inc. VESA: Matrox MILLENNIUM 00 module_register_init: MOD_LOAD (splash_bmp, 0xc053f8c8, 0) error 2 SMP: CPU0 bsp_apic_configure(): lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000010 SVR: 0x000001ff pci_open(1): mode 1 addr port (0x0cf8) is 0x80005848 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=12378086) npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard pci0: physical bus=0 found-> vendor=0x8086, dev=0x1237, revid=0x02 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 IOAPIC #0 intpin 18 -> irq 2 Freeing (NOT implemented) redirected PCI irq 11. map[10]: type 3, range 32, base ffbe8000, size 12, enabled map[14]: type 4, range 32, base 0000ff40, size 5, enabled map[18]: type 1, range 32, base ff800000, size 20, enabled found-> vendor=0x8086, dev=0x1229, revid=0x01 bus=0, slot=6, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=2 found-> vendor=0x8086, dev=0x7000, revid=0x01 bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 map[20]: type 4, range 32, base 0000ffa0, size 4, enabled found-> vendor=0x8086, dev=0x7010, revid=0x00 bus=0, slot=7, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 IOAPIC #0 intpin 17 -> irq 10 map[10]: type 4, range 32, base 0000fc00, size 8, enabled map[14]: type 1, range 32, base ffbeb000, size 12, enabled found-> vendor=0x9004, dev=0x8078, revid=0x00 bus=0, slot=9, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=10 IOAPIC #0 intpin 16 -> irq 11 map[10]: type 1, range 32, base ffbec000, size 14, enabled map[14]: type 3, range 32, base ff000000, size 23, enabled found-> vendor=0x102b, dev=0x0519, revid=0x01 bus=0, slot=11, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=11 map[10]: type 3, range 32, base ffbe9000, size 12, enabled found-> vendor=0x109e, dev=0x0351, revid=0x12 bus=0, slot=15, func=0 class=04-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=10 pci0: on pcib0 fxp0: port 0xff40-0xff5f mem 0xff800000-0xff8fffff,0xffbe8000-0xffbe8fff irq 2 at device 6.0 on pci0 fxp0: using memory space register mapping fxp0: Ethernet address 00:a0:c9:06:c8:b4 fxp0: PCI IDs: 8086 1229 0000 0000 0001 fxp0: Dynamic Standby mode is disabled nsphy0: on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bpf: fxp0 attached isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf at device 7.1 on pci0 ata0: iobase=0x01f0 altiobase=0x03f6 bmaddr=0xffa0 ata0: mask=03 ostat0=50 ostat2=00 ata0-master: ATAPI 14 eb ata0-slave: ATAPI 00 00 ata0: mask=03 stat0=00 stat1=00 ata0: devices=04 ata0: at 0x1f0 irq 14 on atapci0 ata1: iobase=0x0170 altiobase=0x0376 bmaddr=0xffa8 ata1: at 0x170 irq 15 on atapci0 ahc0: port 0xfc00-0xfcff mem 0xffbeb000-0xffbebfff irq 10 at device 9.0 on pci0 ahc0: Reading SEEPROM...done. ahc0: High byte termination Enabled ahc0: Downloading Sequencer Program... 439 instructions downloaded aic7880: Ultra Wide Channel A, SCSI Id=7, 16/255 SCBs pci0: at device 11.0 (no driver attached) pci0: at device 15.0 (no driver attached) ata: ata0 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 ex_isa_identify() pnpbios: 16 devices, largest 126 bytes PNP0201: adding io range 0-0xf, size=0x10, align=0x1 PNP0201: adding io range 0x80-0x90, size=0x11, align=0x1 PNP0201: adding io range 0x94-0x9f, size=0xc, align=0x1 PNP0201: adding io range 0xc0-0xde, size=0x1f, align=0x1 PNP0201: adding io range 0x40b-0x40b, size=0x1, align=0x1 PNP0201: adding io range 0x410-0x43f, size=0x30, align=0x1 PNP0201: adding io range 0x481-0x483, size=0x3, align=0x1 PNP0201: adding io range 0x487-0x487, size=0x1, align=0x1 PNP0201: adding io range 0x489-0x48c, size=0x4, align=0x1 PNP0201: adding io range 0x4d6-0x4d6, size=0x1, align=0x1 PNP0201: adding dma mask 0x10 pnpbios: handle 1 device ID PNP0201 (0102d041) PNP0100: adding io range 0x40-0x43, size=0x4, align=0x1 PNP0100: adding irq mask 0x1 pnpbios: handle 2 device ID PNP0100 (0001d041) PNP0b00: adding io range 0x70-0x71, size=0x2, align=0x1 PNP0b00: adding irq mask 0x100 pnpbios: handle 3 device ID PNP0b00 (000bd041) PNP0800: adding io range 0x61-0x61, size=0x1, align=0x1 pnpbios: handle 4 device ID PNP0800 (0008d041) PNP0c04: adding io range 0xf0-0xff, size=0x10, align=0x1 PNP0c04: adding irq mask 0x2000 pnpbios: handle 5 device ID PNP0c04 (040cd041) PNP0303: adding io range 0x60-0x60, size=0x1, align=0x1 PNP0303: adding io range 0x64-0x64, size=0x1, align=0x1 PNP0303: adding irq mask 0x2 pnpbios: handle 6 device ID PNP0303 (0303d041) PNP0f13: adding irq mask 0x1000 pnpbios: handle 7 device ID PNP0f13 (130fd041) PNP0c01: adding fixed memory32 range 0xe8000-0xfffff, size=0x18000 PNP0c01: adding fixed memory32 range 0-0x9ffff, size=0xa0000 PNP0c01: adding fixed memory32 range 0x100000-0xfffffff, size=0xff00000 PNP0c01: adding fixed memory32 range 0xffe80000-0xffffffff, size=0x180000 PNP0c01: adding fixed memory32 range 0xfec00000-0xfec08fff, size=0x9000 pnpbios: handle 8 device ID PNP0c01 (010cd041) PNP0a03: adding io range 0xcf8-0xcff, size=0x8, align=0x1 pnpbios: handle 9 device ID PNP0a03 (030ad041) PNP0700: adding io range 0x3f2-0x3f5, size=0x4, align=0x1 PNP0700: adding irq mask 0x40 PNP0700: adding dma mask 0x4 pnpbios: handle 10 device ID PNP0700 (0007d041) pnpbios: handle 11 device ID PNP0400 (0004d041) pnpbios: handle 12 device ID PNP0501 (0105d041) pnpbios: handle 13 device ID PNP0501 (0105d041) PNP0c02: adding io range 0x78-0x7f, size=0x8, align=0x1 PNP0c02: adding io range 0x2e-0x2f, size=0x2, align=0x1 pnpbios: handle 14 device ID PNP0c02 (020cd041) pnpbios: handle 15 device ID PNP0c02 (020cd041) sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: