From owner-freebsd-smp Sun Oct 13 00:43:57 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA18438 for smp-outgoing; Sun, 13 Oct 1996 00:43:57 -0700 (PDT) Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id AAA18433 for ; Sun, 13 Oct 1996 00:43:56 -0700 (PDT) Received: from localhost (richardc@localhost) by soda.CSUA.Berkeley.EDU (8.6.12/8.6.12) with SMTP id AAA09236; Sun, 13 Oct 1996 00:44:58 -0700 Date: Sun, 13 Oct 1996 00:44:56 -0700 (PDT) From: Veggy Vinny To: Steve Passe cc: smp@freefall.freebsd.org Subject: Re: In-Reply-To: <199610130453.WAA22736@clem.systemsix.com> 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 Sat, 12 Oct 1996, Steve Passe wrote: Hi, > > I'm doing it without any problems... One question, is the latest > > SMP kernel supposed to report FreeBSD-2.2SNAP100496? > > compiled from sources supped early this morning: > > FreeBSD 2.2-961004-SNAP #1: Sat Oct 12 01:42:29 MDT 1996 Same here, mines says: FreeBSD earth.GAIANET.NET 2.2-961004-SNAP FreeBSD 2.2-961004-SNAP #0: Sat Oct 12 11:59:36 PDT 1996 vince@earth.GAIANET.NET:/usr/src/sys-SMP/compile/EARTH-SMP i386 I thought SMP was based on -current and not the SNAP src tree.. Vince From owner-freebsd-smp Sun Oct 13 01:12:59 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA20361 for smp-outgoing; Sun, 13 Oct 1996 01:12:59 -0700 (PDT) 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 BAA20355 for ; Sun, 13 Oct 1996 01:12:54 -0700 (PDT) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.0/8.8.0) with ESMTP id QAA29099; Sun, 13 Oct 1996 16:12:35 +0800 (WST) Message-Id: <199610130812.QAA29099@spinner.DIALix.COM> X-Mailer: exmh version 1.6.9 8/22/96 To: Veggy Vinny cc: Steve Passe , smp@freefall.freebsd.org Subject: Re: In-reply-to: Your message of "Sun, 13 Oct 1996 00:44:56 MST." Date: Sun, 13 Oct 1996 16:12:34 +0800 From: Peter Wemm Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Veggy Vinny wrote: > > > On Sat, 12 Oct 1996, Steve Passe wrote: > > Hi, > > > > I'm doing it without any problems... One question, is the latest > > > SMP kernel supposed to report FreeBSD-2.2SNAP100496? > > > > compiled from sources supped early this morning: > > > > FreeBSD 2.2-961004-SNAP #1: Sat Oct 12 01:42:29 MDT 1996 > > Same here, mines says: > > FreeBSD earth.GAIANET.NET 2.2-961004-SNAP FreeBSD 2.2-961004-SNAP #0: Sat > Oct 12 11:59:36 PDT 1996 > vince@earth.GAIANET.NET:/usr/src/sys-SMP/compile/EARTH-SMP i386 > > I thought SMP was based on -current and not the SNAP src tree.. > > Vince It is based on -current, don't sweat it. I periodically resync with -current, you see the mega-commit messages when I do it. -current had a bad newvers.sh at the time that I did the last import which is why you see the -SNAP label. Jordan accidently committed something he shouldn't.. :-] It's fixed in -current now, and there's been a few VM fixes now that would probably make it worth another resync now. Cheers, -Peter From owner-freebsd-smp Sun Oct 13 01:59:56 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA22551 for smp-outgoing; Sun, 13 Oct 1996 01:59:56 -0700 (PDT) Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA22546 for ; Sun, 13 Oct 1996 01:59:53 -0700 (PDT) Received: from localhost (richardc@localhost) by soda.CSUA.Berkeley.EDU (8.6.12/8.6.12) with SMTP id BAA12427; Sun, 13 Oct 1996 01:58:49 -0700 Date: Sun, 13 Oct 1996 01:58:48 -0700 (PDT) From: Veggy Vinny To: Peter Wemm cc: Steve Passe , smp@freefall.freebsd.org Subject: Re: In-Reply-To: <199610130812.QAA29099@spinner.DIALix.COM> 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 Sun, 13 Oct 1996, Peter Wemm wrote: > > I thought SMP was based on -current and not the SNAP src tree.. > > It is based on -current, don't sweat it. I periodically resync with > -current, you see the mega-commit messages when I do it. -current had a > bad newvers.sh at the time that I did the last import which is why you see > the -SNAP label. Jordan accidently committed something he shouldn't.. :-] > It's fixed in -current now, and there's been a few VM fixes now that > would probably make it worth another resync now. Oh okay, thanks for clarifying this.... SMP seems to work really well except options COMPATLINUX is still not working under SMP but it does for a -current kernel... But you guys are doing a great job! =) Vince From owner-freebsd-smp Sun Oct 13 02:06:00 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA22880 for smp-outgoing; Sun, 13 Oct 1996 02:06:00 -0700 (PDT) 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 CAA22871 for ; Sun, 13 Oct 1996 02:05:55 -0700 (PDT) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.0/8.8.0) with ESMTP id RAA29236; Sun, 13 Oct 1996 17:05:39 +0800 (WST) Message-Id: <199610130905.RAA29236@spinner.DIALix.COM> X-Mailer: exmh version 1.6.9 8/22/96 To: Veggy Vinny cc: Steve Passe , smp@freefall.freebsd.org Subject: Re: In-reply-to: Your message of "Sun, 13 Oct 1996 01:58:48 MST." Date: Sun, 13 Oct 1996 17:05:38 +0800 From: Peter Wemm Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Veggy Vinny wrote: > On Sun, 13 Oct 1996, Peter Wemm wrote: > > > I thought SMP was based on -current and not the SNAP src tree.. > > > > It is based on -current, don't sweat it. I periodically resync with > > -current, you see the mega-commit messages when I do it. -current had a > > bad newvers.sh at the time that I did the last import which is why you see > > the -SNAP label. Jordan accidently committed something he shouldn't.. :-] > > It's fixed in -current now, and there's been a few VM fixes now that > > would probably make it worth another resync now. > > Oh okay, thanks for clarifying this.... SMP seems to work really > well except options COMPATLINUX is still not working under SMP but it does > for a -current kernel... But you guys are doing a great job! =) I just wish I had the time and energy to try and keep up with Steve at the moment.. ;-) He's been going like a dynamo for the last few weeks, leaving the rest of us in the dust.. > Vince Cheers, -Peter From owner-freebsd-smp Sun Oct 13 02:07:57 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA22993 for smp-outgoing; Sun, 13 Oct 1996 02:07:57 -0700 (PDT) Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA22985 for ; Sun, 13 Oct 1996 02:07:55 -0700 (PDT) Received: from localhost (richardc@localhost) by soda.CSUA.Berkeley.EDU (8.6.12/8.6.12) with SMTP id CAA12882; Sun, 13 Oct 1996 02:08:48 -0700 Date: Sun, 13 Oct 1996 02:08:47 -0700 (PDT) From: Veggy Vinny To: Peter Wemm cc: Steve Passe , smp@freefall.freebsd.org Subject: Re: In-Reply-To: <199610130905.RAA29236@spinner.DIALix.COM> 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 Sun, 13 Oct 1996, Peter Wemm wrote: > I just wish I had the time and energy to try and keep up with Steve at the > moment.. ;-) He's been going like a dynamo for the last few weeks, > leaving the rest of us in the dust.. Yep, Steve has been pretty active it seems, committing the changes and answering all the SMP related questions.... Vince From owner-freebsd-smp Sun Oct 13 05:07:19 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA04796 for smp-outgoing; Sun, 13 Oct 1996 05:07:19 -0700 (PDT) Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id FAA04789 for ; Sun, 13 Oct 1996 05:07:17 -0700 (PDT) Received: by rodan.UU.NET id QQblga28994; Sun, 13 Oct 1996 08:07:15 -0400 (EDT) Date: Sun, 13 Oct 1996 08:07:15 -0400 (EDT) From: mo@UU.NET (Mike O'Dell) Message-Id: To: smp@freebsd.org Subject: dual-cpu PPRO motherboards... Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk any consensus on the hot setup for dual-cpu PPRO Motherboards? the guys at the MIT Advanced Network Architecture group like the Tyan 1662 and 1668 ATX, but other have had contrary opinions. any advice much appreciated. thanks! -mo From owner-freebsd-smp Sun Oct 13 07:51:49 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA17994 for smp-outgoing; Sun, 13 Oct 1996 07:51:49 -0700 (PDT) Received: from uno.sat.t.u-tokyo.ac.jp (uno.sat.t.u-tokyo.ac.jp [133.11.70.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA17985 for ; Sun, 13 Oct 1996 07:51:43 -0700 (PDT) Received: by uno.sat.t.u-tokyo.ac.jp (8.7.3+2.6Wbeta5/8.7.3) with ESMTP id XAA22587; Sun, 13 Oct 1996 23:51:12 +0900 (JST) To: Veggy Vinny Cc: Steve Passe , smp@freefall.freebsd.org Subject: Re: Re: X-Mailer: Mew version 1.06 on Emacs 19.28.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sun, 13 Oct 1996 23:51:12 +0900 Message-ID: <22585.845218272@sat.t.u-tokyo.ac.jp> From: Hidetoshi Shimokawa Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, From: Veggy Vinny Subject: Re: Date: Sun, 13 Oct 1996 01:58:48 -0700 (PDT) Message-ID: > Oh okay, thanks for clarifying this.... SMP seems to work really > well except options COMPATLINUX is still not working under SMP but it does > for a -current kernel... But you guys are doing a great job! =) I thinks the following patch makes linux emulation run. *** linux_misc.c.orig Sat Jul 27 07:01:08 1996 --- linux_misc.c Mon Sep 30 23:03:30 1996 *************** *** 687,693 **** #ifdef DEBUG printf("Linux-emul(%d): times(*)\n", p->p_pid); #endif ! calcru(p, &ru.ru_utime, &ru.ru_stime, NULL); tms.tms_utime = CONVTCK(ru.ru_utime); tms.tms_stime = CONVTCK(ru.ru_stime); --- 687,693 ---- #ifdef DEBUG printf("Linux-emul(%d): times(*)\n", p->p_pid); #endif ! calcru(p, &ru.ru_utime, &ru.ru_stime, NULL, "linux_times"); tms.tms_utime = CONVTCK(ru.ru_utime); tms.tms_stime = CONVTCK(ru.ru_stime); /\ Hidetoshi Shimokawa \/ simokawa@sat.t.u-tokyo.ac.jp PGP public key: finger -l simokawa@sat.t.u-tokyo.ac.jp From owner-freebsd-smp Sun Oct 13 09:41:30 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA24166 for smp-outgoing; Sun, 13 Oct 1996 09:41:30 -0700 (PDT) Received: from omnigate.clarkson.edu (omnigate.clarkson.edu [128.153.4.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA24155 for ; Sun, 13 Oct 1996 09:41:23 -0700 (PDT) Received: from craft.camp.clarkson.edu by omnigate.clarkson.edu with smtp (Smail3.1.29.1 #7) id m0vCTc2-0001U5C; Sun, 13 Oct 96 12:42 EDT Received: from fire.camp.clarkson.edu by craft.camp.clarkson.edu (AIX 3.2/UCB 5.64/4.03) id AA37099; Sun, 13 Oct 1996 12:41:11 -0400 Received: from localhost (todam@localhost) by fire.camp.clarkson.edu (8.6.8.1/8.6.6) with SMTP id MAA101053 for ; Sun, 13 Oct 1996 12:41:11 -0400 X-Authentication-Warning: fire.camp.clarkson.edu: todam owned process doing -bs Date: Sun, 13 Oct 1996 12:41:11 -0400 (EDT) From: Minoru Toda To: SMP Discussion Subject: SMP kernel won't compile Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi folks. I'm new in here, and I am attempting to compile a SMP kernel on my Tyan Tomcat II motherboard (with two Pentium 133s). I have followed the directions posted on http://www.freebsd.org/~fsmp, and downloaded latest snap shot, then supped smp, but I don't get it to compile at all.. (the compiler gives bunch of errors, always at different locations). Can you guys give me some hints on how to tweak with the compiler ? Thanks. Minoru Toda todam@craft.camp.clarkson.edu From owner-freebsd-smp Sun Oct 13 09:58:56 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA24977 for smp-outgoing; Sun, 13 Oct 1996 09:58:56 -0700 (PDT) Received: from po1.glue.umd.edu (po1.glue.umd.edu [129.2.128.44]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA24970 for ; Sun, 13 Oct 1996 09:58:54 -0700 (PDT) Received: from thurston.eng.umd.edu (thurston.eng.umd.edu [129.2.103.25]) by po1.glue.umd.edu (8.8.0/8.7.3) with ESMTP id MAA25690; Sun, 13 Oct 1996 12:58:50 -0400 (EDT) Received: from localhost (chuckr@localhost) by thurston.eng.umd.edu (8.7.5/8.7.3) with SMTP id MAA19089; Sun, 13 Oct 1996 12:58:50 -0400 (EDT) X-Authentication-Warning: thurston.eng.umd.edu: chuckr owned process doing -bs Date: Sun, 13 Oct 1996 12:58:50 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@thurston.eng.umd.edu To: Minoru Toda cc: SMP Discussion Subject: Re: SMP kernel won't compile 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 On Sun, 13 Oct 1996, Minoru Toda wrote: > Hi folks. I'm new in here, and I am attempting to compile a SMP kernel on > my Tyan Tomcat II motherboard (with two Pentium 133s). > > I have followed the directions posted on http://www.freebsd.org/~fsmp, > and downloaded latest snap shot, then supped smp, but I don't get it > to compile at all.. (the compiler gives bunch of errors, always at > different locations). Can you guys give me some hints on how to tweak with > the compiler ? Thanks. You'll get a lot more help if you give folks some idea as to what went wrong, i.e, the last 20 lines of the compiler output. The smp code does usually compile, like the normal kernel code does, although it does go thru short breakages now and then. > > > Minoru Toda > todam@craft.camp.clarkson.edu > > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and n3lxx, both FreeBSD (301) 220-2114 | version 2.2 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-smp Sun Oct 13 10:08:05 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA25426 for smp-outgoing; Sun, 13 Oct 1996 10:08:05 -0700 (PDT) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA25417 for freebsd-smp; Sun, 13 Oct 1996 10:08:03 -0700 (PDT) Date: Sun, 13 Oct 1996 10:08:03 -0700 (PDT) From: Peter Wemm Message-Id: <199610131708.KAA25417@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/linux linux_misc.c Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/10/13 10:08:02 Modified: i386/linux linux_misc.c Log: This should make the linux emulation compile and run Submitted by: Hidetoshi Shimokawa Revision Changes Path 1.2 +5 -9 sys/i386/linux/linux_misc.c From owner-freebsd-smp Sun Oct 13 11:16:04 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA28919 for smp-outgoing; Sun, 13 Oct 1996 11:16:04 -0700 (PDT) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA28910 for freebsd-smp; Sun, 13 Oct 1996 11:16:02 -0700 (PDT) Date: Sun, 13 Oct 1996 11:16:02 -0700 (PDT) From: Peter Wemm Message-Id: <199610131816.LAA28910@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: sys/i386/include smpasm.h apic.h Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/10/13 11:16:02 Modified: i386/include smpasm.h apic.h Log: smpasm.h was missing a copyright and permission to copy, update the apic.h copright. Revision Changes Path 1.6 +26 -0 sys/i386/include/smpasm.h 1.10 +5 -6 sys/i386/include/apic.h From owner-freebsd-smp Sun Oct 13 14:31:32 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA07068 for smp-outgoing; Sun, 13 Oct 1996 14:31:32 -0700 (PDT) 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 OAA07062 for ; Sun, 13 Oct 1996 14:31:25 -0700 (PDT) Received: from MindBender.serv.net by mx.serv.net (8.7.5/SERV Revision: 2.30) id OAA29305; Sun, 13 Oct 1996 14:30:39 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.serv.net (8.7.5/8.7.3) with SMTP id OAA12954; Sun, 13 Oct 1996 14:29:13 -0700 (PDT) Message-Id: <199610132129.OAA12954@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: mo@UU.NET (Mike O'Dell) cc: smp@freebsd.org Subject: Re: dual-cpu PPRO motherboards... In-reply-to: Your message of Sun, 13 Oct 96 08:07:15 -0400. Date: Sun, 13 Oct 1996 14:28:31 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >any consensus on the hot setup for dual-cpu PPRO Motherboards? >the guys at the MIT Advanced Network Architecture group like the >Tyan 1662 and 1668 ATX, but other have had contrary opinions. >any advice much appreciated. I've never tried a Tyan, but have heard good things about them. I have heard of people successfully using SuperMicro P6DNF boards. But, I've also heard of quality-control problems with SuperMicro. And, I personally have had a bad experience with them. I currently have an Asus single-processor P6NP5, that works quite excellently. FYI... ----------------------------------------------------------------------------- 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 Sun Oct 13 14:34:19 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA07158 for smp-outgoing; Sun, 13 Oct 1996 14:34:19 -0700 (PDT) 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 OAA07147 for ; Sun, 13 Oct 1996 14:34:15 -0700 (PDT) Received: from MindBender.serv.net by mx.serv.net (8.7.5/SERV Revision: 2.30) id OAA29339; Sun, 13 Oct 1996 14:31:56 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.serv.net (8.7.5/8.7.3) with SMTP id OAA13000; Sun, 13 Oct 1996 14:30:56 -0700 (PDT) Message-Id: <199610132130.OAA13000@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: mo@UU.NET (Mike O'Dell) cc: smp@freebsd.org Subject: Re: dual-cpu PPRO motherboards... In-reply-to: Your message of Sun, 13 Oct 96 08:07:15 -0400. Date: Sun, 13 Oct 1996 14:30:55 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >any consensus on the hot setup for dual-cpu PPRO Motherboards? >the guys at the MIT Advanced Network Architecture group like the >Tyan 1662 and 1668 ATX, but other have had contrary opinions. >any advice much appreciated. Oh, also... don't buy from Aberdeen. I have bad stories to tell about their service/RMA department... ----------------------------------------------------------------------------- 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 Sun Oct 13 15:23:13 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA08922 for smp-outgoing; Sun, 13 Oct 1996 15:23:13 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA08916 for ; Sun, 13 Oct 1996 15:23:09 -0700 (PDT) Received: by mail4.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24) id <01BBB91A.4F5B91B0@mail4.microsoft.com>; Sun, 13 Oct 1996 15:22:13 -0700 Message-ID: From: Thomas Pfenning To: "'mo@UU.NET'" Cc: "'smp@freebsd.org'" Subject: RE: dual-cpu PPRO motherboards... Date: Sun, 13 Oct 1996 15:22:47 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24 Encoding: 34 TEXT Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Mike, we just received a Tomcat 2 with hardware revision 4, which is just a dual Pentium board but shows a trend. Tyan decided in their great wisdom that people will always want the IDE interrupts and hardwired them to 14 and 15. This combined with the Award BIOS (same functionality as with the Natoma) prevents our brand new machine from even booting the floppy. The Award Bios does not allow you to manually assign a fixed interrupt to a PCI slot. In our configuration both the automatic and the manual mode of the BIOS fail which is only a partial surprise since we need more interrupts than left by subtracting 14 and 15. This might not apply to the Natoma board but I would double check that the configuration you have in mind actually works. Cheers Thomas >-----Original Message----- >From: mo@UU.NET [SMTP:mo@UU.NET] >Sent: Sunday, October 13, 1996 5:07 AM >To: smp@freebsd.org >Subject: dual-cpu PPRO motherboards... > > >any consensus on the hot setup for dual-cpu PPRO Motherboards? >the guys at the MIT Advanced Network Architecture group like the >Tyan 1662 and 1668 ATX, but other have had contrary opinions. >any advice much appreciated. > > thanks! > -mo From owner-freebsd-smp Sun Oct 13 15:43:57 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA09857 for smp-outgoing; Sun, 13 Oct 1996 15:43:57 -0700 (PDT) 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 PAA09851 for ; Sun, 13 Oct 1996 15:43:52 -0700 (PDT) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.0/8.8.0) with ESMTP id GAA02894; Mon, 14 Oct 1996 06:43:20 +0800 (WST) Message-Id: <199610132243.GAA02894@spinner.DIALix.COM> X-Mailer: exmh version 1.6.9 8/22/96 To: Thomas Pfenning cc: "'mo@UU.NET'" , "'smp@freebsd.org'" Subject: Re: dual-cpu PPRO motherboards... In-reply-to: Your message of "Sun, 13 Oct 1996 15:22:47 MST." Date: Mon, 14 Oct 1996 06:43:20 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Thomas Pfenning wrote: > Hi Mike, > > we just received a Tomcat 2 with hardware revision 4, which is just a > dual Pentium board but shows a trend. Tyan decided in their great wisdom > that people will always want the IDE interrupts and hardwired them to 14 > and 15. This combined with the Award BIOS (same functionality as with > the Natoma) prevents our brand new machine from even booting the floppy. > > The Award Bios does not allow you to manually assign a fixed interrupt > to a PCI slot. In our configuration both the automatic and the manual > mode of the BIOS fail which is only a partial surprise since we need > more interrupts than left by subtracting 14 and 15. Hmm, I read somewhere that the Triton-II HX chipset "doesn't support interrupt steering", perhaps this is what they meant? What is the Tomcat 2's chipset? The other "interesting" news is that the mpspec1.4 compliant motherboards are supposed to have the PCI interrupts wired to different APIC interrupt inputs. The IO APIC chipset that goes with the T2-HX pciset and friends has 24 interrupt inputs, of which the first 16 typically go to the ISA bus, the next 4 go to the PCI bus, and the spares are used for other things like SMI and so on. With the work that Steve's been doing on the IO APIC stuff to get it running in full symmetric IO mode (rather than virtual wire), this restriction should become only a bootstrap problem. Once the system is running fully symmetric, you have a total of 20 interrupts available. The IDE interrupts will disappear from irq-14 and 15 once it's switched to symmetric mode, so if you have smart cards in there that have programmable irq's, those will be available for assignment shortly after boot. Once the pci code has been "taught" about interrupts that change after bootup and when to ignore the irq mapping registers, it should be nice. There's a lot of hard coded stuff at the moment that suits Steve's particular machine though, for some strange reason. ;-) Cheers, -Peter From owner-freebsd-smp Sun Oct 13 15:52:25 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA10224 for smp-outgoing; Sun, 13 Oct 1996 15:52:25 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA10219 for ; Sun, 13 Oct 1996 15:52:23 -0700 (PDT) Received: by mail4.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24) id <01BBB91E.6EC67D40@mail4.microsoft.com>; Sun, 13 Oct 1996 15:51:44 -0700 Message-ID: From: Thomas Pfenning To: "'Peter Wemm'" , "'Tonyhain@mirosoft.com'" Cc: "'mo@UU.NET'" , "'smp@freebsd.org'" Subject: RE: dual-cpu PPRO motherboards... Date: Sun, 13 Oct 1996 15:52:17 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.24 Encoding: 61 TEXT Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The Tomcat is indeed a HX board. Is interrupt steering supported by the Natoma? What you describe actually happens when we boot the box with NT4.0. While the BIOS assigns 255 (no assignment) all devices are mapped to interrupts as soon as NT takes control. I can't wait to see the SMP changes make it on a boot floppy because otherwise I have to put the disk into a different machine to bootstrap. Cheers Thomas >-----Original Message----- >From: Peter Wemm [SMTP:peter@spinner.DIALix.COM] >Sent: Sunday, October 13, 1996 3:43 PM >To: Thomas Pfenning >Cc: 'mo@UU.NET'; 'smp@freebsd.org' >Subject: Re: dual-cpu PPRO motherboards... > >Thomas Pfenning wrote: >> Hi Mike, >> >> we just received a Tomcat 2 with hardware revision 4, which is just a >> dual Pentium board but shows a trend. Tyan decided in their great wisdom >> that people will always want the IDE interrupts and hardwired them to 14 >> and 15. This combined with the Award BIOS (same functionality as with >> the Natoma) prevents our brand new machine from even booting the floppy. >> >> The Award Bios does not allow you to manually assign a fixed interrupt >> to a PCI slot. In our configuration both the automatic and the manual >> mode of the BIOS fail which is only a partial surprise since we need >> more interrupts than left by subtracting 14 and 15. > >Hmm, I read somewhere that the Triton-II HX chipset "doesn't support >interrupt steering", perhaps this is what they meant? What is the Tomcat >2's chipset? > >The other "interesting" news is that the mpspec1.4 compliant motherboards >are supposed to have the PCI interrupts wired to different APIC interrupt >inputs. The IO APIC chipset that goes with the T2-HX pciset and friends >has 24 interrupt inputs, of which the first 16 typically go to the ISA >bus, the next 4 go to the PCI bus, and the spares are used for other >things like SMI and so on. > >With the work that Steve's been doing on the IO APIC stuff to get it >running in full symmetric IO mode (rather than virtual wire), this >restriction should become only a bootstrap problem. Once the system is >running fully symmetric, you have a total of 20 interrupts available. The >IDE interrupts will disappear from irq-14 and 15 once it's switched to >symmetric mode, so if you have smart cards in there that have programmable >irq's, those will be available for assignment shortly after boot. Once >the pci code has been "taught" about interrupts that change after bootup >and when to ignore the irq mapping registers, it should be nice. There's >a lot of hard coded stuff at the moment that suits Steve's particular >machine though, for some strange reason. ;-) > >Cheers, >-Peter > > From owner-freebsd-smp Sun Oct 13 22:04:38 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA26008 for smp-outgoing; Sun, 13 Oct 1996 22:04:38 -0700 (PDT) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA26003 for ; Sun, 13 Oct 1996 22:04:35 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.7.5/8.7.3) id WAA12579; Sun, 13 Oct 1996 22:02:38 -0700 (PDT) From: "Rodney W. Grimes" Message-Id: <199610140502.WAA12579@GndRsh.aac.dev.com> Subject: Re: dual-cpu PPRO motherboards... In-Reply-To: <199610132129.OAA12954@MindBender.serv.net> from "Michael L. VanLoon -- HeadCandy.com" at "Oct 13, 96 02:28:31 pm" To: michaelv@MindBender.serv.net (Michael L. VanLoon -- HeadCandy.com) Date: Sun, 13 Oct 1996 22:02:38 -0700 (PDT) Cc: mo@UU.NET, 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 > > >any consensus on the hot setup for dual-cpu PPRO Motherboards? > >the guys at the MIT Advanced Network Architecture group like the > >Tyan 1662 and 1668 ATX, but other have had contrary opinions. > >any advice much appreciated. > > I've never tried a Tyan, but have heard good things about them. > > I have heard of people successfully using SuperMicro P6DNF boards. > But, I've also heard of quality-control problems with SuperMicro. > And, I personally have had a bad experience with them. > > I currently have an Asus single-processor P6NP5, that works quite > excellently. FYI... I have just aquired an ASUS P65UP5 w/C-P6ND Dual Pentium Pro daughter card, but due to the recent (last 3 weeks) price surge in Pentium Pro chips I have not had any of them around to do testing with :-(. Anyone out there tried this board? Or anyone interested in purchasing one of these? (A bit pricey at $696.00) Or anyone have a pair of PPro's in the pdx area who wants to borrow it and give it a test drive? -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD From owner-freebsd-smp Sun Oct 13 23:26:53 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA01261 for smp-outgoing; Sun, 13 Oct 1996 23:26:53 -0700 (PDT) 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 XAA01246 for ; Sun, 13 Oct 1996 23:26:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id AAA29680 for ; Mon, 14 Oct 1996 00:26:36 -0600 Message-Id: <199610140626.AAA29680@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: Re: dual-cpu PPRO motherboards... In-reply-to: Your message of "Mon, 14 Oct 1996 06:43:20 +0800." <199610132243.GAA02894@spinner.DIALix.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Oct 1996 00:26:36 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > > more interrupts than left by subtracting 14 and 15. > > Hmm, I read somewhere that the Triton-II HX chipset "doesn't support > interrupt steering", perhaps this is what they meant? What is the Tomcat > 2's chipset? my board (gigabyte 586DX) has the triton II and does what I would call semi-automatic INT steering, specifically from the AWARD BIOS I can assign each INT as: "disabled": never tried, guess it is a "hard mask" "legacy ISA": PCI leaves it alone "PCI/ISA PnP": BIOS uses some unknown (to me) algorithm to pick INTS from any of these. > The other "interesting" news is that the mpspec1.4 compliant motherboards > are supposed to have the PCI interrupts wired to different APIC interrupt > inputs. The IO APIC chipset that goes with the T2-HX pciset and friends > has 24 interrupt inputs, of which the first 16 typically go to the ISA > bus, the next 4 go to the PCI bus, and the spares are used for other > things like SMI and so on. > > With the work that Steve's been doing on the IO APIC stuff to get it > running in full symmetric IO mode (rather than virtual wire), this > restriction should become only a bootstrap problem. Once the system is > running fully symmetric, you have a total of 20 interrupts available. The theoretical limit is 24, on mine I have 21: 1 cascade of MASTER 8259 INTR out (not used in symmetric mode). 15 ISA. (8259 SLAVE out has no meaning) 4 PCI. 1 SMI (System Management INT) > IDE interrupts will disappear from irq-14 and 15 once it's switched to > symmetric mode, so if you have smart cards in there that have programmable > irq's, those will be available for assignment shortly after boot. Once I'm not sure about this, from what I've seen in the tyan news group, I think they may have REALLY tied those suckers down to IRQ-14/15. and thus I would expect them to be directly tied to IO APIC INTs 14/15. There may be nothing programmatic that you can do to free them up for other use. But what does change is that you have the additional IO APIC INTS 16 thru 23, 4 of which will be available for your PCI cards. Which means they won't have to compete with ISA cards for the 1st 16 INTS. And they are direct, active low, level triggered INTs (if so programmed), so they should be sharable (although sharing will require additional code changes). It's my hope that the PCI INTs will be "free-able", but even that may be a vendor specific issue. The bottom line is that it SHOULD be do-able, but you are still at the mercy of your motherboard's design. > irq's, those will be available for assignment shortly after boot. Once > the pci code has been "taught" about interrupts that change after bootup > and when to ignore the irq mapping registers, it should be nice. There's STefan has said he will give me the necessary changes in pci.c to make that last restriction go away within a few days. If he can't get to it by next week, I have an idea for making my current "PCI bandaid" automatic as oppossed to hardcoded, so there will be a fix soon either way. At that point the kernel should be usable in ISA/EISA/PCI boards with native IO APIC code in effect (but you won't be able to use EISA boards yet, there is something going on with them that is still to be determined). > a lot of hard coded stuff at the moment that suits Steve's particular > machine though, for some strange reason. ;-) very little anymore. the last round of commits I did remove all the hardcoded numbers EXCEPT those for the PCI bus. Each IO APIC pin is programmed according to the declared use in the MP table, including edge/level, hi/lo, etc. Some of this is a little murky, as the table may say "conforms to specifications of the bus" which is not necessarily an absolute. The 8254 and the rtc clock vectors are both programmatically determined and setup according to the MP table. I have NOT gotten to look at vmxxx stuff yet so things that gather statistics thinking the clock is on INT0 may be flakey! But the critical stuff in vector.s, icu.s, etc are now all doing "the good thing". -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Mon Oct 14 07:00:59 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA28759 for smp-outgoing; Mon, 14 Oct 1996 07:00:59 -0700 (PDT) Received: from po1.glue.umd.edu (po1.glue.umd.edu [129.2.128.44]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA28753 for ; Mon, 14 Oct 1996 07:00:56 -0700 (PDT) Received: from protocol.eng.umd.edu (protocol.eng.umd.edu [129.2.98.180]) by po1.glue.umd.edu (8.8.0/8.7.3) with ESMTP id KAA13093 for ; Mon, 14 Oct 1996 10:00:50 -0400 (EDT) Received: from localhost (chuckr@localhost) by protocol.eng.umd.edu (8.7.5/8.7.3) with SMTP id KAA01746 for ; Mon, 14 Oct 1996 10:00:49 -0400 (EDT) X-Authentication-Warning: protocol.eng.umd.edu: chuckr owned process doing -bs Date: Mon, 14 Oct 1996 10:00:48 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@protocol.eng.umd.edu To: freebsd-smp@freebsd.org Subject: Which is the better deal Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have two options available to me, in getting the twin cpus for a Pentium Pro smp board. I can't afford the price of 200MHz cpus, they gone past $900 each, but I can get either: 166 MHz with 512 K Cache or 180 MHz with 256 K Cache I intend this for FreeBSD only, don't bother about things like MS software. I can get either for less than $550 each, what's your guys feelings about which might be better? BTW, this would be on a 64MB system, with 4 GB of scsi disk. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and n3lxx, both FreeBSD (301) 220-2114 | version 2.2 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-smp Mon Oct 14 07:12:39 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA29347 for smp-outgoing; Mon, 14 Oct 1996 07:12:39 -0700 (PDT) Received: from critter.tfs.com ([140.145.230.252]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA29333; Mon, 14 Oct 1996 07:12:34 -0700 (PDT) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id QAA03978; Mon, 14 Oct 1996 16:12:04 +0200 (MET DST) To: Chuck Robey cc: freebsd-smp@freebsd.org Subject: Re: Which is the better deal In-reply-to: Your message of "Mon, 14 Oct 1996 10:00:48 EDT." Date: Mon, 14 Oct 1996 16:12:03 +0200 Message-ID: <3976.845302323@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message , Chuc k Robey writes: >I have two options available to me, in getting the twin cpus for a Pentium >Pro smp board. I can't afford the price of 200MHz cpus, they gone past >$900 each, but I can get either: > >166 MHz with 512 K Cache or >180 MHz with 256 K Cache > >I intend this for FreeBSD only, don't bother about things like MS >software. I can get either for less than $550 each, what's your guys >feelings about which might be better? > >BTW, this would be on a 64MB system, with 4 GB of scsi disk. I'd take the 512K cache any time. The PP seems so cache starved to me that I have decided never to by a 256k version for my own money. -- 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 Oct 14 08:29:27 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA03743 for smp-outgoing; Mon, 14 Oct 1996 08:29:27 -0700 (PDT) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA03738 for ; Mon, 14 Oct 1996 08:29:23 -0700 (PDT) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.7.5/8.7.3) id IAA13106; Mon, 14 Oct 1996 08:29:01 -0700 (PDT) From: "Rodney W. Grimes" Message-Id: <199610141529.IAA13106@GndRsh.aac.dev.com> Subject: Re: Which is the better deal In-Reply-To: <3976.845302323@critter.tfs.com> from Poul-Henning Kamp at "Oct 14, 96 04:12:03 pm" To: phk@critter.tfs.com (Poul-Henning Kamp) Date: Mon, 14 Oct 1996 08:29:01 -0700 (PDT) Cc: chuckr@Glue.umd.edu, 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 > In message , Chuc > k Robey writes: > >I have two options available to me, in getting the twin cpus for a Pentium > >Pro smp board. I can't afford the price of 200MHz cpus, they gone past > >$900 each, but I can get either: > > > >166 MHz with 512 K Cache or > >180 MHz with 256 K Cache > > > >I intend this for FreeBSD only, don't bother about things like MS > >software. I can get either for less than $550 each, what's your guys > >feelings about which might be better? > > > >BTW, this would be on a 64MB system, with 4 GB of scsi disk. > > I'd take the 512K cache any time. The PP seems so cache starved to me > that I have decided never to by a 256k version for my own money. And in additon to phk's reason for the 512K version I will add that this is a 166 chip above, and that is externally clocked at 66MHz, giving a faster memory bus. Stay away from the ppro 150 and 180 for the simple fact that it has an external memory bus clock of 60Mhz. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD From owner-freebsd-smp Mon Oct 14 12:58:03 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA21944 for smp-outgoing; Mon, 14 Oct 1996 12:58:03 -0700 (PDT) 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 MAA21937 for ; Mon, 14 Oct 1996 12:57:58 -0700 (PDT) Received: from MindBender.serv.net by mx.serv.net (8.7.5/SERV Revision: 2.30) id MAA21677; Mon, 14 Oct 1996 12:57:21 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.serv.net (8.7.5/8.7.3) with SMTP id MAA22420; Mon, 14 Oct 1996 12:57:04 -0700 (PDT) Message-Id: <199610141957.MAA22420@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: "Rodney W. Grimes" cc: phk@critter.tfs.com (Poul-Henning Kamp), chuckr@Glue.umd.edu, freebsd-smp@freebsd.org Subject: Re: Which is the better deal In-reply-to: Your message of Mon, 14 Oct 96 08:29:01 -0700. <199610141529.IAA13106@GndRsh.aac.dev.com> Date: Mon, 14 Oct 1996 12:57:04 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> In message , Chuc >> k Robey writes: >> >I have two options available to me, in getting the twin cpus for a Pentium >> >Pro smp board. I can't afford the price of 200MHz cpus, they gone past >> >$900 each, but I can get either: >> > >> >166 MHz with 512 K Cache or >> >180 MHz with 256 K Cache >> > >> >I intend this for FreeBSD only, don't bother about things like MS >> >software. I can get either for less than $550 each, what's your guys >> >feelings about which might be better? >> > >> >BTW, this would be on a 64MB system, with 4 GB of scsi disk. >> >> I'd take the 512K cache any time. The PP seems so cache starved to me >> that I have decided never to by a 256k version for my own money. > >And in additon to phk's reason for the 512K version I will add that this >is a 166 chip above, and that is externally clocked at 66MHz, giving >a faster memory bus. Stay away from the ppro 150 and 180 for the simple >fact that it has an external memory bus clock of 60Mhz. This applies to Pentiums, as well. I have done tests on my own Pentium that conclude that, for Unix type work, a 150 will be slightly slower than a 133, and a 180 will definitely be slower than a 166. ----------------------------------------------------------------------------- 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 Mon Oct 14 13:02:02 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA22179 for smp-outgoing; Mon, 14 Oct 1996 13:02:02 -0700 (PDT) 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 NAA22171 for ; Mon, 14 Oct 1996 13:01:58 -0700 (PDT) Received: from MindBender.serv.net by mx.serv.net (8.7.5/SERV Revision: 2.30) id NAA21776; Mon, 14 Oct 1996 13:01:59 -0700 (PDT) Received: from localhost.HeadCandy.com (michaelv@localhost.HeadCandy.com [127.0.0.1]) by MindBender.serv.net (8.7.5/8.7.3) with SMTP id NAA22442; Mon, 14 Oct 1996 13:01:42 -0700 (PDT) Message-Id: <199610142001.NAA22442@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: Poul-Henning Kamp cc: Chuck Robey , freebsd-smp@freebsd.org Subject: Re: Which is the better deal In-reply-to: Your message of Mon, 14 Oct 96 16:12:03 +0200. <3976.845302323@critter.tfs.com> Date: Mon, 14 Oct 1996 13:01:42 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >In message , Chuc >k Robey writes: >>I have two options available to me, in getting the twin cpus for a Pentium >>Pro smp board. I can't afford the price of 200MHz cpus, they gone past >>$900 each, but I can get either: >> >>166 MHz with 512 K Cache or >>180 MHz with 256 K Cache >> >>I intend this for FreeBSD only, don't bother about things like MS >>software. I can get either for less than $550 each, what's your guys >>feelings about which might be better? >> >>BTW, this would be on a 64MB system, with 4 GB of scsi disk. > >I'd take the 512K cache any time. The PP seems so cache starved to me >that I have decided never to by a 256k version for my own money. Well, in spite of this assessment by several people, my 200MHz 256K Pentium Pro kicks serious ass. It's almost 2.5 times faster than my Pentium 120MHz for Unix type stuff. And I even got close to a 3x speedup doing a large build under NT. Now, I'd love to see a direct comparison between a PP200 256K and a PP200 512K, just to see if there is even more potential performance that I'm not realizing. But, I am certainly *very* satisfied with the performance I'm getting. Every time I do something "heavy" on that machine, I just have to mutter "damn this things fast..." ----------------------------------------------------------------------------- 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 Mon Oct 14 14:51:57 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA28043 for smp-outgoing; Mon, 14 Oct 1996 14:51:57 -0700 (PDT) Received: (from jmb@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA28031; Mon, 14 Oct 1996 14:51:53 -0700 (PDT) From: "Jonathan M. Bresler" Message-Id: <199610142151.OAA28031@freefall.freebsd.org> Subject: Re: Which is the better deal To: michaelv@MindBender.serv.net (Michael L. VanLoon -- HeadCandy.com) Date: Mon, 14 Oct 1996 14:51:53 -0700 (PDT) Cc: phk@critter.tfs.com, chuckr@Glue.umd.edu, freebsd-smp@freebsd.org In-Reply-To: <199610142001.NAA22442@MindBender.serv.net> from "Michael L. VanLoon -- HeadCandy.com" at Oct 14, 96 01:01:42 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Michael L. VanLoon -- HeadCandy.com wrote: > > Now, I'd love to see a direct comparison between a PP200 256K and a > PP200 512K, just to see if there is even more potential performance > that I'm not realizing. But, I am certainly *very* satisfied with the > performance I'm getting. Every time I do something "heavy" on that > machine, I just have to mutter "damn this things fast..." so would i! but please give us solid data, hard facts, not mushy opinions. (not you michael, this is a general comment). someone with access to both please run Hint on each machine and post the results, from the curves we sill be able to which one has the 512kB cache ;) Hint is available at: ftp://ftp.scl.ameslab.gov/pub/HINT/serial/ compiles and runs without modification, new we gotta get a smp version working ;> anyone that gets interested, i have graphs fro a variety of machines. is a pp686 faster than an ultra-1? long data type (haha, the ultra is a dog) floating point (damn close run thing) jmb ps. this is a hardware test, OS does not matter (nearly) shows L1, L2 and main memory speeds. sun sparc 5, 32MB, 4.1.4 or 2.4 the curves are identical. my lowly 486-66 out does both in using long data thanks rod! (we wont talk about floating point. humpf!) -- Jonathan M. Bresler FreeBSD Postmaster jmb@FreeBSD.ORG FreeBSD--4.4BSD Unix for PC clones, source included. http://www.freebsd.org/ PGP 2.6.2 Fingerprint: 31 57 41 56 06 C1 40 13 C5 1C E3 E5 DC 62 0E FB From owner-freebsd-smp Mon Oct 14 22:16:17 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA28850 for smp-outgoing; Mon, 14 Oct 1996 22:16:17 -0700 (PDT) Received: from trapdoor.aracnet.com (trapdoor.aracnet.com [204.188.47.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA28844 for ; Mon, 14 Oct 1996 22:16:14 -0700 (PDT) Received: from cbrowni2-home (ppp-r57.aracnet.com [205.238.13.59]) by trapdoor.aracnet.com (8.7.4/8.6.9) with SMTP id FAA25560 for ; Tue, 15 Oct 1996 05:15:53 GMT Message-ID: <32631426.1B0F@aracnet.com> Date: Mon, 14 Oct 1996 21:33:42 -0700 From: Chris Browning Reply-To: cbrown@aracnet.com X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: freebsd-smp@freebsd.org Subject: Re: Which is the better deal References: <199610141529.IAA13106@GndRsh.aac.dev.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Rodney W. Grimes wrote: > > > In message , Chuc > > k Robey writes: > > >I have two options available to me, in getting the twin cpus for a Pentium > > >Pro smp board. I can't afford the price of 200MHz cpus, they gone past > > >$900 each, but I can get either: > > > > > >166 MHz with 512 K Cache or > > >180 MHz with 256 K Cache > > > > > >I intend this for FreeBSD only, don't bother about things like MS > > >software. I can get either for less than $550 each, what's your guys > > >feelings about which might be better? > > > > > >BTW, this would be on a 64MB system, with 4 GB of scsi disk. > > > > I'd take the 512K cache any time. The PP seems so cache starved to me > > that I have decided never to by a 256k version for my own money. > > And in additon to phk's reason for the 512K version I will add that this > is a 166 chip above, and that is externally clocked at 66MHz, giving > a faster memory bus. Stay away from the ppro 150 and 180 for the simple > fact that it has an external memory bus clock of 60Mhz. I concur with the above statement. The 66MHz host bus for the 166MHz is a definiate advantage. It increases both the memory and I/O bandwidth. Since you are looking at a dual processor system, the larger cache part will also have another effect... it will lower the bus contention. In a UP system, there is only one processor, so bus contention is not as much of a problem. This is why you may not see as much of an improvement in performance, but I haven't done any experiments. With a 2+ processor system, you have a whole new ball game. Now there are 2+ processor all trying to access memory, I/O, and perform consitency operations. All this requires host bus time. A larger cache will mean that the processor is more likely to find information in its L2 cache and will not have to go out on the bus. It is pretty simple, really. There are numerious papers out there explaining this fact. Enjoy! Chris Disclaimer: I don't speak for anyone :-) -- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzJSHeUAAAEEAKQrvftlb+sbnw0hA5vW2Orzq3rCGypldkYxRdXhx0yWx/dY U2PMqxgTwlOeQl3wA1IIWGMaHhbpPp0IegkOm9HIHEvc2G8uWywN5OvkaVFyuIHL juZ6VSem3cd63bqpNe3ZWtWwQdjFivm+YNeQveV220eTPfTuvbz7xZq+b9WZAAUR tCtDaHJpcyBTaGVybWFuIEJyb3duaW5nIDxjYnJvd25AYXJhY25ldC5jb20+ =NxsF -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Mon Oct 14 22:17:12 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA28893 for smp-outgoing; Mon, 14 Oct 1996 22:17:12 -0700 (PDT) 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 WAA28887 for ; Mon, 14 Oct 1996 22:17:11 -0700 (PDT) Received: from trapdoor.aracnet.com (trapdoor.aracnet.com [204.188.47.1]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id WAA22440 for ; Mon, 14 Oct 1996 22:17:08 -0700 (PDT) Received: from cbrowni2-home (ppp-r57.aracnet.com [205.238.13.59]) by trapdoor.aracnet.com (8.7.4/8.6.9) with SMTP id FAA25507 for ; Tue, 15 Oct 1996 05:15:31 GMT Message-ID: <326310DA.2A9B@aracnet.com> Date: Mon, 14 Oct 1996 21:19:38 -0700 From: Chris Browning Reply-To: cbrown@aracnet.com X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: smp@freebsd.org Subject: Re: dual-cpu PPRO motherboards... References: <199610140626.AAA29680@clem.systemsix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve Passe wrote: > my board (gigabyte 586DX) has the triton II and does what I would call > semi-automatic INT steering, specifically from the AWARD BIOS I can assign > each INT as: > > "disabled": never tried, guess it is a "hard mask" That sounds right. It probably mask out that interupt in which ever devices is providing the 8259 compatibility. > "legacy ISA": PCI leaves it alone > > "PCI/ISA PnP": BIOS uses some unknown (to me) algorithm to pick INTS from > any of these. This setting allows the BIOS to choose the interrupt based on PCI/PnP. I think that typically, the BIOS will try to give the card the same interrupt it requested last time. When a card (PCI atleast) is installed in the system, it request an interrupt from the BIOS. The BIOS will typically give the card this interrupt, unless there is another device on that interrupt that doesn't support interrrupt sharing. Now this can vary greatly depending on how the BIOS is implemented. > > The other "interesting" news is that the mpspec1.4 compliant motherboards > > are supposed to have the PCI interrupts wired to different APIC interrupt > > inputs. I think this is true for MP Spec 1.1 also. > > The IO APIC chipset that goes with the T2-HX pciset and friends > > has 24 interrupt inputs, of which the first 16 typically go to the ISA > > bus, the next 4 go to the PCI bus, and the spares are used for other > > things like SMI and so on. > > > > With the work that Steve's been doing on the IO APIC stuff to get it > > running in full symmetric IO mode (rather than virtual wire), this > > restriction should become only a bootstrap problem. Yes, this is certainly the way to go. > > Once the system is > > running fully symmetric, you have a total of 20 interrupts available. The > > theoretical limit is 24, on mine I have 21: Ah hem, the limit on the APIC bus, according to page 7-11 of the Pentium (TM) Pro Family Developers Manual, Volume 3 is 255. I believe this is standard for all system implementing the APIC bus. Now, your motherboard may limit you to less, but not the APIC bus. > 1 cascade of MASTER 8259 INTR out (not used in symmetric mode). > 15 ISA. (8259 SLAVE out has no meaning) > 4 PCI. > 1 SMI (System Management INT) > > > IDE interrupts will disappear from irq-14 and 15 once it's switched to > > symmetric mode, so if you have smart cards in there that have programmable > > irq's, those will be available for assignment shortly after boot. Once Hmm, I'm not sure if this is true by default. Unless the OS goes in and moves those devices, they will stay where they are. > I'm not sure about this, from what I've seen in the tyan news group, > I think they may have REALLY tied those suckers down to IRQ-14/15. > and thus I would expect them to be directly tied to IO APIC INTs 14/15. > There may be nothing programmatic that you can do to free them up for other > use. I agree. IDE is typically hardwired to INT 14 (and i guess 15 for EIDE from what you say). I don't know if drivers, BIOS, etc will find an IDE device elsewhere. > But what does change is that you have the additional IO APIC INTS 16 thru > 23, 4 of which will be available for your PCI cards. Which means they won't > have to compete with ISA cards for the 1st 16 INTS. Wrong. According to the same page I quoted above, interrupts 16-31 are reserved for processor use. This may be different on a non PPro system. 32-255 are available for general purpose use. Now, from an OS prespective, you may never see 16-31 and the rest may get shifted down, since this is all done in HW. You will have to compete for the ISA interrupts still, unless you have a lot of PCI devices you don't want to be visible at boot time (i.e. moving your super-fancy SCSI card to an interrupt above 15 will mean you can't see it until you get into the OS) > And they are direct, active low, level triggered INTs (if so programmed), > so they should be sharable (although sharing will require additional > code changes). Hmm, it would be good to add this. Things get pretty limited these days without sharing interrupts. Of course, all the drivers will have to be rewritten if they can't handle shared interrupts. > It's my hope that the PCI INTs will be "free-able", but even that may be > a vendor specific issue. The bottom line is that it SHOULD be do-able, > but you are still at the mercy of your motherboard's design. > > > irq's, those will be available for assignment shortly after boot. Once > > the pci code has been "taught" about interrupts that change after bootup > > and when to ignore the irq mapping registers, it should be nice. There's > > STefan has said he will give me the > necessary changes in pci.c to make that last restriction go away within a > few days. If he can't get to it by next week, I have an idea for making > my current "PCI bandaid" automatic as oppossed to hardcoded, so there > will be a fix soon either way. At that point the kernel should be usable > in ISA/EISA/PCI boards with native IO APIC code in effect (but you > won't be able to use EISA boards yet, there is something going on with them > that is still to be determined). > > > a lot of hard coded stuff at the moment that suits Steve's particular > > machine though, for some strange reason. ;-) > > very little anymore. the last round of commits I did remove all the hardcoded > numbers EXCEPT those for the PCI bus. Each IO APIC pin is programmed > according to the declared use in the MP table, including edge/level, hi/lo, > etc. Some of this is a little murky, as the table may say "conforms to > specifications of the bus" which is not necessarily an absolute. The 8254 > and the rtc clock vectors are both programmatically determined and setup > according to the MP table. I have NOT gotten to look at vmxxx stuff yet > so things that gather statistics thinking the clock is on INT0 may be > flakey! But the critical stuff in vector.s, icu.s, etc are now all > doing "the good thing". > > -- > Steve Passe | powered by > smp@csn.net | FreeBSD -- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzJSHeUAAAEEAKQrvftlb+sbnw0hA5vW2Orzq3rCGypldkYxRdXhx0yWx/dY U2PMqxgTwlOeQl3wA1IIWGMaHhbpPp0IegkOm9HIHEvc2G8uWywN5OvkaVFyuIHL juZ6VSem3cd63bqpNe3ZWtWwQdjFivm+YNeQveV220eTPfTuvbz7xZq+b9WZAAUR tCtDaHJpcyBTaGVybWFuIEJyb3duaW5nIDxjYnJvd25AYXJhY25ldC5jb20+ =NxsF -----END PGP PUBLIC KEY BLOCK----- From owner-freebsd-smp Mon Oct 14 23:29:22 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA04305 for smp-outgoing; Mon, 14 Oct 1996 23:29:22 -0700 (PDT) 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 XAA04284 for ; Mon, 14 Oct 1996 23:29:04 -0700 (PDT) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.0/8.8.0) with ESMTP id OAA18081; Tue, 15 Oct 1996 14:27:12 +0800 (WST) Message-Id: <199610150627.OAA18081@spinner.DIALix.COM> X-Mailer: exmh version 1.6.9 8/22/96 To: cbrown@aracnet.com cc: smp@freebsd.org Subject: Re: dual-cpu PPRO motherboards... In-reply-to: Your message of "Mon, 14 Oct 1996 21:19:38 MST." <326310DA.2A9B@aracnet.com> Date: Tue, 15 Oct 1996 14:27:12 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Chris Browning wrote: > Steve Passe wrote: > > > Once the system is > > > running fully symmetric, you have a total of 20 interrupts available. Th e > > > > theoretical limit is 24, on mine I have 21: > > Ah hem, the limit on the APIC bus, according to page 7-11 of the Pentium > (TM) Pro > Family Developers Manual, Volume 3 is 255. I believe this is standard > for all > system implementing the APIC bus. Now, your motherboard may limit you > to less, but not > the APIC bus. We were talking about the software side of it. :-) The limit used to be 16 hardware interrupts, we can now deal with 24, although we could probably squeeze a few more in. The software "interrupts" take a few slots too. We've been talking offline about an alternate strategy which should allow us to do masking for all 224 possible IDT entries, not just the 16 (or 24) that correspond to hardware origin. > > 1 cascade of MASTER 8259 INTR out (not used in symmetric mode). > > 15 ISA. (8259 SLAVE out has no meaning) > > 4 PCI. > > 1 SMI (System Management INT) > > > > > IDE interrupts will disappear from irq-14 and 15 once it's switched to > > > symmetric mode, so if you have smart cards in there that have programmabl e > > > irq's, those will be available for assignment shortly after boot. Once > > Hmm, I'm not sure if this is true by default. Unless the OS goes in and > moves those > devices, they will stay where they are. According to the mpspec, there is a pci->isa mapping system that is supposed to "sense" when the system switches into symmetric mode and disable itself when the io apics are activated. So, it depends on how the ide irq's originate I guess. If they originate as "pci interrupts" that go through the redirection matrix, then in theory the isa irq14/15 signals should be freed up. However, Intel could well have hardwired it so that the piix3 chipset generates isa edge triggered interrupts only and cannot do pci-style level sensative irq's. Is the 8259-workalike in the piix3 in the 430HX chipset or in the other "big" chip? If the ide and 8259's are on the same chunk of silicon, they may be hardwired on the chip with the on-chip IDE only being "on" or "off" on the hardwired configuration. Specifically, it says that if the motherboard doesn't support PIC mode and the IMCR, there cannot be any other steps to disable the remapping.. It has to be automatic when the apics are programmed. If the IMCR is present, it can use that to turn the pci irq map registers on and off. > > But what does change is that you have the additional IO APIC INTS 16 thru > > 23, 4 of which will be available for your PCI cards. Which means they won't > > have to compete with ISA cards for the 1st 16 INTS. > > Wrong. According to the same page I quoted above, interrupts 16-31 are > reserved for processor > use. This may be different on a non PPro system. 32-255 are available > for general purpose use. > Now, from an OS prespective, you may never see 16-31 and the rest may > get shifted down, since this > is all done in HW. You are confusing the isa hardware interrupts with the processor's IDT (interrupt descriptor table). Currently, the 16 isa interrupts are mapped into IDT entries 32 through 47. With the work Steve's been doing, the IO Apic's have vector numbers 32 through 55 programmed into them. So, when the 8259 pics are disabled, the IO APIC produces the exact same interrupt vectors, just more of them. Currently the IRQ's are directly mapped in a 1:1 ratio to the IDT table, but there's no need to. If there's a space squeeze to fit all the devices into a 32 bit mask, for example, there's nothing stopping us compacting it. Only one IO apic is supported at present, but I think we know about one motherboard that has two IO apic's already (and two pci busses, etc), so we've got to deal with having 48 or so hardware IRQ's on currently existing hardware. The present irq masking architecture depends on being able to locate the originating IO apic quickly to mask further interrupts during the handler, so having both IO apics generating overlapping IDT vectors is "too hard" at present. I'm sure Steve will yell if I've misunderstood his code. > You will have to compete for the ISA interrupts still, unless you have a > lot of PCI devices > you don't want to be visible at boot time (i.e. moving your super-fancy > SCSI card to an > interrupt above 15 will mean you can't see it until you get into the OS) No, this is not an issue.. The BIOS boots in "virtual wire" mode, with the PCI->ISA mapping active. So, an arbitrary PCI interrupt may already be hardwired to the IO APIC on int18, and _also_ be switched through to the inputs of the 8259-clone PICs. The APIC only sees the given pci IRQ line on interrupt 18, and never sees the result of the pci->isa mapping to the 8259 pics. > > And they are direct, active low, level triggered INTs (if so programmed), > > so they should be sharable (although sharing will require additional > > code changes). > > Hmm, it would be good to add this. Things get pretty limited these days > without > sharing interrupts. Of course, all the drivers will have to be > rewritten if they can't > handle shared interrupts. I believe the existing PCI irq code already handles this. It's just a matter of making sure that it still works with the APIC's active. I have not looked at Steve's changes to the pci code yet. The "problem" is that we have to make sure that we can handle any "curve ball"'s that may be in the various motherboard's mpconfig tables. If the mp table says that pci device 6 is on apic channel #18, we don't have a choice, the motherboard is wired that way and the pci->isa irq mapping refisters are no longer present. If it says that the piix3 is hardwired to 'edge trigger' mode on irq14 even after switching to symmetric mode, we simply have to deal with it. Cheers, -Peter From owner-freebsd-smp Tue Oct 15 01:17:21 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA11932 for smp-outgoing; Tue, 15 Oct 1996 01:17:21 -0700 (PDT) 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 BAA11925 for ; Tue, 15 Oct 1996 01:17:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id CAA07140; Tue, 15 Oct 1996 02:16:28 -0600 Message-Id: <199610150816.CAA07140@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: cbrown@aracnet.com, smp@freebsd.org Subject: Re: dual-cpu PPRO motherboards... In-reply-to: Your message of "Tue, 15 Oct 1996 14:27:12 +0800." <199610150627.OAA18081@spinner.DIALix.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Oct 1996 02:16:28 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, >Chris Browning wrote: >> Steve Passe wrote: >> ... >> Ah hem, the limit on the APIC bus, according to page 7-11 of the Pentium >> (TM) Pro >> Family Developers Manual, Volume 3 is 255. I believe this is standard >> ... > >We were talking about the software side of it. :-) The limit used to be >16 hardware interrupts, we can now deal with 24, although we could >probably squeeze a few more in. The software "interrupts" take a few >slots too. Even more specifically, we are talking about the INPUT capabilities of the IO APIC, a discrete component, NOT the "local APICs" found on P5/P6 CPUs. --- >Is the 8259-workalike in the piix3 in the 430HX chipset or in the other >"big" chip? It appears that it is in the piix3. looking this up I found another missing piece of the puzzle: section 2.2.10 of the piix3 manual. This documents the PI/ISA INT redirection registers. It states: "When a PIRQ signal is routed to an interrupt controller IRQ the PIIX/PIIX3 masks the corresponding IRQ signal." So setting the "disable" bit in one of these registers should free the corresponding ISA INT for use by other hardware (ie 'disable' should both unamsk the ISA bus IRQ and and undirect the PCI PIRQ.) --- >> sharing interrupts. Of course, all the drivers will have to be >> rewritten if they can't >> handle shared interrupts. > >>I believe the existing PCI irq code already handles this. It's just a >matter of making sure that it still works with the APIC's active. I have >not looked at Steve's changes to the pci code yet. At on time I thought I saw something in the generic (non-PCI) side of the INT code (vector.s perhaps?) that was a minor problem for sharing but I can't remember what it was right now... --- >Only one IO apic is supported at present, but I think we know about one >motherboard that has two IO apic's already (and two pci busses, etc), so >we've got to deal with having 48 or so hardware IRQ's on currently >existing hardware. The present irq masking architecture depends on being >able to locate the originating IO apic quickly to mask further interrupts >during the handler, so having both IO apics generating overlapping IDT >vectors is "too hard" at present. I'm sure Steve will yell if I've >misunderstood his code. Here I define 'too hard" more as "unknown". Not enough info is available to me right now to do support for multiple IO APICs. Once I see how a "2 IO APIC" machine "looks" it might not turn out to be a big problem. In general, Peter has explained what I've been doing better than I could! For those of you not privy to the details of this IO APIC work, what I have done so far has been the "conversion" of the existing kernel code that uses the 8259 ICUs to code that uses the "InputOutput AdvancedProgrammableIntController" By itself, this has no real benefit to the kernel, exactly the same things is being accomplished, but with a different body of code and a different piece of silicon. It's the next step that all this is being done for. That step is where we start using the advanced features provided by the general distributed APIC mechanism. The first thing to know is that in addition to the motherboad's IO APIC(s) each CPU has an APIC. All the APICs are tied together on their own private bus. The IO APIC can be programmed to deliver each INT vector to a specific CPU, or to a subset of CPUs, or to all CPUs. Beyond this there are several ways of creating "arbitration" algorithms where the CPUs actually decide between themselves which will accept an INT based on the "priority level" it is currently running at. CPUs can also send "system InterProcessorInterrupts". these are effectively software interrupts sent over the APIC bus from one CPU to another. Among other things, we will use these capabilities to steer INTs to the CPU most suited for handing the INT (several reasons why this is necessary, but thats another discussion...) -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Wed Oct 16 01:16:08 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA19515 for smp-outgoing; Wed, 16 Oct 1996 01:16:08 -0700 (PDT) Received: from trapdoor.aracnet.com (trapdoor.aracnet.com [204.188.47.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA19507 for ; Wed, 16 Oct 1996 01:16:05 -0700 (PDT) Received: from cbrowni2-home (ppp-r46.aracnet.com [205.238.13.48]) by trapdoor.aracnet.com (8.7.4/8.6.9) with SMTP id IAA04679 for ; Wed, 16 Oct 1996 08:15:16 GMT Message-ID: <326496ED.281@aracnet.com> Date: Wed, 16 Oct 1996 01:03:57 -0700 From: Chris Browning Reply-To: cbrown@aracnet.com X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: smp@freebsd.org Subject: Re: dual-cpu PPRO motherboards... References: <199610150627.OAA18081@spinner.DIALix.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Peter Wemm wrote: > According to the mpspec, there is a pci->isa mapping system that is > supposed to "sense" when the system switches into symmetric mode and > disable itself when the io apics are activated. So, it depends on how the > ide irq's originate I guess. If they originate as "pci interrupts" that > go through the redirection matrix, then in theory the isa irq14/15 signals > should be freed up. However, Intel could well have hardwired it so that > the piix3 chipset generates isa edge triggered interrupts only and cannot > do pci-style level sensative irq's. Hmm, I'm not sure how the PIIX3 works, since I have never used a machine with one :-). As far as the mapping switching when APIC mode happens, I'm not sure that this happens automatically. The OS may have to move these where it likes. > Is the 8259-workalike in the piix3 in the 430HX chipset or in the other > "big" chip? If the ide and 8259's are on the same chunk of silicon, they > may be hardwired on the chip with the on-chip IDE only being "on" or "off" > on the hardwired configuration. I think the PIIX3 is a standlone chip. Again, I am not too familiar with it, but I think the IDE is built into it. That would probably also include 8259 compatible logic. > > > But what does change is that you have the additional IO APIC INTS 16 thru > > > 23, 4 of which will be available for your PCI cards. Which means they won't > > > have to compete with ISA cards for the 1st 16 INTS. > > > > Wrong. According to the same page I quoted above, interrupts 16-31 are > > reserved for processor > > use. This may be different on a non PPro system. 32-255 are available > > for general purpose use. > > Now, from an OS prespective, you may never see 16-31 and the rest may > > get shifted down, since this > > is all done in HW. > > You are confusing the isa hardware interrupts with the processor's IDT > (interrupt descriptor table). Currently, the 16 isa interrupts are mapped > into IDT entries 32 through 47. With the work Steve's been doing, the IO > Apic's have vector numbers 32 through 55 programmed into them. So, when > the 8259 pics are disabled, the IO APIC produces the exact same interrupt > vectors, just more of them. I don't think that I am confusing these two. I understand what the IDT is. What I am saying is that the APIC bus supports 255 interrupt sources. In your system it seems that you only have one IO APIC (PIIX3) that is limited to 24 interrupts. Now, you could hook up more IO APICs and get more interrupts on the APIC bus, up to 255. For example, my system has 2 IO APICs on the APIC bus, so I can have many more than 24 interrupts on the APIC bus. Of course, most things don't take advantage of this :-(. > Currently the IRQ's are directly mapped in a 1:1 ratio to the IDT table, > but there's no need to. If there's a space squeeze to fit all the devices > into a 32 bit mask, for example, there's nothing stopping us compacting it. > > Only one IO apic is supported at present, but I think we know about one > motherboard that has two IO apic's already (and two pci busses, etc), so > we've got to deal with having 48 or so hardware IRQ's on currently > existing hardware. Yeap, I am looking at one right now :-) > The present irq masking architecture depends on being > able to locate the originating IO apic quickly to mask further interrupts > during the handler, so having both IO apics generating overlapping IDT > vectors is "too hard" at present. I'm sure Steve will yell if I've > misunderstood his code. > > > You will have to compete for the ISA interrupts still, unless you have a > > lot of PCI devices > > you don't want to be visible at boot time (i.e. moving your super-fancy > > SCSI card to an > > interrupt above 15 will mean you can't see it until you get into the OS) > > No, this is not an issue.. The BIOS boots in "virtual wire" mode, with > the PCI->ISA mapping active. Not all BIOSes boot in VWM. > So, an arbitrary PCI interrupt may already > be hardwired to the IO APIC on int18, and _also_ be switched through to > the inputs of the 8259-clone PICs. The APIC only sees the given pci IRQ > line on interrupt 18, and never sees the result of the pci->isa mapping to > the 8259 pics. From owner-freebsd-smp Wed Oct 16 01:16:05 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA19506 for smp-outgoing; Wed, 16 Oct 1996 01:16:05 -0700 (PDT) Received: from trapdoor.aracnet.com (trapdoor.aracnet.com [204.188.47.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA19460 for ; Wed, 16 Oct 1996 01:15:44 -0700 (PDT) Received: from cbrowni2-home (ppp-r46.aracnet.com [205.238.13.48]) by trapdoor.aracnet.com (8.7.4/8.6.9) with SMTP id IAA04702 for ; Wed, 16 Oct 1996 08:15:34 GMT Message-ID: <32649922.2A14@aracnet.com> Date: Wed, 16 Oct 1996 01:13:22 -0700 From: Chris Browning Reply-To: cbrown@aracnet.com X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: smp@freebsd.org Subject: Re: dual-cpu PPRO motherboards... References: <199610150816.CAA07140@clem.systemsix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> Ah hem, the limit on the APIC bus, according to page 7-11 of the Pentium > >> (TM) Pro > >> Family Developers Manual, Volume 3 is 255. I believe this is standard > >> ... > > > >We were talking about the software side of it. :-) The limit used to be > >16 hardware interrupts, we can now deal with 24, although we could > >probably squeeze a few more in. The software "interrupts" take a few > >slots too. > > Even more specifically, we are talking about the INPUT capabilities of the > IO APIC, a discrete component, NOT the "local APICs" found on P5/P6 CPUs. Actually, I am talking about the APIC bus spec. It supports 255 interrupt sources. The P6 (I'm not sure about the P5) atleast supports this. When you say IP APIC, which one are you talking about? I know of atleast 3 that are commonly found on systems, probably more. Each of them has a different number of interrupts and capabilies. Not to mention systems with more than one IO APIC. > >Is the 8259-workalike in the piix3 in the 430HX chipset or in the other > >"big" chip? > > It appears that it is in the piix3. Yeah, I think this is correct. > >Only one IO apic is supported at present, but I think we know about one > >motherboard that has two IO apic's already (and two pci busses, etc), so > >we've got to deal with having 48 or so hardware IRQ's on currently > >existing hardware. The present irq masking architecture depends on being > >able to locate the originating IO apic quickly to mask further interrupts > >during the handler, so having both IO apics generating overlapping IDT > >vectors is "too hard" at present. I'm sure Steve will yell if I've > >misunderstood his code. > > Here I define 'too hard" more as "unknown". Not enough info is available to > me right now to do support for multiple IO APICs. Once I see how a "2 IO APIC" > machine "looks" it might not turn out to be a big problem. In general, > Peter has explained what I've been doing better than I could! What do you need to know? The machine I am tying this message on right now has 2 IO APICs in it. Neither are PIIX/PIIX3. > For those of you not privy to the details of this IO APIC work, what I have > done so far has been the "conversion" of the existing kernel code that uses > the > 8259 ICUs to code that uses the "InputOutput AdvancedProgrammableIntController" > By itself, this has no real benefit to the kernel, exactly the same things is > being accomplished, but with a different body of code and a different > piece of silicon. It's the next step that all this is being done for. > That step is where we start using the advanced features provided by > the general distributed APIC mechanism. The first thing to know is that > in addition to the motherboad's IO APIC(s) each CPU has an APIC. All the > APICs are tied together on their own private bus. The IO APIC can be > programmed > to deliver each INT vector to a specific CPU, or to a subset of CPUs, > or to all CPUs. Beyond this there are several ways of creating "arbitration" > algorithms where the CPUs actually decide between themselves which will accept > an INT based on the "priority level" it is currently running at. > CPUs can also send "system InterProcessorInterrupts". these are effectively > software interrupts sent over the APIC bus from one CPU to another. > Among other things, we will use these capabilities to steer INTs to the > CPU most suited for handing the INT (several reasons why this is necessary, > but thats another discussion...) Nice explaination! BTW, if the machine is using VWM, then it is using the APIC bus for part of the interrupt delivery, eventhough it is trasparent to the OS. Chris From owner-freebsd-smp Wed Oct 16 02:15:27 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA27074 for smp-outgoing; Wed, 16 Oct 1996 02:15:27 -0700 (PDT) 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 CAA27054 for ; Wed, 16 Oct 1996 02:15:21 -0700 (PDT) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.0/8.8.0) with ESMTP id RAA23430; Wed, 16 Oct 1996 17:15:06 +0800 (WST) Message-Id: <199610160915.RAA23430@spinner.DIALix.COM> X-Mailer: exmh version 1.6.9 8/22/96 To: cbrown@aracnet.com cc: smp@freebsd.org Subject: Re: dual-cpu PPRO motherboards... In-reply-to: Your message of "Wed, 16 Oct 1996 01:13:22 MST." <32649922.2A14@aracnet.com> Date: Wed, 16 Oct 1996 17:15:06 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Chris Browning wrote: > > >> Ah hem, the limit on the APIC bus, according to page 7-11 of the Pentium > > >> (TM) Pro > > >> Family Developers Manual, Volume 3 is 255. I believe this is standard > > >> ... > > > > > >We were talking about the software side of it. :-) The limit used to be > > >16 hardware interrupts, we can now deal with 24, although we could > > >probably squeeze a few more in. The software "interrupts" take a few > > >slots too. > > > > Even more specifically, we are talking about the INPUT capabilities of the > > IO APIC, a discrete component, NOT the "local APICs" found on P5/P6 CPUs. > > Actually, I am talking about the APIC bus spec. It supports 255 > interrupt > sources. The P6 (I'm not sure about the P5) atleast supports this. > When you say IP APIC, which one are you talking about? I know of > atleast > 3 that are commonly found on systems, probably more. Each of them > has a different number of interrupts and capabilies. Not to mention > systems with more than one IO APIC. Actually, there's two versions of the APIC bus, the 2-wire version found with the P5/P6 and the 82093AA APIC, as well as the older 4(?) wire version found on the i82489DX Local+IO Apic. The P5/P6 version supports 15 devices on the APIC bus (unless cluster managers are used), while the older bus protocol supported 255 devices. The 8-bit address field has been reduced to 4 bits. Every input on any apic device has an 8-bit "vector number", so each hardware input signal can generate any of the 256 possible "interrupts" (of which the first 32 are reserved for processor use and about 18 or so are already defined). So far as I can see, each IO APIC device could have 239 hardware interrupts if anybody was crazy enough to build one. Since there can be 14 APIC devices on the current P5/P6 bus, of which one has to be a cpu, you (I think) have a theoretical limit of 3107 interrupt sources in a system. Each of them can be programmed with any of the 255 IDT vector numbers, assuming the OS is prepared to have multiple sources generating the same IDT vector (FreeBSD doesn't at present). 32 of those IDT vectors are unavailable, and one is used for something else (linux system call processing). > > >Only one IO apic is supported at present, but I think we know about one > > >motherboard that has two IO apic's already (and two pci busses, etc), so > > >we've got to deal with having 48 or so hardware IRQ's on currently > > >existing hardware. The present irq masking architecture depends on being > > >able to locate the originating IO apic quickly to mask further interrupts > > >during the handler, so having both IO apics generating overlapping IDT > > >vectors is "too hard" at present. I'm sure Steve will yell if I've > > >misunderstood his code. > > > > Here I define 'too hard" more as "unknown". Not enough info is available to > > me right now to do support for multiple IO APICs. Once I see how a "2 IO A PIC" > > machine "looks" it might not turn out to be a big problem. In general, > > Peter has explained what I've been doing better than I could! > > What do you need to know? The machine I am tying this message on right > now has > 2 IO APICs in it. Neither are PIIX/PIIX3. The PIIX/PIIX3 only provide address decoding for something like an 82093AA APIC, it's got nothing else to do with the IO APIC other than housing the 8259 that we mask out. Supporting multiple IO apics should be pretty simple once we've got around the kernel's existing interrupt masking mechanism which was limited to 16 discreet hardware sources, Steve's bumped this up to 24. There's another "wall" at 28, because 4 bits of the 32-bit mask are used for software interrupts. To go beyond 28 interrupt sources and still maintain the 1:1 irq->IDT mapping we need an alternate masking strategy. On some EISA systems, some irq's (such as the timer) are hardwired internally to the 8259's and are not available as APIC inputs. This is a problem that will complicate things no end. On those systems both the 8259's and the APICs must be active, with the 8259 feeding it's output through the ExINT on the cpu's local apic. But that puts us well over the 32 interrupt source limit, so we are not even thinking about this yet until the basics are working right (which is pretty much there apart from some latency issues apparently, is that right Steve?). > Chris Cheers, -Peter From owner-freebsd-smp Wed Oct 16 02:48:28 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA02182 for smp-outgoing; Wed, 16 Oct 1996 02:48:28 -0700 (PDT) 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 CAA02167 for ; Wed, 16 Oct 1996 02:48:22 -0700 (PDT) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.0/8.8.0) with ESMTP id RAA23558; Wed, 16 Oct 1996 17:48:10 +0800 (WST) Message-Id: <199610160948.RAA23558@spinner.DIALix.COM> X-Mailer: exmh version 1.6.9 8/22/96 To: cbrown@aracnet.com cc: smp@freebsd.org Subject: Re: dual-cpu PPRO motherboards... In-reply-to: Your message of "Wed, 16 Oct 1996 01:03:57 MST." <326496ED.281@aracnet.com> Date: Wed, 16 Oct 1996 17:48:09 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Chris Browning wrote: > Peter Wemm wrote: > > According to the mpspec, there is a pci->isa mapping system that is > > supposed to "sense" when the system switches into symmetric mode and > > disable itself when the io apics are activated. So, it depends on how the > > ide irq's originate I guess. If they originate as "pci interrupts" that > > go through the redirection matrix, then in theory the isa irq14/15 signals > > should be freed up. However, Intel could well have hardwired it so that > > the piix3 chipset generates isa edge triggered interrupts only and cannot > > do pci-style level sensative irq's. > > Hmm, I'm not sure how the PIIX3 works, since I have never used a machine > with one :-). > As far as the mapping switching when APIC mode happens, I'm not sure > that this happens > automatically. The OS may have to move these where it likes. The MPSPEC is very specific about this.. ----- D.1.1 Variable interrupt routing In systems with variable interrupt routing, all PCI interrupts map to EISA/ISA IRQ's when in PIC mode or Virtual wire mode. When switched to symmetric IO mode, the system disables this routing and delivers tghe PCI interrupts through IO APIC inputs different from those used by the EISA/ISA IRQ's. If IMCR is implemented, the hardware design can use this bit to enable/disable the routing og PCI interrupts to EISA/ISA IRQ's. [..] If IMCR is implemented but the system includes one or more IO APICS that are not controlled through IMCR, the hardware must accomplish routing changes by some other means when the system switches into symmetric IO mode. These routing changes _must_ be done without requiring any additional intervention from software. For systems without the IMCR register, the routing if PCI interrupts to the EISA/ISA IRQs must be automatically disabled as the IO APICS are programmed. [..] the hardware must detect this operation and disable the routing mechanism without additional intervention by the operating system. ----- [I trimmed out some of the extended comments, it was too long already]. In a nutshell, this means that if we boot from an AHA2942 on pci and it's been "mapped" into an ISA IRQ 11 (and therefore IDT number 43), once symmetric mode is entered, the 2942 will no longer be connected to the ISA IRQ11. It is wired up to a different input on the IO APIC somewhere. > > > > But what does change is that you have the additional IO APIC INTS 16 th ru > > > > 23, 4 of which will be available for your PCI cards. Which means they w on't > > > > have to compete with ISA cards for the 1st 16 INTS. > > > > > > Wrong. According to the same page I quoted above, interrupts 16-31 are > > > reserved for processor > > > use. This may be different on a non PPro system. 32-255 are available > > > for general purpose use. > > > Now, from an OS prespective, you may never see 16-31 and the rest may > > > get shifted down, since this > > > is all done in HW. > > > > You are confusing the isa hardware interrupts with the processor's IDT > > (interrupt descriptor table). Currently, the 16 isa interrupts are mapped > > into IDT entries 32 through 47. With the work Steve's been doing, the IO > > Apic's have vector numbers 32 through 55 programmed into them. So, when > > the 8259 pics are disabled, the IO APIC produces the exact same interrupt > > vectors, just more of them. > > I don't think that I am confusing these two. I understand what the IDT > is. > What I am saying is that the APIC bus supports 255 interrupt sources. > In > your system it seems that you only have one IO APIC (PIIX3) that is > limited > to 24 interrupts. Now, you could hook up more IO APICs and get more > interrupts > on the APIC bus, up to 255. For example, my system has 2 IO APICs on > the APIC > bus, so I can have many more than 24 interrupts on the APIC bus. Of > course, > most things don't take advantage of this :-(. I was referring to your statement "interrupts 16 - 31 are reserved for processor use". This should have been "IDT entries 16 - 31 are reserved for processor use". We already leave these alone in the kernel and start the isa irq's at "interrupt 32" and go up to irq15 == vector 47. The current limitation is that when we get a vector 33 interrupt, we go back and access the IO APIC redirection for irq-1 to mask it to prevent recursion. This requires 1:1 mapping. Having to figure out which apic caused the interrupt will be extra interrupt time overhead, since it's a run-time configuration issue unlike the present dual-8259 situation where idt vectors 32 through 39 come from PIC #1, and 40 through 47 come from 8259 PIC #2. I've no doubt that it'll be supported, it just means that somebody has got to sit down and figure out _how_ to glue it all together. The present support for 24 interrupt sources from the IO apic is just arbitary. It can go up to 28 without much pain. Beyond that is where it gets tricky and is starting to get into 'major' design changes of the interrupt system in the FreeBSD kernel. BTW, sys/i386/machdep.c is where the first 32 interrupt entries are allocated. Interrupt 0 is divide-by-zero, interrupt 1 is debugging, 2 is the nmi vector, and so on. The "new" reserved entries from 16 - 31 are already partly used.. 16 is the on-chip fpu, 17 is alignment, 18 is machine check. The 486 introduced 16 and 17, the P5 had mchk, the P6 probably has more by now. Cheers, -Peter From owner-freebsd-smp Wed Oct 16 11:51:10 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA25189 for smp-outgoing; Wed, 16 Oct 1996 11:51:10 -0700 (PDT) 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 LAA25178 for ; Wed, 16 Oct 1996 11:51:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id MAA16302; Wed, 16 Oct 1996 12:50:51 -0600 Message-Id: <199610161850.MAA16302@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: cbrown@aracnet.com cc: smp@freebsd.org Subject: Re: dual-cpu PPRO motherboards... In-reply-to: Your message of "Wed, 16 Oct 1996 01:13:22 PDT." <32649922.2A14@aracnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Oct 1996 12:50:51 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, This terminology can get very confusing at times, can't it! >Actually, I am talking about the APIC bus spec. It supports 255 >interrupt >sources. The P6 (I'm not sure about the P5) atleast supports this. >When you say IP APIC, which one are you talking about? ^^ I assume you meant IO here? The only one I have encountered is the 82093AA IO APIC. There is (was) also the 82489DX APIC which could be used as both a "local" APIC with 80486 CPUs and as an IO APIC. But Intel doesn't make these anymore, at least not for new systems (there may be replacement parts available). > I know of atleast >3 that are commonly found on systems, probably more. Each of them >has a different number of interrupts and capabilies. Not to mention >systems with more than one IO APIC. what other parts do you know of (numbers please!) > What do you need to know? The machine I am tying this message on right >now has >2 IO APICs in it. Neither are PIIX/PIIX3. The output of 'mptable', with both IO APICs enabled in the BIOS. This will show me how the variuos INTerrupt sources are associated with IO APIC pins, among other useful data. You can find this program on the SMP web page at the top of the "Various tests that you can help us run:" section: http://www.freebsd.org/~fsmp/SMP/SMP.html This program can be run without the SMP kernel being active, but the 2nd IO APIC MUST be enabled in the BIOS for its assignments to show up. Additionally, if this is an EISA machine it may or may not work, depending on where they stuck the MP table. Also, give me your 'dmesg' output, as well as the part #s of your IO APICs and chipset if known. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Wed Oct 16 12:25:22 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA27925 for smp-outgoing; Wed, 16 Oct 1996 12:25:22 -0700 (PDT) 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 MAA27918 for ; Wed, 16 Oct 1996 12:25:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id NAA16462; Wed, 16 Oct 1996 13:25:00 -0600 Message-Id: <199610161925.NAA16462@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: cbrown@aracnet.com, smp@freebsd.org Subject: Re: dual-cpu PPRO motherboards... In-reply-to: Your message of "Wed, 16 Oct 1996 17:15:06 +0800." <199610160915.RAA23430@spinner.DIALix.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Oct 1996 13:25:00 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > interrupts if anybody was crazy enough to build one. Since there can be > 14 APIC devices on the current P5/P6 bus, of which one has to be a cpu, isn't it 15 APIC devices: 0-14 plus BROADCAST ADDRESS (0xf) > On some EISA systems, some irq's (such as the timer) are hardwired > internally to the 8259's and are not available as APIC inputs. This is a > problem that will complicate things no end. On those systems both the > 8259's and the APICs must be active, with the 8259 feeding it's output > through the ExINT on the cpu's local apic. But that puts us well over the Peter, this isn't the case for your motherboard is it, I read your MP table as saying ISA IRQ0 goes to IO APIC INT2? The "default config' has the master 8259 INTR out going to the IO APIC INT0, and you can program the IO APIC to know that it needs to get the vector from an external source via the standard "int ack" cycle. With this feature we could at least skip the use of the ExINT route, but it still is 'butt ugly complicated'. > until the basics are working right (which is pretty much there apart from > some latency issues apparently, is that right Steve?). $ dmesg FreeBSD 2.2-961004-SNAP #1: Sat Oct 12 01:42:29 MDT 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 ... ahc0 rev 0 int a irq 19 on pci0:12 ^^^^^^ $ uptime 1:10PM up 4 days, 11:26, 2 users, load averages: 0.00, 0.00, 0.00 ( the only reason it has been up this long is that I have a "real" job this week! ) This is my latest version with the 8259s completely out of the picture. The PCI stuff is still hardcoded for my specific motherboard, but STefan now understands my specific needs in the PCI layer and will have that fixed soon. The only symptom I see of problems is that I am getting fairly frequent "ed0: device timeout" messages. Not sure if I am loosing INT5 or what. But the 2940 seems solid, no disk ERRORs whatsoever. My next step is to start playing with delivery modes and sending INTs to all the CPUs. This is where we should actually see some benefits from all this. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Wed Oct 16 12:45:09 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA29841 for smp-outgoing; Wed, 16 Oct 1996 12:45:09 -0700 (PDT) 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 MAA29824 for ; Wed, 16 Oct 1996 12:45:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id NAA16559; Wed, 16 Oct 1996 13:44:52 -0600 Message-Id: <199610161944.NAA16559@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: cbrown@aracnet.com, smp@freebsd.org Subject: Re: dual-cpu PPRO motherboards... In-reply-to: Your message of "Wed, 16 Oct 1996 17:48:09 +0800." <199610160948.RAA23558@spinner.DIALix.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Oct 1996 13:44:52 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, >For systems without the IMCR register, the routing if PCI interrupts to >the EISA/ISA IRQs must be automatically disabled as the IO APICS are >programmed. [..] the hardware must detect this operation and disable the >routing mechanism without additional intervention by the operating system. this is interesting, hadn't noticed it b4. Since in the current code I am programming the IO APIC to default values, even though it is NOT (by default) used, I would expect this to be breaking the kernel for some people. I now program everything I can in the IO APIC, just to test that aspect on the boards of current users, even though the code doesn't actually use the IO APIC. (to use the IO APIC you need to define SMP_SYMIOXXX in apic.h) I wonder if this rule only applies to systems with 2 or more IO APICs (the topic of appendix D)? -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Wed Oct 16 18:24:02 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA21016 for smp-outgoing; Wed, 16 Oct 1996 18:24:02 -0700 (PDT) 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 SAA20982 for ; Wed, 16 Oct 1996 18:23:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id TAA18066; Wed, 16 Oct 1996 19:23:40 -0600 Message-Id: <199610170123.TAA18066@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: 1st IO APIC test Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Oct 1996 19:23:40 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, #if defined( TEST_1 ) /** Peter said: >BTW, if you're feeling "game", try changing the "Delivery mode fixed" on >the counter to "Lowest Priority", making sure that all cpus have a zero in >their TPR and focus processor is disabled. It should then round-robin the >timer scheduling timer interrupt, so that should be the end of >running-forever processes on CPU#1... */ #endif I just did the above test with the following result. Compile time is about the same. Notice the changes in reported user & system times. They look much more reasonable to me, although I have no explanation for the change... ------------------------------------------------------------------------------ SYMIOXXX kernel, pretest: $ date;time make;date Wed Oct 16 17:46:22 MDT 1996 ... loading kernel rearranging symbols text data bss dec hex 946176 65536 75928 1087640 109898 Wed Oct 16 17:56:01 MDT 1996 578.94s real 0.00s user 522.52s system ------------------------------------------------------------------------------ SYMIOXXX kernel, TEST_1: $ date;time make;date Wed Oct 16 18:57:53 MDT 1996 ... loading kernel rearranging symbols text data bss dec hex 950272 65536 75928 1091736 10a898 Wed Oct 16 19:07:37 MDT 1996 584.92s real 418.37s user 97.66s system -- Steve Passe | powered by smp@csn.net | FreeBSD