From owner-freebsd-smp Sun Jun 1 11:58:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA00931 for smp-outgoing; Sun, 1 Jun 1997 11:58:15 -0700 (PDT) Received: from tweetie-bird.cs.washington.edu (tweetie-bird.cs.washington.edu [128.95.2.46]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA00926 for ; Sun, 1 Jun 1997 11:58:13 -0700 (PDT) From: mef@cs.washington.edu Received: (mef@localhost) by tweetie-bird.cs.washington.edu (8.7.2/7.2ws+) id LAA03066; Sun, 1 Jun 1997 11:58:10 -0700 (PDT) Date: Sun, 1 Jun 1997 11:58:10 -0700 (PDT) Message-Id: <199706011858.LAA03066@tweetie-bird.cs.washington.edu> To: smp@csn.net CC: smp@FreeBSD.ORG, ulbright@cs.washington.edu In-reply-to: <199705281813.MAA13794@Ilsa.StevesCafe.com> (message from Steve Passe on Wed, 28 May 1997 12:13:38 -0600) Subject: Re: SMP_PRIVPAGES Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk From: Steve Passe Date: Wed, 28 May 1997 12:13:38 -0600 > What is the plan with using the SMP_PRIVPAGES stuff? Does it work? > (well, I'll find out in an hour or so). not yet, but hopefully soon. It seems to break pretty early on. :( M From owner-freebsd-smp Mon Jun 2 00:47:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA05155 for smp-outgoing; Mon, 2 Jun 1997 00:47:43 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA05150 for ; Mon, 2 Jun 1997 00:47:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with SMTP id AAA29950 for ; Mon, 2 Jun 1997 00:49:25 -0700 (PDT) Message-Id: <199706020749.AAA29950@implode.root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: smp@freebsd.org Subject: 233MHz with PR440FX From: David Greenman Reply-To: dg@root.com Date: Mon, 02 Jun 1997 00:49:25 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk To get the CPUs on the Intel PR440FX motherboard to run at 233MHz (3.5X), move the "G" jumper to the "up" position. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-smp Mon Jun 2 00:57:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA05621 for smp-outgoing; Mon, 2 Jun 1997 00:57:49 -0700 (PDT) Received: from tfs.com (tfs.com [140.145.250.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA05612 for ; Mon, 2 Jun 1997 00:57:47 -0700 (PDT) Received: from critter.dk.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0wYRzP-0003xWC; Mon, 2 Jun 97 00:57 PDT Received: from critter.dk.tfs.com (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.5/8.8.5) with ESMTP id JAA08556; Mon, 2 Jun 1997 09:55:15 +0200 (CEST) To: dg@root.com cc: smp@freebsd.org From: Poul-Henning Kamp Subject: Re: 233MHz with PR440FX In-reply-to: Your message of "Mon, 02 Jun 1997 00:49:25 PDT." <199706020749.AAA29950@implode.root.com> Date: Mon, 02 Jun 1997 09:55:15 +0200 Message-ID: <8554.865238115@critter.dk.tfs.com> Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199706020749.AAA29950@implode.root.com>, David Greenman writes: > To get the CPUs on the Intel PR440FX motherboard to run at 233MHz (3.5X), >move the "G" jumper to the "up" position. Ohh, I did that a week ago, sorry for not telling. Runs like a breeze. Well, a major storm actually :-) -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-smp Mon Jun 2 03:28:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA11491 for smp-outgoing; Mon, 2 Jun 1997 03:28:31 -0700 (PDT) Received: from spinner.dialix.com.au (spinner.dialix.com.au [192.203.228.67]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA11484 for ; Mon, 2 Jun 1997 03:28:27 -0700 (PDT) Received: from spinner.dialix.com.au (localhost.dialix.com.au [127.0.0.1]) by spinner.dialix.com.au with ESMTP id SAA23055; Mon, 2 Jun 1997 18:28:02 +0800 (WST) Message-Id: <199706021028.SAA23055@spinner.dialix.com.au> X-Mailer: exmh version 2.0gamma 1/27/96 To: Poul-Henning Kamp cc: dg@root.com, smp@FreeBSD.ORG Subject: Re: 233MHz with PR440FX In-reply-to: Your message of "Mon, 02 Jun 1997 09:55:15 +0200." <8554.865238115@critter.dk.tfs.com> Date: Mon, 02 Jun 1997 18:28:01 +0800 From: Peter Wemm Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Poul-Henning Kamp wrote: > In message <199706020749.AAA29950@implode.root.com>, David Greenman writes: > > To get the CPUs on the Intel PR440FX motherboard to run at 233MHz (3.5X), > >move the "G" jumper to the "up" position. > > Ohh, I did that a week ago, sorry for not telling. > > Runs like a breeze. > > Well, a major storm actually :-) On that note, is there a working set of isapnp stuff around? There's been one floating around, I think originally for FreeBSD, but I see that NetBSD and OpenBSD have one now.. Are they related, does anybody know? (The reason I ask is the isapnp SB-clone audio stuff on the motherboard) > -- > Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. > http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. > whois: [PHK] | phk@tfs.com TRW Financial Systems, In c. > Power and ignorance is a disgusting cocktail. Cheers, -Peter From owner-freebsd-smp Mon Jun 2 03:31:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA11558 for smp-outgoing; Mon, 2 Jun 1997 03:31:48 -0700 (PDT) Received: from tfs.com (tfs.com [140.145.250.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id DAA11553 for ; Mon, 2 Jun 1997 03:31:47 -0700 (PDT) Received: from critter.dk.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0wYUON-0003zCC; Mon, 2 Jun 97 03:31 PDT Received: from critter.dk.tfs.com (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.5/8.8.5) with ESMTP id MAA08925; Mon, 2 Jun 1997 12:29:13 +0200 (CEST) To: Peter Wemm cc: Poul-Henning Kamp , dg@root.com, smp@FreeBSD.ORG From: Poul-Henning Kamp Subject: Re: 233MHz with PR440FX In-reply-to: Your message of "Mon, 02 Jun 1997 18:28:01 +0800." <199706021028.SAA23055@spinner.dialix.com.au> Date: Mon, 02 Jun 1997 12:29:13 +0200 Message-ID: <8923.865247353@critter.dk.tfs.com> Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <199706021028.SAA23055@spinner.dialix.com.au>, Peter Wemm writes: >On that note, is there a working set of isapnp stuff around? There's been >one floating around, I think originally for FreeBSD, but I see that NetBSD >and OpenBSD have one now.. Are they related, does anybody know? (The >reason I ask is the isapnp SB-clone audio stuff on the motherboard) yeah, somebody did a pretty complete job at it I belive. Look for for isapnp ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-smp Mon Jun 2 12:47:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA07861 for smp-outgoing; Mon, 2 Jun 1997 12:47:50 -0700 (PDT) Received: from mail.vlsi.fi (0fo/rTKmPLnBK4PbjJ2Sb3DovKlq9BZd@mail.vlsi.fi [195.74.10.147]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA07851 for ; Mon, 2 Jun 1997 12:47:46 -0700 (PDT) Received: (from smap@localhost) by mail.vlsi.fi (8.7.6/8.7.3) id WAA11228; Mon, 2 Jun 1997 22:46:49 +0300 (EET DST) Received: from vlsi1.vlsi.fi(193.64.2.2) by mail.vlsi.fi via smap (V1.3) id sma011226; Mon Jun 2 22:46:20 1997 Received: from layout.vlsi.fi by vlsi1.vlsi.fi with ESMTP (1.37.109.16/16.2) id AA015800779; Mon, 2 Jun 1997 22:46:19 +0300 Received: by layout.vlsi.fi (1.37.109.15/16.2) id AA111130778; Mon, 2 Jun 1997 22:46:18 +0300 Date: Mon, 2 Jun 1997 22:46:18 +0300 Message-Id: <199706021946.AA111130778@layout.vlsi.fi> From: Ville Eerola To: dg@root.com Cc: smp@FreeBSD.ORG Subject: Re: 233MHz with PR440FX In-Reply-To: <199706020749.AAA29950@implode.root.com> References: <199706020749.AAA29950@implode.root.com> X-Mailer: VM Version 5.93 (beta) under GNU Emacs 19.29.6 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk David Greenman writes: > To get the CPUs on the Intel PR440FX motherboard to run at 233MHz (3.5X), > move the "G" jumper to the "up" position. Thanks a lot! This was the missing piece of information I have been trying to find out... Intel didn't really document these. Did you find the jumper settings for the other multipliers also? > -DG Regards, Ville -- Ville.Eerola@vlsi.fi VLSI Solution Oy Tel:+358 3 3165579 Hermiankatu 6-8 C Fax:+358 3 3165220 FIN-33720 Tampere, Finland From owner-freebsd-smp Mon Jun 2 14:02:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA12245 for smp-outgoing; Mon, 2 Jun 1997 14:02:41 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA12236 for ; Mon, 2 Jun 1997 14:02:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with SMTP id OAA02593; Mon, 2 Jun 1997 14:04:14 -0700 (PDT) Message-Id: <199706022104.OAA02593@implode.root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: Ville Eerola cc: smp@FreeBSD.ORG Subject: Re: 233MHz with PR440FX In-reply-to: Your message of "Mon, 02 Jun 1997 22:46:18 +0300." <199706021946.AA111130778@layout.vlsi.fi> From: David Greenman Reply-To: dg@root.com Date: Mon, 02 Jun 1997 14:04:14 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >David Greenman writes: >> To get the CPUs on the Intel PR440FX motherboard to run at 233MHz (3.5X), >> move the "G" jumper to the "up" position. > >Thanks a lot! This was the missing piece of information I have been >trying to find out... Intel didn't really document these. Did you find >the jumper settings for the other multipliers also? I didn't do an exhaustive search, but I did stumble across "E" in the up position and the rest in the down position gives 2x (133MHz). Given this information and knowledge about how the configuration pins on the P6 work, you could probably determine the rest of the multipliers. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-smp Mon Jun 2 14:14:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA12902 for smp-outgoing; Mon, 2 Jun 1997 14:14:58 -0700 (PDT) Received: from wlk.com (news.wlk.com [192.86.83.250]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA12884 for ; Mon, 2 Jun 1997 14:14:55 -0700 (PDT) Received: from SMTPdaemon by wlk.com (smail3.2) with SMTPL id m0wYeR3-0009s4C; Mon, 2 Jun 1997 16:14:37 -0500 (CDT) Received: from critter.dk.tfs.com (localhost [127.0.0.1]) by critter.dk.tfs.com (8.8.5/8.8.5) with ESMTP id XAA10514; Mon, 2 Jun 1997 23:11:02 +0200 (CEST) To: dg@root.com cc: Ville Eerola , smp@FreeBSD.ORG From: Poul-Henning Kamp Subject: Re: 233MHz with PR440FX In-reply-to: Your message of "Mon, 02 Jun 1997 14:04:14 PDT." <199706022104.OAA02593@implode.root.com> Date: Mon, 02 Jun 1997 23:11:02 +0200 Message-ID: <10512.865285862@critter.dk.tfs.com> Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In message <199706022104.OAA02593@implode.root.com>, David Greenman writes: >>David Greenman writes: >>> To get the CPUs on the Intel PR440FX motherboard to run at 233MHz (3.5X) >, >>> move the "G" jumper to the "up" position. >> >>Thanks a lot! This was the missing piece of information I have been >>trying to find out... Intel didn't really document these. Did you find >>the jumper settings for the other multipliers also? > > I didn't do an exhaustive search, but I did stumble across "E" in the up >position and the rest in the down position gives 2x (133MHz). Given this >information and knowledge about how the configuration pins on the P6 work, >you could probably determine the rest of the multipliers. The F jumper is the 60/66 jumper (Up for 60MHz) -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@tfs.com TRW Financial Systems, Inc. Power and ignorance is a disgusting cocktail. From owner-freebsd-smp Mon Jun 2 19:40:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA28877 for smp-outgoing; Mon, 2 Jun 1997 19:40:40 -0700 (PDT) Received: from george.lbl.gov (george-2.lbl.gov [131.243.2.12]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id TAA28872; Mon, 2 Jun 1997 19:40:38 -0700 (PDT) Received: (jin@localhost) by george.lbl.gov (8.6.10/8.6.5) id TAA16816; Mon, 2 Jun 1997 19:40:32 -0700 Date: Mon, 2 Jun 1997 19:40:32 -0700 From: "Jin Guojun[ITG]" Message-Id: <199706030240.TAA16816@george.lbl.gov> To: smp@csn.net Subject: Re: SMP (3.0-970527-SNAP) on dual pentium machines Cc: hardware@FreeBSD.ORG, smp@FreeBSD.ORG Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk } > I have two different dual pentium motherboards: } > 1) ASUS P/I-P65UP5 with C-P55T2D } > 2) TYAN S1563D } > } > neither of them really gets worked for SMP. Here is the testing result by } > using pthread library -lc_r: } > } > ----------------------- } > } > FreeBSD with single CPU: } > 60 /data/src: vfft mri.b128 > /dev/null } > 9.7u 0.1s 0:09.95 99.3% 97+11132k 0+0io 0pf+0w } > } > FreeBSD with dual CPU + pthread (failure SMP): } > 62 /data/src: vfft.mt < mri.b128 > /dev/null } > 9.5u 0.2s 0:09.83 99.1% 77+11822k 0+0io 0pf+0w } > } > } > ----------------------- } > } > Solaris 2.5.1.u8 with single CPU: } > 67 /home/data/src: vfft mri.b128 > /dev/null } > 12.0u 0.0s 0:13 87% 0+0k 0+0io 0pf+0w } > } > Solaris 2.5.1.u8 with dual CPU + thread (SMP): } > 69 /home/data/src: vfft.mt mri.b128 > /dev/null } > 12.0u 0.0s 0:07 168% 0+0k 0+0io 0pf+0w } > } > ----------------------- Actually, I had a mistake on testing of FreeBSD with dual CPU + pthread. The SMP /kernel.smp was not booted when doing above testing due to some problem. After trying different SMP options for SMP kernel, I still cannot make it work on these two motherboards. Both systems have page fault (12) after message: apm0: disabled, not probed. (cpu#0) panic: page fault ... The /sys/i386/conf/KSMP configuration file is attached at end of this message. } what you are demonstrating is the fact that we do not yet have kernel threads } working. The threads provided by our libc_r all run in one process, thus no } improvement in thruput for your test. } } Note that FreeBSD does much better (if I'm reading thse right) than Solaris } in the single CPU test. Once we have kernel threads we should also do } substantially better than Solaris in the MP test. Yes. What you read is the truth. In comparing BSD/OS, FreeBSD, Solaris.x86, FreeBSD has the best performance at most areas. That is the reason that we are working on FreeBSD for developing high end file server. It is appreciated if some one can tell me if above motherboards have been tested under FreeBSD 3.0. If not, what are the motherboards tested for SMP version? I do really like to run FreeBSD on some dual pentium (not P6) boxes. Thanks, -Jin From owner-freebsd-smp Mon Jun 2 20:33:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA00887 for smp-outgoing; Mon, 2 Jun 1997 20:33:22 -0700 (PDT) Received: from trout.nosc.mil (trout.nosc.mil [128.49.16.7]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id UAA00882 for ; Mon, 2 Jun 1997 20:33:20 -0700 (PDT) Received: from cod.nosc.mil by trout.nosc.mil (4.1/SMI-4.1) id AA22711; Mon, 2 Jun 97 20:33:18 PDT Received: by cod.nosc.mil (4.1/SMI-4.1) id AA20318; Mon, 2 Jun 97 20:33:18 PDT Date: Mon, 2 Jun 97 20:33:18 PDT From: gshaffer@cod.nosc.mil (Gregory M. Shaffer) Message-Id: <9706030333.AA20318@cod.nosc.mil> To: smp@freebsd.org Cc: gshaffer@cod.nosc.mil Subject: Parallel make worlds Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ------- I noticed that when I do a 'make -j 8 world' I do not get the extra speed benefit of my second CPU. I searched the mailing list archives at www.freebsd.org for info on parallel make worlds. I did not find any definitive answer that this is even possible or advisable. I would like to take advatange of this if at all possible. Can some kind soul please point me in the right direction or provide me with the required modes to make this happen. Thanks Greg Shaffer ------- From owner-freebsd-smp Mon Jun 2 21:39:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA03487 for smp-outgoing; Mon, 2 Jun 1997 21:39:33 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA03448 for ; Mon, 2 Jun 1997 21:39:30 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id WAA15897; Mon, 2 Jun 1997 22:29:15 -0600 (MDT) Message-Id: <199706030429.WAA15897@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: gshaffer@cod.nosc.mil (Gregory M. Shaffer) cc: smp@FreeBSD.ORG Subject: Re: Parallel make worlds In-reply-to: Your message of "Mon, 02 Jun 1997 20:33:18 PDT." <9706030333.AA20318@cod.nosc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 02 Jun 1997 22:29:15 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > ------- > I noticed that when I do a 'make -j 8 world' I do not get the extra speed > benefit of my second CPU. I searched the mailing list archives at > www.freebsd.org for info on parallel make worlds. I did not find any > definitive answer that this is even possible or advisable. I would like to > take advatange of this if at all possible. Can some kind soul please point > me in the right direction or provide me with the required modes to make this > happen. I too would love to be able to do this, but it doesn't currently work. There is a fair degree of work to be done to the /usr/share/mk/* files for it to be possible. My first experiments with it showed problems with dependancies for *.y files (lex,yacc stuff), as well as other misc. things. The basic problem is that these files, as well as some of the actual Makefiles, do not define the dependancies well enough for a parallel system. When run on a single CPU system they work OK, but fall apart when races occure between 2 or more CPUs. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Jun 4 07:40:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA01289 for smp-outgoing; Wed, 4 Jun 1997 07:40:38 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA01281 for ; Wed, 4 Jun 1997 07:40:32 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id AAA15900 for smp@freebsd.org; Thu, 5 Jun 1997 00:10:30 +0930 (CST) From: Michael Smith Message-Id: <199706041440.AAA15900@genesis.atrad.adelaide.edu.au> Subject: Supermicro SMP boards? To: smp@freebsd.org Date: Thu, 5 Jun 1997 00:10:29 +0930 (CST) X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk G'day; in brief, I've been offered a Supermicro board (either a P6*E or F, it's not immediately clear), for around AUD$300 (US$240). I've been toying with the idea of building a new machine, and an SMP box sounds like a lot of fun. Is this a bearable price? Is the board a goer, or a lemon? (yes, I've noted the two are listed on the SMP pages) Any other suggestions while I'm at it? Ta! -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-smp Wed Jun 4 07:54:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA02033 for smp-outgoing; Wed, 4 Jun 1997 07:54:37 -0700 (PDT) Received: from spinner.dialix.com.au (spinner.dialix.com.au [192.203.228.67]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA02022 for ; Wed, 4 Jun 1997 07:54:20 -0700 (PDT) Received: from spinner.dialix.com.au (localhost.dialix.com.au [127.0.0.1]) by spinner.dialix.com.au with ESMTP id WAA18319; Wed, 4 Jun 1997 22:53:51 +0800 (WST) Message-Id: <199706041453.WAA18319@spinner.dialix.com.au> X-Mailer: exmh version 2.0gamma 1/27/96 To: Michael Smith cc: smp@FreeBSD.ORG Subject: Re: Supermicro SMP boards? In-reply-to: Your message of "Thu, 05 Jun 1997 00:10:29 +0930." <199706041440.AAA15900@genesis.atrad.adelaide.edu.au> Date: Wed, 04 Jun 1997 22:53:50 +0800 From: Peter Wemm Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Michael Smith wrote: > > G'day; in brief, I've been offered a Supermicro board (either a P6*E > or F, it's not immediately clear), for around AUD$300 (US$240). > > I've been toying with the idea of building a new machine, and an SMP > box sounds like a lot of fun. Is this a bearable price? Is the board > a goer, or a lemon? (yes, I've noted the two are listed on the SMP > pages) > > Any other suggestions while I'm at it? Ta! The only thing that I'm aware of is that the timer0 (the 100Hz timer) is only connected to the 8259 pic emulation and doesn't reach the IO apic. The PIIX3 seems to have a design choice where it's possible to reuse the pin that would be the irq0 output to the IO apic instead as a steerable motherboard interrupt, eg from the second IDE. It's possible to reprogram this in the piix3, but from my understandingm this is a motherboard design issue and not something we can get away with. However, the SuperMicro board in question does have a workaround, see the option SMP_TIMER_NC, where the 8259 is set up so that it provides a daisy chained interrupt to the IO apic, and we treat that as an IRQ0. This works for only one interrupt though since there's no way to tell which irq on the 8259 triggered the apic. (only the input for the irq0 is unmasked on the 8259 so it doesn't matter). In the SMP-GENERIC file: # SuperMicro P6DNxxx: #options SMP_TIMER_NC # 8254 NOT connected to APIC I don't know if this is the same board, but could be. > -- > ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ > ]] Genesis Software genesis@gsoft.com.au [[ > ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ > ]] realtime instrument control. (ph) +61-8-8267-3493 [[ > ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ Cheers, -Peter From owner-freebsd-smp Wed Jun 4 08:06:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA02605 for smp-outgoing; Wed, 4 Jun 1997 08:06:19 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA02600 for ; Wed, 4 Jun 1997 08:06:13 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id AAA16049; Thu, 5 Jun 1997 00:35:45 +0930 (CST) From: Michael Smith Message-Id: <199706041505.AAA16049@genesis.atrad.adelaide.edu.au> Subject: Re: Supermicro SMP boards? In-Reply-To: <199706041453.WAA18319@spinner.dialix.com.au> from Peter Wemm at "Jun 4, 97 10:53:50 pm" To: peter@spinner.dialix.com.au (Peter Wemm) Date: Thu, 5 Jun 1997 00:35:45 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, smp@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Peter Wemm stands accused of saying: > > However, the SuperMicro board in question does have a workaround, see the > option SMP_TIMER_NC, where the 8259 is set up so that it provides a daisy > chained interrupt to the IO apic, and we treat that as an IRQ0. This works Fair enough; this is only listed for the E and not the F board - is it actually an issue for both? Either way, and more relevant to me given your more local context, is this a reasonable price for a dual P6 board? Ta! -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-smp Wed Jun 4 08:29:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA03756 for smp-outgoing; Wed, 4 Jun 1997 08:29:29 -0700 (PDT) Received: from nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA03748 for ; Wed, 4 Jun 1997 08:29:25 -0700 (PDT) Received: from herring.nlsystems.com (herring.nlsystems.com [10.0.0.2]) by nlsystems.com (8.8.5/8.8.5) with SMTP id QAA14081; Wed, 4 Jun 1997 16:29:27 +0100 (BST) Date: Wed, 4 Jun 1997 16:29:27 +0100 (BST) From: Doug Rabson To: Michael Smith cc: smp@freebsd.org Subject: Re: Supermicro SMP boards? In-Reply-To: <199706041440.AAA15900@genesis.atrad.adelaide.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 5 Jun 1997, Michael Smith wrote: > > G'day; in brief, I've been offered a Supermicro board (either a P6*E > or F, it's not immediately clear), for around AUD$300 (US$240). > > I've been toying with the idea of building a new machine, and an SMP > box sounds like a lot of fun. Is this a bearable price? Is the board > a goer, or a lemon? (yes, I've noted the two are listed on the SMP > pages) > > Any other suggestions while I'm at it? Ta! I am using a P6DNE with 2xP6/200 and I'm very happy with it. I needed the SMP_TIMER_NC option to get it to work but other than that its works fine. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 Fax: +44 181 381 1039 From owner-freebsd-smp Wed Jun 4 13:50:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA08752 for smp-outgoing; Wed, 4 Jun 1997 13:50:02 -0700 (PDT) Received: from csla.csl.sri.com (csla.csl.sri.com [192.12.33.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA08713 for ; Wed, 4 Jun 1997 13:50:00 -0700 (PDT) Received: from japonica.csl.sri.com (japonica.csl.sri.com [130.107.15.17]) by csla.csl.sri.com (8.7.3/8.7.3) with ESMTP id NAA19323 for ; Wed, 4 Jun 1997 13:46:13 -0700 (PDT) Received: from japonica.csl.sri.com (localhost.csl.sri.com [127.0.0.1]) by japonica.csl.sri.com (8.8.5/8.7.3) with ESMTP id NAA00917 for ; Wed, 4 Jun 1997 13:48:54 -0700 (PDT) Message-Id: <199706042048.NAA00917@japonica.csl.sri.com> To: smp@FreeBSD.ORG Subject: Super Micro P6DOF (was Re: Supermicro SMP boards?) Date: Wed, 04 Jun 1997 13:48:53 -0700 From: Fred Gilham Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hello, I'm trying to use SMP with a Super Micro P6DOF board. I find that it dies at random intervals with the SMP kernel, while running OK with the UP kernel. The SMP crashes tend to happen while running X, especially with some xlock screen hack. One thing I've noticed is that after a while even the UP kernel will seem to `lose' timing information, i.e. on my performance meter I'll stop seeing CPU activity at all and in top all the CPU percentages will be 0. I assumed this had something to do with the SMP_TIMER_NC option but when I run the SMP kernel with that option I get a panic with the message, ``8254 Redirect Impossible''. E.g. here's part of the `top' display, showing all the CPU states percentages as zero: ---------------------------------------- last pid: 875; load averages: 0.19, 0.11, 0.03 13:47:35 55 processes: 1 running, 46 sleeping, 8 zombie CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle Mem: 19M Active, 6244K Inact, 12M Wired, 2472K Cache, 7634K Buf, 21M Free Swap: 256M Total, 64K Used, 256M Free ---------------------------------------- Here's an mptable output from the system: =============================================================================== MPTable, version 2.0.11 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000fc350 signature: '_MP_' length: 16 bytes version: 1.1 checksum: 0x9d mode: Virtual Wire ------------------------------------------------------------------------------- MP Config Table Header: physical address: 0x0009fd00 signature: 'PCMP' base table length: 236 version: 1.1 checksum: 0x80 OEM ID: 'AMI ' Product ID: 'P6ISA ' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 21 local APIC address: 0xfee00000 extended table length: 0 extended table checksum: 0 ------------------------------------------------------------------------------- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 1 0x11 BSP, usable 6 1 9 0xfbff 0 0x11 AP, usable 6 1 9 0xfbff -- Bus: Bus ID Type 0 PCI 1 ISA -- I/O APICs: APIC ID Version State Address 14 0x11 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# INT conforms conforms 1 1 14 1 INT conforms conforms 1 0 14 2 INT conforms conforms 1 3 14 3 INT conforms conforms 1 4 14 4 INT conforms conforms 1 5 14 5 INT conforms conforms 1 6 14 6 INT conforms conforms 1 7 14 7 INT conforms conforms 1 8 14 8 INT conforms conforms 1 9 14 9 INT conforms conforms 1 10 14 10 INT conforms conforms 1 11 14 11 INT conforms conforms 1 12 14 12 INT conforms conforms 1 13 14 13 INT conforms conforms 1 14 14 14 INT conforms conforms 1 15 14 15 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# NMI conforms conforms 0 0:A 255 1 ------------------------------------------------------------------------------- # SMP kernel config file options: # Required: options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Useful: #options SMP_AUTOSTART # start the additional CPUs during boot # Optional (built-in defaults will work in most cases): #options NCPU=2 # number of CPUs #options NBUS=2 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=24 # number of INTs # Currently broken: #options SMP_PRIVPAGES # BROKEN, DO NOT use! # Rogue hardware: # # Tyan Tomcat II: #options SMP_TIMER_NC # # # SuperMicro P6DNE: #options SMP_TIMER_NC # =============================================================================== From owner-freebsd-smp Wed Jun 4 18:07:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA23101 for smp-outgoing; Wed, 4 Jun 1997 18:07:17 -0700 (PDT) Received: from mpress.com (mpress.com [208.138.29.130]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id SAA23077 for ; Wed, 4 Jun 1997 18:07:14 -0700 (PDT) Received: (qmail 1823 invoked by uid 100); 5 Jun 1997 01:07:06 -0000 Message-ID: <19970604180706.59979@mpress.com> Date: Wed, 4 Jun 1997 18:07:06 -0700 From: Brian Litzinger To: freebsd-smp@freebsd.org Subject: 2xPP200 vs 2xPP150 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have access to two systems: And noticed the following: MB CPUs RAM eth hdc hd kbt Asus MB 2xPP200 256MB de0 2940W QUANTUM XP34550W LXQ1 2:48 Tyan MB 2xPP150 64MB de0 2940W SEAGATE ST15150W 0009 2:49 kbt = kernel build time with 'make -j 4' So what is going on? -- Brian Litzinger brian@mpress.com From owner-freebsd-smp Wed Jun 4 18:24:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA24889 for smp-outgoing; Wed, 4 Jun 1997 18:24:43 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA24881 for ; Wed, 4 Jun 1997 18:24:40 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id TAA24805; Wed, 4 Jun 1997 19:24:32 -0600 (MDT) Message-Id: <199706050124.TAA24805@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Fred Gilham cc: smp@FreeBSD.ORG Subject: Re: Super Micro P6DOF (was Re: Supermicro SMP boards?) In-reply-to: Your message of "Wed, 04 Jun 1997 13:48:53 PDT." <199706042048.NAA00917@japonica.csl.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Jun 1997 19:24:32 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > I'm trying to use SMP with a Super Micro P6DOF board. I find that it > dies at random intervals with the SMP kernel, while running OK with > the UP kernel. The SMP crashes tend to happen while running X, > especially with some xlock screen hack. > > One thing I've noticed is that after a while even the UP kernel will > seem to `lose' timing information, i.e. on my performance meter I'll > stop seeing CPU activity at all and in top all the CPU percentages > will be 0. I assumed this had something to do with the SMP_TIMER_NC > option but when I run the SMP kernel with that option I get a panic > with the message, ``8254 Redirect Impossible''. > ... > OEM ID: 'AMI ' > Product ID: 'P6ISA ' > ... > I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# > INT conforms conforms 1 1 14 1 > INT conforms conforms 1 0 14 2 > ... > INT conforms conforms 1 15 14 15 > -- > Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# > NMI conforms conforms 0 0:A 255 1 there is no "ExtInt" in the table so 'SMP_TIMER_NC' is indeed impossible. You evidently have an AMI BIOS on this board, which is doing things differently than previous Supermicro mptables I've seen. Unless this box has NO PCI cards in it, this is a "pre appendix D.3" BIOS. does the BIOS have an MP spec version 1.4 setting? are there any PCI cards in this box? -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Jun 4 18:40:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA26117 for smp-outgoing; Wed, 4 Jun 1997 18:40:52 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA26112 for ; Wed, 4 Jun 1997 18:40:47 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id TAA24867; Wed, 4 Jun 1997 19:40:39 -0600 (MDT) Message-Id: <199706050140.TAA24867@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Brian Litzinger cc: freebsd-smp@FreeBSD.ORG Subject: Re: 2xPP200 vs 2xPP150 In-reply-to: Your message of "Wed, 04 Jun 1997 18:07:06 PDT." <19970604180706.59979@mpress.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Jun 1997 19:40:39 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > I have access to two systems: > > And noticed the following: > > MB CPUs RAM eth hdc hd kbt > Asus MB 2xPP200 256MB de0 2940W QUANTUM XP34550W LXQ1 2:48 > > Tyan MB 2xPP150 64MB de0 2940W SEAGATE ST15150W 0009 2:49 > > kbt = kernel build time with 'make -j 4' > > So what is going on? be more specific about exactly what 'kbt' includes, ie make depend? for me if I "make clean && make depend", then "time make -j8" runs in 89-95 seconds (1:29/1:35) on an 2xP6-233x512, and around 1:45 on a 2xP6-200x512 there should be a bigger difference between your 2 systems, and both seem slow. what times do you get if running only one CPU on each? -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed Jun 4 20:35:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA07467 for smp-outgoing; Wed, 4 Jun 1997 20:35:18 -0700 (PDT) Received: from icicle.winternet.com (adm@icicle.winternet.com [198.174.169.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA07423 for ; Wed, 4 Jun 1997 20:35:13 -0700 (PDT) Received: (from adm@localhost) by icicle.winternet.com (8.7.5/8.7.5) id WAA17796 for ; Wed, 4 Jun 1997 22:35:04 -0500 (CDT) Posted-Date: Wed, 4 Jun 1997 22:35:04 -0500 (CDT) Received: from tundra.winternet.com(198.174.169.11) by icicle.winternet.com via smap (V2.0) id xma017712; Wed, 4 Jun 97 22:34:50 -0500 Received: from localhost (mestery@localhost) by tundra.winternet.com (8.8.4/8.8.4) with SMTP id WAA03241 for ; Wed, 4 Jun 1997 22:34:49 -0500 (CDT) X-Authentication-Warning: tundra.winternet.com: mestery owned process doing -bs Date: Wed, 4 Jun 1997 22:34:49 -0500 (CDT) From: Kyle Mestery To: freebsd-smp@freebsd.org Subject: Success! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I just wanted to say that I just recently installed an SMP system and it went smoothly. I have an old Tyan Tomcat II with 2x120s overclocked to 133 and 64MB of RAM. The system has a Seagate EIDE disk (not money for SCSI yet), and I can see a noticeable imporvement in speed with both CPUs active!! Kernel compiles went from 436 seconds to 260 seconds with make -j 16. Also, the SMP_AUTOSTART stuff works like a charm! I have been trying to beat my system into the ground, but to no avail. Running kernel compiles with intense X stuff, ping's -f, and doing remote xanim displays of 7MB avi's doesnt even do it! Thanks to all who have made this possible, it's really great! Kyle Mestery Engineer - Network Systems Group mestery@winternet.com mesteka@chainsaw.network.com From owner-freebsd-smp Thu Jun 5 00:10:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA29705 for smp-outgoing; Thu, 5 Jun 1997 00:10:42 -0700 (PDT) Received: from housing1.stucen.gatech.edu (ken@housing1.stucen.gatech.edu [130.207.52.71]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA29700 for ; Thu, 5 Jun 1997 00:10:40 -0700 (PDT) Received: (from ken@localhost) by housing1.stucen.gatech.edu (8.8.5/8.8.5) id DAA09276; Thu, 5 Jun 1997 03:10:11 -0400 (EDT) From: Kenneth Merry Message-Id: <199706050710.DAA09276@housing1.stucen.gatech.edu> Subject: Re: 2xPP200 vs 2xPP150 In-Reply-To: <199706050140.TAA24867@Ilsa.StevesCafe.com> from Steve Passe at "Jun 4, 97 07:40:39 pm" To: smp@csn.net (Steve Passe) Date: Thu, 5 Jun 1997 03:10:10 -0400 (EDT) Cc: brian@mpress.com, freebsd-smp@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Steve Passe wrote... > Hi, > > > I have access to two systems: > > > > And noticed the following: > > > > MB CPUs RAM eth hdc hd kbt > > Asus MB 2xPP200 256MB de0 2940W QUANTUM XP34550W LXQ1 2:48 > > > > Tyan MB 2xPP150 64MB de0 2940W SEAGATE ST15150W 0009 2:49 > > > > kbt = kernel build time with 'make -j 4' > > > > So what is going on? > > be more specific about exactly what 'kbt' includes, ie make depend? > > for me if I "make clean && make depend", then "time make -j8" > runs in 89-95 seconds (1:29/1:35) on an 2xP6-233x512, > and around 1:45 on a 2xP6-200x512 > > there should be a bigger difference between your 2 systems, and both seem slow. > what times do you get if running only one CPU on each? My system is very similar to one of Brian's: MB CPUs RAM eth hdc hd kbt Asus MB 2xPP200 128MB de0 3940UW QUANTUM XP34550W LXY4 1:50 That time is just build time for a generic kernel, done with make -j 8. (i.e. not including make clean or make depend) My custom kernel, compiled with make -j 8, takes about 1:45. If I had to guess at reasons for the slowdown, I'd say try the following: use make -j 8 instead of make -j 4 - this still wouldn't explain the lack of difference in times between the two machines upgrade the firmware on your drive from LXQ1 to LXY4. - Justin said a little while back that there are bugs with the older firware revisions on at least the Atlas II, and I think the Atlas I that cause tagged command queueing to not work properly. I was able to successfully upgrade my firmware, and I know that Satoshi has done it as well. (he has a XP34550W as well) - Once you get the firmware upgraded, recompile a kernel with these options: AHC_TAGENABLE AHC_SCBPAGING_ENABLE (I have AHC_ALLOW_MEMIO turned on as well, I'm not sure what that does.) It's possible that upgrading the firmware and turning on tagged comand queueing might fix the performance difference. It depends on how disk-bound the kernel compile is. One thing I noticed is that it doesn't look like the kernel Makefile uses -pipe. That would probably speed things up as well. Well, I just tried it -- using make -j 8, it cut my generic kernel compile time by 7 seconds to 1:43. Not a huge change, but it's a little faster. Of course it could turn out that it's not a drive problem at all. Also, I'd like to know whether the times above are for a make depend and a make, or for just a make. Also, which kernel? Since my and Brian's systems are very similar, the performance numbers should be similar. (other things that might factor into my performance -- I was running X during the tests, and I've only got 256K P6-200's, and I've got standard 60ns DRAM) Ken -- Kenneth Merry ken@ulc199.residence.gatech.edu Disclaimer: I don't speak for GTRI, GT, or Elvis. From owner-freebsd-smp Thu Jun 5 00:30:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA00729 for smp-outgoing; Thu, 5 Jun 1997 00:30:01 -0700 (PDT) Received: from caleche.kecl.ntt.co.jp (elysium.kecl.ntt.co.jp [129.60.192.193]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA00701 for ; Thu, 5 Jun 1997 00:29:58 -0700 (PDT) Received: from localhost by caleche.kecl.ntt.co.jp (8.8.5/kecl2.0/r8v7-M2-nishio) with ESMTP id QAA00626; Thu, 5 Jun 1997 16:29:50 +0900 (JST) To: smp@freebsd.org Subject: bug with SMP_AUTOSTART? X-Mailer: Mew version 1.54 on Emacs 19.34.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19970605162949Y.nishio@elysium.kecl.ntt.co.jp> Date: Thu, 05 Jun 1997 16:29:49 +0900 From: NISHIO Shuichi X-Dispatcher: impost version 0.95+ (Nov. 26, 1996) Lines: 54 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, Yesterday I found that kernels with SMP_AUTOSTART shows wierd behavior. When I try to run Mule-2.3@19.34 (a multi-lingual variant of emacs 19.34), it works for 2-3 invocation after reboot. Afterwards, it won't run, just dumps a core. This situation is somewhat similar to the following description from emacs-19.34's "PROBLEMS" file. ---- begin citation ---- * After running emacs once, subsequent invocations crash. Some versions of SVR4 have a serious bug in the implementation of the mmap () system call in the kernel; this causes emacs to run correctly the first time, and then crash when run a second time. Contact your vendor and ask for the mmap bug fix; in the mean time, you may be able to work around the problem by adding a line to your operating system description file (whose name is reported by the configure script) that reads: #define SYSTEM_MALLOC This makes Emacs use memory less efficiently, but seems to work around the kernel bug. ---- end citation ---- The worst thing is, that once felt into this core-dumping situation, disk accesses seems to be corrupted: if I 'cat' a file, it shows wrong contents, with binaries. If I tried 'cat'ing the same file several times, it shows different contents every time. This files are actually not corrupted, and after rebooting, it shows up normally. Using a kernel without SMP_AUTOSTART, and doing 'sysctl -w kern.smp_active=2' seems to work fine (well, I tried to run 100 Mules at once, and the system went panic, but this probably is an another issue). The same thing can be seen with every kernels from 8/May to Yesterday. I'm running 3.0-current with the following hardwares: Tyan S1668ATX P6 200MHz(256K)x2 AHA-2940 x 1 AHA-2940U x 1 AHA-2940UW x 1 DEC DE-500AA x 2 Thank you for any advice, NISHIO Shuichi From owner-freebsd-smp Thu Jun 5 09:43:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA23437 for smp-outgoing; Thu, 5 Jun 1997 09:43:33 -0700 (PDT) Received: from pluto.plutotech.com (root@pluto100.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA23391; Thu, 5 Jun 1997 09:43:26 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id KAA28909; Thu, 5 Jun 1997 10:43:04 -0600 (MDT) Message-Id: <199706051643.KAA28909@pluto.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: Kenneth Merry cc: freebsd-smp@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: 2xPP200 vs 2xPP150 In-reply-to: Your message of "Thu, 05 Jun 1997 03:10:10 EDT." <199706050710.DAA09276@housing1.stucen.gatech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Jun 1997 11:41:39 -0600 From: "Justin T. Gibbs" Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [About the Quantum Atlas II] >upgrade the firmware on your drive from LXQ1 to LXY4. > - Justin said a little while back that there are bugs with the older > firware revisions on at least the Atlas II, and I think the Atlas I > that cause tagged command queueing to not work properly. I was able to > successfully upgrade my firmware, and I know that Satoshi has done it > as well. (he has a XP34550W as well) The Atlas I would return QUEUE FULL at very low tag counts with firmware revisions below L915. With L915, it seems that using up to 31 tags is possible. As for the Atlas II, Quantum still hasn't addressed the QUEUE FULL problem. On my test "CAM SCSI" system: da4 at ahc0 bus 0 target 4 lun 0 da4: Fixed Direct Access SCSI2 device da4: Serial Number PCB=2011303101 ; HDA=189704332253 da4: 20.0MB/s transfers (20.0MHz, offset 15), Tagged Queueing Enabled da4: 8682MB (17781520 512 byte sectors: 255H 63S/T 1106C) (da4:ahc0:0:4:0): tagged openings reduced to 30 (da4:ahc0:0:4:0): tagged openings reduced to 22 (da4:ahc0:0:4:0): tagged openings reduced to 18 (da4:ahc0:0:4:0): tagged openings reduced to 16 (da4:ahc0:0:4:0): tagged openings reduced to 8 (da4:ahc0:0:4:0): tagged openings reduced to 6 (da4:ahc0:0:4:0): tagged openings reduced to 4 This happens simply by performing a: cd /mnt; dump 0f - /usr | restore rf - Now, at least with the new CAM code, receiving QUEUE FULL status from a drive will only reduce performance since it takes time to handle the QUEUE FULL condition and it can result in a reduction in the number of transactions allowed to be queued to the device. In the current SCSI code, things are quite fragile, and repeated QUEUE FULL status can cause an infinite loop in the kernel. According to Quantum, the Atlas II's firmware should be able to handle up to 256 tags at a time. Unfortunately, they seem to hold on to the resource necessary to queue a transaction on writes until they are completely written to the media even though the drive may return good status long before this happens. This makes it really tough for the SCSI system to determine what is an appropriate tag count to use. The current algorithm used in CAM is to simply truncate the number of "openings" when a QUEUE FULL is encountered to the number of transactions that are still left on the device (e.g. if the 15th transaction caused a queue full, we'll drop to 14 and not queue any more to the device until we drop below that number). It may be that, for drives like the Atlas II, better performance could be achieved by adding some hysteresis on the count along with a delay in releasing new transactions, but I don't know how worth while the added complexity would be. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-smp Thu Jun 5 10:05:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA24671 for smp-outgoing; Thu, 5 Jun 1997 10:05:20 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA24645; Thu, 5 Jun 1997 10:05:12 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA20396; Thu, 5 Jun 1997 10:00:18 -0700 From: Terry Lambert Message-Id: <199706051700.KAA20396@phaeton.artisoft.com> Subject: Re: 2xPP200 vs 2xPP150 To: gibbs@plutotech.com (Justin T. Gibbs) Date: Thu, 5 Jun 1997 10:00:17 -0700 (MST) Cc: ken@housing1.stucen.gatech.edu, freebsd-smp@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG In-Reply-To: <199706051643.KAA28909@pluto.plutotech.com> from "Justin T. Gibbs" at Jun 5, 97 11:41:39 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > [About the Quantum Atlas II] [ ... ] > According to Quantum, the Atlas II's firmware should be able to handle up > to 256 tags at a time. Unfortunately, they seem to hold on to the resource > necessary to queue a transaction on writes until they are completely > written to the media even though the drive may return good status long > before this happens. This makes it really tough for the SCSI system to > determine what is an appropriate tag count to use. > > The current algorithm used in CAM is to simply truncate the number of > "openings" when a QUEUE FULL is encountered to the number of transactions > that are still left on the device (e.g. if the 15th transaction caused a > queue full, we'll drop to 14 and not queue any more to the device until we > drop below that number). It may be that, for drives like the Atlas II, > better performance could be achieved by adding some hysteresis on the count > along with a delay in releasing new transactions, but I don't know how > worth while the added complexity would be. >From your description, it seems that it would be worthwhile to seperate hysteresis for read vs. write, if the write problem is localized solely to the write path. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Thu Jun 5 10:58:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA27526 for smp-outgoing; Thu, 5 Jun 1997 10:58:57 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA27518 for ; Thu, 5 Jun 1997 10:58:52 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id LAA27587; Thu, 5 Jun 1997 11:58:02 -0600 (MDT) Message-Id: <199706051758.LAA27587@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: NISHIO Shuichi cc: smp@FreeBSD.ORG Subject: Re: bug with SMP_AUTOSTART? In-reply-to: Your message of "Thu, 05 Jun 1997 16:29:49 +0900." <19970605162949Y.nishio@elysium.kecl.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Jun 1997 11:58:02 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > Hello, > > Yesterday I found that kernels with SMP_AUTOSTART shows wierd > behavior. > > When I try to run Mule-2.3@19.34 (a multi-lingual variant of emacs > 19.34), it works for 2-3 invocation after reboot. Afterwards, it > won't run, just dumps a core. This situation is somewhat similar to > the following description from emacs-19.34's "PROBLEMS" file. > > ---- begin citation ---- > * After running emacs once, subsequent invocations crash. > ... > ---- end citation ---- It might be a mmap issue, but your the first user to report this problem... --- > The worst thing is, that once felt into this core-dumping situation, > disk accesses seems to be corrupted: if I 'cat' a file, it shows > wrong contents, with binaries. If I tried 'cat'ing the same file > several times, it shows different contents every time. > This files are actually not corrupted, and after rebooting, > it shows up normally. > > Using a kernel without SMP_AUTOSTART, and doing > 'sysctl -w kern.smp_active=2' seems to work fine (well, I tried to run > 100 Mules at once, and the system went panic, but this probably is > an another issue). > > The same thing can be seen with every kernels from 8/May to Yesterday. did it work properly b4 may 8? (or was that just the first time you started using SMP_AUTOSTART?) -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Thu Jun 5 11:54:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA00202 for smp-outgoing; Thu, 5 Jun 1997 11:54:11 -0700 (PDT) Received: from pluto.plutotech.com (root@pluto100.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA00175; Thu, 5 Jun 1997 11:54:05 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.5) with ESMTP id MAA01925; Thu, 5 Jun 1997 12:53:08 -0600 (MDT) Message-Id: <199706051853.MAA01925@pluto.plutotech.com> X-Mailer: exmh version 2.0beta 12/23/96 To: Terry Lambert cc: gibbs@plutotech.com (Justin T. Gibbs), ken@housing1.stucen.gatech.edu, freebsd-smp@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: 2xPP200 vs 2xPP150 In-reply-to: Your message of "Thu, 05 Jun 1997 10:00:17 PDT." <199706051700.KAA20396@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Jun 1997 13:51:43 -0600 From: "Justin T. Gibbs" Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >From your description, it seems that it would be worthwhile to >seperate hysteresis for read vs. write, if the write problem is >localized solely to the write path. The problem is that you don't know if a QUEUE FULL is being returned because of a hard or temporary resource limitation. This could occur for different reasons on different devices, because of read activity or write activity. There is also no easy way for you to determine, even in the case of the Quantum, that the QUEUE FULL happened because of write activity. All queued transactions at the time of the QUEUE FULL could be reads, which the writes that actually caused the problem already completed successfully to the caller. Regardless, this is a general problem with the semantics of the QUEUE FULL status on SCSI devices and I'd rather solve it with a generic solution instead of one taylored to a specific device. Hysteresis and some amount of delay before opening the queue up again, may allow us to keep the tag count up even when confronted with the occasional QUEUE FULL due to a temporary resource shortage regardless of the cause of that shortage. > Regards, > Terry Lambert > terry@lambert.org >--- >Any opinions in this posting are my own and not those of my present >or previous employers. > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-smp Thu Jun 5 13:35:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA05599 for smp-outgoing; Thu, 5 Jun 1997 13:35:52 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA05592 for ; Thu, 5 Jun 1997 13:35:47 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id OAA28050; Thu, 5 Jun 1997 14:35:32 -0600 (MDT) Message-Id: <199706052035.OAA28050@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Fred Gilham cc: smp@freebsd.org Subject: Re: Super Micro P6DOF (was Re: Supermicro SMP boards?) In-reply-to: Your message of "Thu, 05 Jun 1997 13:19:01 PDT." <199706052019.NAA03303@japonica.csl.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Jun 1997 14:35:32 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > You wrote: > > >there is no "ExtInt" in the table so 'SMP_TIMER_NC' is indeed impossible. > >You evidently have an AMI BIOS on this board, which is doing things > >differently > >than previous Supermicro mptables I've seen. > >Unless this box has NO PCI cards in it, this is a "pre appendix D.3" > >BIOS. > > > >does the BIOS have an MP spec version 1.4 setting? > > > >are there any PCI cards in this box? > > The system has an AMI bios. It does not have an MP spec 1.4 setting, > it only has a 1.1 setting. I think disabling the 1.1 setting makes it > use an even earlier spec. > > It has all PCI cards---adaptec 2940UW disk controller, Number 9 GX-64 > video and SMC 10/100 tulip-based ethernet. This is then pre appendix D, and thus a problem (tho not necessarily the cause of your random locks) as it prevents efficient usage of the IO APIC. I would suggest seeing if you can get a BIOS upgrade from supermicro. For the random locks, try slowing down the memory accesses in the BIOS. this has the smell of a hardware problem of some sort. --- I don't seem to have any recent mptables for the supermicro series (thought I did, but I must have lost them somewhere...) Could any user's of SMP and supermicros send an 'mptable -dmesg >outfile" to me. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Thu Jun 5 16:31:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA13735 for smp-outgoing; Thu, 5 Jun 1997 16:31:14 -0700 (PDT) Received: from caleche.kecl.ntt.co.jp (elysium.kecl.ntt.co.jp [129.60.192.193]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA13727 for ; Thu, 5 Jun 1997 16:30:56 -0700 (PDT) Received: from localhost by caleche.kecl.ntt.co.jp (8.8.5/kecl2.0/r8v7-M2-nishio) with ESMTP id IAA03496; Fri, 6 Jun 1997 08:30:06 +0900 (JST) To: smp@csn.net Cc: smp@FreeBSD.ORG Subject: Re: bug with SMP_AUTOSTART? In-Reply-To: Your message of "Thu, 05 Jun 1997 11:58:02 -0600" References: <199706051758.LAA27587@Ilsa.StevesCafe.com> X-Mailer: Mew version 1.54 on Emacs 19.34.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19970606083005G.nishio@elysium.kecl.ntt.co.jp> Date: Fri, 06 Jun 1997 08:30:05 +0900 From: NISHIO Shuichi X-Dispatcher: impost version 0.95+ (Nov. 26, 1996) Lines: 15 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk From: Steve Passe Subject: Re: bug with SMP_AUTOSTART? Date: Thu, 05 Jun 1997 11:58:02 -0600 Message-ID: <199706051758.LAA27587@Ilsa.StevesCafe.com> > > The same thing can be seen with every kernels from 8/May to Yesterday. > > did it work properly b4 may 8? (or was that just the first time you > started using SMP_AUTOSTART?) 8/May is the first time I used SMP_AUTOSTART. I haven't tried defining SMP_AUTOSTART with previous kernels, but should I try those kernels? NISHIO Shuichi