From owner-freebsd-smp Sun Jul 27 21:18:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA08670 for smp-outgoing; Sun, 27 Jul 1997 21:18:23 -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 VAA08662 for ; Sun, 27 Jul 1997 21:18:18 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id WAA02828; Sun, 27 Jul 1997 22:17:56 -0600 (MDT) Message-Id: <199707280417.WAA02828@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: dave adkins cc: smp@freebsd.org Subject: PEND_INTS and ISA failure Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 27 Jul 1997 22:17:56 -0600 Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I just committed code to (hopefully) fix the missing INTs when using the new PEND_INTS algorithm. PEND_INTS is still commented out in smptests.h, so please uncomment it, build a kernel & test. I am especially interested in hearing from those who observed the original problem on their hardware. The changes affected 5 files, so I committed instead of rolling a patch as I originally stated I would. Here are the dates & files to look for: fsmp 1997/07/27 20:59:55 PDT Modified files: sys/i386/include mpapic.h smp.h sys/i386/i386 mp_machdep.c mpapic.c sys/i386/isa apic_vector.s Revision Changes Path 1.10 +1 -6 src/sys/i386/include/mpapic.h 1.22 +11 -1 src/sys/i386/include/smp.h 1.38 +4 -4 src/sys/i386/i386/mp_machdep.c 1.24 +13 -2 src/sys/i386/i386/mpapic.c 1.12 +52 -2 src/sys/i386/isa/apic_vector.s -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Mon Jul 28 01:14:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA17381 for smp-outgoing; Mon, 28 Jul 1997 01:14:32 -0700 (PDT) Received: from tyger.inna.net (root@tyger.inna.net [206.151.66.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA17376 for ; Mon, 28 Jul 1997 01:14:29 -0700 (PDT) Received: from caught.inna.net (caught.inna.net [206.151.66.7]) by tyger.inna.net (8.8.5/8.7.3) with SMTP id EAA09668 for ; Mon, 28 Jul 1997 04:14:23 -0400 (EDT) Date: Mon, 28 Jul 1997 04:14:12 -0400 (EDT) From: Thomas Arnold To: smp@freebsd.org Subject: i2o Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Was curious if anyone caught the artical on I2O in Wired and grabbed the file from ftp.i2osig.org before they pulled it offline. It looks to be missing some things but has alot of info in it. +-----------------------------------------------+ : Tom Arnold - No relation to Rosanne : : SysAdmin/Pres - TBI, Ltd ( inna.net ) : : The Middle Peninsula's Internet Connection : +-----------------------------------------------+ From owner-freebsd-smp Mon Jul 28 05:08:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA27607 for smp-outgoing; Mon, 28 Jul 1997 05:08:55 -0700 (PDT) Received: from mhub1.tc.umn.edu (0@mhub1.tc.umn.edu [128.101.131.51]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id FAA27602 for ; Mon, 28 Jul 1997 05:08:53 -0700 (PDT) Received: from gold.tc.umn.edu by mhub1.tc.umn.edu; Mon, 28 Jul 97 07:08:51 -0500 Received: from pub-15-c-176.dialup.umn.edu by gold.tc.umn.edu; Mon, 28 Jul 97 07:08:50 -0500 Date: Mon, 28 Jul 1997 07:06:15 -0500 (CDT) From: dave adkins Reply-To: dave adkins To: Steve Passe cc: smp@freebsd.org Subject: Re: PEND_INTS and ISA failure In-Reply-To: <199707280417.WAA02828@Ilsa.StevesCafe.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sun, 27 Jul 1997, Steve Passe wrote: > Hi, > > I just committed code to (hopefully) fix the missing INTs when using the > new PEND_INTS algorithm. PEND_INTS is still commented out in smptests.h, > so please uncomment it, build a kernel & test. I am especially interested > in hearing from those who observed the original problem on their hardware. > > The changes affected 5 files, so I committed instead of rolling a patch as > I originally stated I would. Here are the dates & files to look for: > > fsmp 1997/07/27 20:59:55 PDT > > Modified files: > sys/i386/include mpapic.h smp.h > sys/i386/i386 mp_machdep.c mpapic.c > sys/i386/isa apic_vector.s > > Revision Changes Path > 1.10 +1 -6 src/sys/i386/include/mpapic.h > 1.22 +11 -1 src/sys/i386/include/smp.h > 1.38 +4 -4 src/sys/i386/i386/mp_machdep.c > 1.24 +13 -2 src/sys/i386/i386/mpapic.c > 1.12 +52 -2 src/sys/i386/isa/apic_vector.s > > -- > Steve Passe | powered by > smp@csn.net | Symmetric MultiProcessor FreeBSD > > > steve, It looks like the changes took care of the problem with both multi-sector enabled and disabled for wd. dave adkins From owner-freebsd-smp Mon Jul 28 08:16:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA11791 for smp-outgoing; Mon, 28 Jul 1997 08:16:00 -0700 (PDT) Received: from pluto.plutotech.com (ken@[206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA11786 for ; Mon, 28 Jul 1997 08:15:56 -0700 (PDT) Received: (from ken@localhost) by pluto.plutotech.com (8.8.5/8.8.5) id JAA14663; Mon, 28 Jul 1997 09:15:30 -0600 (MDT) From: Kenneth Merry Message-Id: <199707281515.JAA14663@pluto.plutotech.com> Subject: Re: i2o In-Reply-To: from Thomas Arnold at "Jul 28, 97 04:14:12 am" To: tom@inna.net (Thomas Arnold) Date: Mon, 28 Jul 1997 09:15:30 -0600 (MDT) Cc: smp@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28s (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Thomas Arnold wrote... > Was curious if anyone caught the artical on I2O in Wired and grabbed the > file from ftp.i2osig.org before they pulled it offline. It looks to be > missing some things but has alot of info in it. I got it, and when I went to their ftp site a few minutes ago, this is what the message said: I2O Sig Temporary Download Directory Log in as "i2o" with a password supplied by Michael Lobue. So apparantly they aren't letting it out freely any more, 'eh? If anyone wants it, let me know, I can put it up for ftp or something. Ken -- Kenneth Merry ken@plutotech.com From owner-freebsd-smp Mon Jul 28 09:42:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA16951 for smp-outgoing; Mon, 28 Jul 1997 09:42:09 -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 JAA16944 for ; Mon, 28 Jul 1997 09:42:04 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id KAA04963; Mon, 28 Jul 1997 10:41:41 -0600 (MDT) Message-Id: <199707281641.KAA04963@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: dave adkins cc: smp@freebsd.org Subject: Re: PEND_INTS and ISA failure In-reply-to: Your message of "Mon, 28 Jul 1997 07:06:15 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Jul 1997 10:41:40 -0600 Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > > I just committed code to (hopefully) fix the missing INTs when using the > > new PEND_INTS algorithm. PEND_INTS is still commented out in smptests.h, > > so please uncomment it, build a kernel & test. I am especially interested > > in hearing from those who observed the original problem on their hardware. > > ... > It looks like the changes took care of the problem with both multi-sector > enabled and disabled for wd. great news, everbody please turn on PEND_INTS in i386/include/smptests.h. thanx for the report, -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Mon Jul 28 10:15:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA18730 for smp-outgoing; Mon, 28 Jul 1997 10:15:02 -0700 (PDT) Received: from tyger.inna.net (root@tyger.inna.net [206.151.66.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA18718 for ; Mon, 28 Jul 1997 10:15:00 -0700 (PDT) Received: from caught.inna.net (caught.inna.net [206.151.66.7]) by tyger.inna.net (8.8.5/8.7.3) with SMTP id NAA07163; Mon, 28 Jul 1997 13:14:59 -0400 (EDT) Date: Mon, 28 Jul 1997 13:14:47 -0400 (EDT) From: Thomas Arnold To: Kenneth Merry cc: smp@FreeBSD.ORG Subject: Re: i2o In-Reply-To: <199707281515.JAA14663@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Was curious if anyone caught the artical on I2O in Wired and grabbed the > > file from ftp.i2osig.org before they pulled it offline. It looks to be > > missing some things but has alot of info in it. > > So apparantly they aren't letting it out freely any more, 'eh? If > anyone wants it, let me know, I can put it up for ftp or something. I used to FTP-Search engine and found it in fairly short order. The Copyright in the material is incredably vague. For what seems so secretive a company I wuld have expected all kinds of threats and warnings. On another I2O note, I have a generic I2O board coming in using of all things the Via 590/VP3 chipset and the StrongARM processor. It was announced to me by one of my Taiwan contacts and I have requested a sample. They should have a URL for it soon. Most interesting thing I noted was the place on the board for a second CPU socket to be soldered in... +-----------------------------------------------+ : Tom Arnold - No relation to Rosanne : : SysAdmin/Pres - TBI, Ltd ( inna.net ) : : The Middle Peninsula's Internet Connection : +-----------------------------------------------+ From owner-freebsd-smp Mon Jul 28 12:50:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA27772 for smp-outgoing; Mon, 28 Jul 1997 12:50:53 -0700 (PDT) Received: from icicle.winternet.com (adm@icicle.winternet.com [198.174.169.13]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA27767 for ; Mon, 28 Jul 1997 12:50:48 -0700 (PDT) Received: (from adm@localhost) by icicle.winternet.com (8.7.5/8.7.5) id OAA22231; Mon, 28 Jul 1997 14:50:37 -0500 (CDT) Posted-Date: Mon, 28 Jul 1997 14:50:37 -0500 (CDT) Received: from tundra.winternet.com(198.174.169.11) by icicle.winternet.com via smap (V2.0) id xma022159; Mon, 28 Jul 97 14:49:55 -0500 Received: from localhost (mestery@localhost) by tundra.winternet.com (8.8.4/8.8.4) with SMTP id OAA29319; Mon, 28 Jul 1997 14:49:55 -0500 (CDT) X-Authentication-Warning: tundra.winternet.com: mestery owned process doing -bs Date: Mon, 28 Jul 1997 14:49:54 -0500 (CDT) From: Kyle Mestery To: Steve Passe cc: smp@FreeBSD.ORG Subject: Re: PEND_INTS and ISA failure In-Reply-To: <199707281641.KAA04963@Ilsa.StevesCafe.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 28 Jul 1997, Steve Passe wrote: > Hi, > > > > I just committed code to (hopefully) fix the missing INTs when using the > > > new PEND_INTS algorithm. PEND_INTS is still commented out in smptests.h, > > > so please uncomment it, build a kernel & test. I am especially interested > > > in hearing from those who observed the original problem on their hardware. > > > ... I did not have a chance to test a kernel until this afternoon, 7-28-97. Hardware: Tyan Tomcat II, 2 120s overclocked to 133, EIDE disks, 64M RAM. With PEND_INTS uncommented, things work fine. Boots, runs fine. Only problem is my kernel compile times went up again! Here is a table of my kernel compiles over the last week or so: MP Kernel from 7-23-97 with -j 8: 313.71 real 425.41 user 104.29 sys MP Kernel from 7-19-97 with -j 8: 310.99 real 414.62 user 103.70 sys UP Kernel from 7-19-97 with -j 8: 394.42 real 345.08 user 30.46 sys UP Kernel from 7-19-97 with no -j: 448.67 real 340.57 user 23.72 sys MP Kernel from 7-28-97 with -j 8: 330.72 real 442.82 user 114.30 sys Is this mostly due to the EIDE disks? All of these compiles are from a fresh reboot in multi-user mode with one user, no X, nothing else running. Kyle Mestery StorageTek's Network Systems Group 7600 Boone Ave. N., Brooklyn Park, MN 55428 mesteka@anubis.network.com, mestery@winternet.com From owner-freebsd-smp Mon Jul 28 13:54:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA02104 for smp-outgoing; Mon, 28 Jul 1997 13:54:42 -0700 (PDT) Received: from fredriks-1.pr.mcs.net (fredriks-1.pr.mcs.net [205.164.50.241]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA02098 for ; Mon, 28 Jul 1997 13:54:38 -0700 (PDT) Received: (from lars@localhost) by fredriks-1.pr.mcs.net (8.8.5/8.6.6) id PAA00509 for smp@freebsd.org; Mon, 28 Jul 1997 15:54:36 -0500 (CDT) From: Lars Fredriksen Message-Id: <199707282054.PAA00509@fredriks-1.pr.mcs.net> Subject: Instantanious combustions!! To: smp@freebsd.org Date: Mon, 28 Jul 1997 15:54:36 -0500 (CDT) 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-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Has anyone had trouble with instantanious reboots on current since yesterday? Currently nfs traffic, tcp traffic and fsck work seems to trigger it. This wide patter might just indicate that something else is wrong as well A straight boot (automatic) will always(so far anyway) result in a instantanious reboot when fsck hits the 2nd or third filesystem. If you boot with the -v option, that problem seems to go away. This seems to indicate that there is some kind of race condition going on, but unfortunately the kernel doesn't panic so it is hard to find out what the race is. Anyone has a good starting point for what kind of breakpoint one could set to try to capture the problem(assuming that there is one)? (Steve??) Lars -- ------------------------------------------------------------------- Lars Fredriksen fredriks@mcs.com (home) lars@fredriks-1.pr.mcs.net (home-home) From owner-freebsd-smp Mon Jul 28 14:57:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA06223 for smp-outgoing; Mon, 28 Jul 1997 14:57:47 -0700 (PDT) Received: from server.local.sunyit.edu (A-V25.rh.sunyit.edu [150.156.211.85]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA06216 for ; Mon, 28 Jul 1997 14:57:40 -0700 (PDT) Received: from localhost (perlsta@localhost) by server.local.sunyit.edu (8.8.5/8.8.5) with SMTP id SAA16554 for ; Mon, 28 Jul 1997 18:02:52 GMT X-Authentication-Warning: server.local.sunyit.edu: perlsta owned process doing -bs Date: Mon, 28 Jul 1997 18:02:52 +0000 (GMT) From: Alfred Perlstein X-Sender: perlsta@server.local.sunyit.edu To: freebsd-smp@freebsd.org Subject: SMP? (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have a couple of questions about SMP, what boards do i have to watch out for, not working? I was recently considering, just to experiment (it would kill my budget though) to buy my roomate's P150 chip (real bargain) then buy a dual pentium mb plus another P150. The whole thing will cost me almost 400$, is it worth it? The thing is I just read that dual pentiums are nothing compared to dual pentium pros, is this true (especially running at 150mhz) What kind of performance increase could i expect over a single P150? Last general question, is the SMP kernel stable as of now and are the same drivers and ports available for it? I would like to contribute to the testing of the SMP system, is there anything i can do? Since the machine would sit idle excpet me running a little X here, and httpd/nfs/samba i wouldn't mind giving access to some of the SMP team. The machine is just a project for me. Since i'm not too 'up' on the staying current idea, maybe a pointer to the information needed to keep the kernel current would be helpful for me. As far as coding i understand a lot of operating system issues/multiprocessing, multi-cpu is a little weird for me though, but i am very interested. Thanks in advance, Alfred perlsta@sunyit.edu From owner-freebsd-smp Mon Jul 28 17:09:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA14850 for smp-outgoing; Mon, 28 Jul 1997 17:09:22 -0700 (PDT) Received: from server.local.sunyit.edu (A-V25.rh.sunyit.edu [150.156.211.85]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA14840 for ; Mon, 28 Jul 1997 17:09:20 -0700 (PDT) Received: from localhost (perlsta@localhost) by server.local.sunyit.edu (8.8.5/8.8.5) with SMTP id UAA16710 for ; Mon, 28 Jul 1997 20:14:36 GMT X-Authentication-Warning: server.local.sunyit.edu: perlsta owned process doing -bs Date: Mon, 28 Jul 1997 20:14:36 +0000 (GMT) From: Alfred Perlstein X-Sender: perlsta@server.local.sunyit.edu To: freebsd-smp@FreeBSD.ORG Subject: Re: SMP? (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Is it possible to mix processor types with SMP? as long as i clock it down accordingly, let's say i set up a dual pentium board, on chip a P150 and the other a P200MMX, if i clock down the 200MMX to 150Mhz until i can afford another P200MMX, will things be okey dokey? Or am i heading for disaster? :) Basically both processors would be running at 150MHZ even though one is really capable of 200MHZ+MMX and the other is topped off at 150MHZ. Thanks, Alfred Perlstein perlsta@sunyit.edu From owner-freebsd-smp Mon Jul 28 17:24:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA16273 for smp-outgoing; Mon, 28 Jul 1997 17:24:21 -0700 (PDT) Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA16244 for ; Mon, 28 Jul 1997 17:24:06 -0700 (PDT) Received: from fast.cs.utah.edu by cs.utah.edu (8.8.4/utah-2.21-cs) id SAA27537; Mon, 28 Jul 1997 18:24:01 -0600 (MDT) Received: by fast.cs.utah.edu (8.6.10/utah-2.15-leaf) id SAA20217; Mon, 28 Jul 1997 18:24:01 -0600 Date: Mon, 28 Jul 1997 18:24:01 -0600 From: vanmaren@fast.cs.utah.edu (Kevin Van Maren) Message-Id: <199707290024.SAA20217@fast.cs.utah.edu> To: perlsta@sunyit.edu Subject: Re: SMP? (fwd) Cc: freebsd-smp@FreeBSD.ORG Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mixing CPUs? Yes and no. It should be possible, but the CPUs really should be the same `stepping'. This isn't possible with a MMX and a non-MMX processor, as the Core voltages are different (and motherboard manufacturers only provide one voltage selection mechanism, as well as one clock-selecting mechanism -- theoretically you can run the CPUs are differnt speeds as long as the BUS speed is the same). It would be nice if motherboard manufacturers started shippping dual boards with two sets of clock-multiplier jumpers. (Of course, you could do this yourself, but I have a feeling that cutting traces and running patch-wires might have adverse effects on the warranty). kevin From owner-freebsd-smp Mon Jul 28 20:07:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA00241 for smp-outgoing; Mon, 28 Jul 1997 20:07:45 -0700 (PDT) Received: from onyx.atipa.com (ns.atipa.com [208.128.22.10]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id UAA00191 for ; Mon, 28 Jul 1997 20:07:33 -0700 (PDT) Received: (qmail-queue invoked by uid 1018); 29 Jul 1997 03:09:06 -0000 Date: Mon, 28 Jul 1997 21:09:06 -0600 (MDT) From: FreeBSD Development X-Sender: freebsd@dot.ishiboo.com To: Kevin Van Maren cc: perlsta@sunyit.edu, freebsd-smp@FreeBSD.ORG Subject: Re: SMP? (fwd) In-Reply-To: <199707290024.SAA20217@fast.cs.utah.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 28 Jul 1997, Kevin Van Maren wrote: > Mixing CPUs? Yes and no. It should be possible, but the CPUs really > should be the same `stepping'. This isn't possible with a MMX and a > non-MMX processor, as the Core voltages are different (and motherboard > manufacturers only provide one voltage selection mechanism, as well > as one clock-selecting mechanism -- theoretically you can run the > CPUs are differnt speeds as long as the BUS speed is the same). > We sell several boards, and the only possible "yes" situation I can think of would be top mix a 256K and 512K PPro. I can not think of any other viable mix. Each board has only one setting each for bus frequency, clock multiplier, and voltage. Only Intel CPUs are SMP compliant (no K5, K6, Cyrix, etc.). AMD claims they are developing an open multiprocessor spec, but it has not yet been finalized or implemented. Kevin From owner-freebsd-smp Mon Jul 28 20:55:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA04507 for smp-outgoing; Mon, 28 Jul 1997 20:55:51 -0700 (PDT) Received: from server.local.sunyit.edu (A-V25.rh.sunyit.edu [150.156.211.85]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA04502 for ; Mon, 28 Jul 1997 20:55:47 -0700 (PDT) Received: from localhost (perlsta@localhost) by server.local.sunyit.edu (8.8.5/8.8.5) with SMTP id AAA16972; Tue, 29 Jul 1997 00:01:02 GMT X-Authentication-Warning: server.local.sunyit.edu: perlsta owned process doing -bs Date: Tue, 29 Jul 1997 00:01:02 +0000 (GMT) From: Alfred Perlstein X-Sender: perlsta@server.local.sunyit.edu To: FreeBSD Development cc: Kevin Van Maren , freebsd-smp@FreeBSD.ORG Subject: Re: SMP? (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Something must have gotten lost in the translation :) What i would like to do is have both CPUs run at the same MHZ, but have the P200MMX clocked down to the same speed as the P150, i don't see a problem with slowing down the CPU, as usually the only difference between a P166MMX and a P200MMX is that somewhere in the 166's creation process something wasn't done perfect so that at 200Mhz it flakes out. If you are saying that the P150 and P200MMX run at different voltage... then that sucks, but hey what can i do? :) > > Mixing CPUs? Yes and no. It should be possible, but the CPUs really > > should be the same `stepping'. This isn't possible with a MMX and a > > non-MMX processor, as the Core voltages are different (and motherboard > > manufacturers only provide one voltage selection mechanism, as well > > as one clock-selecting mechanism -- theoretically you can run the > > CPUs are differnt speeds as long as the BUS speed is the same). > > > > We sell several boards, and the only possible "yes" situation I can think > of would be top mix a 256K and 512K PPro. I can not think of any other > viable mix. > > Each board has only one setting each for bus frequency, clock multiplier, > and voltage. > > Only Intel CPUs are SMP compliant (no K5, K6, Cyrix, etc.). AMD claims > they are developing an open multiprocessor spec, but it has not yet been > finalized or implemented. > > Kevin > From owner-freebsd-smp Mon Jul 28 21:43:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA07847 for smp-outgoing; Mon, 28 Jul 1997 21:43:48 -0700 (PDT) Received: from onyx.atipa.com (user26761@ns.atipa.com [208.128.22.10]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id VAA07822 for ; Mon, 28 Jul 1997 21:43:32 -0700 (PDT) Received: (qmail-queue invoked by uid 1018); 29 Jul 1997 04:45:22 -0000 Date: Mon, 28 Jul 1997 22:45:22 -0600 (MDT) From: FreeBSD Mailing List X-Sender: freebsd@dot.ishiboo.com To: Alfred Perlstein cc: Kevin Van Maren , freebsd-smp@FreeBSD.ORG Subject: Re: SMP? (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 29 Jul 1997, Alfred Perlstein wrote: > Something must have gotten lost in the translation :) > > What i would like to do is have both CPUs run at the same MHZ, but have > the P200MMX clocked down to the same speed as the P150, i don't see a > problem with slowing down the CPU, as usually the only difference between > a P166MMX and a P200MMX is that somewhere in the 166's creation process > something wasn't done perfect so that at 200Mhz it flakes out. Not too certain about that... I know that some boards exist (e.g. Gigabyte GA-586DX-512 older revisions) that support the 166MMX but _DO_NOT_ support the 200MMX, even though CPU bus will run at 200MHz. The newer versions of the above board have CPU voltage auto-detect, but I would not be confident in its ability to run 2 different voltages. It would be a kludge that MAY work, but I would not recommend it. > If you are saying that the P150 and P200MMX run at different voltage... > then that sucks, but hey what can i do? :) Intel just dropped their prices this morning... maybe you could "liquidate" the older processor. The 166MMX's are down under $200 each. The price for (2) 166's will still be less than the original budget for the single 200MMX! Kevin From owner-freebsd-smp Tue Jul 29 07:56:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA18832 for smp-outgoing; Tue, 29 Jul 1997 07:56:21 -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 HAA18824 for ; Tue, 29 Jul 1997 07:56:14 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id IAA08521; Tue, 29 Jul 1997 08:55:59 -0600 (MDT) Message-Id: <199707291455.IAA08521@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Lars Fredriksen cc: smp@FreeBSD.ORG Subject: Re: Instantanious combustions!! In-reply-to: Your message of "Mon, 28 Jul 1997 15:54:36 CDT." <199707282054.PAA00509@fredriks-1.pr.mcs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 29 Jul 1997 08:55:58 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > Has anyone had trouble with instantanious reboots on current since > yesterday? Currently nfs traffic, tcp traffic and fsck work seems to trigger > it. This wide patter might just indicate that something else is wrong as well > A straight boot (automatic) will always(so far anyway) result in a instantanious > reboot when fsck hits the 2nd or third filesystem. If you boot with the -v > option, that problem seems to go away. This seems to indicate that there is > some kind of race condition going on, but unfortunately the kernel doesn't > panic so it is hard to find out what the race is. Anyone has a good starting > point for what kind of breakpoint one could set to try to capture the > problem(assuming that there is one)? (Steve??) my system has no such problem, but its not NFS mounting anything. It built a complete world without problem yesterday. other than trying without PEND_INTS nothing comes to mind. I'm busy making a living this week so I won;t be able to actively help for awhile... -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Tue Jul 29 16:09:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA19842 for smp-outgoing; Tue, 29 Jul 1997 16:09:02 -0700 (PDT) Received: from sanjuan.cs.washington.edu (sanjuan.cs.washington.edu [128.95.8.118]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA19837 for ; Tue, 29 Jul 1997 16:08:56 -0700 (PDT) Received: from localhost (ulbright@localhost) by sanjuan.cs.washington.edu (8.8.5+CS/7.2ws+) with SMTP id QAA28591 for ; Tue, 29 Jul 1997 16:08:54 -0700 (PDT) Date: Tue, 29 Jul 1997 16:08:54 -0700 (PDT) From: Christopher Ulbright To: smp@FreeBSD.ORG Subject: Input on spl changes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hello, In our OS (SPIN) we use FreeBSD as a source of low level(start-up, device drivers) code. At the moment I'm attempting to modify things for SMP. The currently unresolved issue relates to the use of Optimistic Interrupt Protection, often referred to as spl for system priority level. In FreeBSD spl utilizes a global variable, cpl(current priority level), to denote the interruptability of the process currently running on a processor. Any manipulation of the cpl variable is done while the "Giant Lock" is held (is this true?), which protects this shared piece of data. In the uni-processor version of our OS, we make use of spl to protect certain critical sections. The problem arises from the fact that we have a mulit-threaded, preemptable kernel. In the SMP case, the value of cpl can be changed by thread-1 on cpu0 then saved with the state of thread-2 on cpu1 when a context switch occurs. In this case, when thread-2 is run again, the value restored to cpl will be incorrect. My initial reaction was to make per-processor cpl variables but this in and of itself will not solve the problem. This is because when thread-1 on cpu0 sets cpl to disable certain INTs, thread-2 on cpu1 could still enter some code section that thread-1(cpu0) assumes it has exclusive access to. Steve P. informed me that a per-cpu cpl wasn't a good idea. New idea: Have per-cpu cpl variables and restrict access to any FreeBSD code to one cpu at a time. Each time a thread enters FBSD code, it will have restored it's appropriate cpl value. If it needs to enter code requiring the masking of INTs, the cpu-specific cpl will be set accordingly. Restricted access could be achieved through use of a lock similar to Steve's mp_lock. Does anyone see the faults in this idea? Are there other problems with per-cpu cpls that I need to consider? Thanks for any thoughts/ideas/advice. -chris ulbright SPIN OS Project Univ. of WA http://www.cs.washington.edu/research/projects/spin/www/ From owner-freebsd-smp Tue Jul 29 17:57:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA25692 for smp-outgoing; Tue, 29 Jul 1997 17:57:18 -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 RAA25685 for ; Tue, 29 Jul 1997 17:57:15 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id RAA10698; Tue, 29 Jul 1997 17:58:27 -0700 (PDT) Message-Id: <199707300058.RAA10698@implode.root.com> To: Christopher Ulbright cc: smp@FreeBSD.ORG Subject: Re: Input on spl changes In-reply-to: Your message of "Tue, 29 Jul 1997 16:08:54 PDT." From: David Greenman Reply-To: dg@root.com Date: Tue, 29 Jul 1997 17:58:27 -0700 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >My initial reaction was to make per-processor cpl variables but this in >and of itself will not solve the problem. This is because when thread-1 >on cpu0 sets cpl to disable certain INTs, thread-2 on cpu1 could still >enter some code section that thread-1(cpu0) assumes it has exclusive >access to. Steve P. informed me that a per-cpu cpl wasn't a good idea. > >New idea: Have per-cpu cpl variables and restrict access to any FreeBSD >code to one cpu at a time. Each time a thread enters FBSD code, it will >have restored it's appropriate cpl value. If it needs to enter code >requiring the masking of INTs, the cpu-specific cpl will be set >accordingly. > >Restricted access could be achieved through use of a lock similar to >Steve's mp_lock. > >Does anyone see the faults in this idea? Are there other problems with >per-cpu cpls that I need to consider? > >Thanks for any thoughts/ideas/advice. Hmmm. per-cpu cpl doesn't make any sense to me - at least not in the current paradigm. We're using cpl as a global lock on interrupt reentrancy and this is not a cpu-specific thing. I think the current SMP code blocks having concurrent CPUs in interrupt code, but this restriction shouldn't be necessary as long as cpl functions as a global lock. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-smp Tue Jul 29 22:18:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA09130 for smp-outgoing; Tue, 29 Jul 1997 22:18:56 -0700 (PDT) Received: from mx.serv.net (mx.serv.net [205.153.153.234]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA09123 for ; Tue, 29 Jul 1997 22:18:52 -0700 (PDT) Received: from MindBender.serv.net (root@mindbender.serv.net [205.153.153.98]) by mx.serv.net (8.8.5/8.8.5) with ESMTP id WAA04125; Tue, 29 Jul 1997 22:19:01 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.serv.net (8.7.5/8.7.3) with SMTP id WAA06147; Tue, 29 Jul 1997 22:18:43 -0700 (PDT) Message-Id: <199707300518.WAA06147@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: dg@root.com cc: Christopher Ulbright , smp@freebsd.org Subject: Re: Input on spl changes In-reply-to: Your message of Tue, 29 Jul 97 17:58:27 -0700. <199707300058.RAA10698@implode.root.com> Date: Tue, 29 Jul 1997 22:18:43 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>My initial reaction was to make per-processor cpl variables but this in >>and of itself will not solve the problem. This is because when thread-1 >>on cpu0 sets cpl to disable certain INTs, thread-2 on cpu1 could still >>enter some code section that thread-1(cpu0) assumes it has exclusive >>access to. Steve P. informed me that a per-cpu cpl wasn't a good idea. >> >>New idea: Have per-cpu cpl variables and restrict access to any FreeBSD >>code to one cpu at a time. Each time a thread enters FBSD code, it will >>have restored it's appropriate cpl value. If it needs to enter code >>requiring the masking of INTs, the cpu-specific cpl will be set >>accordingly. >> >>Restricted access could be achieved through use of a lock similar to >>Steve's mp_lock. >> >>Does anyone see the faults in this idea? Are there other problems with >>per-cpu cpls that I need to consider? >> >>Thanks for any thoughts/ideas/advice. > Hmmm. per-cpu cpl doesn't make any sense to me - at least not in the >current paradigm. We're using cpl as a global lock on interrupt reentrancy >and this is not a cpu-specific thing. I think the current SMP code blocks >having concurrent CPUs in interrupt code, but this restriction shouldn't >be necessary as long as cpl functions as a global lock. It sounds like what you're trying to do would be better achieved with "standard" critical sections, or something similar. It would only allow one thread into a specific area of code at a time, but would not block the other processor if it wasn't trying to run in that piece of code. This, of course, would have no affect on interrupt levels. ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@MindBender.serv.net --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... ----------------------------------------------------------------------------- From owner-freebsd-smp Wed Jul 30 04:47:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA25798 for smp-outgoing; Wed, 30 Jul 1997 04:47:35 -0700 (PDT) Received: from cenotaph.snafu.de (gw-deadnet.snafu.de [194.121.229.33]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id EAA25791; Wed, 30 Jul 1997 04:47:21 -0700 (PDT) Received: by cenotaph.snafu.de from deadline.snafu.de using smtp id m0wtXDi-000KB8C; Wed, 30 Jul 1997 13:47:10 +0200 (CEST) (Smail-3.2 1996-Jul-4 #1) Received: by deadline.snafu.de id m0wtXDg-0004nDC; Wed, 30 Jul 1997 13:47:08 +0200 (CEST) (Smail-3.2 1996-Jul-4 #1) Message-Id: From: root@deadline.snafu.de (Andreas S. Wetzel) Subject: COMPAT_LINUX + -current To: smp@freebsd.org Date: Wed, 30 Jul 1997 13:47:07 +0200 (CEST) Cc: current@freebsd.org Organization: A world stranger than you have ever imagined. X-Mailer: ELM [version 2.4ME+ PL13] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi! --- Some days ago I reported problems with -current and the linux emulator code. I have now updated to -current as of 30/07/97 and rebuild world and everything seems to run fine again apart from the Linux QuakeWorld client which doesn't run because of: Linux-emul(267): ioperm() not supported So I think there hasn't been a real problem with -current but a problem with my last build. Sorry for your inconvenience. Regards, Mickey -- (__) (@@) Andreas S. Wetzel Mail: mickey@deadline.snafu.de /-------\/ Utrechter Strasse 41 Web: http://cenotaph.snafu.de/ / | || 13347 Berlin Fon: <+4930> 456 066 90 * ||----|| Germany Fax: <+4930> 456 066 91/92 ~~ ~~ From owner-freebsd-smp Fri Aug 1 07:17:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA22114 for smp-outgoing; Fri, 1 Aug 1997 07:17:48 -0700 (PDT) Received: from mhub1.tc.umn.edu (0@mhub1.tc.umn.edu [128.101.131.51]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id HAA22109 for ; Fri, 1 Aug 1997 07:17:42 -0700 (PDT) Received: from gold.tc.umn.edu by mhub1.tc.umn.edu; Fri, 1 Aug 97 09:17:23 -0500 Received: from pub-24-c-172.dialup.umn.edu by gold.tc.umn.edu; Fri, 1 Aug 97 09:17:22 -0500 Date: Fri, 1 Aug 1997 09:14:38 -0500 (CDT) From: dave adkins Reply-To: dave adkins To: smp@freebsd.org Subject: interrupt latency and silo overflows in SMP since 970729 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Have there been any changes since 970729 that could have increased interrupt latencies significantly in the SMP kernel? I'm used to a few silo overflows now and then but kernels after 970729 have seem to have increased their frequency by about a factor of ten. My hw is a tyan S1563D 2x200 with 80Mbytes of DRAM, ide and NCR scsi. Replacing wd with v1.132 and building with wd82371 for piix3 support I still see the silo problem. dave adkins From owner-freebsd-smp Fri Aug 1 08:57:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA26407 for smp-outgoing; Fri, 1 Aug 1997 08:57:39 -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 IAA26391 for ; Fri, 1 Aug 1997 08:57:18 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id JAA22422; Fri, 1 Aug 1997 09:57:08 -0600 (MDT) Message-Id: <199708011557.JAA22422@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: dave adkins cc: smp@FreeBSD.ORG Subject: Re: interrupt latency and silo overflows in SMP since 970729 In-reply-to: Your message of "Fri, 01 Aug 1997 09:14:38 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Aug 1997 09:57:08 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > Have there been any changes since 970729 that could have increased > interrupt latencies significantly in the SMP kernel? I'm used to a few > silo overflows now and then but kernels after 970729 have seem to have > increased their frequency by about a factor of ten. undef PEND_INTS in i386/include/smptests.h and let me know how it affects things. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Fri Aug 1 09:10:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA27027 for smp-outgoing; Fri, 1 Aug 1997 09:10:44 -0700 (PDT) Received: from mhub2.tc.umn.edu (0@mhub2.tc.umn.edu [128.101.131.52]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA27020 for ; Fri, 1 Aug 1997 09:10:31 -0700 (PDT) Received: from gold.tc.umn.edu by mhub2.tc.umn.edu; Fri, 1 Aug 97 11:10:25 -0500 Received: from pub-13-b-148.dialup.umn.edu by gold.tc.umn.edu; Fri, 1 Aug 97 11:10:24 -0500 Date: Fri, 1 Aug 1997 11:07:38 -0500 (CDT) From: dave adkins To: Steve Passe cc: smp@FreeBSD.ORG Subject: Re: interrupt latency and silo overflows in SMP since 970729 In-Reply-To: <199708011557.JAA22422@Ilsa.StevesCafe.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 1 Aug 1997, Steve Passe wrote: > Hi, > > > Have there been any changes since 970729 that could have increased > > interrupt latencies significantly in the SMP kernel? I'm used to a few > > silo overflows now and then but kernels after 970729 have seem to have > > increased their frequency by about a factor of ten. > > undef PEND_INTS in i386/include/smptests.h and let me know how it affects > things. > > -- > Steve Passe | powered by > smp@csn.net | Symmetric MultiProcessor FreeBSD > > > steve, It was the first thing I tried. Sorry I didn't mention it in the original post. I also disabled your profiling in mplock.s with no significant effect (as expected). To quantify the phenomenon, with 970729 kernel I see about 5 to 10 silo overflows per hour of connection. With 970731 kernel I see about 100 to 150 per hour and often drop ftp and cvsup with timeouts. The system boots on IDE but /usr and the rest are mounted on NCR SCSI so about the only IDE activity is in /bin, /etc, and /var. MotherBoard: tyan S1653D 2x200 Bios: award 4.01 Drives: ide, NCR scsi dave From owner-freebsd-smp Fri Aug 1 09:24:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA27581 for smp-outgoing; Fri, 1 Aug 1997 09:24:36 -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 JAA27576 for ; Fri, 1 Aug 1997 09:24:32 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id KAA22586; Fri, 1 Aug 1997 10:24:30 -0600 (MDT) Message-Id: <199708011624.KAA22586@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: dave adkins cc: smp@FreeBSD.ORG Subject: Re: interrupt latency and silo overflows in SMP since 970729 In-reply-to: Your message of "Fri, 01 Aug 1997 11:07:38 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Aug 1997 10:24:30 -0600 Sender: owner-freebsd-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Dave, > > > Have there been any changes since 970729 that could have increased > > > interrupt latencies significantly in the SMP kernel? I'm used to a few > > > silo overflows now and then but kernels after 970729 have seem to have > > > increased their frequency by about a factor of ten. > > > > undef PEND_INTS in i386/include/smptests.h and let me know how it affects > > things. > ... > It was the first thing I tried. Sorry I didn't mention it in the original > post. I also disabled your profiling in mplock.s with no significant > effect (as expected). To quantify the phenomenon, with 970729 kernel I see > about 5 to 10 silo overflows per hour of connection. With 970731 kernel I > see about 100 to 150 per hour and often drop ftp and cvsup with timeouts. > The system boots on IDE but /usr and the rest are mounted on NCR SCSI so > about the only IDE activity is in /bin, /etc, and /var. > > > MotherBoard: tyan S1653D 2x200 > Bios: award 4.01 > Drives: ide, NCR scsi > > dave > > try undefing FREE_FIRST in mplock. you also might want to redefine GLPROFILE and look at the numbers. to do this hit CNTL-PRINTSCREEN to trap to the debugger, and "x gethits,6" on my machine I saw: db> x gethits,3 _gethits: 118de 1c7dd3 3f106 db> x tryhits,3 _tryhits: 9938 2196d 44cc the gethits #s refer to get_mplock calls, tryhits the try_mplock calls. the first # is the times the lock was acquired as an upgrade, ie the caller already possed it. The second # is the times the lock was acquired because it was free. the 3rd is the times that the caller had to spin waiting for it to become free (get_mplock) or the times it failed (try_mplock). Note that in the case of get_mplock the 2nd # must be adjusted by subtracting the 3rd to reflecrt the times it was found free on the first test. It would be useful to see these #s for both FREE_FIRST enabled and disabled, although I don't expect a big difference. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Fri Aug 1 11:51:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA05432 for smp-outgoing; Fri, 1 Aug 1997 11:51:41 -0700 (PDT) Received: from gw1.asacomputers.com (root@gw1.asacomputers.com [204.69.220.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA05426 for ; Fri, 1 Aug 1997 11:51:38 -0700 (PDT) Received: by gw1.asacomputers.com id IAA11364; Fri, 1 Aug 1997 08:51:56 -0700 (PDT) Message-Id: <2.2.32.19970801185134.00685234@gw1> X-Sender: nasir@gw1 X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 01 Aug 1997 11:51:34 -0700 To: smp@freebsd.org From: Nasir Ahmed Subject: dual processor under freebsd Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, Need help to make pentium system work with 2 processor under freebsd. Please send me detail information and use my private email address. Thanks Nasir Ahmesd Email: nasir@asacomputers.com nasir@pacbell.net Nasir Ahmed TEL: (408)232-5999 x229 FAX: (408)232-5963 nasir@asacomputers.com ======================= From owner-freebsd-smp Sat Aug 2 05:05:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA20924 for smp-outgoing; Sat, 2 Aug 1997 05:05:31 -0700 (PDT) Received: from necropolis.org ([207.66.220.160]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA20919 for ; Sat, 2 Aug 1997 05:05:27 -0700 (PDT) Received: from localhost (edmond@localhost) by necropolis.org (8.8.5/8.8.5) with SMTP id FAA25551 for ; Sat, 2 Aug 1997 05:01:47 -0700 (PDT) X-Authentication-Warning: necropolis.org: edmond owned process doing -bs Date: Sat, 2 Aug 1997 05:01:46 -0700 (PDT) From: "Andrew N. Edmond" X-Sender: edmond@necropolis.org To: freebsd-smp@freebsd.org Subject: SMP reliability... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Great to see FreeBSD heading towards SMP! The FreeBSD newsletter mentioned Yahoo is very eager for this, and I'm sure many other people besides myself are eagerly anticipating full relability on this SMP code! I will be purchasing a four PPro200 processor ready sytsem soon, I'm gonna run it just one processor until the SMP code is ready to run mission critical and then slap another three processors in the box. When is the expected data the SMP code will be up to the mission critical safe level? When freebsd 3.0 arrives? Andy ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: \-/ :::::::: Andrew N. Edmond - finger for PGP key :::::::::: \-/ /-\ :::::: ............ :::::: /-\ \-/ ::: edmond@lycaeum.org :::::: an1@anon.nymserver.com ::: \-/ /-\ : Director of the Lycaeum :: the Nymserver Administrator : /-\ \-/ ::: www.lycaeum.org :::::: www.nymserver.com ::: \-/ ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: From owner-freebsd-smp Sat Aug 2 08:33:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA27968 for smp-outgoing; Sat, 2 Aug 1997 08:33:34 -0700 (PDT) Received: from groa.uct.ac.za (groa.uct.ac.za [137.158.128.7]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id IAA27959 for ; Sat, 2 Aug 1997 08:33:27 -0700 (PDT) Received: from rv by groa.uct.ac.za with local (Exim 1.653 #1) id 0wugBA-0001j0-00; Sat, 2 Aug 1997 17:33:16 +0200 Subject: Re: SMP reliability... To: edmond@shaman.lycaeum.org (Andrew N. Edmond) Date: Sat, 2 Aug 1997 17:33:15 +0200 (SAT) Cc: freebsd-smp@freebsd.org In-Reply-To: from "Andrew N. Edmond" at Aug 2, 97 05:01:46 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Message-Id: From: Russell Vincent Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Andrew N. Edmond wrote: > I will be purchasing a four PPro200 processor ready sytsem soon, I'm gonna > run it just one processor until the SMP code is ready to run mission > critical and then slap another three processors in the box. That depends what you are doing, I suppose. I have the following: 5:21PM up 22 days, 1:20, 1 user, load averages: 0.18, 0.19, 0.14 FreeBSD 3.0-CURRENT (UNINET) #0: Fri Jul 11 15:07:18 SAT 1997 This is one of 5 dual-P5 (256MB RAM, 24GB disk) machines running as a nationwide news and web cache network. The machines each handle a relatively full newsfeed (feeding sites, no readers) and full cache traffic for a few universities and smaller educational/research institutions. As you may note, 22 days ago was when I did the upgrade to that version of -current. No problems with it (or the others) at all. There are no performance problems and in fact I expect the machines to be able to take a _lot_ more than they are getting. I upgrade the machines (remotely) using CVSup and a make world every couple of months (at the most). What a pleasure. :-) Many thanks to the FreeBSD team. -Russell