From owner-freebsd-smp Sun Nov 24 00:08:42 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA03139 for smp-outgoing; Sun, 24 Nov 1996 00:08:42 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA03131 for freebsd-smp; Sun, 24 Nov 1996 00:08:38 -0800 (PST) Date: Sun, 24 Nov 1996 00:08:38 -0800 (PST) From: Peter Wemm Message-Id: <199611240808.AAA03131@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/i386 mp_machdep.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/24 00:08:35 Modified: i386/i386 mp_machdep.c Log: Remove the for the normal kernel without the experimental IO apic options. Revision Changes Path 1.18 +1 -3 sys/i386/i386/mp_machdep.c From owner-freebsd-smp Sun Nov 24 00:19:45 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA03415 for smp-outgoing; Sun, 24 Nov 1996 00:19:45 -0800 (PST) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA03405 for ; Sun, 24 Nov 1996 00:19:36 -0800 (PST) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.3/8.8.3) with ESMTP id QAA00407 for ; Sun, 24 Nov 1996 16:19:32 +0800 (WST) Message-Id: <199611240819.QAA00407@spinner.DIALix.COM> To: smp@freebsd.org Subject: state of current smp kernel.. Date: Sun, 24 Nov 1996 16:19:31 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi all.. After Steve's bit of detective work, the smp kernel compiles and runs for me again, even with the distributed syscons.c etc. I don't know why syscons is causing problems for some people, but it's working perfectly here (I'm running it in smp right now). For those having trouble, there's a couple of bits if info that would be useful. 1: does the 3.0-current kernel compile and work for you? 2: do you have ps/2 mouse hardware on the motherboard? Is it disabled in the bios if you are not using it? If the -current kernel doesn't work for you, we need to solve that problem urgently... -Peter From owner-freebsd-smp Sun Nov 24 00:51:15 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA04614 for smp-outgoing; Sun, 24 Nov 1996 00:51:15 -0800 (PST) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA04609 for ; Sun, 24 Nov 1996 00:51:07 -0800 (PST) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.3/8.8.3) with ESMTP id QAA00327 for ; Sun, 24 Nov 1996 16:51:03 +0800 (WST) Message-Id: <199611240851.QAA00327@spinner.DIALix.COM> To: smp@freebsd.org Subject: Whee! :-) Date: Sun, 24 Nov 1996 16:51:03 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At last! :-) APIC_IO works for me on a system with an EISA 2742T controller! :-) -Peter From owner-freebsd-smp Sun Nov 24 01:04:17 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA05061 for smp-outgoing; Sun, 24 Nov 1996 01:04:17 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA05012 for ; Sun, 24 Nov 1996 01:04:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id CAA22933; Sun, 24 Nov 1996 02:03:46 -0700 Message-Id: <199611240903.CAA22933@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Peter Wemm cc: smp@freebsd.org Subject: Re: state of current smp kernel.. In-reply-to: Your message of "Sun, 24 Nov 1996 16:19:31 +0800." <199611240819.QAA00407@spinner.DIALix.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 24 Nov 1996 02:03:45 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > I don't know why syscons is causing problems for some people, but it's > working perfectly here (I'm running it in smp right now). > > For those having trouble, there's a couple of bits if info that would be > useful. --- > 1: does the 3.0-current kernel compile and work for you? yes, with syscons.c v 1.189 the console works fine in the non SMP kernel. --- > 2: do you have ps/2 mouse hardware on the motherboard? yes, but no PS/2 mouse is attached. > Is it disabled in the bios if you are not using it? there is no BIOS entry to enable/disable it. The manual says it is auto-detected and installed @ IRQ12 if found. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Sun Nov 24 01:20:09 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA05409 for smp-outgoing; Sun, 24 Nov 1996 01:20:09 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA05366 for ; Sun, 24 Nov 1996 01:20:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id CAA23035; Sun, 24 Nov 1996 02:19:47 -0700 Message-Id: <199611240919.CAA23035@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Peter Wemm cc: smp@freebsd.org Subject: Re: Whee! :-) In-reply-to: Your message of "Sun, 24 Nov 1996 16:51:03 +0800." <199611240851.QAA00327@spinner.DIALix.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 24 Nov 1996 02:19:46 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > At last! :-) > > APIC_IO works for me on a system with an EISA 2742T controller! :-) > > -Peter will you be checking something in for this, or did it just start working (in that way that computers do to play with our minds)? I'm headed for bed, I'll be checking in new vector.s, icu.s, microtime.s smptests.h, mp_machdep.c, init_main.c and ??? tomorrow. > Modified: i386/i386 mp_machdep.c > Log: > Remove the for the normal kernel without > the experimental IO apic options. I was getting kind of tired of that also.... This was to "encourage" people to test APIC_IO. We need to start thinking about making APIC_IO the default. Perhaps once we get confirmation that my "mixed-mode" 8259 stuff works it will be time to do so. I will be commiting that stuff as an option tomorrow. I've also removed the APIC_LAZY warning from mp_machdep.c and made APIC_LAZY the default in smptests.h Now that the missing INT problem is past us i386/isa/if_ed.c could be reverted to -current. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Sun Nov 24 01:42:09 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA06440 for smp-outgoing; Sun, 24 Nov 1996 01:42:09 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA06428 for freebsd-smp; Sun, 24 Nov 1996 01:42:06 -0800 (PST) Date: Sun, 24 Nov 1996 01:42:06 -0800 (PST) From: Peter Wemm Message-Id: <199611240942.BAA06428@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/isa icu.s Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/24 01:42:03 Modified: i386/isa icu.s Log: Fix accidental merge spam that broke the PC98 compile Revision Changes Path 1.17 +2 -0 sys/i386/isa/icu.s From owner-freebsd-smp Sun Nov 24 02:21:47 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA08115 for smp-outgoing; Sun, 24 Nov 1996 02:21:47 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA08105 for freebsd-smp; Sun, 24 Nov 1996 02:21:44 -0800 (PST) Date: Sun, 24 Nov 1996 02:21:44 -0800 (PST) From: Peter Wemm Message-Id: <199611241021.CAA08105@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/isa vector.s Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/24 02:21:41 Modified: i386/isa vector.s Log: Oops, missed part of this when merging -current last time. This is Bruce's code to limit FAST_INTR handlers to a maximum of three concurrent handlers to avoid overflowing the stack. Revision Changes Path 1.23 +7 -3 sys/i386/isa/vector.s From owner-freebsd-smp Sun Nov 24 09:53:10 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA00855 for smp-outgoing; Sun, 24 Nov 1996 09:53:10 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA00810; Sun, 24 Nov 1996 09:52:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id KAA25252; Sun, 24 Nov 1996 10:52:35 -0700 Message-Id: <199611241752.KAA25252@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Peter Wemm cc: freebsd-smp@freefall.freebsd.org Subject: Re: cvs commit: sys/i386/isa icu.s In-reply-to: Your message of "Sun, 24 Nov 1996 01:42:06 PST." <199611240942.BAA06428@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 24 Nov 1996 10:52:34 -0700 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > peter 96/11/24 01:42:03 > > Modified: i386/isa icu.s > Log: > Fix accidental merge spam that broke the PC98 compile I've been wondering how to attack that PC98 stuff. Does anyone know if there is any chance at all of a PC98 machine running SMP code? The specific questions is: #ifdef PC98 #define ICU_THIS #else #define ICU_THAT #endif If I then need to conditionalize for APIC_IO should I say NO: #ifdef APIC_IO #define APIC_THUS #else #ifdef PC98 #define ICU_THIS #else #define ICU_THAT #endif #endif or YES: #ifdef APIC_IO #ifdef PC98 #define APIC_PC98 #else #define APIC_PCAT #endif #else ... -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Sun Nov 24 09:54:45 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA01028 for smp-outgoing; Sun, 24 Nov 1996 09:54:45 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA01010 for ; Sun, 24 Nov 1996 09:54:31 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id IAA08427 for ; Sun, 24 Nov 1996 08:06:02 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id JAA25292; Sun, 24 Nov 1996 09:02:12 -0700 (MST) Date: Sun, 24 Nov 1996 09:02:12 -0700 (MST) Message-Id: <199611241602.JAA25292@rocky.mt.sri.com> From: Nate Williams To: Peter Wemm Cc: smp@freebsd.org Subject: Re: state of current smp kernel.. In-Reply-To: <199611240819.QAA00407@spinner.DIALix.COM> References: <199611240819.QAA00407@spinner.DIALix.COM> Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > After Steve's bit of detective work, the smp kernel compiles and runs for > me again, even with the distributed syscons.c etc. > > I don't know why syscons is causing problems for some people, but it's > working perfectly here (I'm running it in smp right now). It works on some systems, and is broken on others. Before I brought the code into 2.2 I tested it on 3 boxes and it worked on all of them, but apparently there is enough different hardware that it's broken others. (Including boxes w/out PS/2 mice, although all of the HW I tested it on have PS/2 mice, maybe that's a data point.) Nate From owner-freebsd-smp Sun Nov 24 10:15:31 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA03568 for smp-outgoing; Sun, 24 Nov 1996 10:15:31 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA03553 for freebsd-smp; Sun, 24 Nov 1996 10:15:25 -0800 (PST) Date: Sun, 24 Nov 1996 10:15:25 -0800 (PST) From: Peter Wemm Message-Id: <199611241815.KAA03553@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/isa vector.s Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/24 10:15:22 Modified: i386/isa vector.s Log: correct a missed merge from -current, where the interrupt count was being prematurely incremented. Revision Changes Path 1.24 +1 -1 sys/i386/isa/vector.s From owner-freebsd-smp Sun Nov 24 10:21:04 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA03868 for smp-outgoing; Sun, 24 Nov 1996 10:21:04 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA03859 for freebsd-smp; Sun, 24 Nov 1996 10:21:00 -0800 (PST) Date: Sun, 24 Nov 1996 10:21:00 -0800 (PST) From: Peter Wemm Message-Id: <199611241821.KAA03859@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/isa vector.s Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/24 10:20:59 Modified: i386/isa vector.s Log: Both forms of the FAST_INTR() macro were effectively the same, remove the special case for APIC_IO && APIC_LAZY. It seems this was made a special case when Steve applied Bruces work, but the change was to actually limit the cases where the fast interrupt handler would switch to a normal handler's service routine when nested > 3. Since the code to do this is now in -current, the "normal" code was now effectively the same as the special case version. This file is now in sync with the recent changes in -current. Revision Changes Path 1.25 +0 -71 sys/i386/isa/vector.s From owner-freebsd-smp Sun Nov 24 10:24:40 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA04002 for smp-outgoing; Sun, 24 Nov 1996 10:24:40 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA03995 for freebsd-smp; Sun, 24 Nov 1996 10:24:39 -0800 (PST) Date: Sun, 24 Nov 1996 10:24:39 -0800 (PST) From: Peter Wemm Message-Id: <199611241824.KAA03995@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/conf newvers.sh Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/24 10:24:39 Modified: conf newvers.sh Log: Don't call the smp kernels 3.0-CURRENT. Let's wave our (danger!) flag and use 3.0-SMP instead. Revision Changes Path 1.2 +34 -5 sys/conf/newvers.sh From owner-freebsd-smp Sun Nov 24 10:32:10 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA04243 for smp-outgoing; Sun, 24 Nov 1996 10:32:10 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA04232 for ; Sun, 24 Nov 1996 10:32:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id LAA25475; Sun, 24 Nov 1996 11:31:41 -0700 Message-Id: <199611241831.LAA25475@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Nate Williams cc: Peter Wemm , smp@freebsd.org Subject: Re: state of current smp kernel.. In-reply-to: Your message of "Sun, 24 Nov 1996 09:02:12 MST." <199611241602.JAA25292@rocky.mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 24 Nov 1996 11:31:41 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > It works on some systems, and is broken on others. Before I brought the > code into 2.2 I tested it on 3 boxes and it worked on all of them, but > apparently there is enough different hardware that it's broken others. > > (Including boxes w/out PS/2 mice, although all of the HW I tested it on > have PS/2 mice, maybe that's a data point.) The symptoms I see look like the top-end of the driver is missing. Ie, I 'see' repeatable reaction to hitting keys, usually something that looks like a control char to the term code. They come in pairs, the 1st from the downstroke (switch make), and the 2nd (the repeat) on the upstroke (switch break). My motherboard has builtin PS/2 connector but no PS/2 mouse conected. The BIOS has NO manual enable for it, book claims its auto-detected and enabled. I have never seen any indication that it is enabled or "seen" during boots. The -current kernel (11-20) has NO problems with v 1.189, but the SMP kernel shows these symptoms with same version of syscons.c They first show up at single-user mode root shell prompt. At htis point the 2nd CPU ain't doing much. The biggest difference bwtween the 2 kernels is the configurations, ie which options are included. Perhaps its an interaction or "code position" problem, and not an internal syscons problem. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Sun Nov 24 15:46:27 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA20696 for smp-outgoing; Sun, 24 Nov 1996 15:46:27 -0800 (PST) Received: (from fsmp@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA20689 for freebsd-smp; Sun, 24 Nov 1996 15:46:24 -0800 (PST) Date: Sun, 24 Nov 1996 15:46:24 -0800 (PST) From: Steve Passe Message-Id: <199611242346.PAA20689@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/kern init_main.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk fsmp 96/11/24 15:46:23 Modified: kern init_main.c Log: hack to get around the brokenness of the smp_idleloop(). smp_idleloop now ignores the idle proc queue. cpu_switch() still checks it so (non cpuidleN) idle procs will still run, but they may be slow to start. This greatly improves single task execution speed. Revision Changes Path 1.32 +11 -4 sys/kern/init_main.c From owner-freebsd-smp Sun Nov 24 15:58:37 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA21314 for smp-outgoing; Sun, 24 Nov 1996 15:58:37 -0800 (PST) Received: (from fsmp@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA21305 for freebsd-smp; Sun, 24 Nov 1996 15:58:30 -0800 (PST) Date: Sun, 24 Nov 1996 15:58:30 -0800 (PST) From: Steve Passe Message-Id: <199611242358.PAA21305@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/include smp.h smptests.h sys/i386/i386 microtime.s mp_machdep.c mpapic.c sys/i386/isa clock.c icu.s isa.c vector.s Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk fsmp 96/11/24 15:58:22 Modified: i386/i386 microtime.s mp_machdep.c mpapic.c Log: Initial support for "mixed-mode" APIC/8259 INTerrupts. Enabled by defining IRQ_LO_NC in smptests.h, off by default. Revision Changes Path 1.15 +1 -12 sys/i386/i386/microtime.s 1.19 +13 -9 sys/i386/i386/mp_machdep.c 1.20 +45 -107 sys/i386/i386/mpapic.c Modified: i386/include smp.h smptests.h Log: added IGNORE_IDLEPROCS to control smp_idleloop() brokenness. added IRQ_LO_NC/IRQ_HI_NC to control "mixed-mode" APIC/8259 code. made APIC_LAZY the default action for APIC_IO mode. Revision Changes Path 1.20 +2 -5 sys/i386/include/smp.h 1.4 +23 -7 sys/i386/include/smptests.h Modified: i386/isa clock.c icu.s isa.c vector.s Log: vector.s: merged 2 INTR macros into one, general cleanup. icu.s: general cleanup, support for "mixed-mode" APIC/8259 code. clock.c & isa.c: initial support for "not-connected" IRQs. Revision Changes Path 1.11 +27 -6 sys/i386/isa/clock.c 1.18 +30 -34 sys/i386/isa/icu.s 1.9 +8 -1 sys/i386/isa/isa.c 1.26 +91 -165 sys/i386/isa/vector.s From owner-freebsd-smp Sun Nov 24 17:12:28 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA25589 for smp-outgoing; Sun, 24 Nov 1996 17:12:28 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA25528 for ; Sun, 24 Nov 1996 17:12:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id SAA27439 for ; Sun, 24 Nov 1996 18:11:57 -0700 Message-Id: <199611250111.SAA27439@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: freebsd-smp@freebsd.org Subject: Merge is ready. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 24 Nov 1996 18:11:57 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, The SMP src/sys merge is now complete. The system console is very broken for some motherboards. If you experience problems replace i386/include/console.h and i386/isa/syscons.c with: v 1.25 i386/include/console.h v 1.186 i386/isa/syscons.c both are in: http://freefall.freebsd.org/~fsmp/SMP/files/fixcons.tar.gz --- Features: Speed improvements for single task execution. Initial support for "mixed-mode" APIC/8259 INTerrupt control. EISA boards now appear to work. APIC_LAZY is now the default for "options APIC_IO". --- As always, get reports to us ASAP. In particular we need to know about console problems. Be sure to tell us about your hardware specifics, PS/2 mouse port or not, PS/2 mouse installed, etc. If you haven't tested "options APIC_IO" on your hardware yet you might want to do it now. I'm going to throw the switch on that one soon, and I don't want to here from everyone saying I didn't give ample warning! -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Sun Nov 24 17:58:48 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA27917 for smp-outgoing; Sun, 24 Nov 1996 17:58:48 -0800 (PST) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA27911 for ; Sun, 24 Nov 1996 17:58:43 -0800 (PST) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.3/8.8.3) with ESMTP id JAA03673; Mon, 25 Nov 1996 09:58:29 +0800 (WST) Message-Id: <199611250158.JAA03673@spinner.DIALix.COM> To: Steve Passe cc: freebsd-smp@freebsd.org Subject: Re: Merge is ready. In-reply-to: Your message of "Sun, 24 Nov 1996 18:11:57 MST." <199611250111.SAA27439@clem.systemsix.com> Date: Mon, 25 Nov 1996 09:58:29 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve Passe wrote: > Hi, > > The SMP src/sys merge is now complete. > > The system console is very broken for some motherboards. If you experience > problems replace i386/include/console.h and i386/isa/syscons.c with: > > v 1.25 i386/include/console.h > v 1.186 i386/isa/syscons.c > > both are in: http://freefall.freebsd.org/~fsmp/SMP/files/fixcons.tar.gz BTW, since CVS is required in order to get the files, everybody already has these revision. There is a slightly easier way: cd /where/the/smp/tree/is/sys/i386 cvs update -r v961006 isa/syscons.c include/console.h This is a "sticky" tag update. When new commits are made to these files, you *will not* get the new versions, you will remain at the 6th of october version. To undo this, you do a 'cvs update -A' and they will be unlocked. Cheers, -Peter From owner-freebsd-smp Mon Nov 25 03:19:51 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA09070 for smp-outgoing; Mon, 25 Nov 1996 03:19:51 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA09063 for freebsd-smp; Mon, 25 Nov 1996 03:19:47 -0800 (PST) Date: Mon, 25 Nov 1996 03:19:47 -0800 (PST) From: Peter Wemm Message-Id: <199611251119.DAA09063@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/i386 autoconf.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/25 03:19:43 Modified: i386/i386 autoconf.c Log: Kill the "press reset now! or return at your peril" warning if running in APIC_IO.. It's not exactly confidence inspiring since we're asking people to use it before it becomes default.. :-) Revision Changes Path 1.9 +0 -1 sys/i386/i386/autoconf.c From owner-freebsd-smp Mon Nov 25 03:28:22 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA09370 for smp-outgoing; Mon, 25 Nov 1996 03:28:22 -0800 (PST) Received: from hda.hda.com (ip29-max1-fitch.ziplink.net [199.232.245.29]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id DAA09363 for ; Mon, 25 Nov 1996 03:28:08 -0800 (PST) Received: (from dufault@localhost) by hda.hda.com (8.6.12/8.6.12) id GAA11718; Mon, 25 Nov 1996 06:25:56 -0500 From: Peter Dufault Message-Id: <199611251125.GAA11718@hda.hda.com> Subject: Re: Thread issues In-Reply-To: <199611240135.RAA22152@freefall.freebsd.org> from "Justin T. Gibbs" at "Nov 23, 96 05:35:45 pm" To: gibbs@freefall.freebsd.org (Justin T. Gibbs) Date: Mon, 25 Nov 1996 06:25:55 -0500 (EST) Cc: cracauer@cons.org, freebsd-smp@freebsd.org X-Mailer: ELM [version 2.4ME+ PL25 (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 > Having played with threads under NT, I must say that I find its APIs both > clean and easy to use. I wonder if we should take a step back and consider > what would be the best interface to supply for our users even if it vastly > differs from a "conventional UNIX thread" implementation. We can always > provide POSIX APIs on top of FreeBSD's native thread APIs. > > Threads and AIO are two features that the people doing embedded systems > with FreeBSD really want. In most cases, they are interested in > performance and time to market, not portability, so designing our own > interfaces would not hinder their efforts. In fact, a cleaner, more logical > set of APIs may reduce their TTM and make FreeBSD even more viable in this > arena. I don't agree. There is enough risk in a FreeBSD aproach that adhering to a standard API is a requirement. Working against an existing spec helps piece-wise implementation also. I have no complaint with a WIN32 thread interface as well, though I prefer to have the POSIX API native. -- Peter Dufault Real-Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267 From owner-freebsd-smp Mon Nov 25 03:43:10 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA10045 for smp-outgoing; Mon, 25 Nov 1996 03:43:10 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA10036 for freebsd-smp; Mon, 25 Nov 1996 03:43:03 -0800 (PST) Date: Mon, 25 Nov 1996 03:43:03 -0800 (PST) From: Peter Wemm Message-Id: <199611251143.DAA10036@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/25 03:42:59 Modified: i386/include pmap.h i386/i386 locore.s swtch.s Log: Implement part 1 of per-cpu private pages. This lowers th max kernel VM from 252MB to 248MB so that we can steal a PDE slot for the per-cpu page table. This is copied on cpu_switch(). Note, this is not complete yet. Presently, only one set is created for boot cpu. At present, there is a 4K page at 0xff800000, there is a 4K page mapping the default local apic address to 0xff801000, and the IO apic to 0xff802000. These are just for experimenting, don't panic. :-) Things like curproc, curpcb, runtime, cpu_id, etc will be linked to load in the private page once it's finished, eliminating the need for macros looking up arrays with NCPU elements etc. Each private page is also mapped into the global kvm space, there will be an array of pointers to them, so it'll be possible to get to cpu#6's curproc by doing doing something like: cpudata[6]->curproc. This assumes there will be a 'struct' to make dereferenced accesses to the private pages. Revision Changes Path 1.2 +86 -45 sys/i386/include/pmap.h 1.31 +64 -0 sys/i386/i386/locore.s 1.27 +25 -0 sys/i386/i386/swtch.s From owner-freebsd-smp Mon Nov 25 03:54:43 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA10338 for smp-outgoing; Mon, 25 Nov 1996 03:54:43 -0800 (PST) Received: from critter.tfs.com (disn7.cybercity.dk [194.16.57.7]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id DAA10327; Mon, 25 Nov 1996 03:54:30 -0800 (PST) Received: from critter.tfs.com (LOCALHOST [127.0.0.1]) by critter.tfs.com (8.8.2/8.8.2) with ESMTP id MAA01714; Mon, 25 Nov 1996 12:55:27 +0100 (MET) To: Peter Wemm cc: freebsd-smp@freebsd.org Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h In-reply-to: Your message of "Mon, 25 Nov 1996 03:43:03 PST." <199611251143.DAA10036@freefall.freebsd.org> Date: Mon, 25 Nov 1996 12:55:26 +0100 Message-ID: <1712.848922926@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Log: > Implement part 1 of per-cpu private pages. You'd better get dyson rolled out right away... ;-) -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-smp Mon Nov 25 04:39:00 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA12513 for smp-outgoing; Mon, 25 Nov 1996 04:39:00 -0800 (PST) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA12508 for ; Mon, 25 Nov 1996 04:38:47 -0800 (PST) Received: from spinner.DIALix.COM (peter@localhost [127.0.0.1]) by spinner.DIALix.COM (8.8.3/8.8.3) with ESMTP id UAA00709; Mon, 25 Nov 1996 20:38:16 +0800 (WST) Message-Id: <199611251238.UAA00709@spinner.DIALix.COM> To: Poul-Henning Kamp cc: freebsd-smp@freebsd.org Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h In-reply-to: Your message of "Mon, 25 Nov 1996 12:55:26 +0100." <1712.848922926@critter.tfs.com> Date: Mon, 25 Nov 1996 20:38:15 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Poul-Henning Kamp wrote: > > Log: > > Implement part 1 of per-cpu private pages. > > You'd better get dyson rolled out right away... ;-) Yeah, I've spoken to DG on and off about this, and each time we talked about it we ended up at the conclusion that it was a bit of a kludge but it was probably the most efficient way of doing it. The main difference between this and the previous implementation that we started with the first time, is that this is outside kvm space. The original code "stole" a PDE slot (entry number 59 of 63 in kernel space from memory), and kept bashing it back in over and over again. I think that what I've done here is the least ugly way way of approaching this, hopefully keeping the kludges to a minimum. And yes, there are short-term kludges present that will go away shortly, so don't shoot me just yet for what I did in swtch.s... :-) It's MUCH cleaner than it was as we got it from the original code. I hope John's not going to have too much of a heart attack.. :-] It doesn't interfere with the pmap code or the vm system in general, apart from making the maximum npkt space smaller by 4MB. I'm pretty sure I can get this to fly tonight, and will probably be able to get rid of the idle procs and smp_idleloop() in the process. I know I certainly prefer: extern struct proc *curproc; extern int cpu_id; To this: extern struct proc* SMPcurproc[ NCPU ]; extern int apicIdToLogical[]; extern volatile u_int* apic_base; static __inline unsigned cpunumber(void) { return (unsigned)(apicIdToLogical[ (apic_base[8] & 0x0f000000) >> 24 ]); } #define curproc (SMPcurproc[cpunumber()]) #define cpu_id (cpunumber()) Cheers, -Peter From owner-freebsd-smp Mon Nov 25 05:00:48 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA13309 for smp-outgoing; Mon, 25 Nov 1996 05:00:48 -0800 (PST) Received: from critter.tfs.com (disn6.cybercity.dk [194.16.57.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA13298; Mon, 25 Nov 1996 05:00:31 -0800 (PST) Received: from critter.tfs.com (LOCALHOST [127.0.0.1]) by critter.tfs.com (8.8.2/8.8.2) with ESMTP id OAA01860; Mon, 25 Nov 1996 14:01:33 +0100 (MET) To: Peter Wemm cc: freebsd-smp@freebsd.org Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h In-reply-to: Your message of "Mon, 25 Nov 1996 20:38:15 +0800." <199611251238.UAA00709@spinner.DIALix.COM> Date: Mon, 25 Nov 1996 14:01:32 +0100 Message-ID: <1858.848926892@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199611251238.UAA00709@spinner.DIALix.COM>, Peter Wemm writes: >Poul-Henning Kamp wrote: >> > Log: >> > Implement part 1 of per-cpu private pages. >> >> You'd better get dyson rolled out right away... ;-) > >Yeah, I've spoken to DG on and off about this, and each time we talked >about it we ended up at the conclusion that it was a bit of a kludge >but it was probably the most efficient way of doing it. s/the most/among the most/ I don't doubt that, I just hate the perspectives, that's all :-) >And yes, there are short-term kludges present that will go away shortly, >so don't shoot me just yet for what I did in swtch.s... :-) It's MUCH >cleaner than it was as we got it from the original code. If nothing else because locore.s was cleaned up as part of trying to understand the previous stuff :-) Yes, the initial stuff was certainly not smart about this, and avoiding disturbing the pmap as much as possible is undoubtedly a good idea. >I hope John's not going to have too much of a heart attack.. :-] It doesn't >interfere with the pmap code or the vm system in general, apart from making >the maximum npkt space smaller by 4MB. I'm pretty sure I can get this >to fly tonight, and will probably be able to get rid of the idle procs >and smp_idleloop() in the process. Yeah, well, you still have to keep separate PTD's for each CPU, and make sure to update them all, AND to tell all the cpu's about it when you do -- that's the real trouble I bet. I'm still of the opinion that sticking the logical cpu# in %gs or some other >=8bit register we abduct for the purpose, at least whenever we enter the kernel, and using that as index into arrays will be less pain, and maybe more efficient on top of that, but since I'm not SMPactive at this time I'll not stand in your way... And if it works, then hey... I'm game. The only real benefit I see to this scheme is that you can put the per-cpu idle-kernel-stack somewhere and not worry about it. As long as it fits in the 4K minus the data we stick there. My one particular grief about this is that we will still have to make it extern struct mpstruct mps; #define curproc mps.mp_curproc ... To avoid debugger people shooting us. Having accepted that we could easily make it an #ifdef if you want one model or the other: #ifdef PER_CPU_PAGE extern struct mpstruct mps; #define curproc mps.mp_curproc #else #if PHKS_SCREWBALL_GS_METHOD void __inline__ CPUNUMBER() { asm mumble "mov %eax, %gs" } #else void __inline__ CPUNUMBER() { asm mumble "get it from the apic" } #endif extern struct mpstruct mps[MAXCPU]; #define curproc mps[CPUNUMBER()].mp_curproc #endif And performance/debugging comparisons will be much simpler. (I know, there will be some uglyness in some .s code but that is a minor nuisance compared to the benefit I think. Please at least consider this detour for a moment. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-smp Mon Nov 25 05:14:01 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA14198 for smp-outgoing; Mon, 25 Nov 1996 05:14:01 -0800 (PST) Received: from dyson.iquest.net ([198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA14192 for ; Mon, 25 Nov 1996 05:13:54 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id IAA01616; Mon, 25 Nov 1996 08:12:16 -0500 (EST) From: "John S. Dyson" Message-Id: <199611251312.IAA01616@dyson.iquest.net> Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h To: peter@spinner.dialix.com (Peter Wemm) Date: Mon, 25 Nov 1996 08:12:16 -0500 (EST) Cc: phk@critter.tfs.com, freebsd-smp@freebsd.org In-Reply-To: <199611251238.UAA00709@spinner.DIALix.COM> from "Peter Wemm" at Nov 25, 96 08:38:15 pm X-Mailer: ELM [version 2.4 PL24 ME8] 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 > I hope John's not going to have too much of a heart attack.. :-] It doesn't > interfere with the pmap code or the vm system in general, apart from making > the maximum npkt space smaller by 4MB. I'm pretty sure I can get this > to fly tonight, and will probably be able to get rid of the idle procs > and smp_idleloop() in the process. > Don't worry, just feel free to ask for help (if you need it.) John From owner-freebsd-smp Mon Nov 25 05:28:05 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA14811 for smp-outgoing; Mon, 25 Nov 1996 05:28:05 -0800 (PST) Received: from databus.databus.com (databus.databus.com [198.186.154.34]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id FAA14788 for ; Mon, 25 Nov 1996 05:27:59 -0800 (PST) From: Barney Wolff To: freebsd-smp@freebsd.org Date: Mon, 25 Nov 1996 08:18 EST Subject: Re: Thread issues Content-Type: text/plain Message-ID: <32999eda0.5633@databus.databus.com> Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The only reason I can conceive of to depart from standard APIs is if they are seriously broken, and I've seen no such claim. As long as the Posix thread API is available, having it built on some more comfortable underlying proprietary API is fine - Unixware does it that way. But not to have the Posix API available would condemn fbsd-smp to irrelevancy. Win32 threads could be offered the same way, but my main desire is for Posix. Of course, a great deal of the real work comes in making thread-safe versions of the C library, where possible. Debate over APIs just adds delay - which is a good reason to go with the standard. Barney Wolff From owner-freebsd-smp Mon Nov 25 05:29:04 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA14886 for smp-outgoing; Mon, 25 Nov 1996 05:29:04 -0800 (PST) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA14865 for ; Mon, 25 Nov 1996 05:28:51 -0800 (PST) Received: from spinner.DIALix.COM (peter@localhost [127.0.0.1]) by spinner.DIALix.COM (8.8.3/8.8.3) with ESMTP id VAA01291; Mon, 25 Nov 1996 21:27:57 +0800 (WST) Message-Id: <199611251327.VAA01291@spinner.DIALix.COM> To: "John S. Dyson" cc: phk@critter.tfs.com, freebsd-smp@freebsd.org Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h In-reply-to: Your message of "Mon, 25 Nov 1996 08:12:16 EST." <199611251312.IAA01616@dyson.iquest.net> Date: Mon, 25 Nov 1996 21:27:57 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "John S. Dyson" wrote: > > I hope John's not going to have too much of a heart attack.. :-] It doesn' t > > interfere with the pmap code or the vm system in general, apart from making > > the maximum npkt space smaller by 4MB. I'm pretty sure I can get this > > to fly tonight, and will probably be able to get rid of the idle procs > > and smp_idleloop() in the process. > > > Don't worry, just feel free to ask for help (if you need it.) Don't worry.. I will certainly yell "Help!!!" when I need it. :-) OBTW, easy question. Is it safe to do a: movl %cr3, %eax movl %eax, %cr3 .. from a non-spl-maskable interrupt handler? I'm thinking in terms of a lightning quick interprocessor interrupt to force all cpu's to do an invltlb(). So far as I can see from a quick scan of the code, the only real loads of %cr3 are during cpu_switch(), initialisation, and tlb flushes. cpu_switch() does it from inside cli/sti so it's safe, init code is irrelevant at this point, and I think the tlb flush is implicitly reentrant since it's not changing the register. Have I missed something? > John Cheers, -Peter From owner-freebsd-smp Mon Nov 25 05:39:01 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA15889 for smp-outgoing; Mon, 25 Nov 1996 05:39:01 -0800 (PST) Received: from dyson.iquest.net ([198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA15872 for ; Mon, 25 Nov 1996 05:38:53 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id IAA01700; Mon, 25 Nov 1996 08:38:07 -0500 (EST) From: "John S. Dyson" Message-Id: <199611251338.IAA01700@dyson.iquest.net> Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h To: peter@spinner.dialix.com (Peter Wemm) Date: Mon, 25 Nov 1996 08:38:07 -0500 (EST) Cc: toor@dyson.iquest.net, phk@critter.tfs.com, freebsd-smp@freebsd.org In-Reply-To: <199611251327.VAA01291@spinner.DIALix.COM> from "Peter Wemm" at Nov 25, 96 09:27:57 pm X-Mailer: ELM [version 2.4 PL24 ME8] 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 > > "John S. Dyson" wrote: > > > I hope John's not going to have too much of a heart attack.. :-] It doesn' > t > > > interfere with the pmap code or the vm system in general, apart from making > > > the maximum npkt space smaller by 4MB. I'm pretty sure I can get this > > > to fly tonight, and will probably be able to get rid of the idle procs > > > and smp_idleloop() in the process. > > > > > Don't worry, just feel free to ask for help (if you need it.) > > Don't worry.. I will certainly yell "Help!!!" when I need it. :-) > > OBTW, easy question. Is it safe to do a: > movl %cr3, %eax > movl %eax, %cr3 > .. from a non-spl-maskable interrupt handler? > I think that it is safe to do at anytime. The processor will refill the tlb's as needed. That is *exactly* what I would have suggested for what you are doing. BTW, remember to save %eax :-). It just so happens that pdirs never move once created. Could you possibly do a pushfl;cli;invltlb;popfl though? That will keep interrupts away, and also will make pdirs movable eventually. (just kind of curious more than anything why/if cli/sti won't work in the context that you are describing.) > > Have I missed something? > I don't think so, esp since as I said that current pdirs don't move anyway. John From owner-freebsd-smp Mon Nov 25 06:30:59 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA20514 for smp-outgoing; Mon, 25 Nov 1996 06:30:59 -0800 (PST) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA20494 for ; Mon, 25 Nov 1996 06:30:44 -0800 (PST) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.3/8.8.3) with ESMTP id WAA01541; Mon, 25 Nov 1996 22:29:55 +0800 (WST) Message-Id: <199611251429.WAA01541@spinner.DIALix.COM> To: Barney Wolff cc: freebsd-smp@freebsd.org Subject: Re: Thread issues In-reply-to: Your message of "Mon, 25 Nov 1996 08:18:00 EST." <32999eda0.5633@databus.databus.com> Date: Mon, 25 Nov 1996 22:29:55 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Barney Wolff wrote: > The only reason I can conceive of to depart from standard APIs is if > they are seriously broken, and I've seen no such claim. As long as > the Posix thread API is available, having it built on some more > comfortable underlying proprietary API is fine - Unixware does it > that way. But not to have the Posix API available would condemn > fbsd-smp to irrelevancy. FreeBSD already has posix threads, BTW. The challenge is to produce a simple "back end" API for the thread library to work on multiple cpus at once. I think it would be a mistake to move the posix thread API into the kernel... > Of course, a great deal of the real work comes in making thread-safe > versions of the C library, where possible. Debate over APIs just > adds delay - which is a good reason to go with the standard. We already have a thread-safe C library.. (see libc_r) What we are missing: 1: the ability to do blocking IO within threads. I wrote 95% of the code to support this, but never got around to finishing it due to some sticky efficiency problems with context switching in the kernel. 2: the ability to have one program's threads execute on multiple cpus at once. This becomes "easy" once #1 is done. 3: a synchronisation back end. We may not need kernel support for this if we use kernel-style locked bus cycle mutex operations in user mode. I was working on part 1 for the non-smp kernel, since it was applicable to both the normal and the smp kernel. I have learned enough over the last few months to finish this now. Part 2 is merely an extension of part 1. Cheers, -Peter From owner-freebsd-smp Mon Nov 25 06:42:52 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA21503 for smp-outgoing; Mon, 25 Nov 1996 06:42:52 -0800 (PST) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA21488 for ; Mon, 25 Nov 1996 06:42:34 -0800 (PST) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.3/8.8.3) with ESMTP id WAA01604; Mon, 25 Nov 1996 22:42:02 +0800 (WST) Message-Id: <199611251442.WAA01604@spinner.DIALix.COM> To: "John S. Dyson" cc: phk@critter.tfs.com, freebsd-smp@freebsd.org Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h In-reply-to: Your message of "Mon, 25 Nov 1996 08:38:07 EST." <199611251338.IAA01700@dyson.iquest.net> Date: Mon, 25 Nov 1996 22:42:02 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "John S. Dyson" wrote: > > OBTW, easy question. Is it safe to do a: > > movl %cr3, %eax > > movl %eax, %cr3 > > .. from a non-spl-maskable interrupt handler? > > > I think that it is safe to do at anytime. The processor will > refill the tlb's as needed. That is *exactly* what I would have > suggested for what you are doing. BTW, remember to save %eax :-). Naturally.. Since this is from interrupt context, we don't have a lot of choice about what we have to save... The hardware saves some guff for us, the rest we must do.. > It just so happens that pdirs never move once created. Could > you possibly do a pushfl;cli;invltlb;popfl though? That will > keep interrupts away, and also will make pdirs movable eventually. > (just kind of curious more than anything why/if cli/sti won't work > in the context that you are describing.) Umm, yes, that sounds fine. No, cli/sti etc isn't a problem. I was planning on gutting the FAST_INTR() macro to produce a specific purpose, lightweight, routine for this specific case. What I meant by "non-spl-maskable" is that splhigh() will not block it, and it will be allowed into the outer part of the kernel even if something else has the mplock.. The entire routine will probably be: save registers cli invltlb lock inc counter hit EOI in APIC restore registers reti > John Cheers, -Peter From owner-freebsd-smp Mon Nov 25 06:42:59 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA21514 for smp-outgoing; Mon, 25 Nov 1996 06:42:59 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA21506 for ; Mon, 25 Nov 1996 06:42:51 -0800 (PST) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id GAA10294 for ; Mon, 25 Nov 1996 06:42:42 -0800 (PST) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.3/8.8.3) with ESMTP id WAA01613; Mon, 25 Nov 1996 22:42:35 +0800 (WST) Message-Id: <199611251442.WAA01613@spinner.DIALix.COM> To: Poul-Henning Kamp cc: freebsd-smp@freebsd.org Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h In-reply-to: Your message of "Mon, 25 Nov 1996 14:01:32 +0100." <1858.848926892@critter.tfs.com> Date: Mon, 25 Nov 1996 22:42:35 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Poul-Henning Kamp wrote: > I don't doubt that, I just hate the perspectives, that's all :-) :-) Actually, it doesn't seem to be turning out to look so bad after all.. > Yes, the initial stuff was certainly not smart about this, and avoiding > disturbing the pmap as much as possible is undoubtedly a good idea. You got that right about the "hands off!" nature of the pmap stuff.. :-) John supposedly understands it, and it still bites him regularly. > Yeah, well, you still have to keep separate PTD's for each CPU, and > make sure to update them all, AND to tell all the cpu's about it when > you do -- that's the real trouble I bet. Not necessarily.. What I've done so far is have a per-cpu page table page, not a top-level page directory. Currently pmap_growkernel() already walks all processes in the proc list and modifies their PTD's. This gets more complicated once we have real idle procs, but that's a feature of eliminating them, it's not a side effect of having per-cpu pages. Anyway, I'm not afraid of blood... I could live with the prospect of setting a "pause" flag, sending an IPI to cause all cpu's to drop everything and wait, update all the PTD's, then let them go again. After all, pmap_growkernel only happens a maximum of 54 times during the lifetime of the kernel on a standard system, and most of them it seems are during the first 30 seconds or so as it boots up. > I'm still of the opinion that sticking the logical cpu# in %gs or > some other >=8bit register we abduct for the purpose, at least whenever > we enter the kernel, and using that as index into arrays will be less > pain, and maybe more efficient on top of that, but since I'm not SMPactive > at this time I'll not stand in your way... > And if it works, then hey... I'm game. .. until we fix and use %fs and %gs.. :-) > The only real benefit I see to this scheme is that you can put the > per-cpu idle-kernel-stack somewhere and not worry about it. As long > as it fits in the 4K minus the data we stick there. Actually, I had a more evil plan in mind to start with. I was thinking of using fork() to create the process contexts, teach schedule() how not to assign them to run queues, and double-map their pages into the private pages to hold the contexts for the idle. It sure beats initialising the stack, pcb etc. But on the other hand, we know how many cpu's are online when doing pmap_bootstrap(), so we could just as easily allocate the space then. > My one particular grief about this is that we will still have to make it > > extern struct mpstruct mps; > > #define curproc mps.mp_curproc > ... > > To avoid debugger people shooting us. Again, not necessaily.. I have already thought about this. We *definately* need to be able to read the variables in ddb, and not having a variable "_curproc" etc is a real pain, to say the least. I think it's more useable to have both.. The individual variables put at fixed virtual locations that correspond with the C structure packing. Since we have 4MB of space to play with, I had thought of mapping all the private pages into the each cpu's private space at the same address. So, a map could look like this: page 0: this cpu's private data page 1: this cpu's PT page 2: this cpu's idle pcb - these two pages are the "UPAGES" as page 3: this cpu's idle "stack" - such for the idle processes .. etc page 64: cpu 0's private page page 65: cpu 1's private page ... page 80: cpu 0's private PT page 81: cpu 1's private PT .. page 96: cpu 0's "idle" stack .. etc.. page 512: entire local apic "space" from 0xfee00000->0xfeefffff page 768: entire IO apic "space" from 0xfec00000->0xfecfffff page 1023: "end" of per cpu space. Yes, this is overkill, but it's for free. the mappings consume no memory since this way would need a minimum of 12 bytes out of the 4KB page. We can point the spares to something useful and access it there rather than consume more precious kernel VM. This stuff is static after initial boot, with the exception of the idle PTD's. But then again, the result would look a damn lot like a hall of mirrors.. > And performance/debugging comparisons will be much simpler. (I know, > there will be some uglyness in some .s code but that is a minor > nuisance compared to the benefit I think. > > Please at least consider this detour for a moment. Yes... I've not burned down any bridges yet. What I'm trying to do at the moment is create a convenient place to store this stuff. Then we can compare the results. Going this way eliminates (for each reference to curproc): - a 32 bit IO operation to the local apic (which Eric said should be minimised if possible since IO is slow) - a 32 bit 'and' operation - a 24/32 bit barrel roll - a multiplied by 4 index, 32 bit table lookup and dereference - another 32 bit table lookup and dereference .. and replaces it with a cacheable ram memory fetch. The same goes for curpcb, runtime, possibly 32 run queues, inter-cpu message passing scratch space, and other stuff that will turn up. Hmm, why am I sleepy? Cheers, -Peter From owner-freebsd-smp Mon Nov 25 06:47:32 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA21877 for smp-outgoing; Mon, 25 Nov 1996 06:47:32 -0800 (PST) Received: from dyson.iquest.net ([198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id GAA21852 for ; Mon, 25 Nov 1996 06:47:16 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id JAA01865; Mon, 25 Nov 1996 09:46:36 -0500 (EST) From: John Dyson Message-Id: <199611251446.JAA01865@dyson.iquest.net> Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h To: peter@spinner.dialix.com (Peter Wemm) Date: Mon, 25 Nov 1996 09:46:36 -0500 (EST) Cc: phk@critter.tfs.com, freebsd-smp@freebsd.org In-Reply-To: <199611251442.WAA01604@spinner.DIALix.COM> from "Peter Wemm" at Nov 25, 96 10:42:02 pm Reply-To: dyson@freebsd.org X-Mailer: ELM [version 2.4 PL24 ME8] 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 > > Naturally.. Since this is from interrupt context, we don't have a lot of > choice about what we have to save... The hardware saves some guff for > us, the rest we must do.. > > > It just so happens that pdirs never move once created. Could > > you possibly do a pushfl;cli;invltlb;popfl though? That will > > keep interrupts away, and also will make pdirs movable eventually. > > (just kind of curious more than anything why/if cli/sti won't work > > in the context that you are describing.) > In the lowest level interrupt context, doesn't the machine turn interrupts off anyway? If you can bypass some of the default processing, the code can be mega simple. > > cli > invltlb > lock inc counter > hit EOI in APIC > restore registers > reti > John From owner-freebsd-smp Mon Nov 25 06:54:46 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA22527 for smp-outgoing; Mon, 25 Nov 1996 06:54:46 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA22502 for freebsd-smp; Mon, 25 Nov 1996 06:54:39 -0800 (PST) Date: Mon, 25 Nov 1996 06:54:39 -0800 (PST) From: Peter Wemm Message-Id: <199611251454.GAA22502@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/i386 autoconf.c microtime.s sys/i386/isa clock.c icu.s isa.c vector.s sys/kern init_main.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/25 06:54:25 Modified: i386/i386 autoconf.c microtime.s i386/isa clock.c icu.s isa.c vector.s kern init_main.c Log: Fix $Id$ spam. (the rcs -ko flag is your friend) Revision Changes Path 1.10 +1 -1 sys/i386/i386/autoconf.c 1.16 +1 -1 sys/i386/i386/microtime.s 1.12 +1 -1 sys/i386/isa/clock.c 1.19 +1 -1 sys/i386/isa/icu.s 1.10 +1 -1 sys/i386/isa/isa.c 1.27 +1 -1 sys/i386/isa/vector.s 1.33 +1 -1 sys/kern/init_main.c From owner-freebsd-smp Mon Nov 25 08:46:38 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA11865 for smp-outgoing; Mon, 25 Nov 1996 08:46:38 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA11785 for ; Mon, 25 Nov 1996 08:46:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id JAA01693; Mon, 25 Nov 1996 09:45:51 -0700 Message-Id: <199611251645.JAA01693@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Peter Wemm cc: Poul-Henning Kamp , freebsd-smp@freebsd.org Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h In-reply-to: Your message of "Mon, 25 Nov 1996 22:42:35 +0800." <199611251442.WAA01613@spinner.DIALix.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 25 Nov 1996 09:45:51 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > Going this way eliminates (for each reference to curproc): > - a 32 bit IO operation to the local apic (which Eric said should be > minimised if possible since IO is slow) > - a 32 bit 'and' operation > - a 24/32 bit barrel roll > - a multiplied by 4 index, 32 bit table lookup and dereference > - another 32 bit table lookup and dereference I thought of a shortcut for this awhile back but never tried it. Any code that is running inside the kernel and currently has the lock could skip this and determine which cpu it is with: #define LOCKED_CPUNUM() ((mp_lock & 0x0f000000) >> 24) you still have the shift, but the APIC access is eliminated. Send mail when something is ready to try, looks good so far, and I really want to get all 4 of Erich's CPUs running. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Mon Nov 25 09:07:56 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA16852 for smp-outgoing; Mon, 25 Nov 1996 09:07:56 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA16836 for ; Mon, 25 Nov 1996 09:07:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id KAA01825; Mon, 25 Nov 1996 10:05:58 -0700 Message-Id: <199611251705.KAA01825@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Peter Wemm cc: Poul-Henning Kamp , freebsd-smp@freebsd.org Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h In-reply-to: Your message of "Mon, 25 Nov 1996 09:45:51 MST." <199611251645.JAA01693@clem.systemsix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 25 Nov 1996 10:05:58 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > > Going this way eliminates (for each reference to curproc): > ... > I thought of a shortcut for this awhile back but never tried it. Any code that > is running inside the kernel and currently has the lock could skip this and > determine which cpu it is with: > > #define LOCKED_CPUNUM() ((mp_lock & 0x0f000000) >> 24) > > you still have the shift, but the APIC access is eliminated. gotto have my first cup of coffee b4 trying to think. This is not quite right, still need the phyToLog indirection, the mplock uses physical CPU#. But it does eliminate the APIC access, the most expensive part of the current call. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Mon Nov 25 10:52:06 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA29967 for smp-outgoing; Mon, 25 Nov 1996 10:52:06 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA29942 for ; Mon, 25 Nov 1996 10:51:51 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA22875; Mon, 25 Nov 1996 11:35:13 -0700 From: Terry Lambert Message-Id: <199611251835.LAA22875@phaeton.artisoft.com> Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h To: peter@spinner.dialix.com (Peter Wemm) Date: Mon, 25 Nov 1996 11:35:12 -0700 (MST) Cc: toor@dyson.iquest.net, phk@critter.tfs.com, freebsd-smp@freebsd.org In-Reply-To: <199611251327.VAA01291@spinner.DIALix.COM> from "Peter Wemm" at Nov 25, 96 09:27:57 pm 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 > OBTW, easy question. Is it safe to do a: > movl %cr3, %eax > movl %eax, %cr3 > .. from a non-spl-maskable interrupt handler? > > I'm thinking in terms of a lightning quick interprocessor interrupt to > force all cpu's to do an invltlb(). > > So far as I can see from a quick scan of the code, the only real loads of > %cr3 are during cpu_switch(), initialisation, and tlb flushes. cpu_switch() > does it from inside cli/sti so it's safe, init code is irrelevant at this > point, and I think the tlb flush is implicitly reentrant since it's > not changing the register. > > Have I missed something? Why do you need to force all CPU's to do an invltlb()? Is this to handle bus master DMA target memory? Or is this for IPC? IMO, the first can be handled by declaring the targets non-cacheable, and dealing with the "transfer complete" on the CPU that initiated the I/O. For IPC, there should be a scratch area which is marked non-cacheable in the first place and mapped into all CPU's address spaces. For the interrupt handlers themselves, the events should be queued, but not handled except in upper level code. The interrupts need to be virtualized (I know, I know, this gets back into the discussion about "changing the way non-SMP FreeBSD handles interrupts" that we didn't want to have). 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 Mon Nov 25 11:02:44 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA00949 for smp-outgoing; Mon, 25 Nov 1996 11:02:44 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA00922 for ; Mon, 25 Nov 1996 11:02:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id KAA06981; Mon, 25 Nov 1996 10:58:00 -0800 (PST) Message-Id: <199611251858.KAA06981@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: peter@spinner.dialix.com (Peter Wemm), toor@dyson.iquest.net, phk@critter.tfs.com, freebsd-smp@freebsd.org Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h In-reply-to: Your message of "Mon, 25 Nov 1996 11:35:12 MST." <199611251835.LAA22875@phaeton.artisoft.com> From: David Greenman Reply-To: dg@Root.COM Date: Mon, 25 Nov 1996 10:58:00 -0800 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> OBTW, easy question. Is it safe to do a: >> movl %cr3, %eax >> movl %eax, %cr3 >> .. from a non-spl-maskable interrupt handler? >> >> I'm thinking in terms of a lightning quick interprocessor interrupt to >> force all cpu's to do an invltlb(). >> >> So far as I can see from a quick scan of the code, the only real loads of >> %cr3 are during cpu_switch(), initialisation, and tlb flushes. cpu_switch() >> does it from inside cli/sti so it's safe, init code is irrelevant at this >> point, and I think the tlb flush is implicitly reentrant since it's >> not changing the register. >> >> Have I missed something? > >Why do you need to force all CPU's to do an invltlb()? > >Is this to handle bus master DMA target memory? > >Or is this for IPC? None of the above. It's needed to update/invalidate mappings during paging. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-smp Mon Nov 25 11:09:42 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA01569 for smp-outgoing; Mon, 25 Nov 1996 11:09:42 -0800 (PST) Received: from dyson.iquest.net ([198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA01552 for ; Mon, 25 Nov 1996 11:09:29 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id OAA02289; Mon, 25 Nov 1996 14:07:49 -0500 (EST) From: John Dyson Message-Id: <199611251907.OAA02289@dyson.iquest.net> Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h To: terry@lambert.org (Terry Lambert) Date: Mon, 25 Nov 1996 14:07:49 -0500 (EST) Cc: peter@spinner.dialix.com, phk@critter.tfs.com, freebsd-smp@freebsd.org In-Reply-To: <199611251835.LAA22875@phaeton.artisoft.com> from "Terry Lambert" at Nov 25, 96 11:35:12 am Reply-To: dyson@freebsd.org X-Mailer: ELM [version 2.4 PL24 ME8] 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 > > Why do you need to force all CPU's to do an invltlb()? > One common case is for when a page is freed, that the other processors will need to invalidate the mappings for it. The VM system is not perfect in that it will free pages that are about to be used (once in a long while.) The current SMP system sort-of works without the global invtlb, but when it starts paging -- it probably starts sig-11'ing (my guess.) . So, the invtlb is used to synchronize the TLB on all of the processors with reality. For now, page-by-page invalidates are too complex. Specifically, the invlpg operation works on a VA basis not a PA basis. We would have to go through contortions to find out the VA's that the page is mapped to on the other processor -- for very little gain... Invlpg is only applicable to certain circumstances anyway. Your question implies confusion with winvlb (cache flush) or somesuch? John From owner-freebsd-smp Mon Nov 25 13:03:01 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA09199 for smp-outgoing; Mon, 25 Nov 1996 13:03:01 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA09161 for ; Mon, 25 Nov 1996 13:02:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id OAA02950; Mon, 25 Nov 1996 14:01:23 -0700 Message-Id: <199611252101.OAA02950@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Peter Wemm Cc: Nate Williams , Janick.Taillandier@ratp.fr cc: freebsd-smp@FreeBSD.org Subject: Re: Console lockup Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 25 Nov 1996 14:01:23 -0700 Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi, so naturally it gets wierder.... I just cvsupped the 1st cut of the per CPU stuff, built/installed/booted an APIC_IO version. Works fine: FreeBSD 3.0-SMP #0: Mon Nov 25 11:00:43 MST 1996 fsmp@rick.systemsix.com:/d1usr/src/sys/compile/SMP FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00030010 cpu1 (AP): apic id: 1, version: 0x00030010 io0 (APIC): apic id: 2, version: 0x00170011 ... =========> SECOND CPU LAUNCHED!! <========= I forgot to replace console.h/syscons.c, ie I used the ones that used to cause my console to ALWAYS hang: * $Id: console.h,v 1.26 1996/11/14 22:18:31 sos Exp $ * $Id: syscons.c,v 1.189 1996/11/19 17:08:10 nate Exp $ BUT IT AIN'T HANGING ANYMORE!!! I can't think of anything thats changed that should affect it.... I've rebooted several times, no problems. Is there anything new in the "1st cut code" that could possibly be responsible??? -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Mon Nov 25 14:11:21 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA13615 for smp-outgoing; Mon, 25 Nov 1996 14:11:21 -0800 (PST) Received: from kvikk.uit.no (kvikk.Uit.No [129.242.4.32]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA13610 for ; Mon, 25 Nov 1996 14:11:14 -0800 (PST) Received: from sprint.cc.uit.no (sprint.Cc.Uit.No [129.242.5.198]) by kvikk.uit.no (8.7.3/8.7.1) with ESMTP id XAA06221; Mon, 25 Nov 1996 23:11:04 +0100 (MET) Received: from slibo.cc.uit.no (slibo.Cc.Uit.No [129.242.5.36]) by sprint.cc.uit.no (8.8.0/8.8.0) with ESMTP id XAA26653; Mon, 25 Nov 1996 23:11:03 +0100 (MET) Received: from localhost (terjem@localhost) by slibo.cc.uit.no (8.7.3/8.7.3) with ESMTP id XAA18228; Mon, 25 Nov 1996 23:11:02 +0100 (MET) Message-Id: <199611252211.XAA18228@slibo.cc.uit.no> X-Mailer: exmh version 1.6.9 8/22/96 To: Steve Passe cc: freebsd-smp@freebsd.org Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h In-reply-to: Your message of "Mon, 25 Nov 1996 09:45:51 MET." <199611251645.JAA01693@clem.systemsix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Mon, 25 Nov 1996 23:11:02 +0100 From: Terje Normann Marthinussen Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Send mail when something is ready to try, looks good so far, and I really >want to get all 4 of Erich's CPUs running. Got a 4 CPU HP NetServer 5/133 LS4 here as well, "just waiting" for the day when FreeBSD gets support for more than 2 CPU's. Got it up with the SMP kernel some months ago (did take som minor changes to find the SCSI controllers, and I should have sent in some patches for that, but I haven't gotten so far yet), but it locked up when enabling the second cpu. Haven't had time to do more work on it so far :-/. Terje Marthinussen terjem@cc.uit.no From owner-freebsd-smp Mon Nov 25 14:22:33 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA14501 for smp-outgoing; Mon, 25 Nov 1996 14:22:33 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA14343 for ; Mon, 25 Nov 1996 14:20:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id PAA03430; Mon, 25 Nov 1996 15:20:02 -0700 Message-Id: <199611252220.PAA03430@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Terje Normann Marthinussen cc: freebsd-smp@freebsd.org Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h In-reply-to: Your message of "Mon, 25 Nov 1996 23:11:02 +0100." <199611252211.XAA18228@slibo.cc.uit.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 25 Nov 1996 15:20:02 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > Got a 4 CPU HP NetServer 5/133 LS4 here as well, "just waiting" for the day > when FreeBSD gets support for more than 2 CPU's. > > Got it up with the SMP kernel some months ago (did take som minor changes > to find the SCSI controllers, and I should have sent in some patches for > that, but I haven't gotten so far yet), but it locked up when enabling > the second cpu. Haven't had time to do more work on it so far :-/. so run mptable on it "mptable -verbose -dmesg" and return the results. This is the first step towards getting any machine working. If the development team doesn't know "what it looks like", we can't do much to help! I especially need to see mptable output from 4CPU machines right now as that is one of the things at the top of my todo list. There's a good chance the current SMP will work now (2 CPUs), alot of bugs have been squashed in the last 2 months. -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Mon Nov 25 16:39:26 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA23069 for smp-outgoing; Mon, 25 Nov 1996 16:39:26 -0800 (PST) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA23044 for ; Mon, 25 Nov 1996 16:38:43 -0800 (PST) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.3/8.8.3) with ESMTP id IAA02227; Tue, 26 Nov 1996 08:35:43 +0800 (WST) Message-Id: <199611260035.IAA02227@spinner.DIALix.COM> To: Steve Passe cc: Poul-Henning Kamp , freebsd-smp@freebsd.org Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h In-reply-to: Your message of "Mon, 25 Nov 1996 10:05:58 MST." <199611251705.KAA01825@clem.systemsix.com> Date: Tue, 26 Nov 1996 08:35:42 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve Passe wrote: > Hi, > > > > Going this way eliminates (for each reference to curproc): > > ... > > I thought of a shortcut for this awhile back but never tried it. Any code that > > is running inside the kernel and currently has the lock could skip this and > > determine which cpu it is with: > > > > #define LOCKED_CPUNUM() ((mp_lock & 0x0f000000) >> 24) > > > > you still have the shift, but the APIC access is eliminated. > gotto have my first cup of coffee b4 trying to think. This is not quite righ t, > still need the phyToLog indirection, the mplock uses physical CPU#. But it > does eliminate the APIC access, the most expensive part of the current call. Yes, I know the feeling. :-) I'm having a very slow start this morning too. Just as well Netscape sent me a double-sized coffee mug.. :-) BTW, I would like to change the mplocking to use the logical cpu numbering, since that's the only place left where it takes the physical number. Going via a private page mechanism means we can do this easily since we can supply a pre-shifted, masked and translated 32 bit int with the logical cpu number in 0x0N000000. > -- > Steve Passe | powered by > smp@csn.net | FreeBSD > Cheers, -Peter From owner-freebsd-smp Mon Nov 25 17:53:22 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA26970 for smp-outgoing; Mon, 25 Nov 1996 17:53:22 -0800 (PST) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA26958 for ; Mon, 25 Nov 1996 17:53:09 -0800 (PST) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.3/8.8.3) with ESMTP id JAA02951; Tue, 26 Nov 1996 09:48:51 +0800 (WST) Message-Id: <199611260148.JAA02951@spinner.DIALix.COM> To: Steve Passe cc: Nate Williams , Janick.Taillandier@ratp.fr, freebsd-smp@FreeBSD.org Subject: Re: Console lockup In-reply-to: Your message of "Mon, 25 Nov 1996 14:01:23 MST." <199611252101.OAA02950@clem.systemsix.com> Date: Tue, 26 Nov 1996 09:48:51 +0800 From: Peter Wemm Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Steve Passe wrote: > Hi, > > so naturally it gets wierder.... > > I just cvsupped the 1st cut of the per CPU stuff, built/installed/booted > an APIC_IO version. Works fine: > > FreeBSD 3.0-SMP #0: Mon Nov 25 11:00:43 MST 1996 > fsmp@rick.systemsix.com:/d1usr/src/sys/compile/SMP > FreeBSD/SMP: Multiprocessor motherboard > cpu0 (BSP): apic id: 0, version: 0x00030010 > cpu1 (AP): apic id: 1, version: 0x00030010 > io0 (APIC): apic id: 2, version: 0x00170011 > ... > =========> SECOND CPU LAUNCHED!! <========= > > I forgot to replace console.h/syscons.c, ie I used the ones that used to > cause my console to ALWAYS hang: > > * $Id: console.h,v 1.26 1996/11/14 22:18:31 sos Exp $ > * $Id: syscons.c,v 1.189 1996/11/19 17:08:10 nate Exp $ > > BUT IT AIN'T HANGING ANYMORE!!! I can't think of anything thats changed > that should affect it.... I've rebooted several times, no problems. Is > there anything new in the "1st cut code" that could possibly be responsible?? ? I'm suspicious that we might have some uninitialised data pages somewhere. All of a sudden, I now am having reboot problems again once I've booted into smp. (ie: if I do a reboot or halt, I mist physically hit reset before the kernel will come up into multi-user). I had this problem months earlier this year. The code that I committed should not have changed your syscons behavior BTW, apart from changing code alignment and memory allocation by a few pages. Oh, the other thing that was changed was the "press RESET or RETURN" after printing the IOApicMask vs. imen values was removed. Try putting it back in autoconf.c and see if your problem returns? Cheers, -Peter From owner-freebsd-smp Mon Nov 25 19:14:37 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA01894 for smp-outgoing; Mon, 25 Nov 1996 19:14:37 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA01883 for freebsd-smp; Mon, 25 Nov 1996 19:14:29 -0800 (PST) Date: Mon, 25 Nov 1996 19:14:29 -0800 (PST) From: Peter Wemm Message-Id: <199611260314.TAA01883@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys smp.todo Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/25 19:14:22 Modified: . smp.todo Log: update this a bit so that it's more useful Revision Changes Path 1.3 +40 -15 sys/smp.todo From owner-freebsd-smp Tue Nov 26 09:08:04 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA13581 for smp-outgoing; Tue, 26 Nov 1996 09:08:04 -0800 (PST) Received: from merlin.sedona.net (hogan@merlin.sedona.net [204.157.202.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA13573 for ; Tue, 26 Nov 1996 09:07:53 -0800 (PST) Received: (from hogan@localhost) by merlin.sedona.net (8.8.2/8.8.HW) id KAA03417 for freebsd-smp@freebsd.org; Tue, 26 Nov 1996 10:03:29 -0700 (MST) From: Hogan Whittall Message-Id: <199611261703.KAA03417@merlin.sedona.net> Subject: Problems using 'checkout' on smp files To: freebsd-smp@freebsd.org Date: Tue, 26 Nov 1996 10:03:29 -0700 (MST) 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 Hola. I used cvsup to get the SMP files from cvsup.freebsd.org, but when I go to checkout the files, it'll get partway done and then recursively checkout the files (I end up with /home/smp/sys/sys/sys/sys/...) Also, how does one configure the smp kernel for smp? I looked in the GENERIC config file for an option but didn't see any. Normal kernels I can do...this is just stumping me. Any help on the steps I need to take would be greatly appreciated. :) Thanx... -- _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ | Hogan Whittall Systems & Networking Technician | | hogan@sedona.net Sedona Internet Services, Inc. | | http://cloofone.sedona.net/ Ph: (520) 204-2247 Pg: 282-8030 | |-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-| From owner-freebsd-smp Tue Nov 26 14:52:41 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA05308 for smp-outgoing; Tue, 26 Nov 1996 14:52:41 -0800 (PST) Received: (from fsmp@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA05300 for freebsd-smp; Tue, 26 Nov 1996 14:52:38 -0800 (PST) Date: Tue, 26 Nov 1996 14:52:38 -0800 (PST) From: Steve Passe Message-Id: <199611262252.OAA05300@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/include apic.h ipl.h smptests.h spl.h sys/i386/isa icu.h isa.c isa_device.h vector.s Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk fsmp 96/11/26 14:52:38 Modified: i386/include apic.h ipl.h smptests.h spl.h Log: control of new IPI_INTR() entry points. #define IPI_INTS in i386/include/apic.h to enable (the default). #define TEST_IPI in i386/include/smptests.h for test code (default for now). removed TEST_DISABLEFOCUS define from smptests.h Revision Changes Path 1.15 +9 -1 sys/i386/include/apic.h 1.6 +9 -3 sys/i386/include/ipl.h 1.5 +5 -7 sys/i386/include/smptests.h 1.5 +7 -1 sys/i386/include/spl.h Modified: i386/isa icu.h isa.c isa_device.h vector.s Log: new IPI_INTR() entry points. #define IPI_INTS in i386/include/apic.h to enable (the default). #define TEST_IPI in i386/include/smptests.h for test code (default for now). This code gives us 4 InterProcessor Interrupts in the IDT table. Generically named Xipi2[4567], they link to skeleton functions mp_machdep.c:ipiIntr[0123](). These will be used to send messages between CPUs. Eventually some will be tweaked to do everything in asm inside XipiN, while others will be expanded via the skeleton functions. Support functions in mpapic.c include: send an IPI INTerrupt containing 'vector' to CPUs in 'targetMap': selectedProcsIPI( int targetMap, int vector ) send an IPI INTerrupt containing 'vector' to all CPUs, including myself: allProcsIPI( int vector ) send an IPI INTerrupt containing 'vector' to all CPUs EXCEPT myself: allButSelfIPI( int vector ) send an IPI INTerrupt containing 'vector' to myself: selfIPI( int vector ) Revision Changes Path 1.8 +13 -1 sys/i386/isa/icu.h 1.11 +7 -0 sys/i386/isa/isa.c 1.6 +10 -7 sys/i386/isa/isa_device.h 1.28 +55 -3 sys/i386/isa/vector.s From owner-freebsd-smp Tue Nov 26 18:18:36 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA17477 for smp-outgoing; Tue, 26 Nov 1996 18:18:36 -0800 (PST) Received: from kvikk.uit.no (kvikk.Uit.No [129.242.4.32]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA17472 for ; Tue, 26 Nov 1996 18:18:31 -0800 (PST) Received: from sprint.cc.uit.no (sprint.Cc.Uit.No [129.242.5.198]) by kvikk.uit.no (8.7.3/8.7.1) with ESMTP id DAA02429; Wed, 27 Nov 1996 03:18:20 +0100 (MET) Received: from slibo.cc.uit.no (slibo.Cc.Uit.No [129.242.5.36]) by sprint.cc.uit.no (8.8.0/8.8.0) with ESMTP id DAA08885; Wed, 27 Nov 1996 03:18:19 +0100 (MET) Received: from localhost (terjem@localhost) by slibo.cc.uit.no (8.7.3/8.7.3) with ESMTP id DAA06207; Wed, 27 Nov 1996 03:18:14 +0100 (MET) Message-Id: <199611270218.DAA06207@slibo.cc.uit.no> To: Steve Passe cc: Terje Normann Marthinussen , freebsd-smp@freebsd.org Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h In-reply-to: Your message of "Mon, 25 Nov 1996 15:20:02 MET." <199611252220.PAA03430@clem.systemsix.com> Date: Wed, 27 Nov 1996 03:18:14 +0100 From: Terje Normann Marthinussen Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >so run mptable on it "mptable -verbose -dmesg" and return the results. This >is the first step towards getting any machine working. If the development >team doesn't know "what it looks like", we can't do much to help! >I especially need to see mptable output from 4CPU machines right now >as that is one of the things at the top of my todo list. Here it is. NCPU=4 is not the reason why I didn't get it to work with 2 CPUS, I've tried NCPU=2 as well, I just had to tried 4 and never cared to recompile again. The system has 128MB of memory as well, just didn't get it into the kernel configuration. It's an HP netserver 5/133 LS4. It has: 4 133MHZ pentium CPUs 5 PCI slots on 2 PCI buses, 1 slot on bus 0 is occupied by the second CPU card. 6 EISA slots 2 onboard Adaptec SCSI controllers I believe MPTable isn't to much wrong when it says "Intel XXPRESS" :) =============================================================================== MPTable, version 2.0.4 looking for EBDA pointer @ 0x040e, found, searching EBDA @ 0x0009e400 searching CMOS 'top of mem' @ 0x0009e000 (632K) searching default 'top of mem' @ 0x0009fc00 (639K) searching BIOS @ 0x000f0000 MP FPS found in BIOS @ physical addr: 0x000f73a0 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000f73a0 signature: '_MP_' length: 16 bytes version: 1.1 checksum: 0x71 mode: Virtual Wire ------------------------------------------------------------------------------- MP Config Table Header: physical address: 0x000f73b0 signature: 'PCMP' base table length: 308 version: 1.1 checksum: 0x56 OEM ID: 'INTEL ' Product ID: 'XXPRESS ' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 27 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 0 0x10 BSP, usable 5 2 11 0x03bf 2 0x10 AP, usable 5 2 11 0x03bf 3 0x10 AP, usable 5 2 5 0x03bf 4 0x10 AP, usable 5 2 5 0x03bf -- Bus: Bus ID Type 0 PCI 1 PCI 18 XPRESS 19 EISA -- I/O APICs: APIC ID Version State Address 14 0x11 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ExtINT active-hi edge 19 0 14 0 INT active-hi edge 19 1 14 1 INT active-hi edge 19 0 14 2 INT active-hi edge 19 3 14 3 INT active-hi edge 19 4 14 4 INT active-hi edge 19 5 14 5 INT active-hi edge 19 6 14 6 INT conforms level 19 7 14 7 INT active-hi edge 19 8 14 8 INT active-hi edge 19 9 14 9 INT conforms level 19 10 14 10 INT conforms level 19 11 14 11 INT active-hi edge 19 12 14 12 INT active-hi edge 19 13 14 13 INT active-hi edge 19 14 14 14 INT active-hi edge 19 15 14 15 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ExtINT active-hi edge 19 0 255 0 NMI active-hi edge 0 0:A 255 1 ------------------------------------------------------------------------------- dmesg output: FreeBSD 2.2-CURRENT #0: Fri Oct 25 17:06:09 MET DST 1996 root@quattro:/usr/src/sys.old/compile/netserver Calibrating clock(s) relative to mc146818A clock... i8254 clock: 1193166 Hz CPU: Pentium (586-class CPU) Origin = "GenuineIntel" Id = 0x52b Stepping=11 Features=0x3bf real memory = 67108864 (65536K bytes) avail memory = 62918656 (61444K bytes) eisa0: Probing for devices on the EISA bus Probing for devices on PCI bus 0: chip0 rev 2 on pci0:0 chip1 rev 5 on pci0:14:0 pci0:15:0: Intel Corporation, device=0x0008, class=0xff, subclass=0x00 [no driver assigned] pci0:15:1: Intel Corporation, device=0x0008, class=0xff, subclass=0x00 [no driver assigned] pci0:15:2: Intel Corporation, device=0x0008, class=0xff, subclass=0x00 [no driver assigned] pci0:15:3: Intel Corporation, device=0x0008, class=0xff, subclass=0x00 [no driver assigned] pci0:15:4: Intel Corporation, device=0x0008, class=0xff, subclass=0x00 [no driver assigned] pci0:15:5: Intel Corporation, device=0x0008, class=0xff, subclass=0x00 [no driver assigned] pci0:15:6: Intel Corporation, device=0x0008, class=0xff, subclass=0x00 [no driver assigned] pci0:15:7: Intel Corporation, device=0x0008, class=0xff, subclass=0x00 [no driver assigned] Probing for devices on PCI bus 1: chip2 rev 2 on pci1:0 vx0 <3COM 3C595 Fast Etherlink XL PCI> rev 0 int a irq 11 on pci1:12 mii[*mii*] address 00:60:97:12:60:e8 Warning! Defective early revision adapter! ahc0 rev 3 int a irq 7 on pci1:13 ahc0: Using left over BIOS settings ahc0: aic7870 Wide Channel, SCSI Id=7, 16 SCBs ahc0 waiting for scsi devices to settle (ahc0:0:0): "HP 2.13 GB 1st ### 1221" type 0 fixed SCSI 2 sd0(ahc0:0:0): Direct-Access 2033MB (4165272 512 byte sectors) (ahc0:5:0): "TOSHIBA CD-ROM XM-5301TA 1895" type 5 removable SCSI 2 cd0(ahc0:5:0): CD-ROM cd0(ahc0:5:0): NOT READY asc:3a,0 Medium not present can't get the size ahc1 rev 3 int a irq 10 on pci1:14 ahc1: Using left over BIOS settings ahc1: aic7870 Wide Channel, SCSI Id=6, 16 SCBs ahc1 waiting for scsi devices to settle (ahc1:4:0): "HP 2.13 GB 1st ### 1221" type 0 fixed SCSI 2 sd1(ahc1:4:0): Direct-Access 2033MB (4165272 512 byte sectors) Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 not found at 0x2f8 lpt0 not found at 0xffffffff mse0 not found at 0x23c fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in wdc0 not found at 0x1f0 npx0 on motherboard npx0: INT 16 interface changing root device to sd0a vx0: strange connector type in EEPROM: assuming AUI vx0: strange connector type in EEPROM: assuming AUI vx0: strange connector type in EEPROM: assuming AUI ------------------------------------------------------------------------------- # SMP kernel config file options: options SMP # Symmetric MultiProcessor Kernel #options APIC_IO # Symmetric (APIC) I/O options NCPU=4 # number of CPUs options NBUS=4 # number of busses options NAPIC=1 # number of IO APICs options NINTR=16 # number of INTs =============================================================================== > >There's a good chance the current SMP will work now (2 CPUs), alot of bugs have >been squashed in the last 2 months. Will try soon, seems like smp-current won't compile without going to current for the rest of the system (tried the latest snap, didn't even pass make depend, as failed on %cr4 in locore.s :-/). So, I've got to get an up to date current source tree first. Terje Marthinussen terjem@cc.uit.no From owner-freebsd-smp Tue Nov 26 18:37:04 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA03474 for smp-outgoing; Tue, 26 Nov 1996 14:35:23 -0800 (PST) Received: (from fsmp@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA03439 for freebsd-smp; Tue, 26 Nov 1996 14:35:13 -0800 (PST) Date: Tue, 26 Nov 1996 14:35:13 -0800 (PST) From: Steve Passe Message-Id: <199611262235.OAA03439@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/i386 mp_machdep.c mpapic.c Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk fsmp 96/11/26 14:35:11 Modified: i386/i386 mp_machdep.c mpapic.c Log: skeleton IPI calls for new IPI_INTR() entry points. #define IPI_INTS in i386/include/apic.h to enable (the default). #define TEST_IPI in i386/include/smptests.h for test code (default for now). removed TEST_DISABLEFOCUS code. Revision Changes Path 1.20 +69 -10 sys/i386/i386/mp_machdep.c 1.21 +11 -124 sys/i386/i386/mpapic.c From owner-freebsd-smp Wed Nov 27 01:52:03 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA02290 for smp-outgoing; Tue, 26 Nov 1996 14:30:25 -0800 (PST) Received: (from fsmp@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA02250 for freebsd-smp; Tue, 26 Nov 1996 14:30:07 -0800 (PST) Date: Tue, 26 Nov 1996 14:30:07 -0800 (PST) From: Steve Passe Message-Id: <199611262230.OAA02250@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/kern init_main.c Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk fsmp 96/11/26 14:30:04 Modified: kern init_main.c Log: removed TEST_DISABLEFOCUS, focus processor feature is default. Revision Changes Path 1.34 +2 -6 sys/kern/init_main.c From owner-freebsd-smp Wed Nov 27 02:44:31 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA10859 for smp-outgoing; Wed, 27 Nov 1996 02:44:31 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA10850 for freebsd-smp; Wed, 27 Nov 1996 02:44:29 -0800 (PST) Date: Wed, 27 Nov 1996 02:44:29 -0800 (PST) From: Peter Wemm Message-Id: <199611271044.CAA10850@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/i386 machdep.c mp_machdep.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/27 02:44:27 Modified: i386/i386 machdep.c mp_machdep.c Log: Implement reuse of the GPROC0_SEL TSS on all cpu's. This was something that was holding up N cpu support. Revision Changes Path 1.31 +3 -11 sys/i386/i386/machdep.c 1.21 +3 -2 sys/i386/i386/mp_machdep.c From owner-freebsd-smp Wed Nov 27 02:45:33 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA10935 for smp-outgoing; Wed, 27 Nov 1996 02:45:33 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA10924 for freebsd-smp; Wed, 27 Nov 1996 02:45:31 -0800 (PST) Date: Wed, 27 Nov 1996 02:45:31 -0800 (PST) From: Peter Wemm Message-Id: <199611271045.CAA10924@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/include segments.h Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/27 02:45:30 Modified: i386/include segments.h Log: Remove the GPROC1_SEL TSS entry in the gdt, we don't need it any more. This file is now in sync with -current. Revision Changes Path 1.5 +1 -2 sys/i386/include/segments.h From owner-freebsd-smp Wed Nov 27 02:47:15 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA11039 for smp-outgoing; Wed, 27 Nov 1996 02:47:15 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA11032 for freebsd-smp; Wed, 27 Nov 1996 02:47:14 -0800 (PST) Date: Wed, 27 Nov 1996 02:47:14 -0800 (PST) From: Peter Wemm Message-Id: <199611271047.CAA11032@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/i386 mpboot.s Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/27 02:47:13 Modified: i386/i386 mpboot.s Log: More general boot routine. Remove some 2-cpu dependencies. This should support any number of cpus now. Revision Changes Path 1.10 +9 -15 sys/i386/i386/mpboot.s From owner-freebsd-smp Wed Nov 27 02:50:21 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA11241 for smp-outgoing; Wed, 27 Nov 1996 02:50:21 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA11234 for freebsd-smp; Wed, 27 Nov 1996 02:50:20 -0800 (PST) Date: Wed, 27 Nov 1996 02:50:20 -0800 (PST) From: Peter Wemm Message-Id: <199611271050.CAA11234@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/kern init_main.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/27 02:50:19 Modified: kern init_main.c Log: Support more than 2 cpu's. This drives the changes in mpboot.s to bring up 'n' cpu's in an orderly fashion. NOTE!! It now enables SMP mode *at boot*! The sysctl to set kern.smp_active to 2 is no longer needed. Note, the sysctl is still respected, so you can lower it to 1 and the AP cpu's will freeze. I'm not sure if there are other santity checks to prevent more than 2 cpu's in the code, I've only tested with 2 and have not looked far yet. Revision Changes Path 1.35 +63 -22 sys/kern/init_main.c From owner-freebsd-smp Wed Nov 27 03:45:27 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA14071 for smp-outgoing; Wed, 27 Nov 1996 03:45:27 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id DAA14064 for freebsd-smp; Wed, 27 Nov 1996 03:45:23 -0800 (PST) Date: Wed, 27 Nov 1996 03:45:23 -0800 (PST) From: Peter Wemm Message-Id: <199611271145.DAA14064@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/i386 mp_machdep.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/27 03:45:21 Modified: i386/i386 mp_machdep.c Log: If booting with more than 2 cpus, give it a try. Warn that it's not known to work yet. Revision Changes Path 1.22 +4 -4 sys/i386/i386/mp_machdep.c From owner-freebsd-smp Wed Nov 27 07:49:10 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA25912 for smp-outgoing; Wed, 27 Nov 1996 07:49:10 -0800 (PST) Received: from dn800e0.fingerhut.com (dn800e0-ext.fingerhut.com [204.221.45.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA25907 for ; Wed, 27 Nov 1996 07:49:08 -0800 (PST) Received: from dn800e0.fingerhut.com (daemon@localhost) by dn800e0.fingerhut.com (8.7.2/8.7.2) with ESMTP id JAA05282 for ; Wed, 27 Nov 1996 09:49:20 -0600 (CST) Received: from seag.fingerhut.com (GF007E0.SEAG.fingerhut.com [151.210.140.7]) by dn800e0.fingerhut.com (8.7.2/8.7.2) with SMTP id JAA05278 for ; Wed, 27 Nov 1996 09:49:19 -0600 (CST) Received: from g0084.fingerhut.com. by seag.fingerhut.com (SMI-8.6/SMI-SVR4) id JAA20060; Wed, 27 Nov 1996 09:48:47 -0600 Received: by g0084.fingerhut.com. (SMI-8.6/SMI-SVR4) id JAA03358; Wed, 27 Nov 1996 09:48:40 -0600 Date: Wed, 27 Nov 1996 09:48:40 -0600 Message-Id: <199611271548.JAA03358@g0084.fingerhut.com.> From: Bruce Albrecht To: smp@freebsd.org Subject: P5 vs. P6 performance Mime-Version: 1.0 (generated by tm-edit 7.68) Content-Type: text/plain; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm looking at buying either a dual CPU Pentium motherboard and initially populating it with a single Pentium-200 MHz, and then adding the second Pentium-200 MHz a few months later, OR buying a single Pentium-Pro 200 MHz motherboard. What can I expect for relative performance for each system, assuming that each one has, for example 64 MB memory? If this is an overpowered home system with only occasional periods of sustained computation, would I need more that 64 MB? For example, on a lightly loaded system, how much faster is the Pentium Pro? Which system (dual P5 vs. 1 P6) would be faster at compiling all of FreeBSD from scratch? Thanks. From owner-freebsd-smp Wed Nov 27 09:18:36 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA00190 for smp-outgoing; Wed, 27 Nov 1996 09:18:36 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA00180 for ; Wed, 27 Nov 1996 09:18:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id KAA15456; Wed, 27 Nov 1996 10:18:01 -0700 Message-Id: <199611271718.KAA15456@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Bruce Albrecht cc: smp@freebsd.org Subject: Re: P5 vs. P6 performance In-reply-to: Your message of "Wed, 27 Nov 1996 09:48:40 CST." <199611271548.JAA03358@g0084.fingerhut.com.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Nov 1996 10:18:00 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > I'm looking at buying either a dual CPU Pentium motherboard and > initially populating it with a single Pentium-200 MHz, and then adding the > second Pentium-200 MHz a few months later, OR buying a single Pentium-Pro 200 > MHz motherboard. What can I expect for relative performance for each > system, assuming that each one has, for example 64 MB memory? If this > is an overpowered home system with only occasional periods of > sustained computation, would I need more that 64 MB? > > For example, on a lightly loaded system, how much faster is the > Pentium Pro? Which system (dual P5 vs. 1 P6) would be faster at > compiling all of FreeBSD from scratch? right now the single P6 would be faster than 2 P5s. How much longer that will be true I'm not sure, things are progressing nicely in the SMP kernel. 2 P5-200 might suffer from serious bus congestion. If you can afford it go for a dual P6 with one CPU for now, then add the second CPU when finances permit. There is not that much difference between a P5-200 and a P6 these days (p5-200s are overpriced, but then so are P6). I suspect (hope?) a decent price drop in P6 by February. 64 meg should do nicely unless you are doing something intensive. I have 64 meg and rarely hit swap. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Wed Nov 27 11:01:14 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA05676 for smp-outgoing; Wed, 27 Nov 1996 11:01:14 -0800 (PST) Received: from mx.serv.net (mx.serv.net [199.201.191.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA05671 for ; Wed, 27 Nov 1996 11:01:11 -0800 (PST) Received: from MindBender.serv.net by mx.serv.net (8.7.5/SERV Revision: 2.30) id LAA26490; Wed, 27 Nov 1996 11:00:59 -0800 (PST) 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 LAA05971; Wed, 27 Nov 1996 11:00:52 -0800 (PST) Message-Id: <199611271900.LAA05971@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: Steve Passe cc: Bruce Albrecht , smp@freebsd.org Subject: Re: P5 vs. P6 performance In-reply-to: Your message of Wed, 27 Nov 96 10:18:00 -0700. <199611271718.KAA15456@clem.systemsix.com> Date: Wed, 27 Nov 1996 11:00:52 -0800 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> I'm looking at buying either a dual CPU Pentium motherboard and >> initially populating it with a single Pentium-200 MHz, and then adding the >> second Pentium-200 MHz a few months later, OR buying a single Pentium-Pro 200 >> MHz motherboard. What can I expect for relative performance for each >> system, assuming that each one has, for example 64 MB memory? If this >> is an overpowered home system with only occasional periods of >> sustained computation, would I need more that 64 MB? I have 64MB now. With memory so cheap, it makes a *perfect* system. I never ever push anything out to swap. :-) It's really overkill for my home system -- 32MB was working nicely. But, once again, if memory is so cheap, why not... >> For example, on a lightly loaded system, how much faster is the >> Pentium Pro? Which system (dual P5 vs. 1 P6) would be faster at >> compiling all of FreeBSD from scratch? My experience shows that a P6-200 (256K cache) is roughly 2.5 times faster than a P5-120. Remember also that a P5-200 is *not* 200/120 faster than a P5-120. The P5-200 is reaching bus saturation levels, and supposedly is barely faster than a P5-166. I would suspect that putting two of them in there would only make matters worse, unless you had some really exceptionally designed, and BIG, motherboard caches. This is NetBSD-1.2, but the times are similar to FreeBSD. I can do a make world, from a virgin tree to finished, in 1 hour 21 minutes on a P6-200 w/64MB, an Adaptec 2940UW, and some decent SCSI drives. It takes ~3:15 on my P5-200 (single processor) 2/64MB, 512K PB cache, same SCSI controller and drives. >right now the single P6 would be faster than 2 P5s. How much longer that will >be true I'm not sure, things are progressing nicely in the SMP kernel. I would suspect that dual P5s would only be slightly faster than a decent P6 system. That is pure speculation, though. >2 P5-200 might suffer from serious bus congestion. If you can afford it >go for a dual P6 with one CPU for now, then add the second CPU when >finances permit. This would definitely be the best advice for performance reasons. ----------------------------------------------------------------------------- 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 Nov 27 11:01:49 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA05723 for smp-outgoing; Wed, 27 Nov 1996 11:01:49 -0800 (PST) Received: from saturn.apana.org.au (root@saturn.apana.org.au [202.12.90.3]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA05706 for ; Wed, 27 Nov 1996 11:01:42 -0800 (PST) Received: by saturn.apana.org.au id m0vSpEL-0000XgC (Debian /\oo/\ Smail3.1.29.1 #29.37); Thu, 28 Nov 96 06:01 EST Received: from magpie.apana.org.au (magpie [203.9.107.246]) by bullseye.apana.org.au (8.6.12/8.6.12) with SMTP id VAA07634; Wed, 27 Nov 1996 21:57:18 +1100 Date: Wed, 27 Nov 1996 20:52:52 +1100 (EST) From: Andrew MacIntyre X-Sender: andymac@magpie.apana.org.au To: Terje Normann Marthinussen cc: Steve Passe , freebsd-smp@freebsd.org Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h In-Reply-To: <199611270218.DAA06207@slibo.cc.uit.no> 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 Wed, 27 Nov 1996, Terje Normann Marthinussen wrote: {...} > Processors: APIC ID Version State Family Model Step Flags > 0 0x10 BSP, usable 5 2 11 0x03bf > 2 0x10 AP, usable 5 2 11 0x03bf > 3 0x10 AP, usable 5 2 5 0x03bf > 4 0x10 AP, usable 5 2 5 0x03bf ^^^^ {...} Just FYI, I recall seeing a message recently from Linus Torvalds (in a Linux newsgroup) indicating that there was evidence that Stepping 5 (and possibly earlier) P5 CPUs had a problem that affected operation of the Linux kernel. Unfortunately I don't recall the substance of this message :-(. Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andrew.macintyre@aba.gov.au (work) | Snail: PO Box 370 andymac@bullseye.apana.org.au (play) | Belconnen ACT 2616 Fido: Andrew MacIntyre, 3:620/243.18 | Australia From owner-freebsd-smp Wed Nov 27 11:02:06 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA05756 for smp-outgoing; Wed, 27 Nov 1996 11:02:06 -0800 (PST) Received: from saturn.apana.org.au (root@saturn.apana.org.au [202.12.90.3]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA05748 for ; Wed, 27 Nov 1996 11:02:01 -0800 (PST) Received: by saturn.apana.org.au id m0vSpEM-0000Y8C (Debian /\oo/\ Smail3.1.29.1 #29.37); Thu, 28 Nov 96 06:01 EST Received: from magpie.apana.org.au (magpie [203.9.107.246]) by bullseye.apana.org.au (8.6.12/8.6.12) with SMTP id WAA07668; Wed, 27 Nov 1996 22:30:11 +1100 Date: Wed, 27 Nov 1996 21:25:45 +1100 (EST) From: Andrew MacIntyre X-Sender: andymac@magpie.apana.org.au To: Terje Normann Marthinussen cc: freebsd-smp@freebsd.org, Steve Passe Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk More info: - just stumbled across some followups to the original msg referred to below. Apparently the problem has to do with using the 4MB page extension supported by P5 and better CPUs. Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andrew.macintyre@aba.gov.au (work) | Snail: PO Box 370 andymac@bullseye.apana.org.au (play) | Belconnen ACT 2616 Fido: Andrew MacIntyre, 3:620/243.18 | Australia On Wed, 27 Nov 1996, Andrew MacIntyre wrote: > On Wed, 27 Nov 1996, Terje Normann Marthinussen wrote: > > {...} > > > Processors: APIC ID Version State Family Model Step Flags > > 0 0x10 BSP, usable 5 2 11 0x03bf > > 2 0x10 AP, usable 5 2 11 0x03bf > > 3 0x10 AP, usable 5 2 5 0x03bf > > 4 0x10 AP, usable 5 2 5 0x03bf > > ^^^^ > > {...} > > Just FYI, I recall seeing a message recently from Linus Torvalds (in a Linux > newsgroup) indicating that there was evidence that Stepping 5 (and possibly > earlier) P5 CPUs had a problem that affected operation of the Linux > kernel. Unfortunately I don't recall the substance of this message :-(. > > > Andrew I MacIntyre "These thoughts are mine alone..." > E-mail: andrew.macintyre@aba.gov.au (work) | Snail: PO Box 370 > andymac@bullseye.apana.org.au (play) | Belconnen ACT 2616 > Fido: Andrew MacIntyre, 3:620/243.18 | Australia > From owner-freebsd-smp Wed Nov 27 11:15:38 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA06348 for smp-outgoing; Wed, 27 Nov 1996 11:15:38 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA06340 for ; Wed, 27 Nov 1996 11:15:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id MAA16047; Wed, 27 Nov 1996 12:14:57 -0700 Message-Id: <199611271914.MAA16047@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Andrew MacIntyre cc: Terje Normann Marthinussen , freebsd-smp@freebsd.org Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h In-reply-to: Your message of "Wed, 27 Nov 1996 20:52:52 +1100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Nov 1996 12:14:57 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > On Wed, 27 Nov 1996, Terje Normann Marthinussen wrote: > > {...} > > > Processors: APIC ID Version State Family Model Step Flags > > 0 0x10 BSP, usable 5 2 11 0x03bf > > 2 0x10 AP, usable 5 2 11 0x03bf > > 3 0x10 AP, usable 5 2 5 0x03bf > > 4 0x10 AP, usable 5 2 5 0x03bf > > ^^^^ > > {...} > > Just FYI, I recall seeing a message recently from Linus Torvalds (in a Linux > newsgroup) indicating that there was evidence that Stepping 5 (and possibly > earlier) P5 CPUs had a problem that affected operation of the Linux > kernel. Unfortunately I don't recall the substance of this message :-(. I'm using: Processors: APIC ID Version State Family Model Step Flags 0 0x11 BSP, usable 5 2 1 0x07bf 1 0x11 AP, usable 5 2 1 0x07bf ^^^ without problems (that I'm aware of). -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Wed Nov 27 11:22:31 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA06739 for smp-outgoing; Wed, 27 Nov 1996 11:22:31 -0800 (PST) Received: from kvikk.uit.no (kvikk.Uit.No [129.242.4.32]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA06730 for ; Wed, 27 Nov 1996 11:22:26 -0800 (PST) Received: from sprint.cc.uit.no (sprint.Cc.Uit.No [129.242.5.198]) by kvikk.uit.no (8.7.3/8.7.1) with ESMTP id UAA17898; Wed, 27 Nov 1996 20:22:14 +0100 (MET) Received: from slibo.cc.uit.no (slibo.Cc.Uit.No [129.242.5.36]) by sprint.cc.uit.no (8.8.0/8.8.0) with ESMTP id UAA21085; Wed, 27 Nov 1996 20:22:13 +0100 (MET) Received: from localhost (terjem@localhost) by slibo.cc.uit.no (8.7.3/8.7.3) with ESMTP id UAA02560; Wed, 27 Nov 1996 20:22:12 +0100 (MET) Message-Id: <199611271922.UAA02560@slibo.cc.uit.no> X-Mailer: exmh version 1.6.9 8/22/96 To: Andrew MacIntyre cc: Terje Normann Marthinussen , freebsd-smp@freebsd.org, Steve Passe Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h In-reply-to: Your message of "Wed, 27 Nov 1996 21:25:45 MET." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Nov 1996 20:22:12 +0100 From: Terje Normann Marthinussen Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Just FYI, I recall seeing a message recently from Linus Torvalds (in a Linux > newsgroup) indicating that there was evidence that Stepping 5 (and possibly > earlier) P5 CPUs had a problem that affected operation of the Linux > kernel. Unfortunately I don't recall the substance of this message :-(. Just got current-smp (current as ~13:00 GMT 27 nov 1996) up... sort of up at least... First atemps needed adjustments for NBUS, but that was easy enough. Maybe it would be nice to print a suggested value? Not just that is should be increased? However then came: BIOS basemem (633K) != RTC basemem (640K), setting to BIOS value unknown bus type: 'XPRESS' Followed by panic... Argh, haven't had time to study what it would like to know about the bus. If it is something special, anyone that has enough information to do something about it? Well, it worked in earlier releases, so I quickly commented out the panic() and continued. Just didn't have the patience :) Then: Warning: current SMP kernel only tested with 2 CPUs. Please report the results to: to continue... Application Processor #3 failed! panic (cpu#0): Yup, thats it. Forcing it to run on just the two first cpus works though. Seems to be something fishy somewhere though. Sendmail likes to core dump after boot, and running make -j usually ends up with kernel: pid 1338 (cpp), uid 0: exited on signal 11 (core dumped) Haven't got further, but this machine has run Linux with smp support earlier. Hmm. We have another of these computers here. Maybe I should have a look at the cpu steppings on the 2. cpu card on that one.... Terje Marthinussen terjem@cc.uit.no From owner-freebsd-smp Wed Nov 27 11:55:51 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA08256 for smp-outgoing; Wed, 27 Nov 1996 11:55:51 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA08249 for ; Wed, 27 Nov 1996 11:55:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id MAA16277; Wed, 27 Nov 1996 12:55:14 -0700 Message-Id: <199611271955.MAA16277@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Terje Normann Marthinussen cc: Andrew MacIntyre , freebsd-smp@freebsd.org Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h In-reply-to: Your message of "Wed, 27 Nov 1996 20:22:12 +0100." <199611271922.UAA02560@slibo.cc.uit.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Nov 1996 12:55:14 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > Just got current-smp (current as ~13:00 GMT 27 nov 1996) up... sort of > up at least... > > First atemps needed adjustments for NBUS, but that was easy enough. Maybe > it would be nice to print a suggested value? Not just that is should > be increased? the program 'mptable' (on the SMP web page) will analyze your board and create a definitive "options" list for your config file. The defaults are set to the minimums to avoid kernel bloat. I want to keep extended examination of the MP table out of the kernel, again to avoid bloat, hence the mptable tool. Maybe I should make the message suggest mptable? --- > However then came: > BIOS basemem (633K) != RTC basemem (640K), setting to BIOS value > unknown bus type: 'XPRESS' > > Followed by panic... > Argh, haven't had time to study what it would like to know about the bus. > If it is something special, anyone that has enough information to do > something about it? > ... > Well, it worked in earlier releases, so I quickly commented out the panic() > and continued. Just didn't have the patience :) if you don't need to use anything on the XPRESS bus it should be simple, I'll look at it later today... --- > Then: > Warning: current SMP kernel only tested with 2 CPUs. > Please report the results to: > to continue... > Application Processor #3 failed! > panic (cpu#0): > > Yup, thats it. Peter? --- > Forcing it to run on just the two first cpus works though. > Seems to be something fishy somewhere though. Sendmail likes to > core dump after boot, and running make -j usually ends up with > kernel: pid 1338 (cpp), uid 0: exited on signal 11 (core dumped) known problem in current SMP kernel, expected and being worked on... We will announce its fix LOUDLY when we finish it! -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Wed Nov 27 12:19:17 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA09736 for smp-outgoing; Wed, 27 Nov 1996 12:19:17 -0800 (PST) Received: (from fsmp@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA09729 for freebsd-smp; Wed, 27 Nov 1996 12:19:16 -0800 (PST) Date: Wed, 27 Nov 1996 12:19:16 -0800 (PST) From: Steve Passe Message-Id: <199611272019.MAA09729@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/i386 autoconf.c mp_machdep.c mpapic.c sys/i386/include mpapic.h smp.h sys/i386/isa clock.c icu.h if_ed.c if_ze.c npx.c vector.s Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk fsmp 96/11/27 12:19:15 Modified: i386/i386 autoconf.c mp_machdep.c mpapic.c i386/include mpapic.h smp.h Log: Merged the 2 global INTerrupt masks: imen and IOApicMask. Revision Changes Path 1.11 +2 -7 sys/i386/i386/autoconf.c 1.23 +15 -35 sys/i386/i386/mp_machdep.c 1.22 +42 -11 sys/i386/i386/mpapic.c 1.6 +34 -19 sys/i386/include/mpapic.h 1.21 +6 -5 sys/i386/include/smp.h Modified: i386/isa clock.c icu.h if_ed.c if_ze.c npx.c vector.s Log: Merged the 2 global INTerrupt masks: imen and IOApicMask. revert if_ed.c to -current. fix missing include file for options APIC_IO in if_ze.c. Revision Changes Path 1.13 +9 -1 sys/i386/isa/clock.c 1.9 +33 -10 sys/i386/isa/icu.h 1.5 +1 -25 sys/i386/isa/if_ed.c 1.7 +2 -1 sys/i386/isa/if_ze.c 1.13 +9 -9 sys/i386/isa/npx.c 1.29 +3 -5 sys/i386/isa/vector.s From owner-freebsd-smp Wed Nov 27 12:38:43 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA10623 for smp-outgoing; Wed, 27 Nov 1996 12:38:43 -0800 (PST) Received: from kvikk.uit.no (kvikk.Uit.No [129.242.4.32]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA10617 for ; Wed, 27 Nov 1996 12:38:40 -0800 (PST) Received: from sprint.cc.uit.no (sprint.Cc.Uit.No [129.242.5.198]) by kvikk.uit.no (8.7.3/8.7.1) with ESMTP id VAA18795; Wed, 27 Nov 1996 21:38:30 +0100 (MET) Received: from slibo.cc.uit.no (slibo.Cc.Uit.No [129.242.5.36]) by sprint.cc.uit.no (8.8.0/8.8.0) with ESMTP id VAA21402; Wed, 27 Nov 1996 21:38:29 +0100 (MET) Received: from localhost (terjem@localhost) by slibo.cc.uit.no (8.7.3/8.7.3) with ESMTP id VAA04476; Wed, 27 Nov 1996 21:38:28 +0100 (MET) Message-Id: <199611272038.VAA04476@slibo.cc.uit.no> X-Mailer: exmh version 1.6.9 8/22/96 To: Steve Passe cc: freebsd-smp@freebsd.org Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h In-reply-to: Your message of "Wed, 27 Nov 1996 12:55:14 MET." <199611271955.MAA16277@clem.systemsix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Nov 1996 21:38:28 +0100 From: Terje Normann Marthinussen Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >the program 'mptable' (on the SMP web page) will analyze your >board and create a definitive "options" list for your config file. The >defaults are set to the minimums to avoid kernel bloat. I want to keep >extended examination of the MP table out of the kernel, again to avoid >bloat, hence the mptable tool. Maybe I should make the message suggest >mptable? Yes, I know of mptable, used it to find the right number. But don't you already examine the table when you discover that NBUS is to low? >--- >> However then came: >> BIOS basemem (633K) != RTC basemem (640K), setting to BIOS value >> unknown bus type: 'XPRESS' >> >> Followed by panic... >> Argh, haven't had time to study what it would like to know about the bus. >> If it is something special, anyone that has enough information to do >> something about it? >> ... >> Well, it worked in earlier releases, so I quickly commented out the panic() >> and continued. Just didn't have the patience :) > >if you don't need to use anything on the XPRESS bus it should be simple, >I'll look at it later today... Well, I'm not really sure what the XPRESS bus is. I'm a bit new to these machines. I would suspect it to be the system bus? If so, I would suspect that the PCI busses and CPU cards are already on it? The only slots in it that is non pci/eisa are those that the CPU and memory cards are plugged into. Shall see if I can find something (there isn't much documentation on these boxes here) later. Have to do some other work now. Terje Marthinussen terjem@cc.uit.no From owner-freebsd-smp Wed Nov 27 13:02:54 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA12162 for smp-outgoing; Wed, 27 Nov 1996 13:02:54 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA12155 for ; Wed, 27 Nov 1996 13:02:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id OAA16661; Wed, 27 Nov 1996 14:02:34 -0700 Message-Id: <199611272102.OAA16661@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Terje Normann Marthinussen cc: freebsd-smp@freebsd.org Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h In-reply-to: Your message of "Wed, 27 Nov 1996 21:38:28 +0100." <199611272038.VAA04476@slibo.cc.uit.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Nov 1996 14:02:34 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > >the program 'mptable' (on the SMP web page) will analyze your > >board and create a definitive "options" list for your config file. The > ... > Yes, I know of mptable, used it to find the right number. > But don't you already examine the table when you discover that NBUS is > to low? yes, you could go on to count them, but there are a half dozen other options that also might need tuning, requireing more code to handle them. Its just an arbitrary decision on my part, there is no technical reason it can't be done. --- > >--- > >> However then came: > >> BIOS basemem (633K) != RTC basemem (640K), setting to BIOS value > >> unknown bus type: 'XPRESS' > >> > >> Followed by panic... > >> Argh, haven't had time to study what it would like to know about the bus. > >> If it is something special, anyone that has enough information to do > >> something about it? > >> ... > >> Well, it worked in earlier releases, so I quickly commented out the panic() > >> and continued. Just didn't have the patience :) > > > >if you don't need to use anything on the XPRESS bus it should be simple, > >I'll look at it later today... > > Well, I'm not really sure what the XPRESS bus is. I'm a bit new to these > machines. I would suspect it to be the system bus? > > If so, I would suspect that the PCI busses and CPU cards are already on it? > The only slots in it that is non pci/eisa are those that the CPU > and memory cards are plugged into. the CPU/memory might be whats on the XXPRESS bus. you have 2 PCI busses, as well as an EISA bus in addition to the XPRESS bus: --- Bus: Bus ID Type 0 PCI 1 PCI 18 XPRESS 19 EISA -- I/O APICs: APIC ID Version State Address 14 0x11 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ExtINT active-hi edge 19 0 14 0 INT active-hi edge 19 1 14 1 INT active-hi edge 19 0 14 2 INT active-hi edge 19 3 14 3 INT active-hi edge 19 4 14 4 INT active-hi edge 19 5 14 5 INT active-hi edge 19 6 14 6 INT conforms level 19 7 14 7 INT active-hi edge 19 8 14 8 INT active-hi edge 19 9 14 9 INT conforms level 19 10 14 10 INT conforms level 19 11 14 11 INT active-hi edge 19 12 14 12 INT active-hi edge 19 13 14 13 INT active-hi edge 19 14 14 14 INT active-hi edge 19 15 14 15 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ExtINT active-hi edge 19 0 255 0 NMI active-hi edge 0 0:A 255 1 --- none of the above entries use the XPRESS bus id (18) so nothing important appears to be on the XPRESS bus. I suspect your problems are a bug in the >2 CPU stuff, its only a few hours old at this point and neither Peter or I have a 4 CPU machine for testing. we'll be dependant on testers like yourself to get past this one! -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Wed Nov 27 13:21:28 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA13218 for smp-outgoing; Wed, 27 Nov 1996 13:21:28 -0800 (PST) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA13212 for ; Wed, 27 Nov 1996 13:21:20 -0800 (PST) Received: from star.cirrus.com by mail.crl.com with SMTP id AA00951 (5.65c/IDA-1.5 for ); Wed, 27 Nov 1996 13:22:07 -0800 Received: from ss563.corp.cirrus.com (ss563.corp.cirrus.com [141.131.8.55]) by star.cirrus.com (8.6.12/8.6.12) with ESMTP id NAA25878; Wed, 27 Nov 1996 13:18:42 -0800 Received: from elbert.colorado.cirrus.com (elbert.colorado.cirrus.com [198.90.142.11]) by ss563.corp.cirrus.com with ESMTP id NAA19534 (8.7.5/IDA-1.6); Wed, 27 Nov 1996 13:18:40 -0800 (PST) Received: from longs.colorado.cirrus.com (longs.colorado.cirrus.com [198.90.139.11]) by elbert.colorado.cirrus.com with SMTP id OAA02980 (8.6.12/IDA-1.6); Wed, 27 Nov 1996 14:18:41 -0700 Received: by longs.colorado.cirrus.com (4.1-Colorado/2.00) id AA16802; Wed, 27 Nov 96 14:18:40 MST Date: Wed, 27 Nov 96 14:18:40 MST From: clintw@colorado.cirrus.com (Clint Wolff) Message-Id: <9611272118.AA16802@longs.colorado.cirrus.com> To: smp@FreeBSD.org, Bruce.Albrecht@seag.fingerhut.com Subject: Re: P5 vs. P6 performance Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > I'm looking at buying either a dual CPU Pentium motherboard and > initially populating it with a single Pentium-200 MHz, and then adding the > second Pentium-200 MHz a few months later, OR buying a single Pentium-Pro 200 > MHz motherboard. What can I expect for relative performance for each > system, assuming that each one has, for example 64 MB memory? If this > is an overpowered home system with only occasional periods of > sustained computation, would I need more that 64 MB? > > For example, on a lightly loaded system, how much faster is the > Pentium Pro? Which system (dual P5 vs. 1 P6) would be faster at > compiling all of FreeBSD from scratch? > > Thanks. > Everyone I have talked to about buying a single pentium 200 and adding a second one later has cautioned against it... Apparently, Intel recommends only using dual processors with the same S-Spec number (I assume this is the stepping)... Buying one now and one later doesn't give you any way of insuring this... clint From owner-freebsd-smp Wed Nov 27 13:40:58 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA14448 for smp-outgoing; Wed, 27 Nov 1996 13:40:58 -0800 (PST) Received: from brimstone.gage.com (brimstone.gage.com [205.217.2.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA14443 for ; Wed, 27 Nov 1996 13:40:56 -0800 (PST) Received: (from mail@localhost) by brimstone.gage.com (8.8.3/8.7.3) id PAA24914; Wed, 27 Nov 1996 15:40:20 -0600 (CST) Received: from octopus.gage.com(158.60.57.50) by brimstone.gage.com via smap (V2.0beta) id xma024912; Wed, 27 Nov 96 15:40:00 -0600 Received: from squid.gage.com (squid [158.60.57.101]) by octopus.gage.com (8.7.5/8.7.3) with SMTP id PAA05666; Wed, 27 Nov 1996 15:30:43 -0600 (CST) Received: from schemer by squid.gage.com (NX5.67e/NX3.0S) id AA22429; Wed, 27 Nov 96 15:30:42 -0600 Message-Id: <9611272130.AA22429@squid.gage.com> Received: by schemer.gage.com (NX5.67g/NX3.0X) id AA00550; Wed, 27 Nov 96 15:30:42 -0600 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.0 v146.2) In-Reply-To: <9611272118.AA16802@longs.colorado.cirrus.com> X-Nextstep-Mailer: Mail 3.3 (Enhance 1.3) Received: by NeXT.Mailer (1.146.2) From: Ben Black Date: Wed, 27 Nov 96 15:30:34 -0600 To: clintw@colorado.cirrus.com (Clint Wolff) Subject: Re: P5 vs. P6 performance Cc: smp@freebsd.org, Bruce.Albrecht@seag.fingerhut.com References: <9611272118.AA16802@longs.colorado.cirrus.com> Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Everyone I have talked to about buying a single pentium 200 and adding a >second one later has cautioned against it... Apparently, Intel recommends >only using dual processors with the same S-Spec number (I assume this is >the stepping)... Buying one now and one later doesn't give you any >way of insuring this... yes, it said this in the docs that came with my dual p6 board. i may end up selling yms ingle p6 and buying 2 at once to get the same stepping. or i could risk it. b3n From owner-freebsd-smp Wed Nov 27 13:42:18 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA14494 for smp-outgoing; Wed, 27 Nov 1996 13:42:18 -0800 (PST) Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA14486 for ; Wed, 27 Nov 1996 13:42:15 -0800 (PST) Received: from arts.ratp.fr (arts.ratp.fr [193.106.40.1]) by soleil.uvsq.fr (8.8.3/jtpda-5.2) with ESMTP id WAA04306 for ; Wed, 27 Nov 1996 22:42:12 +0100 (MET) Received: by arts.ratp.fr id WAA28692 for ; Wed, 27 Nov 1996 22:42:14 +0100 (MET) Received: from minos.noisy.ratp by arts.ratp.fr with SMTP id SAA028683 for ; Wed Nov 27 22:41:45 1996 Received: by minos.noisy.ratp id WAA14477 for freebsd-smp@freebsd.org; Wed, 27 Nov 1996 22:41:45 +0100 (MET) From: Janick.Taillandier@ratp.fr (Janick TAILLANDIER) Message-Id: <199611272141.WAA14477@minos.noisy.ratp> Subject: IO APIC mode on Dell Optiplex To: freebsd-smp@freebsd.org Date: Wed, 27 Nov 1996 22:41:45 +0100 (MET) X-Mailer: ELM [version 2.4 PL24 ME8] 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 Hello, I am using a Dell Optiplex GXpro. Until recently this machine would not work with : options APIC_IO defined in the kernel configuration file because this machine does not connect the 8254 clock to the IO APIC. As a result you get the following message during boot: APIC missing 8254 connection panic(cpu#0) Recent updates now allow this configuration to work. All you have to do is to uncomment the line : #define IRQ_LO_NC in sys/i386/include/smptests.h. Et voila ! Everything works great after that. Once it is known to be working on several machines it will become the default action. If your motherboard experiences this panic, please report the results of using this option to smp@freebsd.org. I wish to thank Steve Pass for his code and help with this special case. Janick Taillandier From owner-freebsd-smp Wed Nov 27 14:17:47 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA16476 for smp-outgoing; Wed, 27 Nov 1996 14:17:47 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA16464 for ; Wed, 27 Nov 1996 14:17:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id PAA17055; Wed, 27 Nov 1996 15:17:15 -0700 Message-Id: <199611272217.PAA17055@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: clintw@colorado.cirrus.com (Clint Wolff) cc: smp@FreeBSD.org, Bruce.Albrecht@seag.fingerhut.com Subject: Re: P5 vs. P6 performance In-reply-to: Your message of "Wed, 27 Nov 1996 14:18:40 MST." <9611272118.AA16802@longs.colorado.cirrus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Nov 1996 15:17:15 -0700 Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi, > > > I'm looking at buying either a dual CPU Pentium motherboard and > > initially populating it with a single Pentium-200 MHz, and then adding the > > second Pentium-200 MHz a few months later, OR buying a single Pentium-Pro 200 > ... > Everyone I have talked to about buying a single pentium 200 and adding a > second one later has cautioned against it... Apparently, Intel recommends > only using dual processors with the same S-Spec number (I assume this is > the stepping)... Buying one now and one later doesn't give you any > way of insuring this... I know this is the "common knowledge", but I wonder if it is only historical, or still has some basis in fact. In the beginning Intel begat the P5 60/66 which didn't have an APIC. Then starting with the P5-90 SOME had working APICS, some evidently didn't, judgeing by the S-spec page on the Intel web page. Now I don't think Intel makes any P5 parts without working APICs. It's my belief that current P5/P6 parts needn't necessarily be of the same stepping, assumming same speed, etc. I have NO direct knowledge of this and would like to hear from anyone who does. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Wed Nov 27 14:51:30 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA19255 for smp-outgoing; Wed, 27 Nov 1996 14:51:30 -0800 (PST) Received: from dyson.iquest.net ([198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA19236 for ; Wed, 27 Nov 1996 14:51:22 -0800 (PST) Received: (from root@localhost) by dyson.iquest.net (8.8.2/8.6.9) id RAA01710; Wed, 27 Nov 1996 17:51:16 -0500 (EST) From: John Dyson Message-Id: <199611272251.RAA01710@dyson.iquest.net> Subject: Re: P5 vs. P6 performance To: clintw@colorado.cirrus.com (Clint Wolff) Date: Wed, 27 Nov 1996 17:51:11 -0500 (EST) Cc: smp@FreeBSD.org, Bruce.Albrecht@seag.fingerhut.com In-Reply-To: <9611272118.AA16802@longs.colorado.cirrus.com> from "Clint Wolff" at Nov 27, 96 02:18:40 pm Reply-To: dyson@FreeBSD.org X-Mailer: ELM [version 2.4 PL24 ME8] 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 > > Everyone I have talked to about buying a single pentium 200 and adding a > second one later has cautioned against it... Apparently, Intel recommends > only using dual processors with the same S-Spec number (I assume this is > the stepping)... Buying one now and one later doesn't give you any > way of insuring this... > Per the P6 errata, there isn't much of a problem. John From owner-freebsd-smp Wed Nov 27 21:50:14 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA07766 for smp-outgoing; Wed, 27 Nov 1996 21:50:14 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA07759 for ; Wed, 27 Nov 1996 21:50:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id WAA19237 for ; Wed, 27 Nov 1996 22:50:08 -0700 Message-Id: <199611280550.WAA19237@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: smp@freebsd.org Subject: latest code Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Nov 1996 22:50:08 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, we seem to have a synchronization problem between CPUs of some sort. please send reports, both good and bad, about the latest code. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Thu Nov 28 00:09:36 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA12184 for smp-outgoing; Thu, 28 Nov 1996 00:09:36 -0800 (PST) Received: from relay.internode.net (mail.internode.net [198.161.228.50]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA12179 for ; Thu, 28 Nov 1996 00:09:34 -0800 (PST) Received: from [198.161.228.114] by relay.internode.net (SMTPD32-3.02) id A6E4177800A2; Thu, 28 Nov 1996 01:01:40 -0700 Message-Id: <1.5.4.32.19961128081002.006798c0@internode.net> X-Sender: drussell@internode.net X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 28 Nov 1996 01:10:02 -0700 To: smp@freebsd.org From: Doug Russell Subject: Re: P5 vs. P6 performance Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk While we are on the subject of CPUs... Can you do SMP with the Cyrix 6x86 chips? Later...... From owner-freebsd-smp Thu Nov 28 05:19:28 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA25212 for smp-outgoing; Thu, 28 Nov 1996 05:19:28 -0800 (PST) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA25205 for ; Thu, 28 Nov 1996 05:19:21 -0800 (PST) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.3/8.8.3) with ESMTP id VAA06295; Thu, 28 Nov 1996 21:18:53 +0800 (WST) Message-Id: <199611281318.VAA06295@spinner.DIALix.COM> To: Steve Passe cc: freebsd-smp@freebsd.org Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h In-reply-to: Your message of "Wed, 27 Nov 1996 12:14:57 MST." <199611271914.MAA16047@clem.systemsix.com> Date: Thu, 28 Nov 1996 21:18:52 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve Passe wrote: > Hi, > > On Wed, 27 Nov 1996, Terje Normann Marthinussen wrote: > > > > {...} > > > > > Processors: APIC ID Version State Family Model Step Flags > > > 0 0x10 BSP, usable 5 2 11 0x03bf > > > 2 0x10 AP, usable 5 2 11 0x03bf > > > 3 0x10 AP, usable 5 2 5 0x03bf > > > 4 0x10 AP, usable 5 2 5 0x03bf > > > > ^^^^ > > {...} [..] > I'm using: > > Processors: APIC ID Version State Family Model Step Flags > 0 0x11 BSP, usable 5 2 1 0x07bf > 1 0x11 AP, usable 5 2 1 0x07bf > ^^^ > without problems (that I'm aware of). I think Step 6 was where they fixed the FPU divide bug.. (I saw a reference to this on "The Ultimate Chip list" or something like that) Cheers, -Peter From owner-freebsd-smp Thu Nov 28 07:15:22 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA29742 for smp-outgoing; Thu, 28 Nov 1996 07:15:22 -0800 (PST) Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA29735 for ; Thu, 28 Nov 1996 07:15:19 -0800 (PST) Received: from fast.cs.utah.edu by cs.utah.edu (8.8.3/utah-2.21-cs) id PAA06192; Thu, 28 Nov 1996 15:15:14 GMT Received: by fast.cs.utah.edu (8.6.10/utah-2.15-leaf) id IAA13282; Thu, 28 Nov 1996 08:15:13 -0700 Date: Thu, 28 Nov 1996 08:15:13 -0700 From: vanmaren@fast.cs.utah.edu (Kevin Van Maren) Message-Id: <199611281515.IAA13282@fast.cs.utah.edu> To: drussell@internode.net, smp@freebsd.org Subject: Re: P5 vs. P6 performance Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk While we are on the subject of CPUs... Can you do SMP with the Cyrix 6x86 chips? Later...... Short answer: No. Cyrix and AMD proposed a competing standard for SMP, called Open PIC. However, I talked to AMD folks at COMDEX, and they said that not only had they given up on Open PIC, but that they only care about the low end. He also mentioned that he thought that Cyrix was going to give up on Open PIC (this is good for us, as we won't have two competing specs to support), but it was unclear from the AMD guy if, and when, Cyrix would finally add an APIC compatable with Intel's (most likely have to license it). From owner-freebsd-smp Thu Nov 28 08:21:23 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA02053 for smp-outgoing; Thu, 28 Nov 1996 08:21:23 -0800 (PST) Received: from rocky.mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA02048 for ; Thu, 28 Nov 1996 08:21:20 -0800 (PST) Received: (from nate@localhost) by rocky.mt.sri.com (8.7.5/8.7.3) id JAA14714; Thu, 28 Nov 1996 09:20:45 -0700 (MST) Date: Thu, 28 Nov 1996 09:20:45 -0700 (MST) Message-Id: <199611281620.JAA14714@rocky.mt.sri.com> From: Nate Williams To: Peter Wemm Cc: Steve Passe , freebsd-smp@freebsd.org Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h In-Reply-To: <199611281318.VAA06295@spinner.DIALix.COM> References: <199611271914.MAA16047@clem.systemsix.com> <199611281318.VAA06295@spinner.DIALix.COM> Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Processors: APIC ID Version State Family Model Step Flags > > 0 0x11 BSP, usable 5 2 1 0x07bf > > 1 0x11 AP, usable 5 2 1 0x07bf > > ^^^ > > without problems (that I'm aware of). > > I think Step 6 was where they fixed the FPU divide bug.. (I saw a > reference to this on "The Ultimate Chip list" or something like that) Nope, I've got a Stepping 5 P100 chip here and it's work fine (been tested and everything). Nate From owner-freebsd-smp Thu Nov 28 10:14:22 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA07318 for smp-outgoing; Thu, 28 Nov 1996 10:14:22 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA07312 for ; Thu, 28 Nov 1996 10:14:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id LAA22385; Thu, 28 Nov 1996 11:14:07 -0700 Message-Id: <199611281814.LAA22385@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Doug Russell cc: smp@freebsd.org Subject: Re: P5 vs. P6 performance In-reply-to: Your message of "Thu, 28 Nov 1996 01:10:02 MST." <1.5.4.32.19961128081002.006798c0@internode.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Nov 1996 11:14:07 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > While we are on the subject of CPUs... Can you do SMP with the Cyrix 6x86 > chips? You can't do FreeBSD SMP with them. We follow the Intel MP spec, which they nicely tied to propietary Intel silicon. Specifically this means the APIC we've been talking so much about lately. AMD/Cyrix have a competing standard called "Open Apic", but I know of no boards using it at present. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Thu Nov 28 13:12:18 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA13470 for smp-outgoing; Thu, 28 Nov 1996 13:12:18 -0800 (PST) Received: from uruk.org (root@faustus.dev.com [198.145.95.253]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA13465 for ; Thu, 28 Nov 1996 13:12:13 -0800 (PST) Received: from uruk.org [127.0.0.1] (erich) by uruk.org with esmtp (Exim 0.53 #1) id E0vTDop-0002oO-00; Thu, 28 Nov 1996 13:16:27 -0800 To: Steve Passe cc: Terje.N.Marthinussen@cc.uit.no, smp@freebsd.org Subject: XXPRESS bus In-reply-to: Your message of "Wed, 27 Nov 1996 14:02:34 MST." <199611272102.OAA16661@clem.systemsix.com> Date: Thu, 28 Nov 1996 13:16:27 -0800 From: Erich Boleyn Message-Id: Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve Passe writes: > > >--- > > >> However then came: > > >> BIOS basemem (633K) != RTC basemem (640K), setting to BIOS value > > >> unknown bus type: 'XPRESS' > > >> > > >> Followed by panic... ... > > > > Well, I'm not really sure what the XPRESS bus is. I'm a bit new to these > > machines. I would suspect it to be the system bus? > > > > If so, I would suspect that the PCI busses and CPU cards are already on it? > > The only slots in it that is non pci/eisa are those that the CPU > > and memory cards are plugged into. > > the CPU/memory might be whats on the XXPRESS bus. > you have 2 PCI busses, as well as an EISA bus in addition to the XPRESS > bus: ... The XPRESS bus is basically the Pentium CPU/memory bus. There are many high-end (especially >2 CPU SMP) boxes with this bus explicitly supported to add expandability for RAM/CPU cards. The PCI and/or (E)ISA buses are bridged from the XPRESS bus. Note that although I've never seen a Pentium Pro that has it's CPU/memory bus explicitly listed in the MP Spec tables, they do all have a separate bus which the PCI and/or (E)ISA buses are bridged from. ...and yes, the Pentium Pro CPU/memory bus is totally different from the XPRESS bus. Actually, the (E)ISA bus is usually bridged from the PCI bus on the high-end boxes. -- Erich Stefan Boleyn \_ E-mail (preferred): Mad Genius wanna-be, CyberMuffin \__ (finger me for other stats) Web: http://www.uruk.org/~erich/ Motto: "I'll live forever or die trying" From owner-freebsd-smp Thu Nov 28 20:18:32 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA26760 for smp-outgoing; Thu, 28 Nov 1996 20:18:32 -0800 (PST) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA26753 for ; Thu, 28 Nov 1996 20:18:18 -0800 (PST) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.3/8.8.3) with ESMTP id MAA10448; Fri, 29 Nov 1996 12:17:04 +0800 (WST) Message-Id: <199611290417.MAA10448@spinner.DIALix.COM> X-Mailer: exmh version 1.6.9 8/22/96 To: vanmaren@fast.cs.utah.edu (Kevin Van Maren) cc: drussell@internode.net, smp@freebsd.org Subject: Re: P5 vs. P6 performance In-reply-to: Your message of "Thu, 28 Nov 1996 08:15:13 MST." <199611281515.IAA13282@fast.cs.utah.edu> Date: Fri, 29 Nov 1996 12:17:03 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Kevin Van Maren wrote: > > While we are on the subject of CPUs... Can you do SMP with the Cyrix 6 x86 > chips? > > Later...... > > Short answer: No. Cyrix and AMD proposed a competing standard for > SMP, called Open PIC. However, I talked to AMD folks at COMDEX, and > they said that not only had they given up on Open PIC, but that they > only care about the low end. He also mentioned that he thought that > Cyrix was going to give up on Open PIC (this is good for us, as we > won't have two competing specs to support), but it was unclear from > the AMD guy if, and when, Cyrix would finally add an APIC compatable > with Intel's (most likely have to license it). Well, as I understand it, the APIC "invention" is patented to the hilt which pretty much precludes cloning of it without licenses. I've read the OpenPIC stuff, at least superficially, and it looks like it wouldn't be all that much hard work to use it, but it's definately something that we don't need to deal with right now. Considering that the APIC design at present is partly in the CPU and partly on the motherboard, and I'm not aware of *any* motherboards with an OpenPIC interrupt system in them, I'm skeptical of whether it's even worth worrying about right now. However, that doesn't mean the situation won't change in the future. I certainly won't be doing anything that's going to prevent any chance of support for it being written. Having said that, we're discovering the magnitude of the difficulties that we're facing in the kernel proper, even after we've got the low-level stuff sorted out. It's starting to look pretty much like the lower layers (APIC, OpenPIC etc) are going to be a small fraction of the work that's needed in the big picture. Cheers, -Peter From owner-freebsd-smp Thu Nov 28 20:22:29 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA26838 for smp-outgoing; Thu, 28 Nov 1996 20:22:29 -0800 (PST) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA26830 for ; Thu, 28 Nov 1996 20:22:16 -0800 (PST) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.3/8.8.3) with ESMTP id MAA10484; Fri, 29 Nov 1996 12:21:04 +0800 (WST) Message-Id: <199611290421.MAA10484@spinner.DIALix.COM> X-Mailer: exmh version 1.6.9 8/22/96 To: Nate Williams cc: Steve Passe , freebsd-smp@freebsd.org Subject: Re: cvs commit: sys/i386/i386 locore.s swtch.s sys/i386/include pmap.h In-reply-to: Your message of "Thu, 28 Nov 1996 09:20:45 MST." <199611281620.JAA14714@rocky.mt.sri.com> Date: Fri, 29 Nov 1996 12:21:04 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Nate Williams wrote: > > > Processors: APIC ID Version State Family Model Step Fla gs > > > 0 0x11 BSP, usable 5 2 1 0x 07bf > > > 1 0x11 AP, usable 5 2 1 0x 07bf > > > ^^^ > > > without problems (that I'm aware of). > > > > I think Step 6 was where they fixed the FPU divide bug.. (I saw a > > reference to this on "The Ultimate Chip list" or something like that) > > Nope, I've got a Stepping 5 P100 chip here and it's work fine (been > tested and everything). Well, that's what I suspected too. I had only seen step 1, 5 and much higher. I wondered if there was a mistake in the list and in fact it was step 5 that fixes it. (I have P5-90 Step 1 cpus btw) BTW, does anybody have the code to test for the fdiv bug? I looked in the linux kernel to see what it tests (since the fdiv bug is listed in /proc/cpuinfo), and discovered that the linux (2.0.x last time I looked) kernel doesn't even test it!! it simply sets the value to "no". What a crock! (.. unless I missed the test..) > Nate Cheers, -Peter From owner-freebsd-smp Fri Nov 29 04:13:28 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA15255 for smp-outgoing; Fri, 29 Nov 1996 04:13:28 -0800 (PST) Received: from ceylon.informatik.uni-rostock.de (ceylon.informatik.uni-rostock.de [139.30.5.237]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA15244 for ; Fri, 29 Nov 1996 04:13:17 -0800 (PST) Received: by ceylon.informatik.uni-rostock.de id NAA25866; Fri, 29 Nov 1996 13:12:46 +0100 Received: by donau.informatik.uni-rostock.de id NAA27254; Fri, 29 Nov 1996 13:12:45 +0100 (MET) Date: Fri, 29 Nov 1996 13:12:45 +0100 (MET) From: Gunther Hipper Message-Id: <199611291212.NAA27254@donau.informatik.uni-rostock.de> To: freebsd-smp@FreeBSD.org Subject: Problems: includes / segmentation faults / latest SMP-kernel doesn't boot X-Sun-Charset: US-ASCII Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi all ! Now - i (less) successfully got an SMP kernel up and running. Board is Gigabyte DX, the relevant kernel configuration as follows: options SMP # Symmetric MultiProcessor Kernel #options APIC_IO # Symmetric (APIC) I/O options NCPU=2 # number of CPUs options NBUS=2 # number of busses options NAPIC=1 # number of IO APICs options NINTR=21 # number of INTs The first thing: When i did "make most; make installmost; cd /usr/src/sys-SMP/compile/SMP", i had to make links/copies of the opt_smp.h. i used the following commands: cp /usr/src/sys-SMP/compile/SMP/opt_smp.h /usr/src/sys/sys cp /usr/src/sys-SMP/compile/SMP/opt_smp.h /usr/src/sys/i386/isa cp /usr/src/sys-SMP/compile/SMP/opt_smp.h /usr/include/machine cp /usr/src/sys-SMP/compile/SMP/opt_smp.h /usr/include Is this a fault in the configuration of my includes or is it not my fault ? There seem to be lots of "opt_smp.h" and .... Shouldn't these be all ? If not, how about putting some copy/link sequence in the /usr/sbin/config SMP ? The second (and mayor) problem: I started last week on a config-file without turning APIC_IO on. The problem in this case was that a reboot or halt just got a segmentation fault, as other commands (i think also ls, ps). The following from /var/log/messages: Nov 27 19:48:39 fcna1 /kernel: pid 1478 (reboot), uid 0: exited on signal 10 (core dumped) Nov 27 19:48:45 fcna1 /kernel: pid 1479 (ls), uid 0: exited on signal 11 (core dumped) Nov 27 19:48:57 fcna1 /kernel: pid 1485 (hostname), uid 0: exited on signal 8 (core dumped) ps, reboot - okay that's mainly kernel-dependent stuff. But i started wondering why ls didn't work. The whole binaries were built of the CVS set (with the sys/sys-includes etc. from the smp set of src-sys). When i turned on APIC_IO, the kernel came up booting, i got the SMP: messages. But the kernel stopped after telling that APIC successfully turned on ... What could be the reason for this ?? The third (and the BIGGEST) problem: I just supped the lastest version of the kernel and compiled it. Conf is the same as metioned in the beginning. Now i get the following messages (last from file kern/init_main.c, smp_idleloop(): SMP: Idle procs online, starting an AP ! AP CPU #1 Launched ! Starting Scheduling ... TADA! CPU#1 made it into the scheduler and the final one is SMP: All 2 CPU's are online! And that's it - no more booting......... please help. Give me hints, what could i do to find out a bit more. It's probably not a fault in smp_idleloop(), where else ? Could it be an idle SCSI controller (IRQ problem) .. ? The SMP-kernel before worked well (only the segmentation faults). Bye Gunther Gunther Hipper | University of Rostock | Department of Computer Science | Tel +49 381 498 3391 Albert-Einstein-Str. 21 | Fax +49 381 498 3440 18051 Rostock - Germany | Email Gunther.Hipper@informatik.uni-rostock.de From owner-freebsd-smp Fri Nov 29 08:43:16 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA23880 for smp-outgoing; Fri, 29 Nov 1996 08:43:16 -0800 (PST) Received: from uruk.org (root@faustus.dev.com [198.145.95.253]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA23875 for ; Fri, 29 Nov 1996 08:43:11 -0800 (PST) Received: from uruk.org [127.0.0.1] (erich) by uruk.org with esmtp (Exim 0.53 #1) id E0vTW5b-000543-00; Fri, 29 Nov 1996 08:46:59 -0800 To: Peter Wemm , Nate Williams cc: Steve Passe , freebsd-smp@freebsd.org Subject: Pentium CPU steppings In-reply-to: Your message of "Fri, 29 Nov 1996 12:21:04 +0800." <199611290421.MAA10484@spinner.DIALix.COM> Date: Fri, 29 Nov 1996 08:46:59 -0800 From: Erich Boleyn Message-Id: Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Peter Wemm writes: > Nate Williams wrote: > > > > Processors: APIC ID Version State Family Model Step Fla > gs > > > > 0 0x11 BSP, usable 5 2 1 0x > 07bf > > > > 1 0x11 AP, usable 5 2 1 0x > 07bf > > > > ^^^ > > > > without problems (that I'm aware of). > > > > > > I think Step 6 was where they fixed the FPU divide bug.. (I saw a > > > reference to this on "The Ultimate Chip list" or something like that) > > > > Nope, I've got a Stepping 5 P100 chip here and it's work fine (been > > tested and everything). > > Well, that's what I suspected too. I had only seen step 1, 5 and much > higher. I wondered if there was a mistake in the list and in fact it was > step 5 that fixes it. (I have P5-90 Step 1 cpus btw) Uh... you can't just look at the "step" number. The "model" number is also quite relevant. The "family" is the chip design (386, 486, Pentium, etc.), the "model" is the major revision, and the "step" is the stepping. The 3 numbers are pretty much strictly ordered for severity of changes. The fdiv bug occurs in model 1 chips with stepping less then 6 (I think, don't quote me). A higher stepping in the same model, or any higher model with any stepping is fixed. -- Erich Stefan Boleyn \_ E-mail (preferred): Mad Genius wanna-be, CyberMuffin \__ (finger me for other stats) Web: http://www.uruk.org/~erich/ Motto: "I'll live forever or die trying" From owner-freebsd-smp Fri Nov 29 09:43:33 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA25515 for smp-outgoing; Fri, 29 Nov 1996 09:43:33 -0800 (PST) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA25509 for ; Fri, 29 Nov 1996 09:43:25 -0800 (PST) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.3/8.8.3) with ESMTP id BAA19182; Sat, 30 Nov 1996 01:42:01 +0800 (WST) Message-Id: <199611291742.BAA19182@spinner.DIALix.COM> X-Mailer: exmh version 1.6.9 8/22/96 To: Erich Boleyn cc: Nate Williams , Steve Passe , freebsd-smp@freebsd.org Subject: Re: Pentium CPU steppings In-reply-to: Your message of "Fri, 29 Nov 1996 08:46:59 PST." Date: Sat, 30 Nov 1996 01:42:00 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Erich Boleyn wrote: > Uh... you can't just look at the "step" number. The "model" number is > also quite relevant. The "family" is the chip design (386, 486, Pentium, > etc.), the "model" is the major revision, and the "step" is the stepping. > The 3 numbers are pretty much strictly ordered for severity of changes. Ahh yes, sorry, I'd forgotten about this since it's been a while since I've seen anything other 5/2/x. > The fdiv bug occurs in model 1 chips with stepping less then 6 (I think, > don't quote me). A higher stepping in the same model, or any higher model > with any stepping is fixed. Hmm, weren't both the P5-60/66 and the early P5-90's affected? I was under the impression that model "1" of the "5" family was the 5V non-clock-multiplied 60/66Mhz Pentiums? And model "2" was the improved 3.3V design with the clock multiplication and the on-chip local APIC? Anyway, according to this C version of the Intel test assembler code, 0x521 (P5-90 in my case) has the bug: /* be sure to disable optimisation when compiling, eg: gcc -O0 ... */ main() { double x = 4195835.0; double y = 3145727.0; double result = (x - (x / y) * y); printf("x = %f, y = %f, result = %f, FDIV %s\n", x, y, result, result < 1.0 ? "OK" : "BUG PRESENT"); } peter@spinner[1:34am]~/fdiv-128> ./chk x = 4195835.000000, y = 3145727.000000, result = 256.000000, FDIV BUG PRESENT peter@spinner[1:34am]~/fdiv-130> dmesg | grep Step Origin = "GenuineIntel" Id = 0x521 Stepping=1 And on a newer P5-100 cpu: peter@curie[4:35am]~-108> cc -O0 -o chk chk.c peter@curie[4:35am]~-109> ./chk x = 4195835.000000, y = 3145727.000000, result = 0.000000, FDIV OK peter@curie[4:35am]~-110> dmesg | grep Step Origin = "GenuineIntel" Id = 0x525 Stepping=5 Grumble.. It looks like the low steppings of "model 2" have it as well. Damn.. Hmm, I wonder if it's safe to test for this at the end of npx.c in the kernel? Cheers, -Peter From owner-freebsd-smp Fri Nov 29 09:52:20 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA25774 for smp-outgoing; Fri, 29 Nov 1996 09:52:20 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA25769 for ; Fri, 29 Nov 1996 09:52:18 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0vTX68-0003vvC; Fri, 29 Nov 96 09:51 PST Received: from critter.tfs.com (localhost.dk.tfs.com [127.0.0.1]) by critter.tfs.com (8.8.2/8.8.2) with ESMTP id SAA02944; Fri, 29 Nov 1996 18:52:45 +0100 (MET) To: Peter Wemm cc: Erich Boleyn , Nate Williams , Steve Passe , freebsd-smp@freebsd.org Subject: Re: Pentium CPU steppings In-reply-to: Your message of "Sat, 30 Nov 1996 01:42:00 +0800." <199611291742.BAA19182@spinner.DIALix.COM> Date: Fri, 29 Nov 1996 18:52:44 +0100 Message-ID: <2942.849289964@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199611291742.BAA19182@spinner.DIALix.COM>, Peter Wemm writes: > >peter@spinner[1:34am]~/fdiv-128> ./chk >x = 4195835.000000, y = 3145727.000000, result = 256.000000, FDIV BUG >PRESENT >peter@spinner[1:34am]~/fdiv-130> dmesg | grep Step > Origin = "GenuineIntel" Id = 0x521 Stepping=1 Well, call intel and get a new :-) >Hmm, I wonder if it's safe to test for this at the end of npx.c in the >kernel? Linux can do it, so why couldn't we ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-smp Fri Nov 29 10:15:30 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA26677 for smp-outgoing; Fri, 29 Nov 1996 10:15:30 -0800 (PST) Received: from ceylon.informatik.uni-rostock.de (ceylon.informatik.uni-rostock.de [139.30.5.237]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA26672 for ; Fri, 29 Nov 1996 10:15:23 -0800 (PST) Received: by ceylon.informatik.uni-rostock.de id TAA27383; Fri, 29 Nov 1996 19:15:19 +0100 Received: by donau.informatik.uni-rostock.de id TAA00445; Fri, 29 Nov 1996 19:15:18 +0100 (MET) Date: Fri, 29 Nov 1996 19:15:18 +0100 (MET) From: Gunther Hipper Message-Id: <199611291815.TAA00445@donau.informatik.uni-rostock.de> To: freebsd-smp@freebsd.org Subject: PING - IS MY MAIL BROKEN ?!?! X-Sun-Charset: US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ignore this one :-( just testing whether freebsd.org ignores my mails From owner-freebsd-smp Fri Nov 29 10:21:03 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA26957 for smp-outgoing; Fri, 29 Nov 1996 10:21:03 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA26949 for ; Fri, 29 Nov 1996 10:21:01 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0vTXY5-0003vyC; Fri, 29 Nov 96 10:20 PST Received: from critter.tfs.com (localhost.dk.tfs.com [127.0.0.1]) by critter.tfs.com (8.8.2/8.8.2) with ESMTP id TAA03012; Fri, 29 Nov 1996 19:21:46 +0100 (MET) To: Gunther Hipper cc: freebsd-smp@freebsd.org Subject: Re: PING - IS MY MAIL BROKEN ?!?! In-reply-to: Your message of "Fri, 29 Nov 1996 19:15:18 +0100." <199611291815.TAA00445@donau.informatik.uni-rostock.de> Date: Fri, 29 Nov 1996 19:21:45 +0100 Message-ID: <3010.849291705@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199611291815.TAA00445@donau.informatik.uni-rostock.de>, Gunther Hip per writes: >ignore this one :-( >just testing whether freebsd.org ignores my mails it is. :-) -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-smp Fri Nov 29 10:28:15 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA27209 for smp-outgoing; Fri, 29 Nov 1996 10:28:15 -0800 (PST) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA27204 for ; Fri, 29 Nov 1996 10:28:10 -0800 (PST) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.3/8.8.3) with ESMTP id CAA19491; Sat, 30 Nov 1996 02:28:01 +0800 (WST) Message-Id: <199611291828.CAA19491@spinner.DIALix.COM> X-Mailer: exmh version 1.6.9 8/22/96 To: Poul-Henning Kamp cc: freebsd-smp@freebsd.org Subject: Re: Pentium CPU steppings In-reply-to: Your message of "Fri, 29 Nov 1996 18:52:44 +0100." <2942.849289964@critter.tfs.com> Date: Sat, 30 Nov 1996 02:28:01 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Poul-Henning Kamp wrote: > >Hmm, I wonder if it's safe to test for this at the end of npx.c in the > >kernel? > > Linux can do it, so why couldn't we ? Yeah, but have you ever seen it report "yes"? Last I checked, (2.0.twenty something), the code looked very much like it hardwired the "fdiv bug present?" result to "no" and I could not find any code in the kernel that actually tested for the bug. (That's not to say that there isn't, but the only references to the variable that my grep turned up were the default initialisation and the printing of the (bogus) result.) Cheers, -Peter From owner-freebsd-smp Fri Nov 29 10:35:21 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA27429 for smp-outgoing; Fri, 29 Nov 1996 10:35:21 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA27422 for ; Fri, 29 Nov 1996 10:35:18 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0vTXlu-0003w6C; Fri, 29 Nov 96 10:34 PST Received: from critter.tfs.com (localhost.dk.tfs.com [127.0.0.1]) by critter.tfs.com (8.8.2/8.8.2) with ESMTP id TAA03059; Fri, 29 Nov 1996 19:36:03 +0100 (MET) To: Peter Wemm cc: freebsd-smp@freebsd.org Subject: Re: Pentium CPU steppings In-reply-to: Your message of "Sat, 30 Nov 1996 02:28:01 +0800." <199611291828.CAA19491@spinner.DIALix.COM> Date: Fri, 29 Nov 1996 19:36:03 +0100 Message-ID: <3057.849292563@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199611291828.CAA19491@spinner.DIALix.COM>, Peter Wemm writes: >Poul-Henning Kamp wrote: >> >Hmm, I wonder if it's safe to test for this at the end of npx.c in the >> >kernel? >> >> Linux can do it, so why couldn't we ? > >Yeah, but have you ever seen it report "yes"? Last I checked, (2.0.twenty >something), the code looked very much like it hardwired the "fdiv bug >present?" result to "no" and I could not find any code in the kernel that yes, they circumvent it, I belive in their compiler :-) -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-smp Fri Nov 29 11:16:09 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA00912 for smp-outgoing; Fri, 29 Nov 1996 11:16:09 -0800 (PST) Received: from ceylon.informatik.uni-rostock.de (ceylon.informatik.uni-rostock.de [139.30.5.237]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA00907 for ; Fri, 29 Nov 1996 11:16:06 -0800 (PST) Received: by ceylon.informatik.uni-rostock.de id UAA27942; Fri, 29 Nov 1996 20:15:56 +0100 Received: by donau.informatik.uni-rostock.de id UAA00453; Fri, 29 Nov 1996 20:15:50 +0100 (MET) Date: Fri, 29 Nov 1996 20:15:50 +0100 (MET) From: Gunther Hipper Message-Id: <199611291915.UAA00453@donau.informatik.uni-rostock.de> To: freebsd-smp@freebsd.org Subject: Re: Problems: includes / segmentation faults / latest SMP-kernel doesn't boot Cc: smp@csn.net X-Sun-Charset: US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi ! As my last mail reached the list i suppose the two before didn't. So: >> The first thing: >> When i did "make most; make installmost; cd /usr/src/sys-SMP/compile/SMP", >> i had to make links/copies of the opt_smp.h. >> i used the following commands: >> cp /usr/src/sys-SMP/compile/SMP/opt_smp.h /usr/src/sys/sys >> cp /usr/src/sys-SMP/compile/SMP/opt_smp.h /usr/src/sys/i386/isa >> cp /usr/src/sys-SMP/compile/SMP/opt_smp.h /usr/include/machine >> cp /usr/src/sys-SMP/compile/SMP/opt_smp.h /usr/include >> Is this a fault in the configuration of my includes or is it not my >I assumme you were in /usr/src when doing "make most"? This probably broke >the opt.smp file. after making things outside /usr/src/sys-SMP >you will probably need to go to sys-SMP/i386/conf and config file> before attempting to build the SMP kernel. this will create opt_smp.h >and place it in the correct directiries. You were right - my configuration was wrong. dunno exactly what was wrong. >> fault ? There seem to be lots of "opt_smp.h" and .... >> Shouldn't these be all ? >they probably should all be one or the other, but I'm not sure which... You were right - everything is gone, compiling is just fine >> The third (and the BIGGEST) problem: >> I just supped the lastest version of the kernel and compiled it. >> Conf is the same as metioned in the beginning. >> Now i get the following messages (last from file kern/init_main.c, smp_idleloop(): >> SMP: Idle procs online, starting an AP ! >> AP CPU #1 Launched ! Starting Scheduling ... >> TADA! CPU#1 made it into the scheduler >> and the final one is >> SMP: All 2 CPU's are online! >> >> And that's it - no more booting......... please help. Give me hints, >> what could i do to find out a bit more. >> It's probably not a fault in smp_idleloop(), where else ? >> Could it be an idle SCSI controller (IRQ problem) .. ? >this is biting about 50% of the testers right now. Since we have very similar >hardware and I don't have this problem it is an excellant opportunity for >us to figure out why. After I look at your config file and mptable output >I will get back in touch with a suggested plan of attack, I'm sorry (or better i really don't know what to say), but this problem is gone. Maybe it was caused by my wrong configuration or making... could this be ? I tried to get this error again, but it seems to be gone. Or is there some connection to the one which i actually have right now (please, don't be bothered).. There is another problem concerning the root-filesystem: panic(cpu#0): nobody wants to mount my root I stopped over in configure(), autoconf.c but couldn't find out why its not mounted...still trying. Hope i can solve this on myself. If not, i'll have to ask tomorrow. Anyway - hereafter is the output of mptable 2.0.4 as requested. Bye Gunther =============================================================================== MPTable, version 2.0.4 looking for EBDA pointer @ 0x040e, NOT found searching CMOS 'top of mem' @ 0x0009fc00 (639K) searching BIOS @ 0x000f0000 MP FPS found in BIOS @ physical addr: 0x000f0c80 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000f0c80 signature: '_MP_' length: 16 bytes version: 1.1 checksum: 0xf4 mode: Virtual Wire ------------------------------------------------------------------------------- MP Config Table Header: physical address: 0x000f0c94 signature: 'PCMP' base table length: 292 version: 1.1 checksum: 0x31 OEM ID: 'OEM00000' Product ID: 'PROD00000000' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 28 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 0 0x11 BSP, usable 5 2 1 0x07bf 1 0x11 AP, usable 5 2 1 0x07bf -- Bus: Bus ID Type 0 ISA 1 PCI -- I/O APICs: APIC ID Version State Address 2 0x11 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ExtINT conforms conforms 0 0 2 0 INT conforms conforms 0 1 2 1 INT conforms conforms 0 0 2 2 INT conforms conforms 0 3 2 3 INT conforms conforms 0 4 2 4 INT conforms conforms 0 5 2 5 INT conforms conforms 0 6 2 6 INT conforms conforms 0 7 2 7 INT conforms conforms 0 8 2 8 INT conforms conforms 0 9 2 9 INT conforms conforms 0 10 2 10 INT conforms conforms 0 11 2 11 INT conforms conforms 0 12 2 12 INT conforms conforms 0 13 2 13 INT conforms conforms 0 14 2 14 INT conforms conforms 0 15 2 15 INT active-lo level 1 8:A 2 16 INT active-lo level 1 9:A 2 17 INT active-lo level 1 10:A 2 18 INT active-lo level 1 12:A 2 19 SMI conforms conforms 0 0 2 23 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ExtINT active-hi edge 0 0 255 0 NMI active-hi edge 0 0 255 1 ------------------------------------------------------------------------------- dmesg output: FreeBSD 2.2-961014-SNAP #22: Sun Nov 17 16:03:37 1996 root@fcna1.informatik.uni-rostock.de:/usr/src/sys/compile/GENERIC_FCNA Calibrating clock(s) relative to mc146818A clock... i586 clock: 150376665 Hz, i8254 clock: 1193468 Hz CPU: Pentium (150.34-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping=12 Features=0x3bf real memory = 33554432 (32768K bytes) avail memory = 30720000 (30000K bytes) Probing for devices on PCI bus 0: chip0 rev 1 on pci0:0 chip1 rev 1 on pci0:7:0 chip2 rev 0 on pci0:7:1 vga0 rev 227 int a irq 11 on pci0:8 chip3 rev 2 on pci0:10 ahc0 rev 0 int a irq 9 on pci0:12 ahc0: aic7880 Unsupported adapter type. Ignoring Probing for devices on PCI bus 1: de0 rev 32 int a irq 10 on pci1:4 **** This is an EM400 Master **** **** EM400 Master returning 0 de0: enabling 100baseTX port de0: Cogent EM400 MS DC21140A [10-100Mb/s] pass 2.0 de0: address 00:00:92:95:16:b8 Hi from tulip_dc21140_cogent_em100_media_probe() de1 rev 32 int a irq 9 on pci1:5 **** This is an EM400 Slave **** root_unit 0 set hwaddr..set boardsw.. de1: enabling 100baseTX port de1: Cogent EM400 SL DC21140A [10-100Mb/s] pass 2.0 de1: address 00:00:92:95:16:b9 Hi from tulip_dc21140_cogent_em100_media_probe() de2 rev 32 int a irq 11 on pci1:6 **** This is an EM400 Slave **** root_unit 1 0 set hwaddr..set boardsw.. de2: enabling 100baseTX port de2: Cogent EM400 SL DC21140A [10-100Mb/s] pass 2.0 de2: address 00:00:92:95:16:ba Hi from tulip_dc21140_cogent_em100_media_probe() de3 rev 32 int a irq 7 on pci1:7 **** This is an EM400 Slave **** root_unit 2 1 0 set hwaddr..set boardsw.. de3: enabling 100baseTX port de3: Cogent EM400 SL DC21140A [10-100Mb/s] pass 2.0 de3: address 00:00:92:95:16:bb Hi from tulip_dc21140_cogent_em100_media_probe() Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> ed0 at 0x300-0x31f irq 5 on isa ed0: address 00:40:05:32:cb:aa, type NE2000 (16 bit) fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 2015MB (4127760 sectors), 4095 cyls, 16 heads, 63 S/T, 512 B/S npx0 on motherboard npx0: INT 16 interface ------------------------------------------------------------------------------- # SMP kernel config file options: options SMP # Symmetric MultiProcessor Kernel #options APIC_IO # Symmetric (APIC) I/O options NCPU=2 # number of CPUs options NBUS=2 # number of busses options NAPIC=1 # number of IO APICs options NINTR=21 # number of INTs =============================================================================== From owner-freebsd-smp Fri Nov 29 11:36:35 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA01825 for smp-outgoing; Fri, 29 Nov 1996 11:36:35 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA01818 for ; Fri, 29 Nov 1996 11:36:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id MAA29466; Fri, 29 Nov 1996 12:35:25 -0700 Message-Id: <199611291935.MAA29466@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Peter Wemm cc: Erich Boleyn , Nate Williams , Steve Passe , freebsd-smp@freebsd.org Subject: Re: Pentium CPU steppings In-reply-to: Your message of "Sat, 30 Nov 1996 01:42:00 +0800." <199611291742.BAA19182@spinner.DIALix.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Nov 1996 12:35:24 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, different P5s I have: --- 1: FreeBSD 2.1.0-RELEASE #9: Wed Aug 14 20:42:01 MDT 1996 CPU: 86-MHz Pentium 735\\90 or 815\\100 (Pentium-class CPU) Origin = "GenuineIntel" Id = 0x521 Stepping=1 >>> Features=0x1bf $ fdiv x = 4195835.000000, y = 3145727.000000, result = 256.000000, FDIV BUG PRESENT --- 2: FreeBSD 2.1.5-RELEASE #0: Thu Jul 25 21:17:19 MDT 1996 CPU: 133-MHz Pentium 735\\90 or 815\\100 (Pentium-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping=12 >>> Features=0x1bf $ fdiv x = 4195835.000000, y = 3145727.000000, result = 0.000000, FDIV OK --- 3: FreeBSD 3.0-SMP #0: Fri Nov 29 10:03:58 MST 1996 CPU: Pentium (586-class CPU) Origin = "GenuineIntel" Id = 0x52c Stepping=12 Features=0x3bf 3 % fdiv x = 4195835.000000, y = 3145727.000000, result = 0.000000, FDIV OK Processors: APIC ID Version State Family Model Step Flags 0 0x11 BSP, usable 5 2 1 0x07bf 1 0x11 AP, usable 5 2 1 0x07bf --- note that both 1 & 2 have a feature value of 1bf, neither of which have the APIC bit set (bit #9). 2.1.0 claims the 90mHz chip has an APIC, which I didn't expect, while 2.1.5 claims it doesn't have an APIC, which is consistant with 1bf. However this is a fairly new chip so I think it really does have an APIC. also note that the kernel says stepping 12 for #3, but mptable always says stepping 1. I previously said that I think certain MP BIOS report a BAD value for the CPU APIC version number, I now add CPU stepping as reported by some MP BIOS (and thus mptable) as being suspect. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Fri Nov 29 11:42:04 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA02017 for smp-outgoing; Fri, 29 Nov 1996 11:42:04 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id LAA02011 for ; Fri, 29 Nov 1996 11:42:03 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0vTYoQ-0003vvC; Fri, 29 Nov 96 11:41 PST Received: from critter.tfs.com (localhost.dk.tfs.com [127.0.0.1]) by critter.tfs.com (8.8.2/8.8.2) with ESMTP id UAA03228; Fri, 29 Nov 1996 20:42:42 +0100 (MET) To: Steve Passe cc: Peter Wemm , Erich Boleyn , Nate Williams , freebsd-smp@freebsd.org Subject: Re: Pentium CPU steppings In-reply-to: Your message of "Fri, 29 Nov 1996 12:35:24 MST." <199611291935.MAA29466@clem.systemsix.com> Date: Fri, 29 Nov 1996 20:42:41 +0100 Message-ID: <3226.849296561@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >--- >note that both 1 & 2 have a feature value of 1bf, neither >of which have the APIC bit set (bit #9). 2.1.0 claims the >90mHz chip has an APIC, which I didn't expect, while 2.1.5 >claims it doesn't have an APIC, which is consistant with 1bf. 2.1.0 was bogus. Somebody tried to use %b without using too much time on the task. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-smp Fri Nov 29 13:02:20 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA06815 for smp-outgoing; Fri, 29 Nov 1996 13:02:20 -0800 (PST) Received: from ceylon.informatik.uni-rostock.de (ceylon.informatik.uni-rostock.de [139.30.5.237]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA06809 for ; Fri, 29 Nov 1996 13:02:12 -0800 (PST) Received: by ceylon.informatik.uni-rostock.de id WAA28144; Fri, 29 Nov 1996 22:02:03 +0100 Received: by donau.informatik.uni-rostock.de id WAA00506; Fri, 29 Nov 1996 22:02:01 +0100 (MET) Date: Fri, 29 Nov 1996 22:02:01 +0100 (MET) From: Gunther Hipper Message-Id: <199611292102.WAA00506@donau.informatik.uni-rostock.de> To: freebsd-smp@freebsd.org Subject: Re: Problems: includes / segmentation faults / latest SMP-kernel doesn't boot Cc: gunther@ceylon.informatik.uni-rostock.de X-Sun-Charset: US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi again ! > most likely it was the wrong configuration, but it might also be the clue we > are looking for. Have cvsupped -current recently, ie AFTER 96-11-21? > This was the date of the last merge of SMP with -current. Sometimes > changes in current AFTER such a merge break the SMP kernel's ability > to run on the NEWER -current system. I cvssupped the whole cvs-tree (not current !) after 96-11-21 from cvsup.nl.freebsd.org. Then, I made most, installmost. Hereafter, I moved /usr/src/sys to /usr/src/sys-UP and supped the sys-smp-tree. Then, cvs -d dontcare chekcout sys. Moved sys to /usr/src/sys-SMP. If the cvs-tree is okay, there should be no error... > what does "ls -alt /sys" say? lrwxr-xr-x 1 root wheel 11 Nov 29 20:57 /sys -> usr/src/sys and then, /usr/src/sys is linked to /usr/src/sys-SMP, exactly the way you suggested :) > > There is another problem concerning the root-filesystem: > > > > panic(cpu#0): nobody wants to mount my root > > > > I stopped over in configure(), autoconf.c but couldn't find out why > > its not mounted...still trying. Hope i can solve this on myself. > > I'm a little confused by this... I thought I understood you to say > above that you were no longer hanging after the: > SMP: All 2 CPU's are online! > > line. > > The attempt to mount the root fs comes before this point, booting with > the '-v' option I get: > > ... > Device configuration finished. > Considering FFS root f/s. > ^^^^^^^^^^^^^^^^^^^^^^^^ > configure() finished. > ^^^^^^^^^^^^^^^^^^^^^ > Enabled INTs: 1, 2, 3, 4, 6, 7, 8, 10, 16, 19, imen: 0x00f6fa21 > sd0s1: type 0xa5, start 32, end = 3450879, size 3450848 : OK > SMP: Idle procs online, starting an AP! > SMP: AP CPU #1 LAUNCHED!! Starting Scheduling... > SMP: TADA! CPU #1 made it into the scheduler!. > SMP: All 2 CPU's are online! > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > I must be missing something??? I'm sorry... when I started working again after I send the email I remembered that the errors could be caused by my (deaf and dumb) Makefile which copies opt_smp.h somewhere. Therefore, i cleaned it up and compiled again. Then, the hang was gone and the following panic occurred: imasks: bio c0004040 tty f0000002 net e0000420 panic(cpu#0): Nobody wants to mount my root for me I thought, the panic concerning the filesystem is not so severe, I wanted to try to get after it. Maybe, if this is away, the kernel hangs again up at the old place. Furthermore, I tried out to remove the NBUS, NCPU, APIC_IO, NAPIC, NINTR and just left the options line SMP in the config file. The result is: imasks: bio c0004040 tty c0030002 net c0020420 Device configuration finished panic(cpu#0): Nobody wants to mount my root for me > If you consistantly get the root fs mount panic I think itmight be time > for you to boot a non-SMP kernel and fsck all your disks. > Then run config/make depend/make/make install for your SMP kernel, > then retry it. I only have a single FreeBSD machine, so to compile I have to reboot and to try I have to reboot again.... It's not a filesystem problem, I even made an fsck /dev/rwd0a rigth now. Maybe I should try to start scratch with rm -rf /usr/src/*, grab the -current instead of -cvs, make most, installmost, grab the smp-sys and see what happens. What would you suggest ? Bye Gunther Gunther Hipper | University of Rostock | Department of Computer Science | Tel +49 381 498 3391 Albert-Einstein-Str. 21 | Fax +49 381 498 3440 18051 Rostock - Germany | Email Gunther.Hipper@informatik.uni-rostock.de From owner-freebsd-smp Fri Nov 29 13:17:36 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA07394 for smp-outgoing; Fri, 29 Nov 1996 13:17:36 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA07388 for ; Fri, 29 Nov 1996 13:17:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id OAA29993 for ; Fri, 29 Nov 1996 14:17:26 -0700 Message-Id: <199611292117.OAA29993@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: freebsd-smp@freebsd.org Subject: SMP-current hang problems. In-reply-to: Your message of "Fri, 29 Nov 1996 20:15:50 +0100." <199611291915.UAA00453@donau.informatik.uni-rostock.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Nov 1996 14:17:26 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, we have decided to more or less freeze development till we figure out the "system hang" problem with the latest code. If you have one of the systems that hangs anywhere in the area of: SMP: Idle procs online, starting an AP! SMP: AP CPU #1 LAUNCHED!! Starting Scheduling... SMP: TADA! CPU #1 made it into the scheduler!. SMP: All 2 CPU's are online! we need to here from you ASAP: have you updated any of your -current tree (ie, the non SMP src/sys part) since 96-11-21? (This is the date that SMP was merged with -current) what does "ls -alt /sys" show? try enabling the kernel debugger and see if you can get to it via CONTROL-ALT-ESCAPE when in the hung state. To use the debugger add: options DDB to your kernel config file. "man ddb" for usage. If you can get from the hung state to ddb, do a trace and/or 'ps'. If you have another system or terminal available you could use this idea from Peter: - try using "options FORCE_COMCONSOLE" and use a 9600 baud serial link on com1, if it's an interrupt problem affecting syscons, it might make sense to try getting syscons out of the picture entirely for a test. Also, "options BREAK_TO_DEBUGGER" is useful, you can send a break and get a DDB prompt on the com port (with comconsole enabled). Note: I (smp) think "options FORCE_COMCONSOLE" should be "options COMCONSOLE", add both to be sure. --- I'm about to change the locking on mpboot.s a little, I'll post it as soon as I prove it works here... -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Fri Nov 29 15:48:19 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA13771 for smp-outgoing; Fri, 29 Nov 1996 15:48:19 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA13766 for ; Fri, 29 Nov 1996 15:48:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id QAA00819 for ; Fri, 29 Nov 1996 16:48:13 -0700 Message-Id: <199611292348.QAA00819@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: freebsd-smp@freebsd.org Subject: Re: SMP-current hang problems. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Nov 1996 16:48:13 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, here's the patch I promised for i386/i386/mpboot.s. It doesn't break anything on my system, but since mine works already I can't promise it will help anything either. let me know what it does... -------------------------------------- cut ------------------------------------ *** mpboot.s~ Fri Nov 29 15:52:31 1996 --- mpboot.s Fri Nov 29 16:19:37 1996 *************** *** 63,68 **** --- 63,78 ---- * Wait for the booting CPU to signal startup */ mp_begin: /* now running relocated at KERNBASE */ + movl _apic_base, %esi + + movl APIC_SVR(%esi), %eax /* get spurious vector reg. */ + andl $~0x00000100, %eax /* disable the APIC */ + movl %eax, APIC_SVR(%esi) + + movl APIC_VER(%esi), %eax + movl %eax, _cpuApicVersions + incl _mp_ncpus + /* One at a time, we are running on the shared mp_stk */ /* This is the Intel reccomended semaphore method */ movb $0xff, %al *************** *** 82,93 **** movl APIC_TPR(%esi), %eax /* get current TPR */ orl $0x000000ff, %eax /* block all INTs */ movl %eax, APIC_TPR(%esi) /* put new TPR */ - /* :EMXIF **/ - movl _apic_base, %esi - movl APIC_SVR(%esi), %eax /* get spurious vector reg. */ - orl $0x00000100, %eax /* This bit enables the APIC */ - movl %eax, APIC_SVR(%esi) #if 0 /* the alternate CPU is not ready to receive interrupts yet */ movl APIC_LVT1(%esi), %eax /* Setup LVT1 as ExtINT */ andl $0xfffe58ff, %eax --- 92,98 ---- *************** *** 99,107 **** orl $0xffff0400, %eax movl %eax, APIC_LVT2(%esi) ! movl APIC_VER(%esi), %eax ! movl %eax, _cpuApicVersions ! incl _mp_ncpus #if 0 1: movl _smp_active, %eax --- 104,113 ---- orl $0xffff0400, %eax movl %eax, APIC_LVT2(%esi) ! movl APIC_SVR(%esi), %eax /* get spurious vector reg. */ ! orl $0x00000100, %eax /* This bit enables the APIC */ ! movl %eax, APIC_SVR(%esi) ! /* :EMXIF **/ #if 0 1: movl _smp_active, %eax -------------------------------------- cut ------------------------------------ -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Fri Nov 29 16:03:32 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA14295 for smp-outgoing; Fri, 29 Nov 1996 16:03:32 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA14290 for ; Fri, 29 Nov 1996 16:03:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id RAA00944 for ; Fri, 29 Nov 1996 17:03:26 -0700 Message-Id: <199611300003.RAA00944@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: freebsd-smp@freebsd.org Subject: Re: SMP-current hang problems. In-reply-to: Your message of "Fri, 29 Nov 1996 16:48:13 MST." <199611292348.QAA00819@clem.systemsix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Nov 1996 17:03:26 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, HEADS UP, that patch I just sent is broken!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! I'll be back..... -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Fri Nov 29 16:08:41 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA14431 for smp-outgoing; Fri, 29 Nov 1996 16:08:41 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA14424 for ; Fri, 29 Nov 1996 16:08:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id RAA00982 for ; Fri, 29 Nov 1996 17:08:33 -0700 Message-Id: <199611300008.RAA00982@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: freebsd-smp@freebsd.org Subject: Re: SMP-current hang problems. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Nov 1996 17:08:33 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, sorry about that, I sent a patch to a patch.... this should be for real: --------------------------------------- cut ----------------------------------- *** mpboot.s.old 1996/11/29 22:50:07 1.1 --- mpboot.s 1996/11/29 23:19:37 *************** *** 30,35 **** --- 30,36 ---- * * mpboot.s: FreeBSD machine support for the Intel MP Spec * multiprocessor systems. + * $Id$ */ *************** *** 62,77 **** * Wait for the booting CPU to signal startup */ mp_begin: /* now running relocated at KERNBASE */ call _init_secondary /* load i386 tables */ /** * FIXME: this code is of little value at the moment, * going to a SYMMETRIC IO mode will change that. */ ! movl _apic_base, %esi ! movl APIC_SVR(%esi), %eax /* get spurious vector reg. */ ! orl $0x00000100, %eax /* This bit enables the APIC */ ! movl %eax, APIC_SVR(%esi) #if 0 /* the alternate CPU is not ready to receive interrupts yet */ movl APIC_LVT1(%esi), %eax /* Setup LVT1 as ExtINT */ andl $0xfffe58ff, %eax --- 63,98 ---- * Wait for the booting CPU to signal startup */ mp_begin: /* now running relocated at KERNBASE */ + movl _apic_base, %esi + + movl APIC_SVR(%esi), %eax /* get spurious vector reg. */ + andl $~0x00000100, %eax /* disable the APIC */ + movl %eax, APIC_SVR(%esi) + + movl APIC_VER(%esi), %eax + movl %eax, _cpuApicVersions + incl _mp_ncpus + + /* One at a time, we are running on the shared mp_stk */ + /* This is the Intel reccomended semaphore method */ + movb $0xff, %al + 2: + xchgb %al, bootlock /* xchg is implicitly locked */ + cmpb $0xff, %al + jz 2b + call _init_secondary /* load i386 tables */ /** * FIXME: this code is of little value at the moment, * going to a SYMMETRIC IO mode will change that. */ ! ! /* ensure APs will not accept BROADCAST INTs sent in LOPRIO mode */ ! movl APIC_TPR(%esi), %eax /* get current TPR */ ! orl $0x000000ff, %eax /* block all INTs */ ! movl %eax, APIC_TPR(%esi) /* put new TPR */ ! #if 0 /* the alternate CPU is not ready to receive interrupts yet */ movl APIC_LVT1(%esi), %eax /* Setup LVT1 as ExtINT */ andl $0xfffe58ff, %eax *************** *** 83,110 **** orl $0xffff0400, %eax movl %eax, APIC_LVT2(%esi) ! /* ensure APs will not accept BROADCAST INTs sent in LOPRIO mode */ ! movl APIC_TPR(%esi), %eax /* get current TPR */ ! orl $0x000000ff, %eax /* block all INTs */ ! movl %eax, APIC_TPR(%esi) /* put new TPR */ /* :EMXIF **/ ! movl APIC_VER(%esi), %eax ! movl %eax, _cpuApicVersions ! incl _mp_ncpus ! 1: movl _smp_active, %eax cmpl $0, %eax jz 1b ! ! /* One at a time, we are running on the shared mp_stk */ ! /* This is the Intel reccomended semaphore method */ ! movb $0xff, %al ! 2: ! xchgb %al, bootlock /* xchg is implicitly locked */ ! cmpb $0xff, %al ! jz 2b ! /* Now, let's do some REAL WORK :-) */ call _get_mplock call _secondary_main --- 104,119 ---- orl $0xffff0400, %eax movl %eax, APIC_LVT2(%esi) ! movl APIC_SVR(%esi), %eax /* get spurious vector reg. */ ! orl $0x00000100, %eax /* This bit enables the APIC */ ! movl %eax, APIC_SVR(%esi) /* :EMXIF **/ ! #if 0 1: movl _smp_active, %eax cmpl $0, %eax jz 1b ! #endif /* Now, let's do some REAL WORK :-) */ call _get_mplock call _secondary_main --------------------------------------- cut ----------------------------------- -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Sat Nov 30 10:15:49 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA28892 for smp-outgoing; Sat, 30 Nov 1996 10:15:49 -0800 (PST) Received: from uruk.org (root@faustus.dev.com [198.145.95.253]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA28882 for ; Sat, 30 Nov 1996 10:15:46 -0800 (PST) Received: from uruk.org [127.0.0.1] (erich) by uruk.org with esmtp (Exim 0.53 #1) id E0vTu1B-000831-00; Sat, 30 Nov 1996 10:20:01 -0800 To: Steve Passe cc: smp@freebsd.org Subject: Re: SMP-current hang problems. In-reply-to: Your message of "Fri, 29 Nov 1996 14:17:26 MST." <199611292117.OAA29993@clem.systemsix.com> Date: Sat, 30 Nov 1996 10:20:01 -0800 From: Erich Boleyn Message-Id: Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve Passe writes: > we have decided to more or less freeze development till we figure out > the "system hang" problem with the latest code. If you have one > of the systems that hangs anywhere in the area of: > > SMP: Idle procs online, starting an AP! > SMP: AP CPU #1 LAUNCHED!! Starting Scheduling... > SMP: TADA! CPU #1 made it into the scheduler!. > SMP: All 2 CPU's are online! ... Well, I wanted to try an unmunged syscons, so I took the existing SMP source tree and tried it with and without APIC_IO. (My test box is a 4-CPU Pentium Pro with PCI SCSI and EISA network cards) Without APIC_IO, I got messages like the above for all 3 of the other CPUs in my box. Pretty cool! Syscons was screwed up here, so I don't think it is just an "APIC_IO" problem. I could bang on the keyboard for a long time and it kept going. With APIC_IO, I got one message like the above for "CPU #3", but after the "Starting Scheduling..." part, it said "SMP: freezing CPU #3", then no more SMP CPU booting messages. Syscons was screwed up here in apparently the exact same fashion. If I banged on the keyboard too much, it would lock up. I think I'm more interested in fixing syscons than regressing it and a bunch of other files, perhaps with unpredictable results. More later. (is there anything specific I should try?) -- Erich Stefan Boleyn \_ E-mail (preferred): Mad Genius wanna-be, CyberMuffin \__ (finger me for other stats) Web: http://www.uruk.org/~erich/ Motto: "I'll live forever or die trying" From owner-freebsd-smp Sat Nov 30 10:56:38 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA01258 for smp-outgoing; Sat, 30 Nov 1996 10:56:38 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA01252 for ; Sat, 30 Nov 1996 10:56:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id LAA07855; Sat, 30 Nov 1996 11:56:05 -0700 Message-Id: <199611301856.LAA07855@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Erich Boleyn cc: Peter Wemm , smp@freebsd.org Subject: Re: SMP-current hang problems. In-reply-to: Your message of "Sat, 30 Nov 1996 10:20:01 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 Nov 1996 11:56:05 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, >Without APIC_IO, I got messages like the above for all 3 of the other CPUs >in my box. Pretty cool! Syscons was screwed up here, so I don't think >it is just an "APIC_IO" problem. I could bang on the keyboard for a long >time and it kept going. > >With APIC_IO, I got one message like the above for "CPU #3", but after >the "Starting Scheduling..." part, it said "SMP: freezing CPU #3", then >no more SMP CPU booting messages. Syscons was screwed up here in nice to hear some good news for a change! there is a known race condition in the order in which APs are started. Specifically they are all started at low level in mpboot.s and held by the sem "bootlock". The 1st AP is released by the BSP once the system is running processes. Each AP then releases another as it "enters" its own process space. The offending code is in kern/init_main.c, smp_idleloop(), which ONLY works if APs happen to start in numeric order. Peter was doing the fix, perhaps he should release this now if it won't confuse the "hang" situation too much. --- >With APIC_IO, I got one message like the above for "CPU #3", but after >the "Starting Scheduling..." part, it said "SMP: freezing CPU #3", then >no more SMP CPU booting messages. Syscons was screwed up here in >apparently the exact same fashion. If I banged on the keyboard too much, >it would lock up. as described above, probably just the race on CPU numbers. If you rebooted several times it might work, and there are no guarantees that the non APIC_IO version will work every time. --- >I think I'm more interested in fixing syscons than regressing it and >a bunch of other files, perhaps with unpredictable results. > >More later. (is there anything specific I should try?) I haven't heard anything lately on the syscons problems, it just "went away" for my system so I haven't been able to attack it. If you can gain any insight on this one it would be greatly appreciated! -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Sat Nov 30 11:15:46 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA02138 for smp-outgoing; Sat, 30 Nov 1996 11:15:46 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA02128 for freebsd-smp; Sat, 30 Nov 1996 11:15:44 -0800 (PST) Date: Sat, 30 Nov 1996 11:15:44 -0800 (PST) From: Peter Wemm Message-Id: <199611301915.LAA02128@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/kern init_main.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/30 11:15:43 Modified: kern init_main.c Log: Fix boot race noted by Steve a few days ago. The AP's are unlocked in random order, this code could freeze a freshly started cpu before it gets a chance to finish coming online. *blush*. This should fix part of Erich's problem, I hope.. (I'm 95% asleep at the moment) Revision Changes Path 1.36 +2 -3 sys/kern/init_main.c From owner-freebsd-smp Sat Nov 30 12:12:57 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA05389 for smp-outgoing; Sat, 30 Nov 1996 12:12:57 -0800 (PST) Received: from uruk.org (root@faustus.dev.com [198.145.95.253]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA05382 for ; Sat, 30 Nov 1996 12:12:53 -0800 (PST) Received: from uruk.org [127.0.0.1] (erich) by uruk.org with esmtp (Exim 0.53 #1) id E0vTvqX-0008HG-00; Sat, 30 Nov 1996 12:17:09 -0800 To: Peter Wemm cc: smp@freebsd.org Subject: Re: cvs commit: sys/kern init_main.c In-reply-to: Your message of "Sat, 30 Nov 1996 11:15:44 PST." <199611301915.LAA02128@freefall.freebsd.org> Date: Sat, 30 Nov 1996 12:17:09 -0800 From: Erich Boleyn Message-Id: Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Peter Wemm writes: > peter 96/11/30 11:15:43 > > Modified: kern init_main.c > Log: > Fix boot race noted by Steve a few days ago. The AP's are unlocked in > random order, this code could freeze a freshly started cpu before it > gets a chance to finish coming online. *blush*. > > This should fix part of Erich's problem, I hope.. (I'm 95% asleep at > the moment) > > Revision Changes Path > 1.36 +2 -3 sys/kern/init_main.c There is a small typo in the above change. The obvious fix was the following (hopefully this is what you intended): -------------------------(start cvs diff)---------------------------------- Index: sys/kern/init_main.c =================================================================== RCS file: /usr/cvssup/sys/kern/init_main.c,v retrieving revision 1.36 diff -r1.36 init_main.c 792c792 < smp_active = mp_ncpu; --- > smp_active = mp_ncpus; --------------------------(end cvs diff)----------------------------------- -- Erich Stefan Boleyn \_ E-mail (preferred): Mad Genius wanna-be, CyberMuffin \__ (finger me for other stats) Web: http://www.uruk.org/~erich/ Motto: "I'll live forever or die trying" From owner-freebsd-smp Sat Nov 30 14:31:36 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA09964 for smp-outgoing; Sat, 30 Nov 1996 14:31:36 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA09958 for ; Sat, 30 Nov 1996 14:31:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id PAA08844; Sat, 30 Nov 1996 15:31:10 -0700 Message-Id: <199611302231.PAA08844@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: "J.M. Chuang" cc: smp@freebsd.org, Peter Wemm Subject: Re: New smp kernel In-reply-to: Your message of "Sat, 30 Nov 1996 18:08:32 -0400." <199611302208.SAA05140@bluenose.na.tuns.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 Nov 1996 15:31:10 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > With today's init_main.c, the system still hangs if the boot-device > is IDE. I believe that there is a conflict between the kernel and > APIC stuff (built in ID controller in Tomcat and Tyan Titan). this is good news! So I think we may be past the general "system hang" problem. Is there ANYONE out there that still has this problem after applying todays (96-11-30) kern/init_main.c? SPEAK UP NOW!!! --- > I managed to get a SCSI HD with Adaptic 2940A controller this morning. > With the same smp kernel, the system booted up from SCSI HD without any > problem and the system recognizes the IDE drive which can be accessed (mount). > The only glitches with the current smp-kernel are the coredumps showed up once in a while > when I compile the kernel. It is a kind of strang that after the coredump > if I keep on typing `make', the compilation of the kernel can be > finished. Is is due to the syncronization (??) problem of two CPU's? It is believed that its caused by our failure to do tlb flushing during page stealing. Peter's working on an implementation of IPI's to trigger tlb flushes, which should fix that problem. Jim, thanx again for your patience and help, -- Steve Passe | powered by smp@csn.net | FreeBSD -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE 04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ =ds99 -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Sat Nov 30 14:42:33 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA10757 for smp-outgoing; Sat, 30 Nov 1996 14:42:33 -0800 (PST) Received: from ceylon.informatik.uni-rostock.de (ceylon.informatik.uni-rostock.de [139.30.5.237]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA10752 for ; Sat, 30 Nov 1996 14:42:29 -0800 (PST) Received: by ceylon.informatik.uni-rostock.de id XAA06189; Sat, 30 Nov 1996 23:42:18 +0100 Received: by donau.informatik.uni-rostock.de id XAA04636; Sat, 30 Nov 1996 23:42:11 +0100 (MET) Date: Sat, 30 Nov 1996 23:42:11 +0100 (MET) From: Gunther Hipper Message-Id: <199611302242.XAA04636@donau.informatik.uni-rostock.de> To: freebsd-smp@freebsd.org Subject: Panic(cpu#0): Nobody wants to mount my root for me Cc: gunther@ceylon.informatik.uni-rostock.de X-Sun-Charset: US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi again ! Okay, from the start. My Config is a GA586DX, SCSI on board but EIDE disk. In the beginning, FreeBSD 2.2-961014 installed. A first cvsup of smp-src had some problems running, but the SMP-kernel came up to a login. Now i did the following: 1) I ftped to ftp.de.freebsd.org and got the /pub/FreeBSD/2.2-ALPHA/src/* Then i made the install.sh and got a nice /usr/src. 2) Made world - everything ok 3) cvsup the smp-src from cvsup.freebsd.org 4) made the "smp_active = mp_ncpus;" 5) First try: options SMP and omitting the rest, reboot and result: Panic(cpu#0): Nobody wants to mount my root for me 6) Second try: options SMP options NCPU=2 options NBUS=2 options NAPIC=1 options NINTR=21 options APIC_IO and result: Panic(cpu#0): Nobody wants to mount my root for me 7) Third try: options SMP #options NCPU=2 #options NBUS=2 options NAPIC=1 #options NINTR=21 options APIC_IO and result: Panic(cpu#0): Nobody wants to mount my root for me 8) Silly idea. Switched back to options SMP and omitting the rest. But this time, i tried to keep out: #controller pci0 #device de0 my (inoperational #options PCI reboot and result as above.... 9) Final Countdown: same conf as 8) but now - boot from msdos-formatted floppy... :-) Maybe you're laughing right now :-( The ufs-filesystem is okay, FreeBSD 2.2-961014 boots and compiles the SMP-Kernel just fine.... Does anyone of you boot from an EIDE-drive (disklabel says ESDI) ? At this point, i've obly two ideas left: a) to get out some old SCSI-Drive, repeat the procedure and see what happens. b) try to get /pub/FreeBSD/FreeBSD-current/src/* from somewhere. c) try to play in smptests.h ? d) The EIDE disk operates in BIOS-Mode LBA. Switch this to LARGE or NORMAL ? The last could be crazy because there are other partitions.... What would you suggest to do ? Thanks Gunther From owner-freebsd-smp Sat Nov 30 14:48:56 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA10907 for smp-outgoing; Sat, 30 Nov 1996 14:48:56 -0800 (PST) Received: from ceylon.informatik.uni-rostock.de (ceylon.informatik.uni-rostock.de [139.30.5.237]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA10902 for ; Sat, 30 Nov 1996 14:48:52 -0800 (PST) Received: by ceylon.informatik.uni-rostock.de id XAA06205; Sat, 30 Nov 1996 23:48:42 +0100 Received: by donau.informatik.uni-rostock.de id XAA04639; Sat, 30 Nov 1996 23:48:36 +0100 (MET) Date: Sat, 30 Nov 1996 23:48:36 +0100 (MET) From: Gunther Hipper Message-Id: <199611302248.XAA04639@donau.informatik.uni-rostock.de> To: freebsd-smp@freebsd.org Subject: Re: New smp kernel X-Sun-Charset: US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Hi, > > > With today's init_main.c, the system still hangs if the boot-device > > is IDE. I believe that there is a conflict between the kernel and > > APIC stuff (built in ID controller in Tomcat and Tyan Titan). > > this is good news! So I think we may be past the general "system hang" > problem. Is there ANYONE out there that still has this problem after > applying todays (96-11-30) kern/init_main.c? SPEAK UP NOW!!! YYYYYYYYYYYYUUUUUUUUUUUUUUPPPPPPPPP - this seems to be my Problem, too !!!!!!!! > > I managed to get a SCSI HD with Adaptic 2940A controller this morning. > > With the same smp kernel, the system booted up from SCSI HD without any > > problem and the system recognizes the IDE drive which can be accessed (mount). Do you want me to try this, too ? I could get a 1542C and a 2GB SCSI for a trial with my GA586DX..... Bye Gunther From owner-freebsd-smp Sat Nov 30 14:50:46 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA11003 for smp-outgoing; Sat, 30 Nov 1996 14:50:46 -0800 (PST) Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA10998 for ; Sat, 30 Nov 1996 14:50:45 -0800 (PST) Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0vTyEK-0003vyC; Sat, 30 Nov 96 14:49 PST Received: from critter.tfs.com (localhost.dk.tfs.com [127.0.0.1]) by critter.tfs.com (8.8.2/8.8.2) with ESMTP id XAA06480; Sat, 30 Nov 1996 23:51:23 +0100 (MET) To: Gunther Hipper cc: freebsd-smp@freebsd.org, gunther@ceylon.informatik.uni-rostock.de Subject: Re: Panic(cpu#0): Nobody wants to mount my root for me In-reply-to: Your message of "Sat, 30 Nov 1996 23:42:11 +0100." <199611302242.XAA04636@donau.informatik.uni-rostock.de> Date: Sat, 30 Nov 1996 23:51:23 +0100 Message-ID: <6478.849394283@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >What would you suggest to do ? boot -v send us the output of the boot sequence. Consider using a serial console to capture it. -- 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 Sat Nov 30 15:20:43 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA14245 for smp-outgoing; Sat, 30 Nov 1996 15:20:43 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA14238 for ; Sat, 30 Nov 1996 15:20:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id QAA09127; Sat, 30 Nov 1996 16:20:26 -0700 Message-Id: <199611302320.QAA09127@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Gunther Hipper cc: freebsd-smp@freebsd.org Subject: Re: New smp kernel In-reply-to: Your message of "Sat, 30 Nov 1996 23:48:36 +0100." <199611302248.XAA04639@donau.informatik.uni-rostock.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 Nov 1996 16:20:26 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > > > With today's init_main.c, the system still hangs if the boot-device > > > is IDE. I believe that there is a conflict between the kernel and > > > APIC stuff (built in ID controller in Tomcat and Tyan Titan). > > > > this is good news! So I think we may be past the general "system hang" > > problem. Is there ANYONE out there that still has this problem after > > applying todays (96-11-30) kern/init_main.c? SPEAK UP NOW!!! > YYYYYYYYYYYYUUUUUUUUUUUUUUPPPPPPPPP - this seems to be my Problem, too !!!!!!!! > > > > I managed to get a SCSI HD with Adaptic 2940A controller this morning. > > > With the same smp kernel, the system booted up from SCSI HD without any > > > problem and the system recognizes the IDE drive which can be accessed (mount). > Do you want me to try this, too ? I could get a 1542C and a 2GB SCSI for a trial > with my GA586DX..... I should have looked CLOSER at the dmesg output you sent me. Since you are using the same board as I am, I just jumped to the conclusion that you were using a SCSI disk, pass me the pointy hat! from your dmesg: > FreeBSD 2.2-961014-SNAP #22: Sun Nov 17 16:03:37 1996 > ... > ahc0 rev 0 int a irq 9 on pci0:12 > ahc0: aic7880 Unsupported adapter type. Ignoring I *think* ^^^^^^^^^^^^^^^^^^^^^^^^ this is because its OFF in BIOS earlier boards came with this chip as an option, but I think this says your board actually has it, but its turned off in the BIOS. The BIOS may also be "smart" enough to see that there are no SCSI disks attached and turn it off on its own, so just turning it on in the BIOS may not be enough to make this message go away. It might also be a result of using the 961014 SNAP, I don't remember when support for the 7880 was added, but it definately IS supported in the SMP-current kernel. > wdc0 at 0x1f0-0x1f7 irq 14 on isa > wdc0: unit 0 (wd0): > wd0: 2015MB (4127760 sectors), 4095 cyls, 16 heads, 63 S/T, 512 B/S So this is what you are actually trying to boot off of? So confirm you have the SCSI support on your motherboard and then all you need is a SCSI disk. If this is your only problem then the current code, including the init_main.c commited today, should work for you with without "options APIC_IO". This is the first thing to verify. If you can run that, then we are down to 1 reported failing machine (excluding the IDE related failures). This 1 machine is a 4 CPU motherboard, and also might now run with todays init_main.c. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Sat Nov 30 15:43:26 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA15582 for smp-outgoing; Sat, 30 Nov 1996 15:43:26 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA15572 for ; Sat, 30 Nov 1996 15:43:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id QAA09261 for ; Sat, 30 Nov 1996 16:43:17 -0700 Message-Id: <199611302343.QAA09261@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: freebsd-smp@freebsd.org Subject: debugging SMP kernels Mime-Version: 1.0 Content-Type: text/plain Date: Sat, 30 Nov 1996 16:43:17 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, here is a VERY ROUGH 1st draft of how to go about setting up a remote serial debug session for the SMP kernel. Send comments etc. I know its full of holes, but it should get you started. -------------------------------------- cut ------------------------------------ =============================================================================== To debug via a 'serial terminal' and ddb: Terms used in this discussion: HOST: the machine with which you are providing "terminal facilities". Note that this could be a RS-232 terminal, but using an XTerm on a computer gives many advantages such as output capture, etc. TARGET: The machine that the SMP kernel is being run on. PORT: the serial port used on the machine. This must be /dev/cuaa0 on the TARGET (ie SMP kernel) machine, but can be any available port on the HOST machine. For my examples below I will use: HOST == larry, larry's PORT == /dev/cuaa1 TARGET == moe, moe's PORT == /dev/cuaa0 (COMCONSOLE *must* be cuaa0) 1) setup a null-modem connection between PORT on the HOST machine and PORT on the TARGET machine. 2) create an entry in HOST:/etc/remote that looks like: moe:dv=/dev/cuaa1:br#9600:pa=none:el=^J^M: 'moe' is the target machine name. 'dv=/dev/cuaa0' sets the port to /dev/cuaa0 'br#9600' sets the baudrate to 9600 'pa=none' disables parity generation/checking 'el=^J^M' adds to the default as legal EOL chars. optional, this makes output from inside an emacs SHELL cleaner. see "man 5 remote" for further details. to get the proper permissions for this to all work on my 2.1.5 box I set things like this: ls -l HOST:/PORT crw-rw---- 1 uucp dialer 28, 129 Nov 30 14:48 /dev/cuaa1 ^^^^^^ HOST:/etc/group [ add yourself to group 'dialer' ] ^^^^^^ 3) add the following to your SMP kernel config file: options DDB # enable the kernel debugger. options COMCONSOLE # prefer serial console to video options BREAK_TO_DEBUGGER # a BREAK on a comconsole goes to DDB then the usual config/make depend/make/make install. 4) run "tip moe" on the HOST machine. 5) reboot the TARGET machine. It should show output as usual on the system console up thru the point of loading the kernel. If you use options to boot or a kernel other than 'kernel' you will need to type to the TARGET console. 6) the ONLY way I could get BREAKS sent by tip to be seen by the TARGET machine was to "cat >/dev/cuaa0 &" as root on the TARGET machine after it comes up. Something to do with the port needing to be open to catch the INTerrupts generated by the BREAK. 7) you will see all the normal startup messages appear on the HOST screen. To trap to the debugger hit a BREAK character. To send a BREAK from tip use "~#". Note the the "~" must be the 1st char on the line to be recognized by tip. 8) running tip from an emacs shell: for some reason emacs echos something that causes ddb to exit the debug trap as soon as it enters it. To get around this I built the following bandaid: --------------------------------- cut ------------------------------ /* * genbrk.c */ #include #include #include /* the port that tip uses to talk to the TARGET COMCONSOLE */ #error fix the following line and remove this one to compile #define DEVICE "/dev/cuaa?" main( int argc, char* argv[] ) { int fd; fd = open( DEVICE, O_WRONLY ); ioctl( fd, TIOCSBRK, NULL ); sleep(1); ioctl( fd, TIOCCBRK, NULL ); } --------------------------------- cut ------------------------------ you can execute it with the emacs command META-! Lock it down for security with: chown root:dialer /usr/local/bin/genbrk chmod 4750 /usr/local/bin/genbrk If anyone nows how to tickle emacs so this is unnecessary please let us know. --- Steve Passe =============================================================================== To debug via remote gdb: --- Eric L. Hernes provided the following, which he derived from a message Julian sent to -hackers a while back. --- In a nutshell here: 1) null-modem sio0 on the `to be debugged' machine to a tty on another machine. I'm using sio0 <-> sio0 on jake and tess. `jake' is my main desktop, which is the smp box. tess is my normal kernel-hacking machine. Their role's are reversed for this project. 2) I set up the kernel sources on the `stable' machine. For smp work this is tess. For normal kernel work, this is jake. So I've got my smp kernel source on tess. config your kernel with `config -g' to put debugging symbols in the kernel. 3) make depend all, as normal. copy kernel to kernel.debug or something it'll be around 9 Meg! then `strip -d' the kernel to get rid of debugging symbols, but leave the symbol table intact (so things like ps will work) Julian suggested patching the Makefile with something like: (warning: cut-n-paste tab breakage) --- Makefile~ Mon Nov 4 20:19:14 1996 +++ Makefile Tue Nov 5 11:16:44 1996 @@ -71,6 +72,8 @@ .endif SYSTEM_LD_TAIL= @echo rearranging symbols; \ symorder -m ${SYMORDER_EXCLUDE} symbols.sort $@; \ + cp $@ $@.debug; \ + strip -d $@; \ size $@; chmod 755 $@ BEFORE_DEPEND=linux_assym.h This is the kernel that will be booted. 4) install `kernel' (the strip -d'ed) one on the target machine. 5) start gdb in the kernel compile directory on the stable machine. The three magical commands you need to run within gdb are: A) `set remotebaud 9600' (or whatever baudrate, this works for me, I've heard some complaints about speed); B) `file kernel.debug' (or whatever file still has debugging symbols in from step 3) C) target remote /dev/cuaa0 (or whatever the tty device is) 6) reboot. At the boot prompt, you can type -g to get traps to go to remote gdb. My boot blocks are too old to support this, and I'm lazy so I run -d at the boot prompt and type `gdb' at the ddb prompt. This reports something like `next trab will go to remote gdb'. then you can set breakpoints, and continue etc... 7) the next trap on the debug'ed machine will give a standard gdb prompt with the source line number printed! most gdb commands work as expected. 8) There are some flakey things, like I've not been able to reboot the remote machine from within gdb, I always go for the reset switch. Sometimes gdb reports that the program seg-faulted, then you may as well head for the reset too. 9) you can substitute in your favorite front end for gdb in step 5. I've used xemacs, ddd, tkgdb, gdb, xxgdb, (any more?) --- Eric L. Hernes =============================================================================== -------------------------------------- cut ------------------------------------ -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Sat Nov 30 16:03:38 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA17702 for smp-outgoing; Sat, 30 Nov 1996 16:03:38 -0800 (PST) Received: from ceylon.informatik.uni-rostock.de (ceylon.informatik.uni-rostock.de [139.30.5.237]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA17692 for ; Sat, 30 Nov 1996 16:03:34 -0800 (PST) Received: by ceylon.informatik.uni-rostock.de id BAA06486; Sun, 1 Dec 1996 01:03:31 +0100 Received: by donau.informatik.uni-rostock.de id BAA04830; Sun, 1 Dec 1996 01:03:24 +0100 (MET) Date: Sun, 1 Dec 1996 01:03:24 +0100 (MET) From: Gunther Hipper Message-Id: <199612010003.BAA04830@donau.informatik.uni-rostock.de> To: freebsd-smp@freebsd.org Subject: Re: New smp kernel / Panic(cpu#0): Nobody wants to mount my root for me X-Sun-Charset: US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi ! Great news - since 4 hours I've no girlfriend, but maybe an _SMP_kernel_ ! That's better than nothing ! > > ahc0 rev 0 int a irq 9 on pci0:12 > > ahc0: aic7880 Unsupported adapter type. Ignoring > I *think* ^^^^^^^^^^^^^^^^^^^^^^^^ this is because its OFF in BIOS > > earlier boards came with this chip as an option, but I think this says your > board actually has it, but its turned off in the BIOS. The BIOS may also > be "smart" enough to see that there are no SCSI disks attached and turn it off > on its own, so just turning it on in the BIOS may not be enough to make this > message go away. It might also be a result of using the 961014 SNAP, I don't > remember when support for the 7880 was added, but it definately IS supported > in the SMP-current kernel. I have the SCSI-chip, and i always tried to turn it on and off in BIOS - but this made no difference concerning the boot from the latest SMP-kernel. > > wdc0 at 0x1f0-0x1f7 irq 14 on isa > > wdc0: unit 0 (wd0): > > wd0: 2015MB (4127760 sectors), 4095 cyls, 16 heads, 63 S/T, 512 B/S > > So this is what you are actually trying to boot off of? Jupp. Some days ago it was possible to boot off the IDE ... but now - no chance. This is why i wanted to start to take a look into the autoconf.c, somewhere where the while(1){} of the init is, there was the function calling isa_configure() or so. This was the point when i considered to ask you :-) > So confirm you have the SCSI support on your motherboard and then all you need > is a SCSI disk. > If this is your only problem then the current code, including the init_main.c > commited today, should work for you with without "options APIC_IO". Okay, I can go on, but the problem is that i have 16 GA586DX but only a sinlge SCSI disk ..... but I would really _DIE_ for having a FreeBSD-SMP. At the moment, my boss wants WinNT and is keen on any reason for switching off of Unix. Ahemm s.th. else - Poul-Henning Kamp just said: >>What would you suggest to do ? >boot -v >send us the output of the boot sequence. >Consider using a serial console to capture it. This could take some time.... i've to get a null-modem, an old pc but the worst thing is that i've never done kernel debugging with a debugger/FreeBSD right now... just straight device-drivers. You still want me to copy the boot-up-sequence ? But could take some time. HERE IS MY CONFIG-FILE: machine "i386" cpu "I586_CPU" ident SMP maxusers 10 options SMP # Symmetric MultiProcessor Kernel #options NCPU=2 # number of CPUs #options NBUS=2 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=21 # number of INTs #options APIC_IO # Symmetric (APIC) I/O options INET #InterNETworking options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options BOUNCE_BUFFERS #include support for DMA bounce buffers options UCONSOLE #Allow users to grab the console options FAILSAFE #Be conservative options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor config kernel root on wd0 controller isa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr device npx0 at isa? port "IO_NPX" irq 13 vector npxintr device de0 device ed0 at isa? port 0x300 net irq 5 iomem 0xd8000 vector edintr pseudo-device loop pseudo-device ether cpu "I586_CPU" ident SMP maxusers 10 options SMP # Symmetric MultiProcessor Kernel #options NCPU=2 # number of CPUs #options NBUS=2 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=21 # number of INTs #options APIC_IO # Symmetric (APIC) I/O options INET #InterNETworking options PROCFS #Process filesystem options "COMPAT_43" #Compatible with BSD 4.3 [KEEP THIS!] options BOUNCE_BUFFERS #include support for DMA bounce buffers options UCONSOLE #Allow users to grab the console options FAILSAFE #Be conservative options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor config kernel root on wd0 controller isa0 controller pci0 controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive 0 controller wdc0 at isa? port "IO_WD1" bio irq 14 vector wdintr disk wd0 at wdc0 drive 0 device sc0 at isa? port "IO_KBD" tty irq 1 vector scintr device npx0 at isa? port "IO_NPX" irq 13 vector npxintr device de0 device ed0 at isa? port 0x300 net irq 5 iomem 0xd8000 vector edintr pseudo-device loop pseudo-device ether pseudo-device log pseudo-device pty 16 pseudo-device gzip options KTRACE #kernel tracing options DDB END OF MY CONFIG-FILE From owner-freebsd-smp Sat Nov 30 16:06:22 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA17845 for smp-outgoing; Sat, 30 Nov 1996 16:06:22 -0800 (PST) Received: from ceylon.informatik.uni-rostock.de (ceylon.informatik.uni-rostock.de [139.30.5.237]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA17840 for ; Sat, 30 Nov 1996 16:06:19 -0800 (PST) Received: by ceylon.informatik.uni-rostock.de id BAA07269; Sun, 1 Dec 1996 01:06:14 +0100 Received: by donau.informatik.uni-rostock.de id BAA04832; Sun, 1 Dec 1996 01:06:07 +0100 (MET) Date: Sun, 1 Dec 1996 01:06:07 +0100 (MET) From: Gunther Hipper Message-Id: <199612010006.BAA04832@donau.informatik.uni-rostock.de> To: smp@csn.net, freebsd-smp@freebsd.org Subject: Re: New smp kernel / Panic(cpu#0): Nobody wants to mount my root for me Cc: gunther@ceylon.informatik.uni-rostock.de X-Sun-Charset: US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk There is an error in my config-file - i took out the sio but left the DDB on. That's just what i wanted to do to get the boot -v sequence. Sorry. From owner-freebsd-smp Sat Nov 30 18:38:26 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA26858 for smp-outgoing; Sat, 30 Nov 1996 18:38:26 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA26853 for ; Sat, 30 Nov 1996 18:38:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id TAA10184 for ; Sat, 30 Nov 1996 19:38:15 -0700 Message-Id: <199612010238.TAA10184@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: freebsd-smp@freebsd.org Subject: SMP-current status Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 Nov 1996 19:38:15 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, The scorecard: all systems seem to be working right now except: 1: systems booting off of (E)IDE disks. 2: >2 CPU systems. 3: frequent sig11/12 faults on all systems. Please confirm/refute items 1 & 2 ASAP! --- Status: 1: I think that I broke something when I merged the global used for INTerrupt masking by the 8259s (imen) and the global used by the APIC_IO code (IOApicMask). But I am clueless as to what. I just rebuilt a non APIC_IO kernel that works well. But I have no IDE disk so I have no way of testing that aspect of it. 2: Peter commited a fix for this today but we haven't heard back from any >2 CPU testers yet. 3: we really want to get on this one, honest, I swear, no kidding... get those success/failure reports in so we can feel comfortable proceeding! -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Sat Nov 30 18:49:49 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA27146 for smp-outgoing; Sat, 30 Nov 1996 18:49:49 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA27136 for freebsd-smp; Sat, 30 Nov 1996 18:49:47 -0800 (PST) Date: Sat, 30 Nov 1996 18:49:47 -0800 (PST) From: Peter Wemm Message-Id: <199612010249.SAA27136@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/kern init_main.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/30 18:49:46 Modified: kern init_main.c Log: *blush* OK, so I was so tired, I didn't actually try to compile this. Hey, it was a 2-line change, it can't possibly be wrong, can it? :-) (On that note, I'm replacing the previous untested 2-line change with another untested 1-character change. *gulp*) Submitted by: Erich Boleyn Revision Changes Path 1.37 +1 -1 sys/kern/init_main.c From owner-freebsd-smp Sat Nov 30 19:11:44 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA27855 for smp-outgoing; Sat, 30 Nov 1996 19:11:44 -0800 (PST) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA27837 for ; Sat, 30 Nov 1996 19:11:28 -0800 (PST) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.3/8.8.3) with ESMTP id LAA02585; Sun, 1 Dec 1996 11:10:02 +0800 (WST) Message-Id: <199612010310.LAA02585@spinner.DIALix.COM> To: Steve Passe cc: "J.M. Chuang" , smp@freebsd.org Subject: Re: New smp kernel In-reply-to: Your message of "Sat, 30 Nov 1996 15:31:10 MST." <199611302231.PAA08844@clem.systemsix.com> Date: Sun, 01 Dec 1996 11:10:02 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve Passe wrote: > > I managed to get a SCSI HD with Adaptic 2940A controller this morning. > > With the same smp kernel, the system booted up from SCSI HD without any > > problem and the system recognizes the IDE drive which can be accessed (moun t). > > The only glitches with the current smp-kernel are the coredumps showed up o nce in a while > > when I compile the kernel. It is a kind of strang that after the coredump > > if I keep on typing `make', the compilation of the kernel can be > > finished. Is is due to the syncronization (??) problem of two CPU's? > > It is believed that its caused by our failure to do tlb flushing during page > stealing. Peter's working on an implementation of IPI's to trigger tlb > flushes which should fix that problem. Just as a BTW, I have an early implementation of this that I think is working, apart from the fact that the system wedges shortly after going smp. I'm not yet sure whether this is the syscons problem, interrupt masking problems, tlb sync problems, IPI problems, or what else I don't know. I'm in the middle of ressurecting the serial port debugging trace code so that I can see how far it's getting. And for what it's worth, I should mention that thse problems are nasty. I strongly reccomend *not* running with the kernel in this state for very long and avoid lots of disk writes. I got bitten by this yesterday where a cron job that runs a mess of processes in sequence and each writes data to differnet files accidently ran while the system was struggling to compile a kernel. The results were... "interesting".. In several places in the files, pages that were meant for one file actually ended up in another. I think this is best explained by one cpu "stealing" pages and didn't notify the other cpu that it had done so. I have another theory as to why this has suddenly started being a problem. The -current merge that happened right before these problems had quite a bit of VM work done on it since the last time we merged -current from a few months back. One of the features was 'page colouring' where the VM system attempts to use physical memory more efficiently to get the best effect from a direct mapped cache. I'm not 100% sure exactly what the impact of this is on the page management policies, but it's bound to be something. It might explain why page reclaiming appears to have become more common even though there is free memory at the time. Cheers, -Peter From owner-freebsd-smp Sat Nov 30 19:43:15 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA28837 for smp-outgoing; Sat, 30 Nov 1996 19:43:15 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA28830 for freebsd-smp; Sat, 30 Nov 1996 19:43:13 -0800 (PST) Date: Sat, 30 Nov 1996 19:43:13 -0800 (PST) From: Peter Wemm Message-Id: <199612010343.TAA28830@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/kern init_main.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/30 19:43:12 Modified: kern init_main.c Log: Argh, it's not my day. Steve pointed out that my last commit didn't fix all the problems from the commit before it. Note that the code that is being changed here is really diagnostic code and will probably go away when things have calmed down. Revision Changes Path 1.38 +9 -5 sys/kern/init_main.c From owner-freebsd-smp Sat Nov 30 20:50:23 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA00994 for smp-outgoing; Sat, 30 Nov 1996 20:50:23 -0800 (PST) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA00985 for freebsd-smp; Sat, 30 Nov 1996 20:50:22 -0800 (PST) Date: Sat, 30 Nov 1996 20:50:22 -0800 (PST) From: Peter Wemm Message-Id: <199612010450.UAA00985@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/kern init_main.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/11/30 20:50:21 Modified: kern init_main.c Log: Sigh. Try to fix stupid mistake number 167 and 168 for the day.. :-/ CTLFLAG_RO should have been CTLFLAG_RD Pointed out by: J.M. Chuang smp_cpus was not being incremented Pointed out by: Steve Passe Argh, I think I need to fix my tree so that I can compile it. These blunders in trivial untested commits are getting rather embarresing.. :-] Revision Changes Path 1.39 +2 -1 sys/kern/init_main.c