From owner-freebsd-smp Sun May 4 12:54:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA13411 for smp-outgoing; Sun, 4 May 1997 12:54:44 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA13406 for ; Sun, 4 May 1997 12:54:42 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id NAA26777; Sun, 4 May 1997 13:54:29 -0600 (MDT) Message-Id: <199705041954.NAA26777@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Francis Dupont cc: "John S. Dyson" , smp@freebsd.org Subject: Re: maptable of SuperMicro P6DNH In-reply-to: Your message of "Sun, 04 May 1997 17:23:08 +0200." <199705041523.RAA17402@givry.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 04 May 1997 13:54:29 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, >I have a Supermicro P6DNH (biPPro board with 2 PCI (8 slots), i960, ...) > ... >the bipro test kernel but it hangs after the boot, I can do the tests >you'd like if you need more infos, including installing special system). I think you probably can run an SMP kernel if you are running 3.0-current and build it with "options SMP_TIMER_NC" in the kernel config file: http://www.freebsd.org/~fsmp/SMP/getstarted.html I also am tracking down a better solution to this problem. I suspect that its a matter of programming the PIIX3 chip on the motherboard. I need a little info about these supermicro boards: According to the manual and/or actual BIOS actions, is it possible to choose from a range of IRQs for the secondary IDE controller? or do they claim your only choice is IRQ15? -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Sun May 4 13:07:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA14009 for smp-outgoing; Sun, 4 May 1997 13:07:25 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA14004 for ; Sun, 4 May 1997 13:07:21 -0700 (PDT) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.5/8.7.3) with ESMTP id WAA01074; Sun, 4 May 1997 22:07:19 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id WAA17582; Sun, 4 May 1997 22:07:17 +0200 (MET DST) Message-Id: <199705042007.WAA17582@givry.inria.fr> From: Francis Dupont To: Steve Passe cc: "John S. Dyson" , smp@freebsd.org Subject: Re: maptable of SuperMicro P6DNH In-reply-to: Your message of Sun, 04 May 1997 13:54:29 MDT. <199705041954.NAA26777@Ilsa.StevesCafe.com> Date: Sun, 04 May 1997 22:07:16 +0200 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In your previous mail you wrote: >I have a Supermicro P6DNH (biPPro board with 2 PCI (8 slots), i960, ...) > ... >the bipro test kernel but it hangs after the boot, I can do the tests >you'd like if you need more infos, including installing special system). I think you probably can run an SMP kernel if you are running 3.0-current and build it with "options SMP_TIMER_NC" in the kernel config file: => I'll try the 3.0-970502-SNAP tomorrow (it is 22h00 here and of course ftp.fr.freebsd.org (with a 34Mbits/s access) is down :-). According to the manual and/or actual BIOS actions, is it possible to choose from a range of IRQs for the secondary IDE controller? or do they claim your only choice is IRQ15? => I have the manual in an other building, I'll send the answer tommorrow. Regards Francis.Dupont@inria.fr PS: it seems to be a nice board (8 PCI slots are good because I do some research in networking (IPv6 & ATM) and I have some 10/100Mbits/s Ethernet (DE500), FDDI (DEFPA), ATM (Efficient) boards to put in) but I already had to change the place of the Adaptec because Windows NT 4.0 wanted to find it on the first PCI bus (FreeBSD didn't matter)... From owner-freebsd-smp Sun May 4 15:47:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA21188 for smp-outgoing; Sun, 4 May 1997 15:47:55 -0700 (PDT) Received: from zen.nash.org (nash.pr.mcs.net [204.95.47.72]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA21181 for ; Sun, 4 May 1997 15:47:49 -0700 (PDT) Received: from zen.nash.org (localhost [127.0.0.1]) by zen.nash.org (8.8.5/8.6.12) with SMTP id RAA01508 for ; Sun, 4 May 1997 17:47:17 -0500 (CDT) Message-ID: <336D11F5.2781E494@mcs.com> Date: Sun, 04 May 1997 17:47:17 -0500 From: Alex Nash X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: freebsd-smp@freebsd.org Subject: SMP performance (what am I doing wrong) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've just upgraded to 3.0 with SMP support, and have been pleasantly surprised with the stability of the kernel. However, I'm having a few problems getting the performance I expected. Before anyone asks, yes, I do have both CPUs running :) # sysctl -a | grep smp kern.smp_active: 2 kern.smp_cpus: 2 Using the old RC5 client we're all so familiar with, I ran a few benchmarks. Under 2.2 with one processor, I think I was getting in the low 100,000-110,000 range. Here's what I got with the SMP kernel (all results are with the system in a quiescent state): $ ./client -m rc5-56-client: Performance testing with 1000000 crypts rc5-56-client: Complete in 13.298 seconds. (75198.80 keys/sec) Now with 2 clients: $ ./client -m & ./client -m;wait [1] 1425 rc5-56-client: Performance testing with 1000000 crypts rc5-56-client: Performance testing with 1000000 crypts rc5-56-client: Complete in 24.969 seconds. (40049.51 keys/sec) rc5-56-client: Complete in 25.112 seconds. (39821.81 keys/sec) Ouch! I ran it again and got completely different results: $ ./client -m & ./client -m;wait [1] 1451 rc5-56-client: Performance testing with 1000000 crypts rc5-56-client: Performance testing with 1000000 crypts rc5-56-client: Complete in 18.588 seconds. (53797.31 keys/sec) rc5-56-client: Complete in 18.910 seconds. (52881.56 keys/sec) An interesting thing I saw in top: the cpuidle processes were at about 20% the entire time the clients were running. How could that be? Running it again produced similar results to the last run. Another benchmark I tried was compiling some software from work with various make -j options. Again the results were interesting: Real User Sys Single CPU/make -j1 4:38.7 3:20.0 0:57.8 Single CPU/make -j4 4:38.6 3:24.8 0:56.8 Dual CPU/make -j1 5:31.5 2:41.0 3:19.9 Dual CPU/make -j4 4:11.6 4:16.9 2:55.9 Dual CPU/make -j8 4:21.0 4:16.1 2:59.9 Am I missing kernel compile options? I've used SMP, and APIC_IO. If anyone has any clues as to what's going on, I'd really appreciate hearing them. Thanks. Alex From owner-freebsd-smp Sun May 4 17:30:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA24887 for smp-outgoing; Sun, 4 May 1997 17:30:56 -0700 (PDT) Received: from gargoyle.bazzle.com (gargoyle.bazzle.com [206.103.246.190]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA24882 for ; Sun, 4 May 1997 17:30:53 -0700 (PDT) Received: from gargoyle.bazzle.com (gargoyle.bazzle.com [206.103.246.189]) by gargoyle.bazzle.com (8.8.5/8.6.12) with SMTP id UAA19358; Sun, 4 May 1997 20:30:54 -0400 (EDT) Date: Sun, 4 May 1997 20:30:53 -0400 (EDT) From: "Eric J. Chet" To: Alex Nash cc: freebsd-smp@FreeBSD.ORG, "Dan O'Brien" Subject: Re: SMP performance (what am I doing wrong) In-Reply-To: <336D11F5.2781E494@mcs.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, 4 May 1997, Alex Nash wrote: > Using the old RC5 client we're all so familiar with, I ran a > few benchmarks. Under 2.2 with one processor, I think I was > getting in the low 100,000-110,000 range. Here's what I got > with the SMP kernel (all results are with the system in a > quiescent state): Hello I'm not seeing any difference between a -current-up kernel and a -current-mp kernel with rc5. On a current-up kernel I was seeing 122k keys a second. On a -current-mp box with 2 rc5 processes running I was seeing 2x122k keys a second. I was running the rc5 clients with a nice value of 20. client 1: rc5-56-client: [0x08D0B2D0000000 -> 0x08D0B2DFFFFFFF] rc5-56-client: Notifying Key Server ``famine.noc.best.net'' rc5-56-client: Obtaining Key Mask from ``famine.noc.best.net:2056''. rc5-56-client: The Bovine Proxy KeyServer (Build 1510) rc5-56-client: Received Keyspace Mask 0x0000000FFFFFFF rc5-56-client: Start Key 0x08D109D0000000, trying 268435456 keys. rc5-56-client: Processed 122425.42 keys per second. rc5-56-client: Keyspace Exhausted in 36.54 minutes. client 2 rc5-56-client: [0x08D0B310000000 -> 0x08D0B31FFFFFFF] rc5-56-client: Notifying Key Server ``famine.noc.best.net'' rc5-56-client: Obtaining Key Mask from ``famine.noc.best.net:2056''. rc5-56-client: The Bovine Proxy KeyServer (Build 1510) rc5-56-client: Received Keyspace Mask 0x0000000FFFFFFF rc5-56-client: Start Key 0x08D10A90000000, trying 268435456 keys. rc5-56-client: Processed 122442.80 keys per second. rc5-56-client: Keyspace Exhausted in 36.54 minutes. Try running the two rc5 clients if have a dual smp box. What might have happend was your single rc5 client was bouncing between cpus and thats where your performance lose came from. The current schedular doesn't have any code to help process cpu affinity. I'm using a dual pentium-133 box BTW. Peace, Eric From owner-freebsd-smp Sun May 4 18:44:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA27942 for smp-outgoing; Sun, 4 May 1997 18:44:44 -0700 (PDT) Received: from zen.nash.org (nash.pr.mcs.net [204.95.47.72]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA27934 for ; Sun, 4 May 1997 18:44:41 -0700 (PDT) Received: from zen.nash.org (localhost [127.0.0.1]) by zen.nash.org (8.8.5/8.6.12) with SMTP id UAA02147; Sun, 4 May 1997 20:43:33 -0500 (CDT) Message-ID: <336D3B45.15FB7483@mcs.com> Date: Sun, 04 May 1997 20:43:33 -0500 From: Alex Nash X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 3.0-CURRENT i386) MIME-Version: 1.0 To: "Eric J. Chet" CC: freebsd-smp@FreeBSD.ORG, "Dan O'Brien" Subject: Re: SMP performance (what am I doing wrong) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Eric J. Chet wrote: > I'm not seeing any difference between a -current-up kernel > and a -current-mp kernel with rc5. On a current-up kernel I was > seeing 122k keys a second. On a -current-mp box with 2 rc5 > processes running I was seeing 2x122k keys a second. I was > running the rc5 clients with a nice value of 20. [ rc5 output ] > Try running the two rc5 clients if have a dual smp box. What might have > happend was your single rc5 client was bouncing between cpus and thats > where your performance lose came from. The current schedular doesn't > have any code to help process cpu affinity. I'm using a dual pentium-133 > box BTW. I did try two simultaneous rc5 clients (see my last mail for the differing results I got by running the same test twice). However, you just pointed me in the right direction: You ran the client in key cracking mode, as opposed to the benchmarking mode I had run it in. Mine ran for about tens of seconds, yours for tens of minutes... I ran the client the same way you did and watched the output in top. The cpuidle processes started out >50% CPU and then slowly decayed. After about 45 seconds (or thereabouts) they were consuming a few percent. Another 15 seconds later they dropped to 0%, and have stayed there ever since. I don't doubt I will get 2X throughput now :) Perhaps you could try this and see if you get similar results: Run 'top -S -I' and then start the two clients. Do you see a similar decay in idle proc CPU%? Alex From owner-freebsd-smp Mon May 5 03:38:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA17315 for smp-outgoing; Mon, 5 May 1997 03:38:06 -0700 (PDT) Received: from shore.cyberbeach.net (shore.cyberbeach.net [207.236.41.14]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA17302 for ; Mon, 5 May 1997 03:38:03 -0700 (PDT) Received: (from kschafer@localhost) by shore.cyberbeach.net (8.8.5/8.8.5) id KAA01852 for freebsd-smp@freebsd.org; Mon, 5 May 1997 10:37:49 -0400 (EDT) Date: Mon, 5 May 1997 10:37:49 -0400 (EDT) From: Kurt Schafer Message-Id: <199705051437.KAA01852@shore.cyberbeach.net> To: freebsd-smp@freebsd.org Subject: Enabling SMP in 3.0-SNAP Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Just downloaded the 3.0 snapshot released a couple of days ago and would like some information on how to enable a second CPU. Pointers to a FAQ or txt file welcome. TIA -Kurt From owner-freebsd-smp Mon May 5 10:18:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA07381 for smp-outgoing; Mon, 5 May 1997 10:18:00 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA07344 for ; Mon, 5 May 1997 10:16:39 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id LAA02787; Mon, 5 May 1997 11:15:22 -0600 (MDT) Message-Id: <199705051715.LAA02787@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Kurt Schafer cc: freebsd-smp@FreeBSD.ORG Subject: Re: Enabling SMP in 3.0-SNAP In-reply-to: Your message of "Mon, 05 May 1997 10:37:49 EDT." <199705051437.KAA01852@shore.cyberbeach.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 May 1997 11:15:21 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > > Just downloaded the 3.0 snapshot released a couple of days ago and would like > some information on how to enable a second CPU. > > Pointers to a FAQ or txt file welcome. http://www.freebsd.org/~fsmp/SMP/SMP.html -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Mon May 5 14:37:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA22188 for smp-outgoing; Mon, 5 May 1997 14:37:54 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA22173 for ; Mon, 5 May 1997 14:37:50 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id PAA03682 for ; Mon, 5 May 1997 15:37:48 -0600 (MDT) Message-Id: <199705052137.PAA03682@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: freebsd-smp@FreeBSD.ORG Subject: IRQ13 & npx0 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 May 1997 15:37:48 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, I am working my way thru known bugs, it used to be that some users saw IRQ13 being enabled during boot. I believe it only happened on Neptune motherboards, never happened consistantly, and didn't seem to really cause problems. Nevertheless this is broken behaviour and shouldn't happen. So the question is: does anyone still see this with SMP, APIC_IO and -current? you would see a line near the end of dmesg that looked like: Enabled INTs: 1, 2, 3, 4, 6, 7, 8, 13, 17, 18, imen: 0x00f9de21 ^^ ^ | -> xx0x -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Tue May 6 00:35:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA22358 for smp-outgoing; Tue, 6 May 1997 00:35:43 -0700 (PDT) Received: from abby.skypoint.net (abby.skypoint.net [199.86.32.252]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA22353 for ; Tue, 6 May 1997 00:35:41 -0700 (PDT) Received: (from uucp@localhost) by abby.skypoint.net (8.8.5/alexis 2.7) with UUCP id CAA25583 for freebsd-smp@freebsd.org; Tue, 6 May 1997 02:35:40 -0500 (CDT) Received: (from bruce@localhost) by zuhause.mn.org (8.8.5/8.8.5) id CAA00328; Tue, 6 May 1997 02:31:51 -0500 (CDT) Date: Tue, 6 May 1997 02:31:51 -0500 (CDT) Message-Id: <199705060731.CAA00328@zuhause.mn.org> From: Bruce Albrecht To: freebsd-smp@freebsd.org Subject: fatal trap during boot Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I had some other problems (I think a disk drive went bad), so I had to reload DOS 6 and the NT bootstrap loader onto a new disk. I installed the Boot-Eazy 1.7 bootloader onto the new disk after installing DOS 6 and NT, and now I can't boot SMP. I get the following error: Fatal trap 9: general protection fault while in kernel mode cpunumber=0 instruction ptr = 0x8:0cf02083ea stack ptr = 0x10:0xf4cd5eac frame ptr = 0x10:0xf4cd5efc code segment = base 0x0 limit 0xfffff type 0x1b = DPL 0 pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL current process = 6 (CPUIDLE1) interrupt mask = kernel: type 9 trap, code = 0 stopped at _sccnputc+0x22 repe movsl (%es1), %es:(%edi) It happens right after it lists the interrupts. I'm able to boot with a kernel that is identical exact that the SMP options are disabled. The kernel was originally from Saturday, but I rebuilt it from code cvsupped this afternooon. Any suggestions? NT seems to be running OK, and tells me that it's running 2 CPU kernel. From owner-freebsd-smp Tue May 6 03:10:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA02290 for smp-outgoing; Tue, 6 May 1997 03:10:38 -0700 (PDT) Received: from bagpuss.visint.co.uk (bagpuss.vis.net.uk [194.207.134.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA02285 for ; Tue, 6 May 1997 03:10:33 -0700 (PDT) Received: from bagpuss.visint.co.uk (bagpuss.vis.net.uk [194.207.134.1]) by bagpuss.visint.co.uk (8.7.5/8.7.3) with SMTP id LAA16529; Tue, 6 May 1997 11:19:22 +0100 (BST) Date: Tue, 6 May 1997 11:19:22 +0100 (BST) From: Stephen Roome To: Terry Lambert cc: Steve Passe , bruce@zuhause.mn.org, freebsd-smp@FreeBSD.org Subject: Re: Where to start SMP? In-Reply-To: <199705011825.LAA04751@phaeton.artisoft.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 Thu, 1 May 1997, Terry Lambert wrote: > > > Where's the recommended location for starting SMP? I'm doing it in > > > /usr/local/etc/rc.d, but I was wondering if I was missing something. > > > I think it should be added to /etc/rc and /etc/rc.conf now that the > > > SMP code is in -current. > > > > -- > > there is no 'recommended' place. experiment, let us know what works well... > > It would help posters like this, now that the merge is done, to have > an "SMP" file in /etc/i386/conf" for an SMP version of "GENERIC". I'm not sure that that is the problem area. I only just started with SMP, and the biggest problem was not figuring out the config (as frankly there really isn't much to do to make it work from a user point of view). What was a lot harder was figuring what the options do. The new LINT may have all (or many anyway) possible options in it, but most of them are poorly explained and 50% of them aren't documented other than 2 words. Although a generic smp config file would be helpful, a slightly more prominent entry in the standard handbook really is required as well. -- Steve Roome Technical Systems Manager, Vision Interactive Ltd. E: steve@visint.co.uk M: +44 (0) 976 241 342 T: +44 (0) 117 973 0597 F: +44 (0) 117 923 8522 From owner-freebsd-smp Tue May 6 04:48:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA06523 for smp-outgoing; Tue, 6 May 1997 04:48:03 -0700 (PDT) Received: from bagpuss.visint.co.uk (bagpuss.vis.net.uk [194.207.134.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA06489; Tue, 6 May 1997 04:47:56 -0700 (PDT) Received: from bagpuss.visint.co.uk (bagpuss.vis.net.uk [194.207.134.1]) by bagpuss.visint.co.uk (8.7.5/8.7.3) with SMTP id MAA17826; Tue, 6 May 1997 12:58:19 +0100 (BST) Date: Tue, 6 May 1997 12:58:19 +0100 (BST) From: Stephen Roome To: Steve Passe cc: hackers@freebsd.org, smp@freebsd.org Subject: Re: 7860 In-Reply-To: <199705012029.OAA08130@Ilsa.StevesCafe.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 Thu, 1 May 1997, Steve Passe wrote: > I believe we are talking about the GA586DX here. I am told that gigabyte > is now shipping a new version that uses the ATX PS connector. If buying this > board be sure to verify that your vendor will be supplying you with the new > version. I have two of the newer version boards with ATX power. These are Revision 3B. They cost us about 250 (UK pounds sterling) each. I'm running with two 133's and I think it's the cheapest option there is. okay 133's are slow ... (apparently too slow for most people anyway). But two P133's in this box deliver the performance of approx. P266 * 0.9 at a much lower cost than buying one Pentium 200 on a UP motherboard. > You *probably* could overclock 150s to 166, I have been > overclocking my P6-166x512s to 200mHz for almost a month now without any > sign of trouble. This P150 has been running at 166 for about 2 months without a single problem. Anyway, is it time to consider buying smp as a real alternative? It seems that it can now deliver a real performance gain over uniprocessor, and with any given processor, doubling the clock speed is more than doubling the price. So, how long before SMP is in a release version? -- Steve Roome Technical Systems Manager, Vision Interactive Ltd. E: steve@visint.co.uk M: +44 (0) 976 241 342 T: +44 (0) 117 973 0597 F: +44 (0) 117 923 8522 From owner-freebsd-smp Tue May 6 07:35:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA13785 for smp-outgoing; Tue, 6 May 1997 07:35:36 -0700 (PDT) Received: from pluto.plutotech.com (root@pluto100.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA13780 for ; Tue, 6 May 1997 07:35:34 -0700 (PDT) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.5/8.8.3) with ESMTP id IAA27572 for ; Tue, 6 May 1997 08:35:34 -0600 (MDT) Message-Id: <199705061435.IAA27572@pluto.plutotech.com> To: smp@FreeBSD.org Subject: FYI Date: Tue, 06 May 1997 09:34:06 -0600 From: "Justin T. Gibbs" Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk ------- Forwarded Message To: tech-kern@NetBSD.ORG Reply-To: tech-kern@NetBSD.ORG Subject: Fwd: Pentium Pro architecture (synchronization/speculative loads) bits Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 06 May 1997 01:24:24 -0700 From: Greg Earle Sender: tech-kern-owner@NetBSD.ORG Precedence: list Delivered-To: tech-kern@NetBSD.ORG X-UIDL: 39d6891e0396119075dd0fcb748174e9 Hi folks, Not sure who would be most interested in this, but I saw this fly by on the Plan 9 mailing list. I suspect that most of the info that could possibly be relevant to us would be of interest to anyone doing compiler work (do we do any customization/knob-twiddling to gcc ourselves for our platforms?) but at any rate, it might be worth filing away for future use nonetheless. - Greg P.S. You can find these bits in DejaNews using a search string of "Haertel & ~g (comp.os.plan9)" - ------- Forwarded Message From: presotto@plan9.bell-labs.com Message-Id: <199704221935.PAA02595@cse.psu.edu> To: 9fans@cse.psu.edu Date: Tue, 22 Apr 1997 15:35:29 -0400 Subject: How the Pentium Pro really works Sender: owner-9fans@cse.psu.edu Reply-To: 9fans@cse.psu.edu Precedence: bulk Here's 3 messages from Mike Haertel describing how the Pentium Pro works vis a vis synchronization. As he forcefully point out, the problem isn't speculative loads, its just queued stores. As expected, surrounding shared accesses with spin locks is sufficient. Only iffy operations like our current version of sleep/wakeup have to be more carefully handled. An interesting point is that the same model exists on the Pentium. However, the shorter pipelines and buffers in the Pentium are less likely to exacerbate the problem. We were just lucky. =================================== To: research.bell-labs.com!presotto Subject: Pentium Pro and coherence Date: Tue, 22 Apr 1997 01:15:56 -0700 From: Mike Haertel In article <199704211614.MAA02731@cse.psu.edu>, you wrote: > The Pro people have remained silent > on the subject (we've sent email). Hi, I am an architect at Intel. Who did you send email to? I'm surprised you got no response. In any case, perhaps I can clarify things a little. > Of course, I could be totally wrong about the speculative reads and > it may be the interlock instruction on the writer and not the > reader that causes the processors to become coherent. The caches are always coherent using an MESI protocol. The real problem is that not all written data in the system is in the cache(s). The Pentium Pro's memory ordering model is called "processor ordering" and is a formalization of the 486's semantics. The 486 had a write-through cache with write queue to memory which was not snooped by loads on other processors. Loosely speaking, this means the ordering of events originating from any one processor in the system, as observed by other processors, is always the same. However, different observers are allowed to disagree on the interleaving of events from two or more processors. The PPro does speculative and out-of-order loads. However, it has a mechanism called the "memory order buffer" to ensure that the above memory ordering model is not violated. Load and store instructions do not get retired until the processor can prove there are no memory ordering violations in the actual order of execution that was used. Stores do not get sent to memory until they are ready to be retired. If the processor detects a memory ordering violation, it discards all unretired operations (including the offending memory operation) and restarts execution at the oldest unretired instruction. i.e. when a violation is detected the MOB whacks the machine ... :-) For example, consider the following sequence: P1: load (1000) -> reg P2: store 10 -> (1000) load (1000) -> reg store 20 -> (1000) Suppose on P1, the 2nd load speculatively executes first (for whatever reason), and picks up 10 (the result of the first store on P2). Later, P2 executes the 2nd store (causing the cached copy of location 1000 on P1 to be invalidated), and finally P1 executes the 1st load. At this point, P1 discovers that a younger load has already read from the same location, and that the location was subsequently invalidated by P2. P1 says "a-ha! that violates the memory ordering model!", clobbers the speculative state of the machine from the offending instruction (the 1st load) onward, and resumes execution starting at the offending load. Serializing instructions like CPUID force the machine to wait until all queued stores have been written out. (Actually, serializing instructions force the machine to wait until they are retired, but they cannot retire until all older stores have retired, which has an effect equivalent to draining a store queue.) Note that serializing instructions do not serialize the other processors, only the local processor. You should be able to reproduce your bug by manually working through the possible processor-ordering-consistent interleavings of events from multiple processors. Note that you should think of a processor as also observing itself. Finally, since the caches are actually fully coherent, you should be able to do correct locking without too many serializing instructions, perhaps without any. Future Intel processors will implement the same memory ordering model. =================================== To: research.bell-labs.com!presotto Subject: Re: Pentium Pro and coherence Date: Tue, 22 Apr 1997 09:24:42 -0700 From: Mike Haertel > 0,0 blows us away. If I understand correctly, putting a > synchronizing instruction between the writes and subsequent read > > P1: P2: > x = 0 y = 0 > x = 1 y = 1 > cpuid cpuid > read y read x > > will cause the processor the instruction was executed on > to wait until all processors have gotten out their > queued stores and then blow away any inconsistencies on > caused by speculative loads. The cpuid waits only until the *local* processor has gotten out its queued stores. It doesn't wait for any of the other processors. However, in this example (where all processors do cpuid before any processor does a load) I think you're OK. The cpuid forces the local processor to wait until its queued writes have been globally observed. What this means is that you are effectively serializing access to "the bus" (really, the combination of the bus and the coherent caches--writes to M-state cache lines on the local processor count as "globally observed"). Some processor (say P2) is last to execute cpuid. This means that P1 has already executed cpuid, therefore P1's "x=1" has been globally observed, so P2's load is guaranteed to see x=1. Finally, I'd like to emphasize: The inconsistencies are NOT caused by speculative loads, they are caused by queued writes on other processors. > What we need is that if the following sequence is executed > > P1: P2: > x = 0 y = 0 > x = 1 y = 1 > read y read x > > has the values read will be one of > > 1 0 > 0 1 > 1 1 > > 0,0 blows us away. You could get 0,0 even on the 486 or Pentium. The difference is that the PPro has such deep pipelines and buffers that it is more likely to expose such bugs. =================================== To: research.bell-labs.com!presotto Date: Tue, 22 Apr 1997 11:01:30 -0700 From: Mike Haertel > Do you mind if I repost your mail to the 9fans list? Sure, go ahead. One other addendum I'd like to make: in your original post to 9fans, you mentioned some paranoia about similar problems possibly existing in other parts of the kernel. One bit of reassurance: any data structure protected by a spin lock is safe. Here's why: P1 P2 [already holding lock] wait for lock->busy == 0 store data->x grab lock store data->y use data->x and ->y lock->busy = 0 Because of processor ordering, when P2 observes lock->busy == 0, it also has observed all prior stores by P1. Hence P2 never gets an inconsistent view of P1's updates. This would not be the case if the Pentium Pro allowed speculative loads to violate processor ordering semantics. This is also probably not the case on other processors with weaker memory ordering semantics. Digital's Alpha may be one such processor, I'm not sure. On those processors, when releasing a spin lock you need a "lock release" synchronization instruction rather than a simple store. - ------- End of Forwarded Message ------- End of Forwarded Message From owner-freebsd-smp Tue May 6 09:23:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA19606 for smp-outgoing; Tue, 6 May 1997 09:23:53 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA19601 for ; Tue, 6 May 1997 09:23:49 -0700 (PDT) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.5/8.7.3) with ESMTP id SAA18460; Tue, 6 May 1997 18:22:00 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id SAA20405; Tue, 6 May 1997 18:21:59 +0200 (MET DST) Message-Id: <199705061621.SAA20405@givry.inria.fr> From: Francis Dupont To: Steve Passe cc: "John S. Dyson" , smp@freebsd.org Subject: Re: maptable of SuperMicro P6DNH In-reply-to: Your message of Sun, 04 May 1997 13:54:29 MDT. <199705041954.NAA26777@Ilsa.StevesCafe.com> Date: Tue, 06 May 1997 18:21:57 +0200 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In your previous mail you wrote: According to the manual and/or actual BIOS actions, is it possible to choose from a range of IRQs for the secondary IDE controller? or do they claim your only choice is IRQ15? => it seems IRQ14 and IRQ15 are hardly bound to IDE controllers... Here is the log of mptable on a 3.0 SMP (without the IDE, the kernel crashes in wdattach if I keep it ?) for SuperMicro P6DNH : Francis.Dupont@inria.fr =============================================================================== MPTable, version 2.0.9 looking for EBDA pointer @ 0x040e, found, searching EBDA @ 0x0009fc00 searching CMOS 'top of mem' @ 0x0009f800 (638K) searching default 'top of mem' @ 0x0009fc00 (639K) searching BIOS @ 0x000f0000 MP FPS found in BIOS @ physical addr: 0x000fb070 ------------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000fb070 signature: '_MP_' length: 16 bytes version: 1.1 checksum: 0x31 mode: Virtual Wire ------------------------------------------------------------------------------- MP Config Table Header: physical address: 0x000f5310 signature: 'PCMP' base table length: 296 version: 1.1 checksum: 0x4c OEM ID: 'INTEL ' Product ID: '440FX ' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 30 local APIC address: 0xfee00000 extended table length: 0 extended table checksum: 0 ------------------------------------------------------------------------------- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 0 0x11 BSP, usable 6 1 9 0xfbff -- Bus: Bus ID Type 0 PCI 1 PCI 2 ISA -- I/O APICs: APIC ID Version State Address 2 0x11 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ExtINT conforms conforms 2 0 2 0 INT conforms conforms 2 1 2 1 INT conforms conforms 2 0 2 2 INT conforms conforms 2 3 2 3 INT conforms conforms 2 4 2 4 INT conforms conforms 2 5 2 5 INT conforms conforms 2 6 2 6 INT conforms conforms 2 7 2 7 INT active-hi edge 2 8 2 8 INT conforms conforms 2 9 2 9 INT conforms conforms 2 10 2 10 INT conforms conforms 2 11 2 11 INT conforms conforms 2 12 2 12 INT conforms conforms 2 13 2 13 INT conforms conforms 2 14 2 14 INT conforms conforms 2 15 2 20 INT active-lo level 1 1:A 2 16 INT active-lo level 0 19:A 2 16 INT active-lo level 0 18:A 2 17 INT active-lo level 1 1:A 2 18 INT active-lo level 0 19:A 2 18 INT active-lo level 0 20:A 2 19 SMI conforms conforms 2 0 2 23 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID INT# ExtINT conforms conforms 0 0:A 255 0 NMI conforms conforms 0 0:A 255 1 ------------------------------------------------------------------------------- # SMP kernel config file options: # Required: options SMP # Symmetric MultiProcessor Kernel # Recommended: options APIC_IO # Symmetric (APIC) I/O # Optional (built-in defaults will work in most cases): options NCPU=1 # number of CPUs options NBUS=3 # number of busses options NAPIC=1 # number of IO APICs options NINTR=24 # number of INTs # Currently broken: #options SMP_PRIVPAGES # BROKEN, DO NOT use! #options SMP_AUTOSTART # BROKEN, DO NOT use! # Rogue hardware: # # Tyan Tomcat II: #options SMP_TIMER_NC # # # SuperMicro P6DNE: #options SMP_TIMER_NC # ------------------------------------------------------------------------------- dmesg output: Copyright (c) 1992-1997 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-970502-SNAP #0: Tue May 6 11:22:22 CEST 1997 root@kilkenny.inria.fr:/usr/src/sys/compile/KILKENNY FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011 io0 (APIC): apic id: 2, version: 0x00170011 CPU: Pentium Pro (686-class CPU) Origin = "GenuineIntel" Id = 0x619 Stepping=9 Features=0xfbff,MTRR,PGE,MCA,CMOV> real memory = 134217728 (131072K bytes) avail memory = 128618496 (125604K bytes) Probing for devices on PCI bus 0: chip0 rev 2 on pci0:0:0 chip1 rev 1 on pci0:7:0 chip2 rev 0 on pci0:7:1 ahc0 rev 0 int a irq 17 on pci0:18:0 Freeing (NOT implemented) irq 15 for ISA cards. ahc0: aic7880 Wide Channel, SCSI Id=7, 16/255 SCBs ahc0: waiting for scsi devices to settle scbus0 at ahc0 bus 0 ahc0: target 0 Tagged Queuing Device sd0 at scbus0 target 0 lun 0 sd0: type 0 fixed SCSI 2 sd0: Direct-Access 2151MB (4406960 512 byte sectors) ahc0: target 1 Tagged Queuing Device sd1 at scbus0 target 1 lun 0 sd1: type 0 fixed SCSI 2 sd1: Direct-Access 2151MB (4406960 512 byte sectors) ahc0: target 4 Tagged Queuing Device sd2 at scbus0 target 4 lun 0 sd2: type 0 removable SCSI 2 sd2: Direct-Access sd2: ILLEGAL REQUEST asc:24,0 Invalid field in CDB sd2 could not mode sense (4). Using ficticious geometry sd2: NOT READY asc:3a,0 Medium not present sd2: could not get size 0MB (0 512 byte sectors) vga0 rev 2 int a irq 16 on pci0:19:0 Freeing (NOT implemented) irq 11 for ISA cards. chip3 rev 1 on pci0:20:0 pci0:20:1: Intel Corporation, device=0x1960, class=memory (misc) int a irq 9 [no driver assigned] Probing for devices on PCI bus 1: de0 rev 17 int a irq 16 on pci1:1:0 Freeing (NOT implemented) irq 11 for ISA cards. de0: 21041 [10Mb/s] pass 1.1 de0: address 00:00:c0:c3:00:f9 Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2: disabled, not probed. lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in wdc0: disabled, not probed. npx0 on motherboard npx0: INT 16 interface sb0 at 0x220-0x22f irq 5 drq 1 on isa sb0: sbxvi0 at 0x220-0x22f irq 5 drq 5 on isa sbxvi0: sbmidi0 at 0x330-0x331 irq 5 on isa sbmidi0: Enabled INTs: 0, 1, 3, 4, 5, 6, 7, 8, 16, 17, imen: 0x00fcfe04 de0: enabling 10baseT port SMP: All idle procs online. You can now activate SMP processing, use: sysctl -w kern.smp_active=1 =============================================================================== From owner-freebsd-smp Tue May 6 09:36:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA20193 for smp-outgoing; Tue, 6 May 1997 09:36:55 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA20188 for ; Tue, 6 May 1997 09:36:52 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id KAA07279; Tue, 6 May 1997 10:34:17 -0600 (MDT) Message-Id: <199705061634.KAA07279@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Francis Dupont cc: "John S. Dyson" , smp@freebsd.org Subject: Re: maptable of SuperMicro P6DNH In-reply-to: Your message of "Tue, 06 May 1997 18:21:57 +0200." <199705061621.SAA20405@givry.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 May 1997 10:34:17 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, >FreeBSD/SMP: Multiprocessor motherboard > cpu0 (BSP): apic id: 0, version: 0x00040011 > io0 (APIC): apic id: 2, version: 0x00170011 >CPU: Pentium Pro (686-class CPU) you appear to only have 1 CPU on this board, is that correct? if so I'm surprised it can run an SMP kernel at all! we have given zip thought to such a thing... -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Tue May 6 09:56:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA21285 for smp-outgoing; Tue, 6 May 1997 09:56:42 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA21278 for ; Tue, 6 May 1997 09:56:38 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id KAA07354; Tue, 6 May 1997 10:54:12 -0600 (MDT) Message-Id: <199705061654.KAA07354@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Stephen Roome cc: Terry Lambert , bruce@zuhause.mn.org, freebsd-smp@FreeBSD.org Subject: Re: Where to start SMP? In-reply-to: Your message of "Tue, 06 May 1997 11:19:22 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 May 1997 10:54:11 -0600 Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi, > What was a lot harder was figuring what the options do. The new LINT may have > all (or many anyway) possible options in it, but most of them are poorly > explained and 50% of them aren't documented other than 2 words. > > Although a generic smp config file would be helpful, a slightly more > prominent entry in the standard handbook really is required as well. we know that the doc is severly lacking, its just a matter of priorities. There are approx. 2-3 people working part time on this, and there is more than enough to keep us busy with the code. This is something that one or more of the more experienced users should jump on. If someone were to write a handbook section, I and others will be available to answer specific questions where there are holes. We just dont have the time to do it all! We need: improved LINT section. man 4(?) smp. info page. handbook section. entry in the FAQ. ??? -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Tue May 6 10:00:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA21442 for smp-outgoing; Tue, 6 May 1997 10:00:13 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA21432; Tue, 6 May 1997 10:00:10 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id KAA07381; Tue, 6 May 1997 10:59:07 -0600 (MDT) Message-Id: <199705061659.KAA07381@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Stephen Roome cc: hackers@freebsd.org, smp@freebsd.org Subject: Re: 7860 In-reply-to: Your message of "Tue, 06 May 1997 12:58:19 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 May 1997 10:59:07 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > So, how long before SMP is in a release version? When 3.0-current becomes 3.0-RELEASE. We went from 2.2-current to 3.0 in part because of the major changes that we knew would occur for SMP, thus it will never be retro-fitted to 2.2. (I have no guesses as to when 3.0-RELEASE will happen) -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Tue May 6 10:29:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA22933 for smp-outgoing; Tue, 6 May 1997 10:29:43 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA22926 for ; Tue, 6 May 1997 10:29:39 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA18734; Tue, 6 May 1997 10:23:29 -0700 From: Terry Lambert Message-Id: <199705061723.KAA18734@phaeton.artisoft.com> Subject: Re: Where to start SMP? To: steve@visint.co.uk (Stephen Roome) Date: Tue, 6 May 1997 10:23:29 -0700 (MST) Cc: terry@lambert.org, smp@csn.net, bruce@zuhause.mn.org, freebsd-smp@FreeBSD.ORG In-Reply-To: from "Stephen Roome" at May 6, 97 11:19:22 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > It would help posters like this, now that the merge is done, to have > > an "SMP" file in /etc/i386/conf" for an SMP version of "GENERIC". > > I'm not sure that that is the problem area. I only just started with SMP, > and the biggest problem was not figuring out the config (as frankly there > really isn't much to do to make it work from a user point of view). This is not necessarily to help you, specifically. It's to remove the curb for people wanting to beat on the SMP kernel and provide feedback information to the SMP coders without requiring a lot of hand-holding in trade for the (needed) feedback. One effect this should have is that an SMP kernel should be built for the snap's (whech gets it on the CDROM). This won't happen without an "SMP GENERIC config" of some kind. > What was a lot harder was figuring what the options do. The new LINT may have > all (or many anyway) possible options in it, but most of them are poorly > explained and 50% of them aren't documented other than 2 words. The SMP options also need to be runtime instead of compile time configurable, based on flags values which can be modified at boot configuration time. This would let a single SMP kernel work on all hardware, regardless of which options must be twiddled to get it to go. The alternative is multiple "SMP GENERIC" configurations -- not a likely event. My suggestion was aimed at main-streaming the code so that there would be more feedback, while at the same time offloading some of the issues requring hand-holding to the standard UP kernel channels. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Tue May 6 10:48:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA23965 for smp-outgoing; Tue, 6 May 1997 10:48:41 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA23953 for ; Tue, 6 May 1997 10:48:37 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id LAA07575; Tue, 6 May 1997 11:47:20 -0600 (MDT) Message-Id: <199705061747.LAA07575@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Terry Lambert cc: steve@visint.co.uk (Stephen Roome), bruce@zuhause.mn.org, freebsd-smp@FreeBSD.ORG Subject: Re: Where to start SMP? In-reply-to: Your message of "Tue, 06 May 1997 10:23:29 PDT." <199705061723.KAA18734@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 May 1997 11:47:19 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > This is not necessarily to help you, specifically. It's to remove > the curb for people wanting to beat on the SMP kernel and provide > feedback information to the SMP coders without requiring a lot of > hand-holding in trade for the (needed) feedback. > > One effect this should have is that an SMP kernel should be built > for the snap's (whech gets it on the CDROM). This won't happen > without an "SMP GENERIC config" of some kind. I've avoided this thinking that it was unnecessary src bloat, but perhaps I'll go ahead and add SMP to i386/conf. --- > The SMP options also need to be runtime instead of compile time > configurable, based on flags values which can be modified at boot > configuration time. This would let a single SMP kernel work on all > hardware, regardless of which options must be twiddled to get it to > go. The alternative is multiple "SMP GENERIC" configurations -- not > a likely event. This would centainly be desirable. I need to think about the necessary changes to the code to make it feasable. My first thoughts: APIC_IO is going away as an option (it will be mandatory) SMP_AUTOSTART will be easy. NCPUS is probably the hardest, I think the compromise will be that SMP.GENERIC will support up to 4 CPUs, beyond that will require a compile. SMP_TIMER_NC will be easy to add as a boot time option. the better solution is to write the code that looks for the timere INTs on both ICU and APIC and programs accordingly. I've never dealt with coding boot-time options, could someone point me towards a good example in the syr/sys tree? -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Tue May 6 12:09:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA29013 for smp-outgoing; Tue, 6 May 1997 12:09:30 -0700 (PDT) Received: from mpress.com (mpress.com [208.138.29.130]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA29003 for ; Tue, 6 May 1997 12:09:29 -0700 (PDT) Received: (qmail 433 invoked by uid 100); 6 May 1997 19:09:20 -0000 Message-ID: <19970506120919.05018@mpress.com> Date: Tue, 6 May 1997 12:09:19 -0700 From: Brian Litzinger To: freebsd-current@freebsd.org, freebsd-smp@freebsd.org Subject: ed2 device timeout (current/SMP) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I built a recent -current(SMP) kernel and now my ethernet devices report 'ed2 device timeout' or 'de0 device timeout'. So I did a make world and still have the problem. The systems work correctly with a -current(UNI) kernel from a few days earlier. Any ideas what has done wrong? The MB is a Tyan S1668. -- Brian Litzinger brian@mediacity.com From owner-freebsd-smp Tue May 6 12:21:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA29661 for smp-outgoing; Tue, 6 May 1997 12:21:47 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA29651 for ; Tue, 6 May 1997 12:21:42 -0700 (PDT) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.5/8.7.3) with ESMTP id VAA20885; Tue, 6 May 1997 21:21:33 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id VAA21014; Tue, 6 May 1997 21:21:31 +0200 (MET DST) Message-Id: <199705061921.VAA21014@givry.inria.fr> From: Francis Dupont To: Steve Passe cc: "John S. Dyson" , smp@freebsd.org Subject: Re: maptable of SuperMicro P6DNH In-reply-to: Your message of Tue, 06 May 1997 10:34:17 MDT. <199705061634.KAA07279@Ilsa.StevesCafe.com> Date: Tue, 06 May 1997 21:21:29 +0200 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In your previous mail you wrote: >FreeBSD/SMP: Multiprocessor motherboard > cpu0 (BSP): apic id: 0, version: 0x00040011 > io0 (APIC): apic id: 2, version: 0x00170011 >CPU: Pentium Pro (686-class CPU) you appear to only have 1 CPU on this board, is that correct? if so I'm surprised it can run an SMP kernel at all! we have given zip thought to such a thing... => of course I have only one CPU, my purpose is not (yet :-) to debug the SMP kernel. I need only a large number of PCI slots (I have 8 slots)... But the SMP kernel seems to run and mptable gives interesting results! Thanks Francis.Dupont@inria.fr PS: perhaps when SMP support will be available on many OSs I'll buy an extra processor. From owner-freebsd-smp Tue May 6 12:59:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA01274 for smp-outgoing; Tue, 6 May 1997 12:59:59 -0700 (PDT) Received: from mpress.com (mpress.com [208.138.29.130]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA01264 for ; Tue, 6 May 1997 12:59:55 -0700 (PDT) Received: (qmail 1936 invoked by uid 100); 6 May 1997 19:59:50 -0000 Message-ID: <19970506125949.44800@mpress.com> Date: Tue, 6 May 1997 12:59:49 -0700 From: Brian Litzinger To: freebsd-current@freebsd.org, freebsd-smp@freebsd.org Subject: ed2 device timeout [more] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As reported earlier a -current(SMP) kernel, running in single processor mode, on my Tyan S1668 breaks both the ed2 and de0 devices such that I get 'ed2: device timeout' or 'de0: device timeout' errors. However, a -current(UNI) kernel from the same source works correctly. Also, the kernel.2cpu.970428 reference SMP kernel exhibits the same broken behavior. Any ideas? -- Brian Litzinger brian@mediacity.com From owner-freebsd-smp Tue May 6 13:18:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA02370 for smp-outgoing; Tue, 6 May 1997 13:18:12 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA02363; Tue, 6 May 1997 13:18:09 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id OAA00934; Tue, 6 May 1997 14:17:58 -0600 (MDT) Message-Id: <199705062017.OAA00934@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Brian Litzinger cc: freebsd-current@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: ed2 device timeout [more] In-reply-to: Your message of "Tue, 06 May 1997 12:59:49 PDT." <19970506125949.44800@mpress.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 May 1997 14:17:57 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > As reported earlier a -current(SMP) kernel, running in single processor > mode, on my Tyan S1668 breaks both the ed2 and de0 devices such that I > get 'ed2: device timeout' or 'de0: device timeout' errors. > > However, a -current(UNI) kernel from the same source works correctly. > > Also, the kernel.2cpu.970428 reference SMP kernel exhibits the same > broken behavior. > > Any ideas? I just cvsup'ed -current sys and am rebuilding, will let you know if I find any brokenness. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Tue May 6 13:43:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA03760 for smp-outgoing; Tue, 6 May 1997 13:43:40 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA03753; Tue, 6 May 1997 13:43:37 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id OAA01050; Tue, 6 May 1997 14:42:18 -0600 (MDT) Message-Id: <199705062042.OAA01050@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Steve Passe cc: Brian Litzinger , freebsd-current@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Subject: Re: ed2 device timeout [more] In-reply-to: Your message of "Tue, 06 May 1997 14:17:57 MDT." <199705062017.OAA00934@Ilsa.StevesCafe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 May 1997 14:42:18 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > > As reported earlier a -current(SMP) kernel, running in single processor > > mode, on my Tyan S1668 breaks both the ed2 and de0 devices such that I > > get 'ed2: device timeout' or 'de0: device timeout' errors. > > > > However, a -current(UNI) kernel from the same source works correctly. > > > > Also, the kernel.2cpu.970428 reference SMP kernel exhibits the same > > broken behavior. > > > > Any ideas? > > I just cvsup'ed -current sys and am rebuilding, will let you know if I find > any brokenness. I've successfully built and run both SMP-GENERIC and my LOCAL SMP with the de0 driver. No problems with either. please confirm are you using APIC_IO? what messages occur when the de0 device is probed? is the INT being redirected to the APIC as expected? I suspect that it might be something in world that broke. I'm not in a position to rebuild world right now so I can't test that scenerio. Has anyone else built world within the last 24 hours and had success (or failure) with the SMP kernel? -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed May 7 03:24:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA14772 for smp-outgoing; Wed, 7 May 1997 03:24:06 -0700 (PDT) Received: from mpress.com (mpress.com [208.138.29.130]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id DAA14762 for ; Wed, 7 May 1997 03:24:02 -0700 (PDT) Received: (qmail 1290 invoked by uid 100); 7 May 1997 10:24:00 -0000 Message-ID: <19970507032359.06345@mpress.com> Date: Wed, 7 May 1997 03:23:59 -0700 From: Brian Litzinger To: Steve Passe Cc: freebsd-smp@FreeBSD.ORG Subject: Re: ed2 device timeout [more 2] References: <199705062017.OAA00934@Ilsa.StevesCafe.com> <199705062042.OAA01050@Ilsa.StevesCafe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199705062042.OAA01050@Ilsa.StevesCafe.com>; from Steve Passe on Tue, May 06, 1997 at 02:42:18PM -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On May 6, Steve Passe wrote: brian@mediacity.com wrote: > > > As reported earlier a -current(SMP) kernel, running in single processor > > > mode, on my Tyan S1668 breaks both the ed2 and de0 devices such that I > > > get 'ed2: device timeout' or 'de0: device timeout' errors. > > > > > > However, a -current(UNI) kernel from the same source works correctly. > > > > > > Also, the kernel.2cpu.970428 reference SMP kernel exhibits the same > > > broken behavior. Steve Passe wrote: > I've successfully built and run both SMP-GENERIC and my LOCAL SMP with the > de0 driver. No problems with either. > > please confirm are you using APIC_IO? >From /sys/i386/conf/SMP options SMP # Symmetric MultiProcessor Kernel # Recommended: options APIC_IO # Symmetric (APIC) I/O options SMP_INVLTLB # invalidate TLB IPIs # Optional, these are the defaults: #options NCPU=2 # number of CPUs #options NBUS=4 # number of busses #options NAPIC=1 # number of IO APICs #options NINTR=24 # number of INTs machine "i386" cpu "I586_CPU" cpu "I686_CPU" ident GENERIC maxusers 32 > what messages occur when the de0 device is probed? is the INT being > redirected > to the APIC as expected? I plugged both the ed2 and de0 cards into the system cause I was tired of swapping them back and forth. Now the de0 works and the ed2 reports the timeout errors. So at least the system has connectivity again. Here is what the system had to say with this semi-working setup. (following are copies of the same info for single card failure modes) [-----------------ed2+de0, de0 works------------------] FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011 cpu1 (AP): apic id: 0, version: 0x00040011 io0 (APIC): apic id: 2, version: 0x00170011 CPU: Pentium Pro (686-class CPU) Origin = "GenuineIntel" Id = 0x612 Stepping=2 Features=0xfbff rev 0 int a irq 10 on pci0:10:0 ed2: address 00:a0:76:a0:4f:2a, type NE2000 (16 bit) de0 rev 35 int a irq 19 on pci0:11:0 Freeing (NOT implimented) irq 11 for ISA cards. de0: 21040 [10Mb/s] pass 2.3 de0: address 00:c0:95:ec:22:ef de0: enabling 10baseT port Freeing (NOT implimented) irq 15 for ISA cards. ... Enabled INTs: 1, 2, 3, 4, 6, 7, 8, 10, 18, 19, imen: 0x00f3fa21 ... [-----------------ed2 only, no work------------------] May 6 20:19:33 research /kernel.foo: FreeBSD/SMP: Multiprocessor motherboard May 6 20:19:33 research /kernel.foo: cpu0 (BSP): apic id: 1, version: 0x00040011 May 6 20:19:33 research /kernel.foo: cpu1 (AP): apic id: 0, version: 0x00040011 May 6 20:19:33 research /kernel.foo: io0 (APIC): apic id: 2, version: 0x00170011 May 6 20:19:33 research /kernel.foo: CPU: Pentium Pro (686-class CPU) May 6 20:19:33 research /kernel.foo: Origin = "GenuineIntel" Id = 0x612 Stepping=2 May 6 20:19:33 research /kernel.foo: Features=0xfbff,MTRR,PGE,MCA,CMOV> ... May 6 20:19:33 research /kernel.foo: ed2 rev 0 int a irq 11 on pci0:10:0 May 6 20:19:33 research /kernel.foo: ed2: address 00:a0:76:a0:4f:2a, type NE2000 (16 bit) May 6 20:19:33 research /kernel.foo: ahc0 rev 3 int a irq 18 on pci0:12:0 May 6 20:19:33 research /kernel.foo: Freeing (NOT implemented) redirected PCI irq 15. ... May 6 20:19:35 research /kernel.foo: Enabled INTs: 1, 2, 3, 4, 6, 7, 8, 11, 18, imen: 0x00fbf621 May 6 20:19:35 research /kernel.foo: SMP: All idle procs online. May 6 20:19:35 research /kernel.foo: You can now activate SMP processing, use: sysctl -w kern.smp_active=2 May 6 20:19:35 research /kernel.foo: ed2: device timeout May 6 20:19:41 research /kernel.foo: ed2: device timeout [-----------------de0 only, no work------------------] May 6 09:07:39 research /kernel: FreeBSD/SMP: Multiprocessor motherboard May 6 09:07:39 research /kernel: cpu0 (BSP): apic id: 1, version: 0x00040011 May 6 09:07:39 research /kernel: cpu1 (AP): apic id: 0, version: 0x00040011 May 6 09:07:39 research /kernel: io0 (APIC): apic id: 2, version: 0x00170011 May 6 09:07:39 research /kernel: CPU: Pentium Pro (686-class CPU) May 6 09:07:39 research /kernel: Origin = "GenuineIntel" Id = 0x612 Steppin g=2 May 6 09:07:39 research /kernel: Features=0xfbff,MTRR,PGE,MCA,CMOV> ... May 6 09:07:39 research /kernel: de0 rev 35 int a irq 11 on pci0:10:0 May 6 09:07:39 research /kernel: de0: 21040 [10Mb/s] pass 2.3 May 6 09:07:39 research /kernel: de0: address 00:c0:95:ec:22:ef May 6 09:07:40 research /kernel: de0: enabling BNC/AUI port May 6 09:07:40 research /kernel: vga0 rev 0 on pci0:11:0 May 6 09:07:40 research /kernel: ahc0 rev 3 in t a irq 18 on pci0:12:0 May 6 09:07:40 research /kernel: Freeing (NOT implemented) redirected PCI irq 1 5. ... May 6 09:07:41 research /kernel: Enabled INTs: 1, 2, 3, 4, 6, 7, 8, 11, 18, ime n: 0x00fbf621 May 6 09:07:41 research /kernel: SMP: All idle procs online. May 6 09:07:41 research /kernel: You can now activate SMP processing, use: sysc tl -w kern.smp_active=2 May 6 09:07:41 research /kernel: de0: transmission timeout For those of you who read all the way through this here is a bit of humor: I was playing with the dual Pentium Pro system for quite a bit. Later I noticed my P5-90 based system, the one my X server runs on, seemed slower than usual. I just figured it as getting used to the 2xPentiumPro system too quickly. After about 4 hours of such figuring I decided it wasn't my imagination, and found that I had bumped the turbo switch and the P5-90 had been running at 8MHz for the past hours. 8-) -- Brian Litzinger brian@mediacity.com From owner-freebsd-smp Wed May 7 06:19:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA21537 for smp-outgoing; Wed, 7 May 1997 06:19:43 -0700 (PDT) Received: from bagpuss.visint.co.uk (bagpuss.vis.net.uk [194.207.134.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA21531 for ; Wed, 7 May 1997 06:19:39 -0700 (PDT) Received: from bagpuss.visint.co.uk (bagpuss.vis.net.uk [194.207.134.1]) by bagpuss.visint.co.uk (8.7.5/8.7.3) with SMTP id OAA06952; Wed, 7 May 1997 14:29:40 +0100 (BST) Date: Wed, 7 May 1997 14:29:40 +0100 (BST) From: Stephen Roome To: Steve Passe cc: Terry Lambert , bruce@zuhause.mn.org, freebsd-smp@FreeBSD.org Subject: Re: Where to start SMP? In-Reply-To: <199705061654.KAA07354@Ilsa.StevesCafe.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 Tue, 6 May 1997, Steve Passe wrote: > Hi, > > > What was a lot harder was figuring what the options do. The new LINT may have > > all (or many anyway) possible options in it, but most of them are poorly > > explained and 50% of them aren't documented other than 2 words. > > > > Although a generic smp config file would be helpful, a slightly more > > prominent entry in the standard handbook really is required as well. > > we know that the doc is severly lacking, its just a matter of priorities. > There are approx. 2-3 people working part time on this, and there is more > than enough to keep us busy with the code. This is something that one or > more of the more experienced users should jump on. If someone were to > write a handbook section, I and others will be available to answer specific > questions where there are holes. We just dont have the time to do it all! Most of the docs are already there on the web pages. It's wasn't easy to find the SMP homepage, but after that it got easier =) What to buy is more confusing, but how to install is really very easy now, apart from do ppl need to download the source for libkvm and ps etc. and recompile. That's about all that is unclear. There's only one other thing, that I as a user would ask and that's that when the options go in LINT, it's important that each 50 hours of coding gets at least 5 mins worth of typing an explanation in LINT if it gives a compile option. It's not much to ask, and it means that the new code will get used sooner. I remeber having a slow IDE drive for ages on my home computer, until someone thought to tell me that adding flags 0x80ff80ff would be a good idea. Someone probably spent ages getting some code working to do this, and I didn't use it for months, even though it was there. Okay, I'm dim, but there's a lot of people who stay with Linux for the very reason that to compile a kernel they type yes and no a few times. Just making LINT slightly more readable might be very good for FreeBSD. [On the whole though, I'm damn impressed with the SMP support so far as it's saved me having to install NT =)] -- Steve Roome Technical Systems Manager, Vision Interactive Ltd. E: steve@visint.co.uk M: +44 (0) 976 241 342 T: +44 (0) 117 973 0597 F: +44 (0) 117 923 8522 From owner-freebsd-smp Wed May 7 06:26:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA21936 for smp-outgoing; Wed, 7 May 1997 06:26:37 -0700 (PDT) Received: from bagpuss.visint.co.uk (bagpuss.vis.net.uk [194.207.134.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA21930 for ; Wed, 7 May 1997 06:26:34 -0700 (PDT) Received: from bagpuss.visint.co.uk (bagpuss.vis.net.uk [194.207.134.1]) by bagpuss.visint.co.uk (8.7.5/8.7.3) with SMTP id OAA07053; Wed, 7 May 1997 14:37:01 +0100 (BST) Date: Wed, 7 May 1997 14:37:01 +0100 (BST) From: Stephen Roome To: Terry Lambert cc: freebsd-smp@freebsd.org Subject: Re: Where to start SMP? In-Reply-To: <199705061723.KAA18734@phaeton.artisoft.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 Tue, 6 May 1997, Terry Lambert wrote: > > > It would help posters like this, now that the merge is done, to have > > > an "SMP" file in /etc/i386/conf" for an SMP version of "GENERIC". > > > > I'm not sure that that is the problem area. I only just started with SMP, > > and the biggest problem was not figuring out the config (as frankly there > > really isn't much to do to make it work from a user point of view). > > This is not necessarily to help you, specifically. It's to remove > the curb for people wanting to beat on the SMP kernel and provide > feedback information to the SMP coders without requiring a lot of > hand-holding in trade for the (needed) feedback. Yup, sorry, following on from the conversation though, in the interests of helping people just documenting the options better would be a nice idea. What you say though is a different matter. > > One effect this should have is that an SMP kernel should be built > for the snap's (whech gets it on the CDROM). This won't happen > without an "SMP GENERIC config" of some kind. A nice option would be a choice of kernel from the install menu. SMP or UP. (perhaps it can decide for you ?) > > > > What was a lot harder was figuring what the options do. The new LINT may have > > all (or many anyway) possible options in it, but most of them are poorly > > explained and 50% of them aren't documented other than 2 words. > > The SMP options also need to be runtime instead of compile time > configurable, based on flags values which can be modified at boot > configuration time. This would let a single SMP kernel work on all > hardware, regardless of which options must be twiddled to get it to > go. The alternative is multiple "SMP GENERIC" configurations -- not > a likely event. Maybe, but surely some of the changes to run an efficient SMP system should come at kernel compile level. Unless FreeBSD moves to a modular system on the scale of something like HURD this looks likely to decrease performance. > > > My suggestion was aimed at main-streaming the code so that there would > be more feedback, while at the same time offloading some of the issues > requring hand-holding to the standard UP kernel channels. > Hand holding gets a user base, don't knock it. It worked for Windows. > > Regards, > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > Steve Roome Technical Systems Manager, Vision Interactive Ltd. E: steve@visint.co.uk M: +44 (0) 976 241 342 T: +44 (0) 117 973 0597 F: +44 (0) 117 923 8522 From owner-freebsd-smp Wed May 7 08:31:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA27802 for smp-outgoing; Wed, 7 May 1997 08:31:16 -0700 (PDT) Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id IAA27797 for ; Wed, 7 May 1997 08:31:14 -0700 (PDT) Received: from mailhost.ipsilon.com (localhost [127.0.0.1]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id IAA16545; Wed, 7 May 1997 08:28:03 -0700 Message-Id: <199705071528.IAA16545@mailhost.Ipsilon.COM> X-Mailer: exmh version 1.6.4 10/10/95 To: Stephen Roome cc: Terry Lambert , freebsd-smp@FreeBSD.ORG Subject: Re: Where to start SMP? In-reply-to: Your message of "Wed, 07 May 1997 14:37:01 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 May 1997 08:28:02 -0700 From: Peter Grehan Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>This would let a single SMP kernel work on all >> hardware, regardless of which options must be twiddled to get it to >> go. The alternative is multiple "SMP GENERIC" configurations -- not >> a likely event. > >Maybe, but surely some of the changes to run an efficient SMP system >should come at kernel compile level. Unless FreeBSD moves to a modular >system on the scale of something like HURD this looks likely to decrease >performance. Have a look at http://www.digital.com/info/DTJF03/DTJF03SC.TXT - a single kernel is used, with the lock strategy determined at boot-time. The overhead for this was brought down to just 3% over that of a system that had locks compiled out. So it is possible, but may require some effort. later, Peter. From owner-freebsd-smp Wed May 7 10:08:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA02102 for smp-outgoing; Wed, 7 May 1997 10:08:04 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA02094 for ; Wed, 7 May 1997 10:08:02 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA21345; Wed, 7 May 1997 10:04:01 -0700 From: Terry Lambert Message-Id: <199705071704.KAA21345@phaeton.artisoft.com> Subject: Re: Where to start SMP? To: steve@visint.co.uk (Stephen Roome) Date: Wed, 7 May 1997 10:04:01 -0700 (MST) Cc: terry@lambert.org, freebsd-smp@FreeBSD.ORG In-Reply-To: from "Stephen Roome" at May 7, 97 02:37:01 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The SMP options also need to be runtime instead of compile time > > configurable, based on flags values which can be modified at boot > > configuration time. This would let a single SMP kernel work on all > > hardware, regardless of which options must be twiddled to get it to > > go. The alternative is multiple "SMP GENERIC" configurations -- not > > a likely event. > > Maybe, but surely some of the changes to run an efficient SMP system > should come at kernel compile level. Unless FreeBSD moves to a modular > system on the scale of something like HURD this looks likely to decrease > performance. Depends on whether the options are set with negative or positive logic, and at what level they are wired in. Best case, they cause the use of different contents of an existing function pointer and are set at boot time. Worst case, they are an extra compare and branch in a path. If you want optimal performance, then have #ifdef's to dike out the compares (worst case) at compile time, and then *you* compile your kernel. The point of a GENERIC is to make some that (within memory limits) works on as much hardware as possible. The same should be true of an SMP-GENERIC, considering it's going to be on a CDROM. > > My suggestion was aimed at main-streaming the code so that there would > > be more feedback, while at the same time offloading some of the issues > > requring hand-holding to the standard UP kernel channels. > > Hand holding gets a user base, don't knock it. It worked for Windows. I understand. But if you can automate it to the level that there isn't a lot of SMP-specific hand-holding, then you've freed up resources to work on SMP. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Wed May 7 10:22:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA02996 for smp-outgoing; Wed, 7 May 1997 10:22:56 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA02981 for ; Wed, 7 May 1997 10:22:53 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id LAA04596; Wed, 7 May 1997 11:22:34 -0600 (MDT) Message-Id: <199705071722.LAA04596@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Brian Litzinger cc: smp@freebsd.org Subject: Re: ed2 device timeout [more 2] In-reply-to: Your message of "Wed, 07 May 1997 03:23:59 PDT." <19970507032359.06345@mpress.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 May 1997 11:22:33 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, q1: was this the same binary kernel for all 3 tests? please send me the COMPLETE output of "mptable -dmesg" for all 3 cases, especially the de0 case. something is definately wrong in the PCI card recognition area, In the ed2 + de0 case the de0 (only) is recognized as being on the APIC, and it works. for all others the PCI cards are NOT recognized as being attached to the APIC, and fail (as would be expected). Scratch your head, has anything changed in the system recently , BIOS configuration, new or replacement cards, ??? So far no one else has reported similar problems, I have 1 de0 card in my test system, no other network cards, and it works fine, so I'm really puzzled by this one! -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed May 7 10:29:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA03305 for smp-outgoing; Wed, 7 May 1997 10:29:09 -0700 (PDT) Received: from caipfs.rutgers.edu (root@caipfs.rutgers.edu [128.6.19.100]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA03298 for ; Wed, 7 May 1997 10:29:06 -0700 (PDT) Received: from jenolan.caipgeneral (jenolan.rutgers.edu [128.6.111.5]) by caipfs.rutgers.edu (8.8.5/8.8.5) with SMTP id NAA00422; Wed, 7 May 1997 13:27:30 -0400 (EDT) Received: by jenolan.caipgeneral (SMI-8.6/SMI-SVR4) id NAA05360; Wed, 7 May 1997 13:26:09 -0400 Date: Wed, 7 May 1997 13:26:09 -0400 Message-Id: <199705071726.NAA05360@jenolan.caipgeneral> From: "David S. Miller" To: terry@lambert.org CC: steve@visint.co.uk, terry@lambert.org, freebsd-smp@FreeBSD.ORG In-reply-to: <199705071704.KAA21345@phaeton.artisoft.com> (message from Terry Lambert on Wed, 7 May 1997 10:04:01 -0700 (MST)) Subject: Re: Where to start SMP? Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk From: Terry Lambert Date: Wed, 7 May 1997 10:04:01 -0700 (MST) Depends on whether the options are set with negative or positive logic, and at what level they are wired in. Best case, they cause the use of different contents of an existing function pointer and are set at boot time. Worst case, they are an extra compare and branch in a path. Wrong, best case they use self modifying code so there is zero cost. Each call really points to a patch function, which takes the return address and patches that call instruction to actually call the locking function for the desired MODE. Therefore you eat the relocation cost once per code path, it essentially dynamically links itself at run time. Come on Terry, read the friggin' paper before becoming an instant expert on how to do these things... ---------------------------------------------//// Yow! 11.26 MB/s remote host TCP bandwidth & //// 199 usec remote TCP latency over 100Mb/s //// ethernet. Beat that! //// -----------------------------------------////__________ o David S. Miller, davem@caip.rutgers.edu /_____________/ / // /_/ >< From owner-freebsd-smp Wed May 7 10:34:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA03639 for smp-outgoing; Wed, 7 May 1997 10:34:09 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA03634 for ; Wed, 7 May 1997 10:34:06 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id LAA04643; Wed, 7 May 1997 11:32:34 -0600 (MDT) Message-Id: <199705071732.LAA04643@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Stephen Roome cc: Terry Lambert , freebsd-smp@FreeBSD.ORG Subject: Re: Where to start SMP? In-reply-to: Your message of "Wed, 07 May 1997 14:37:01 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 May 1997 11:32:34 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, >Maybe, but surely some of the changes to run an efficient SMP system >should come at kernel compile level. Unless FreeBSD moves to a modular >system on the scale of something like HURD this looks likely to decrease >performance. my rule is that when the choice is between "works faster/better" and "more convient", "faster/better" wins. I don't always win the "discussions" where we make the final decision, but I'll always fight for that position. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed May 7 10:40:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA03941 for smp-outgoing; Wed, 7 May 1997 10:40:17 -0700 (PDT) Received: from bagpuss.visint.co.uk (bagpuss.vis.net.uk [194.207.134.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA03936 for ; Wed, 7 May 1997 10:40:13 -0700 (PDT) Received: from bagpuss.visint.co.uk (bagpuss.vis.net.uk [194.207.134.1]) by bagpuss.visint.co.uk (8.7.5/8.7.3) with SMTP id SAA10145; Wed, 7 May 1997 18:50:39 +0100 (BST) Date: Wed, 7 May 1997 18:50:39 +0100 (BST) From: Stephen Roome To: Terry Lambert cc: freebsd-smp@FreeBSD.ORG Subject: Re: Where to start SMP? In-Reply-To: <199705071704.KAA21345@phaeton.artisoft.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 Wed, 7 May 1997, Terry Lambert wrote: > > > The SMP options also need to be runtime instead of compile time > > > configurable, based on flags values which can be modified at boot > > > configuration time. This would let a single SMP kernel work on all > > > hardware, regardless of which options must be twiddled to get it to > > > go. The alternative is multiple "SMP GENERIC" configurations -- not > > > a likely event. > > > > Maybe, but surely some of the changes to run an efficient SMP system > > should come at kernel compile level. Unless FreeBSD moves to a modular > > system on the scale of something like HURD this looks likely to decrease > > performance. > > Depends on whether the options are set with negative or positive > logic, and at what level they are wired in. Best case, they cause > the use of different contents of an existing function pointer and > are set at boot time. Worst case, they are an extra compare and > branch in a path. Is this really feasible in terms of development time. For the best case you're describing isn't it going to take a lot longer to write stuff? If so, wouldn't it be too long? > > If you want optimal performance, then have #ifdef's to dike out the > compares (worst case) at compile time, and then *you* compile your > kernel. > I'd want optimal performance, but imho it's not feasible/possible. Unless of course you go totally microkernel.... Although I'm sure enough people will be arguing macro/micro kernel for a few millenia yet I don't think moving FreeBSD towards 1000's of lkm's is going to improve it, but it would/might give a higher degree of platform / architecture support... just think: /lkm/mod_smp.o nasty?! > The point of a GENERIC is to make some that (within memory limits) > works on as much hardware as possible. The same should be true of > an SMP-GENERIC, considering it's going to be on a CDROM. Okay, that's great but is it feasible to have a GENERIC kernel which works on both UP and SMP, without losing performance on both architectures over a different design for each ? I don't think so, not without moving to a completely micro-kernel based approach, but then again, I don't write this stuff, I just use it. So, as I said earlier, you just need a menu on install that lets you chose your system stats. Hey, a kernel isn't really very big, you could actually compile quite a few "GENERIC" kernels for each release. e.g GENERIC-UP : single processor freebsd kernel GENERIC-2SMP : dual processor GENERIC-4SMP : 4 processor GENERIC-PCISA : PCI/ISA machine GENERIC-VLB : vesa local bus machine GENERIC-SLIM: cut down minimal boot kernel GENERIC-MOST: bloated near LINT system In fact having the option of about 10 different kernels to install at startup would be a nice idea anyway, it's not necessary, but for those folks who have problems with having to make boot disks for specific hardware it might sort that out. > > > > My suggestion was aimed at main-streaming the code so that there would > > > be more feedback, while at the same time offloading some of the issues > > > requring hand-holding to the standard UP kernel channels. > > > > Hand holding gets a user base, don't knock it. It worked for Windows. > > I understand. But if you can automate it to the level that there isn't > a lot of SMP-specific hand-holding, then you've freed up resources to > work on SMP. Of course, I would think that SMP support should remain as a compile time option rather than run-time. Unless UP is as a poor-mans SMP, but that would slow the system on a UP arch. SMP isn't much different from UP from the user point of view (in fact how many -users- know/care how many processors they have). It's only in the installation that problems occur, so the handholding as far as SMP goes will always be a problem until UP becomes just a 1 processor SMP solution. > Any opinions in this posting are my own and not those of my present > or previous employers. Any opinions in this posting are my own and not those of my present or previous employers, altough it's definitely their fault I'm feeling so damn incoherent at the moment. Steve Roome From owner-freebsd-smp Wed May 7 10:56:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA04614 for smp-outgoing; Wed, 7 May 1997 10:56:19 -0700 (PDT) Received: from bagpuss.visint.co.uk (bagpuss.vis.net.uk [194.207.134.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA04606 for ; Wed, 7 May 1997 10:56:16 -0700 (PDT) Received: from bagpuss.visint.co.uk (bagpuss.vis.net.uk [194.207.134.1]) by bagpuss.visint.co.uk (8.7.5/8.7.3) with SMTP id TAA10332; Wed, 7 May 1997 19:06:41 +0100 (BST) Date: Wed, 7 May 1997 19:06:41 +0100 (BST) From: Stephen Roome To: Steve Passe cc: Terry Lambert , freebsd-smp@FreeBSD.ORG Subject: Re: Where to start SMP? In-Reply-To: <199705071732.LAA04643@Ilsa.StevesCafe.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 Wed, 7 May 1997, Steve Passe wrote: > Hi, > > >Maybe, but surely some of the changes to run an efficient SMP system > >should come at kernel compile level. Unless FreeBSD moves to a modular > >system on the scale of something like HURD this looks likely to decrease > >performance. > > my rule is that when the choice is between "works faster/better" and > "more convient", "faster/better" wins. I don't always win the "discussions" > where we make the final decision, but I'll always fight for that position. I hope your not trying to make money out of this, I'd be worried you meant: faster to write and better for my wallet =) *duck* I guess you'd be for the other (sensible) option.. I don't profess to know which is faster/better I just wouldn't want to see SMP get bastardised into some weird runtime option you can turn on and off really easily. I don't think that's going to be a performance boost ? -- Steve Roome Technical Systems Meddler, Vision Idiotic Ltd. E: steve@visint.co.uk M: +44 (0) 976 241 342 T: +44 (0) 117 973 0597 F: +44 (0) 117 923 8522 From owner-freebsd-smp Wed May 7 11:06:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA05230 for smp-outgoing; Wed, 7 May 1997 11:06:42 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA05223 for ; Wed, 7 May 1997 11:06:40 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id MAA04770; Wed, 7 May 1997 12:05:31 -0600 (MDT) Message-Id: <199705071805.MAA04770@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Stephen Roome cc: Terry Lambert , freebsd-smp@FreeBSD.ORG Subject: Re: Where to start SMP? In-reply-to: Your message of "Wed, 07 May 1997 19:06:41 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 May 1997 12:05:31 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > I don't profess to know which is faster/better I just wouldn't want to see > SMP get bastardised into some weird runtime option you can turn on and off > really easily. I don't think that's going to be a performance boost ? Nor do I. I don't see one kernel binary ever being able to support both UP and SMP (unless the UP version takes the performance hit). Its a struggle just to do it with the same sources! I do see most of the 'minor' SMP options being made runtime, but only within the context of an SMP only kernel. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed May 7 11:34:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA07230 for smp-outgoing; Wed, 7 May 1997 11:34:47 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA07223 for ; Wed, 7 May 1997 11:34:44 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA21813; Wed, 7 May 1997 11:30:42 -0700 From: Terry Lambert Message-Id: <199705071830.LAA21813@phaeton.artisoft.com> Subject: Re: Where to start SMP? To: davem@jenolan.rutgers.edu (David S. Miller) Date: Wed, 7 May 1997 11:30:42 -0700 (MST) Cc: terry@lambert.org, steve@visint.co.uk, freebsd-smp@FreeBSD.ORG In-Reply-To: <199705071726.NAA05360@jenolan.caipgeneral> from "David S. Miller" at May 7, 97 01:26:09 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Depends on whether the options are set with negative or positive > logic, and at what level they are wired in. Best case, they cause > the use of different contents of an existing function pointer and > are set at boot time. Worst case, they are an extra compare and > branch in a path. > > Wrong, best case they use self modifying code so there is zero cost. > Each call really points to a patch function, which takes the return > address and patches that call instruction to actually call the locking > function for the desired MODE. Therefore you eat the relocation cost > once per code path, it essentially dynamically links itself at run > time. > > Come on Terry, read the friggin' paper before becoming an instant > expert on how to do these things... Uh, what "friggin' paper"? We were talking about whether or not run-time configuration should be done in a generic SMP kernel, or if it should be compile time (making it non-generic). I hesistate to suggest self-modifying code without a better understanding of what has and hasn't been called at the time the -c option is processed by the running kernel. At the very lease, the console code is there, so at lest the time code is present -- which means you are past the point of using self-modifying code on the time stuff. Now the timer stuff is one of the run-time options we need to hack, which leaves your idea somewhat problematic... yes, it could be gotten around, but please read the code on how 'boot -c' operates before you condemn me for not going immediately for the self-modifying code. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Wed May 7 11:48:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA07797 for smp-outgoing; Wed, 7 May 1997 11:48:43 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA07792 for ; Wed, 7 May 1997 11:48:41 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA21853; Wed, 7 May 1997 11:44:42 -0700 From: Terry Lambert Message-Id: <199705071844.LAA21853@phaeton.artisoft.com> Subject: Re: Where to start SMP? To: steve@visint.co.uk (Stephen Roome) Date: Wed, 7 May 1997 11:44:42 -0700 (MST) Cc: terry@lambert.org, freebsd-smp@FreeBSD.ORG In-Reply-To: from "Stephen Roome" at May 7, 97 06:50:39 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > The point of a GENERIC is to make some that (within memory limits) > > works on as much hardware as possible. The same should be true of > > an SMP-GENERIC, considering it's going to be on a CDROM. > > Okay, that's great but is it feasible to have a GENERIC kernel which > works on both UP and SMP, without losing performance on both > architectures over a different design for each ? No. That's why you buy Oreo's (compile your own kernel) rather than buying generic cookies (run the install kernel). > I don't think so, not without moving to a completely micro-kernel based > approach, but then again, I don't write this stuff, I just use it. > So, as I said earlier, you just need a menu on install that lets you > chose your system stats. Hey, a kernel isn't really very big, you could > actually compile quite a few "GENERIC" kernels for each release. > e.g > GENERIC-UP : single processor freebsd kernel > GENERIC-2SMP : dual processor > GENERIC-4SMP : 4 processor > GENERIC-PCISA : PCI/ISA machine > GENERIC-VLB : vesa local bus machine > GENERIC-SLIM: cut down minimal boot kernel > GENERIC-MOST: bloated near LINT system > > In fact having the option of about 10 different kernels to install at > startup would be a nice idea anyway, it's not necessary, but for those > folks who have problems with having to make boot disks for specific > hardware it might sort that out. It's evil. It's evil because you move the burden of knowledge either to the user or to the install system. Either one just means that you are pushing work into someone else's "in" box. If the user's "in" box, then you are multiplying the work by the number of users. 8-(. This is a bit off topic anyway. We are discussing issues of: GENERIC-SMP : dual processor GENERIC-SMP-BROKEN-MPTABLE : dual processor ... Not issues of SMP vs. UP, so your table above is, at best, incomplete. The 2 vs. 4 is autodetectable, so it's a non-issue in a release system. > Of course, I would think that SMP support should remain as a compile time > option rather than run-time. Unless UP is as a poor-mans SMP, but that > would slow the system on a UP arch. SMP isn't much different from UP from > the user point of view (in fact how many -users- know/care how many > processors they have). It's only in the installation that problems occur, > so the handholding as far as SMP goes will always be a problem until UP > becomes just a 1 processor SMP solution. There is little architectural difference between supporting SMP and supporting general kernel preemption necessary for kernel multithreading or Real Time scheduling in the UP case. The difference is in mutexes vs. semaphores, for most things, so that the synchronization occurs across processor memory domains instead of in a single memory domain. The UnixWare 2.x kernel's UFS performed 160% of UnixWare 1.x's UFS on the same UP hardware because of concurrency wins that came with SMP-ising the kernel, even without the lock strategy switching. So do I think UP will be better off with an SMP kernel? Yes, if it's done correctly. Now as to UP vs. SMP locking: that's an isolated enough issue that David Miller's point about self-modifying code is a good point. But it would mean isolating all code up to the point of the SMP startup in such a way as to either not encounter locking primitivs, or, more likely, not encounter the hot-patch code in the boot phase, defaulting to one or the other, and then replacing the function pointer at the call address with the hot patch function. A lot of voodoo. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Wed May 7 12:42:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA10740 for smp-outgoing; Wed, 7 May 1997 12:42:14 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA10733 for ; Wed, 7 May 1997 12:42:09 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id NAA05240; Wed, 7 May 1997 13:41:52 -0600 (MDT) Message-Id: <199705071941.NAA05240@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Brian Litzinger cc: freebsd-smp@FreeBSD.ORG Subject: Re: ed2 device timeout [more 2] In-reply-to: Your message of "Wed, 07 May 1997 03:23:59 PDT." <19970507032359.06345@mpress.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 May 1997 13:41:52 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Brian, Peter found the cause of your problem, code I recently added to deal with secondary IDE controller/APIC mapping was at fault. try this patch: ------------------------------------ cut ------------------------------------- --- mp_machdep.c 1997/05/05 22:56:27 1.8 +++ mp_machdep.c 1997/05/07 19:29:26 @@ -901,7 +901,10 @@ apicpin = get_isa_apic_irq(isairq - 1); if (apicpin == -1) { - return 0; + apicpin = get_eisa_apic_irq(isairq - 1); + if (apicpin == -1) { + return 0; + } } return (1 << apicpin); ------------------------------------ cut ------------------------------------- I will commit it to the src tree later tonite, Peter is currently doing a large commit that I don't want to collide with. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed May 7 13:16:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA13028 for smp-outgoing; Wed, 7 May 1997 13:16:22 -0700 (PDT) Received: from mpress.com (mpress.com [208.138.29.130]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA13023 for ; Wed, 7 May 1997 13:16:20 -0700 (PDT) Received: (qmail 8674 invoked by uid 100); 7 May 1997 20:16:18 -0000 Message-ID: <19970507131617.06188@mpress.com> Date: Wed, 7 May 1997 13:16:17 -0700 From: Brian Litzinger To: freebsd-smp@freebsd.org Subject: ed2: device timeout [final] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Well, I cvsup'ed, and "maked world"/rebuilt kernel again last night, and today the system is working correctly with the de0 ethernet card. -- Brian Litzinger brian@mediacity.com From owner-freebsd-smp Wed May 7 13:36:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA14192 for smp-outgoing; Wed, 7 May 1997 13:36:08 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA14186 for ; Wed, 7 May 1997 13:36:05 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id OAA05523; Wed, 7 May 1997 14:36:00 -0600 (MDT) Message-Id: <199705072036.OAA05523@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Brian Litzinger cc: freebsd-smp@FreeBSD.ORG Subject: Re: ed2: device timeout [final] In-reply-to: Your message of "Wed, 07 May 1997 13:16:17 PDT." <19970507131617.06188@mpress.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 May 1997 14:36:00 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, I suspect that ed2 would still fail. You probably have already received Peter's patch for this. (sent about 15 minutes ago...) -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed May 7 14:13:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA18056 for smp-outgoing; Wed, 7 May 1997 14:13:08 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA18051 for ; Wed, 7 May 1997 14:13:04 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id PAA05775 for ; Wed, 7 May 1997 15:13:03 -0600 (MDT) Message-Id: <199705072113.PAA05775@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: freebsd-smp@FreeBSD.ORG Subject: Headsup: SMP_AUTOSTART In-reply-to: Your message of "Wed, 07 May 1997 13:26:09 EDT." <199705071726.NAA05360@jenolan.caipgeneral> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 May 1997 15:13:02 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, SMP_AUTOSTART is now working and a valid option for your SMP kernel config file. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed May 7 14:32:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA19063 for smp-outgoing; Wed, 7 May 1997 14:32:13 -0700 (PDT) Received: from cs.utah.edu (cs.utah.edu [128.110.4.21]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA19058 for ; Wed, 7 May 1997 14:32:10 -0700 (PDT) Received: from fast.cs.utah.edu by cs.utah.edu (8.8.4/utah-2.21-cs) id PAA09453; Wed, 7 May 1997 15:22:53 -0600 (MDT) Received: by fast.cs.utah.edu (8.6.10/utah-2.15-leaf) id PAA15650; Wed, 7 May 1997 15:22:42 -0600 Date: Wed, 7 May 1997 15:22:42 -0600 From: vanmaren@fast.cs.utah.edu (Kevin Van Maren) Message-Id: <199705072122.PAA15650@fast.cs.utah.edu> To: freebsd-smp@FreeBSD.ORG, smp@csn.net Subject: Re: Headsup: SMP_AUTOSTART Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >SMP_AUTOSTART is now working and a valid option for your SMP kernel config >file. Great! Has it been tested with more than two processors (ie, used to start multiple application processors)? Kevin From owner-freebsd-smp Wed May 7 14:35:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA19148 for smp-outgoing; Wed, 7 May 1997 14:35:21 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA19143 for ; Wed, 7 May 1997 14:35:19 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id PAA05912; Wed, 7 May 1997 15:35:13 -0600 (MDT) Message-Id: <199705072135.PAA05912@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: vanmaren@fast.cs.utah.edu (Kevin Van Maren) cc: freebsd-smp@FreeBSD.ORG Subject: Re: Headsup: SMP_AUTOSTART In-reply-to: Your message of "Wed, 07 May 1997 15:22:42 MDT." <199705072122.PAA15650@fast.cs.utah.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 May 1997 15:35:13 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > >SMP_AUTOSTART is now working and a valid option for your SMP kernel config > >file. > > Great! Has it been tested with more than two processors (ie, used > to start multiple application processors)? no it hasn't, thats a good point. The code is written to support multiple APs, but till its tested... quad users please report. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed May 7 14:50:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA19773 for smp-outgoing; Wed, 7 May 1997 14:50:13 -0700 (PDT) Received: from cypher.net (black@zen.pratt.edu [205.232.115.155]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA19766 for ; Wed, 7 May 1997 14:50:10 -0700 (PDT) Received: (from black@localhost) by cypher.net (8.8.5/8.7.1) id RAA04654; Wed, 7 May 1997 17:11:15 -0400 Date: Wed, 7 May 1997 17:11:15 -0400 (EDT) From: Ben Black To: Kevin Van Maren cc: freebsd-smp@FreeBSD.ORG, smp@csn.net Subject: Re: Headsup: SMP_AUTOSTART In-Reply-To: <199705072122.PAA15650@fast.cs.utah.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk stop me if i'm wrong, but there is no such thing as an "application processor" in typical SMP and as far as i knew freebsd smp was pretty typical for early smp unix. b3n On Wed, 7 May 1997, Kevin Van Maren wrote: > >SMP_AUTOSTART is now working and a valid option for your SMP kernel config > >file. > > Great! Has it been tested with more than two processors (ie, used > to start multiple application processors)? > > Kevin > From owner-freebsd-smp Wed May 7 14:56:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA20096 for smp-outgoing; Wed, 7 May 1997 14:56:45 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA20087 for ; Wed, 7 May 1997 14:56:41 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id PAA06000; Wed, 7 May 1997 15:56:25 -0600 (MDT) Message-Id: <199705072156.PAA06000@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Ben Black cc: Kevin Van Maren , freebsd-smp@FreeBSD.ORG Subject: Re: Headsup: SMP_AUTOSTART In-reply-to: Your message of "Wed, 07 May 1997 17:11:15 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 May 1997 15:56:25 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, In the Intel SMP spec they differentiate the processors as bootstrap processor (BSP) and application processors (APs). This is mostly semantics and doesn't imply any differences in CPU priority when running SMP. It is primarily for describing the bootstrap sequence and how its achieved. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Wed May 7 15:14:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA21056 for smp-outgoing; Wed, 7 May 1997 15:14:37 -0700 (PDT) Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id PAA21051 for ; Wed, 7 May 1997 15:14:35 -0700 (PDT) Received: from mailhost.ipsilon.com (localhost [127.0.0.1]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id PAA03731; Wed, 7 May 1997 15:05:31 -0700 Message-Id: <199705072205.PAA03731@mailhost.Ipsilon.COM> X-Mailer: exmh version 1.6.4 10/10/95 To: Ben Black cc: Kevin Van Maren , freebsd-smp@FreeBSD.ORG, smp@csn.net Subject: Re: Headsup: SMP_AUTOSTART In-reply-to: Your message of "Wed, 07 May 1997 17:11:15 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 May 1997 15:05:31 -0700 From: Peter Grehan Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >stop me if i'm wrong, but there is no such thing as an "application >processor" in typical SMP and as far as i knew freebsd smp was pretty >typical for early smp unix. This is just terminology from the Intel MP specification. For other Unix systems, 'application processor's are called secondary CPU's, or something similar (i.e. all others except the bootstrap, or primary, CPU). later, Peter. From owner-freebsd-smp Wed May 7 15:19:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA21222 for smp-outgoing; Wed, 7 May 1997 15:19:30 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id PAA21217 for ; Wed, 7 May 1997 15:19:28 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA23011; Wed, 7 May 1997 15:15:16 -0700 From: Terry Lambert Message-Id: <199705072215.PAA23011@phaeton.artisoft.com> Subject: Re: Headsup: SMP_AUTOSTART To: black@zen.cypher.net (Ben Black) Date: Wed, 7 May 1997 15:15:15 -0700 (MST) Cc: vanmaren@fast.cs.utah.edu, freebsd-smp@FreeBSD.ORG, smp@csn.net In-Reply-To: from "Ben Black" at May 7, 97 05:11:15 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > stop me if i'm wrong, but there is no such thing as an "application > processor" in typical SMP and as far as i knew freebsd smp was pretty > typical for early smp unix. Read the Intel specification. There are AP's and there is the BP. The BP runs the bootstrap code before the AP's are started. The bootstrap code is non-SMP-capable ROM BIOS code. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Thu May 8 04:15:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA21397 for smp-outgoing; Thu, 8 May 1997 04:15:50 -0700 (PDT) Received: from bagpuss.visint.co.uk (bagpuss.vis.net.uk [194.207.134.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA21390 for ; Thu, 8 May 1997 04:15:47 -0700 (PDT) Received: from bagpuss.visint.co.uk (bagpuss.vis.net.uk [194.207.134.1]) by bagpuss.visint.co.uk (8.7.5/8.7.3) with SMTP id MAA22377; Thu, 8 May 1997 12:26:22 +0100 (BST) Date: Thu, 8 May 1997 12:26:22 +0100 (BST) From: Stephen Roome To: Steve Passe cc: Terry Lambert , freebsd-smp@FreeBSD.ORG Subject: Re: Where to start SMP? In-Reply-To: <199705071805.MAA04770@Ilsa.StevesCafe.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 Wed, 7 May 1997, Steve Passe wrote: > Hi, > > > I don't profess to know which is faster/better I just wouldn't want to see > > SMP get bastardised into some weird runtime option you can turn on and off > > really easily. I don't think that's going to be a performance boost ? > > Nor do I. I don't see one kernel binary ever being able to support both UP > and SMP (unless the UP version takes the performance hit). Its a struggle > just to do it with the same sources! If multiprocessor machines take off in a big way (in the small computer market anyway) then it wouldn't matter. It's a marketing decision for you then. I'd be interested to see what the actual performance hit would be, if designed well it might not be so bad for UP, and it would perhaps get more people in on the MP source. Whether that's good or bad isn't for me to decide though. I'm totally undecided on this now, last week I'd have said they should both be completely separate, well that's cleared it up for me. I'm just plain confused/uninformed/uneducated ! > I do see most of the 'minor' SMP options being made runtime, but only within > the context of an SMP only kernel. Well, as a user at least this would make things much easier. -- Steve Roome B.S.C Important Job, Important Sounding Company (B.S.C stands for Bronze Swimming Certificate) From owner-freebsd-smp Thu May 8 05:54:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA25092 for smp-outgoing; Thu, 8 May 1997 05:54:21 -0700 (PDT) Received: from bagpuss.visint.co.uk (bagpuss.vis.net.uk [194.207.134.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA25087 for ; Thu, 8 May 1997 05:54:18 -0700 (PDT) Received: from bagpuss.visint.co.uk (bagpuss.vis.net.uk [194.207.134.1]) by bagpuss.visint.co.uk (8.7.5/8.7.3) with SMTP id OAA23623; Thu, 8 May 1997 14:04:58 +0100 (BST) Date: Thu, 8 May 1997 14:04:57 +0100 (BST) From: Stephen Roome To: Terry Lambert cc: freebsd-smp@FreeBSD.ORG Subject: Re: Where to start SMP? In-Reply-To: <199705071844.LAA21853@phaeton.artisoft.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 Wed, 7 May 1997, Terry Lambert wrote: [BIG snip] > Stephen Roome wrote: > > Of course, I would think that SMP support should remain as a compile time > > option rather than run-time. Unless UP is as a poor-mans SMP, but that > > would slow the system on a UP arch. SMP isn't much different from UP from > > the user point of view (in fact how many -users- know/care how many > > processors they have). It's only in the installation that problems occur, > > so the handholding as far as SMP goes will always be a problem until UP > > becomes just a 1 processor SMP solution. > > There is little architectural difference between supporting SMP and > supporting general kernel preemption necessary for kernel multithreading > or Real Time scheduling in the UP case. The difference is in mutexes vs. > semaphores, for most things, so that the synchronization occurs across > processor memory domains instead of in a single memory domain. > > The UnixWare 2.x kernel's UFS performed 160% of UnixWare 1.x's UFS > on the same UP hardware because of concurrency wins that came with > SMP-ising the kernel, even without the lock strategy switching. > So do I think UP will be better off with an SMP kernel? Yes, if it's > done correctly. Well, this was my point, the question then is, are there people out there smart enough to actually write the bits of necessary evil self-modyfying code to get something like this done so that UP and SMP are the same kernel with run time options. Without it actually taking 100 times longer and not actually being a 100* improvement. I doubt it, especially after your next para. Personally, I think that it would be an amazing claim to have a GENERIC kernel that could run on both UP and SMP, and utilise each hardware. > Now as to UP vs. SMP locking: that's an isolated enough issue that > David Miller's point about self-modifying code is a good point. But > it would mean isolating all code up to the point of the SMP startup > in such a way as to either not encounter locking primitivs, or, more > likely, not encounter the hot-patch code in the boot phase, defaulting > to one or the other, and then replacing the function pointer at the > call address with the hot patch function. A lot of voodoo. A lot of headaches. It'd be great fun debugging! -- Steve Roome Technical Systems Manager, Vision Interactive Ltd. E: steve@visint.co.uk M: +44 (0) 976 241 342 T: +44 (0) 117 973 0597 F: +44 (0) 117 923 8522 From owner-freebsd-smp Thu May 8 06:26:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA26435 for smp-outgoing; Thu, 8 May 1997 06:26:10 -0700 (PDT) Received: from spinner.DIALix.COM (spinner.dialix.com [192.203.228.67]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA26427 for ; Thu, 8 May 1997 06:25:56 -0700 (PDT) Received: from spinner.DIALix.COM (localhost.dialix.com.au [127.0.0.1]) by spinner.DIALix.COM with ESMTP id VAA06214; Thu, 8 May 1997 21:23:39 +0800 (WST) Message-Id: <199705081323.VAA06214@spinner.DIALix.COM> To: Stephen Roome cc: Terry Lambert , freebsd-smp@FreeBSD.ORG Subject: Re: Where to start SMP? In-reply-to: Your message of "Thu, 08 May 1997 14:04:57 +0100." Date: Thu, 08 May 1997 21:23:38 +0800 From: Peter Wemm Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Stephen Roome wrote: [..] > Well, this was my point, the question then is, are there people out there > smart enough to actually write the bits of necessary evil self-modyfying > code to get something like this done so that UP and SMP are the same > kernel with run time options. Without it actually taking 100 times longer > and not actually being a 100* improvement. I doubt it, especially after > your next para. > > Personally, I think that it would be an amazing claim to have a GENERIC > kernel that could run on both UP and SMP, and utilise each hardware. Just as a BTW, the early versions of the SMP work actually did run on both uniprocessor (no apic at all), and smp motherboards with either 0 or 1 cpu present. It's not out of the question. We're having a head scratch at the moment about how best to deal with lots of interrupt sources. One thing that I have in mind might not be too difficult to have an apic-aware kernel that *also* can support the 8259 without much (if any) interrupt/spl overhead - and allow up to about 220 interrupt sources in a system without having a 256 bit interrupt mask. The problem is when we have a device that has multiple interrupt sources and when one interrupt handler has to block the others. (I'm thinking of the soundblaster type devices that have multiple components on the same card). There is a low cost way of doing this too.... (Sorry, I know that's teasing..) Just because the current unfinished work is compile time configurable, it doesn't automatically mean that the final result will be to. It's just that there are more important things to fix at the moment. > > Now as to UP vs. SMP locking: that's an isolated enough issue that > > David Miller's point about self-modifying code is a good point. But > > it would mean isolating all code up to the point of the SMP startup > > in such a way as to either not encounter locking primitivs, or, more > > likely, not encounter the hot-patch code in the boot phase, defaulting > > to one or the other, and then replacing the function pointer at the > > call address with the hot patch function. A lot of voodoo. > > A lot of headaches. It'd be great fun debugging! You said it... This (like what DEC did for their 3.0 and above releases) would solve certain run-time problems, but certainly presents a significant challenge. There are other ways around the problem too without resorting to self modifying code if we're prepared to wear the cost of a simple_lock() call to something that just does a ret for the UP case. DEC probably had it easier than we would since it's a risc cpu with probably just one subroutine call instruction - the x86 family can call subroutines in several ways and having a handler track back and figure out what code sequence that gcc generated would be a nightmare. I suspect the cost of changing a call _simple_lock to a set of nop's would be bad too - I vaguely recall something about nop being used to synchronise all pipeline execution and being quite expensive (although perhaps I'm thinking of another cpu arch). > -- > Steve Roome > Technical Systems Manager, Vision Interactive Ltd. > E: steve@visint.co.uk M: +44 (0) 976 241 342 > T: +44 (0) 117 973 0597 F: +44 (0) 117 923 8522 Cheers, -Peter From owner-freebsd-smp Thu May 8 11:45:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA12837 for smp-outgoing; Thu, 8 May 1997 11:45:49 -0700 (PDT) Received: from uruk.org (root@ns.uruk.org [198.145.95.253]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA12829 for ; Thu, 8 May 1997 11:45:45 -0700 (PDT) Received: from uruk.org [127.0.0.1] (erich) by uruk.org with esmtp (Exim 0.53 #1) id E0wPXRv-00040s-00; Thu, 8 May 1997 10:57:51 -0700 To: Steve Passe cc: Ben Black , Kevin Van Maren , freebsd-smp@freebsd.org Subject: Re: Headsup: SMP_AUTOSTART In-reply-to: Your message of "Wed, 07 May 1997 15:56:25 MDT." <199705072156.PAA06000@Ilsa.StevesCafe.com> Date: Thu, 08 May 1997 10:57:50 -0700 From: Erich Boleyn Message-Id: Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve Passe wrote: > In the Intel SMP spec they differentiate the processors as > bootstrap processor (BSP) and application processors (APs). > > This is mostly semantics and doesn't imply any differences in CPU > priority when running SMP. It is primarily for describing the bootstrap > sequence and how its achieved. There are 2 differences: -- The BP can always run the BIOS, and the APs might only work with some parts of it (for example, many machines don't support booting from an arbitrary CPU socket). -- The BP might be connected to special hardware for PC compatibility which isn't connected to the APs at all. This is sometimes the case for systems which don't use "Virtual Wire" compatibility mode. The implication here is that DOS interrupts may not be able to be routed to APs unless the switch to "Symmetric Interrupt Mode" is done, and even then maybe not (if the APIC doesn't have all it's inputs connected to the appropriate PCI/EISA/ISA IRQs). -- Erich Stefan Boleyn \_ E-mail (preferred): Mad Genius wanna-be, CyberMuffin \__ (finger me for other stats) Web: http://www.uruk.org/~erich/ Motto: "I'll live forever or die trying" From owner-freebsd-smp Thu May 8 13:39:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA18317 for smp-outgoing; Thu, 8 May 1997 13:39:10 -0700 (PDT) Received: from mpress.com (mpress.com [208.138.29.130]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA18308 for ; Thu, 8 May 1997 13:39:06 -0700 (PDT) Received: (qmail 10730 invoked by uid 100); 8 May 1997 20:39:03 -0000 Message-ID: <19970508133903.59852@mpress.com> Date: Thu, 8 May 1997 13:39:03 -0700 From: Brian Litzinger To: freebsd-smp@freebsd.org, freebsd-current@freebsd.org Subject: Panic Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Tyan S1668 Dual PP150 in dual processor mode. with make world and kernel late 5/6/97 PDT. Fatal trap 12: page fault while in kernel mode cpunumber = 0 fault virtual address = 0x44 fault code = supervisor read, page not present instruction pointer = 0x8:0xf0111330 stack pointer = 0x10:0xf49bff30 frame pointer = 0x10:0xf49bff30 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 4 (update) interrupt mask = kernel: type 12 trap, code=0 Stopped at _lockstatus+0x8: cmpw $0,0x10(%edx) Copyright (c) 1992-1997 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-CURRENT #0: Thu May 8 02:38:55 GMT 1997 brian@research.mpress.com:/uss/src/sys-UP/compile/SMP FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011 cpu1 (AP): apic id: 0, version: 0x00040011 io0 (APIC): apic id: 2, version: 0x00170011 CPU: Pentium Pro (686-class CPU) Origin = "GenuineIntel" Id = 0x612 Stepping=2 Features=0xfbff,MTRR,PGE,MCA,CMOV> real memory = 67108864 (65536K bytes) avail memory = 63348736 (61864K bytes) bdevsw_add_generic: adding D_DISK flag for device 7 bdevsw_add_generic: adding D_DISK flag for device 16 bdevsw_add_generic: adding D_DISK flag for device 17 Probing for devices on PCI bus 0: chip0 rev 2 on pci0:0:0 chip1 rev 1 on pci0:7:0 chip2 rev 0 on pci0:7:1 de0 rev 35 int a irq 19 on pci0:11:0 Freeing (NOT implemented) redirected PCI irq 11. de0: 21040 [10Mb/s] pass 2.3 de0: address 00:c0:95:ec:22:ef de0: enabling 10baseT port ahc0 rev 3 int a irq 18 on pci0:12:0 Freeing (NOT implemented) redirected PCI irq 15. ahc0: aic7870 Wide Channel, SCSI Id=7, 16 SCBs scbus0 at ahc0 bus 0 sd0 at scbus0 target 0 lun 0 sd0: type 0 fixed SCSI 2 sd0: Direct-Access 4095MB (8388315 512 byte sectors) vga0 rev 0 on pci0:13:0 Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> ed0 not found at 0x280 ed1 not found at 0x300 sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A sio2: disabled, not probed. lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface psm0: disabled, not probed. fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 72065B fd0: 1.44MB 3.5in wdc0 not found at 0x1f0 wdc1 not found at 0x170 aha0 not found at 0x330 aic0 not found at 0x340 wt0 not found at 0x300 mcd0 not found at 0x300 matcdc0 not found at 0x230 scd0 not found at 0x230 npx0 on motherboard npx0: INT 16 interface apm0: disabled, not probed. changing root device to sd0a Enabled INTs: 1, 2, 3, 4, 6, 7, 8, 18, 19, imen: 0x00f3fe21 WARNING: / was not properly dismounted. SMP: All idle procs online. You can now activate SMP processing, use: sysctl -w kern.smp_active=2 SMP: Starting 1st AP! SMP: AP CPU #1 LAUNCHED!! Starting Scheduling... SMP: TADA! CPU #1 made it into the scheduler!. SMP: All 2 CPU's are online! -- Brian Litzinger brian@mediacity.com From owner-freebsd-smp Thu May 8 14:32:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA20893 for smp-outgoing; Thu, 8 May 1997 14:32:03 -0700 (PDT) Received: from lamb.sas.com (daemon@lamb.sas.com [192.35.83.8]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA20852 for ; Thu, 8 May 1997 14:32:00 -0700 (PDT) Received: from mozart by lamb.sas.com (5.65c/SAS/Gateway/01-23-95) id AA21146; Thu, 8 May 1997 17:31:58 -0400 Received: from iluvatar.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA24711; Thu, 8 May 1997 17:31:31 -0400 Received: by iluvatar.unx.sas.com (5.65c/SAS/Generic 9.01/3-26-93) id AA26049; Thu, 8 May 1997 17:31:30 -0400 From: "John W. DeBoskey" Message-Id: <199705082131.AA26049@iluvatar.unx.sas.com> Subject: Dell Optiplex GXPro Dual will not boot To: freebsd-smp@freebsd.org Date: Thu, 8 May 1997 17:31:30 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] 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 Hi, The GENERIC kernel builds and boots just fine on this machine. An SMP kernel starts to boot, but comes to a standstill just after printing out the following msg: BIOS basemem(638K) != RTC basemem(640K), setting to BIOS value. ie: The copyright msgs never come out. I get the same result if I boot with -v also. ie: no additional output. If I remove the SMP option, the kernel builds & boots just fine. As soon as I can get the machine network connected I will send a copy of the mptable & dmesg output. If anyone has any ideas, please let me know. The code is from the 3.0-970502-SNAP. Thanks, John -- jwd@unx.sas.com (w) John W. De Boskey (919) 677-8000 x6915 From owner-freebsd-smp Thu May 8 15:59:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA24837 for smp-outgoing; Thu, 8 May 1997 15:59:06 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA24829 for ; Thu, 8 May 1997 15:59:03 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id QAA10996; Thu, 8 May 1997 16:58:52 -0600 (MDT) Message-Id: <199705082258.QAA10996@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: "John W. DeBoskey" cc: freebsd-smp@FreeBSD.ORG Subject: Re: Dell Optiplex GXPro Dual will not boot In-reply-to: Your message of "Thu, 08 May 1997 17:31:30 EDT." <199705082131.AA26049@iluvatar.unx.sas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 08 May 1997 16:58:52 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, this brand has worked in the past. it is dying just before attempting to boot the APs. I suspect the BIOS might not have some necessary seting. check for references to "APIC" and MP spec, making sure its 1.4 if availabel. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Thu May 8 16:16:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA25649 for smp-outgoing; Thu, 8 May 1997 16:16:58 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA25627; Thu, 8 May 1997 16:16:52 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id RAA11065; Thu, 8 May 1997 17:16:46 -0600 (MDT) Message-Id: <199705082316.RAA11065@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Brian Litzinger cc: freebsd-smp@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Panic In-reply-to: Your message of "Thu, 08 May 1997 13:39:03 PDT." <19970508133903.59852@mpress.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 08 May 1997 17:16:46 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, >Tyan S1668 Dual PP150 in dual processor mode. >with make world and kernel late 5/6/97 PDT. > >Fatal trap 12: page fault while in kernel mode > ... ...get one problem fixed then somwething else breaks! I just cvsup'ed standard and started a make world, haven't done that in over a week. I have to go fix someones network, so I won't know the results till late tonite... Any idea what program caught the trap? had you been running long, or was it almost immediate? -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Thu May 8 19:26:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA04237 for smp-outgoing; Thu, 8 May 1997 19:26:30 -0700 (PDT) Received: from mpress.com (mpress.com [208.138.29.130]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id TAA04223 for ; Thu, 8 May 1997 19:26:27 -0700 (PDT) Received: (qmail 13841 invoked by uid 100); 9 May 1997 02:26:21 -0000 Message-ID: <19970508192621.06979@mpress.com> Date: Thu, 8 May 1997 19:26:21 -0700 From: Brian Litzinger To: Steve Passe Cc: freebsd-smp@FreeBSD.ORG, freebsd-current@FreeBSD.ORG Subject: Re: Panic References: <19970508133903.59852@mpress.com> <199705082316.RAA11065@Ilsa.StevesCafe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <199705082316.RAA11065@Ilsa.StevesCafe.com>; from Steve Passe on Thu, May 08, 1997 at 05:16:46PM -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On May 8, Steve Passe wrote: > Hi, > > >Tyan S1668 Dual PP150 in dual processor mode. > >with make world and kernel late 5/6/97 PDT. > > > >Fatal trap 12: page fault while in kernel mode > > ... > > ...get one problem fixed then somwething else breaks! > > I just cvsup'ed standard and started a make world, haven't done that in over > a week. I have to go fix someones network, so I won't know the results till > late tonite... > > Any idea what program caught the trap? had you been running long, or was it > almost immediate? I do not. The system had been running for about 12 hours when it happened. The system was just sitting idle. It did it in the middle of the night. brian From owner-freebsd-smp Fri May 9 01:11:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA19896 for smp-outgoing; Fri, 9 May 1997 01:11:06 -0700 (PDT) Received: from mx12.netvision.net.il (mx12.NetVision.net.il [194.90.1.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id BAA19884 for ; Fri, 9 May 1997 01:11:02 -0700 (PDT) Received: (qmail 6058 invoked from network); 9 May 1997 08:10:54 -0000 Received: from burka.netvision.net.il (gena@194.90.1.23) by mx12.netvision.net.il with SMTP; 9 May 1997 08:10:54 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19970508133903.59852@mpress.com> Date: Fri, 09 May 1997 11:09:05 +0300 (IDT) X-Face: #v>4HN>#D_"[olq9y`HqTYkLVB89Xy|3')Vs9v58JQ*u-xEJVKY`xa.}E?z0RkLI/P&;BJmi0#u=W0).-Y'J4(dw{"54NhSG|YYZG@[)(`e! >jN#L!~qI5fE-JHS+< Organization: NetVision Ltd. From: Gennady Sorokopud To: Brian Litzinger Subject: RE: Panic Cc: freebsd-current@FreeBSD.ORG, freebsd-smp@FreeBSD.ORG Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I'm getting those panics for already 2-3 weeks :-(. (i'm not using SMP). One was caused by lstat on file with very long file name, all others .. god knows. I just got one exactly like this 2 hours ago :-(. On 08-May-97 Brian Litzinger wrote: >Tyan S1668 Dual PP150 in dual processor mode. >with make world and kernel late 5/6/97 PDT. > >Fatal trap 12: page fault while in kernel mode >cpunumber = 0 >fault virtual address = 0x44 >fault code = supervisor read, page not present >instruction pointer = 0x8:0xf0111330 >stack pointer = 0x10:0xf49bff30 >frame pointer = 0x10:0xf49bff30 >code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32, gran 1 >processor eflags = interrupt enabled, resume, IOPL = 0 >current process = 4 (update) >interrupt mask = > >kernel: type 12 trap, code=0 >Stopped at _lockstatus+0x8: cmpw $0,0x10(%edx) > > >Copyright (c) 1992-1997 FreeBSD Inc. >Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. >FreeBSD 3.0-CURRENT #0: Thu May 8 02:38:55 GMT 1997 > brian@research.mpress.com:/uss/src/sys-UP/compile/SMP >FreeBSD/SMP: Multiprocessor motherboard > cpu0 (BSP): apic id: 1, version: 0x00040011 > cpu1 (AP): apic id: 0, version: 0x00040011 > io0 (APIC): apic id: 2, version: 0x00170011 >CPU: Pentium Pro (686-class CPU) > Origin = "GenuineIntel" Id = 0x612 Stepping=2 > >Features=0xfbff,MTRR,PGE,MCA,CMOV >> >real memory = 67108864 (65536K bytes) >avail memory = 63348736 (61864K bytes) >bdevsw_add_generic: adding D_DISK flag for device 7 >bdevsw_add_generic: adding D_DISK flag for device 16 >bdevsw_add_generic: adding D_DISK flag for device 17 >Probing for devices on PCI bus 0: >chip0 rev 2 on pci0:0:0 >chip1 rev 1 on pci0:7:0 >chip2 rev 0 on pci0:7:1 >de0 rev 35 int a irq 19 on pci0:11:0 >Freeing (NOT implemented) redirected PCI irq 11. >de0: 21040 [10Mb/s] pass 2.3 >de0: address 00:c0:95:ec:22:ef >de0: enabling 10baseT port >ahc0 rev 3 int a irq 18 on pci0:12:0 >Freeing (NOT implemented) redirected PCI irq 15. >ahc0: aic7870 Wide Channel, SCSI Id=7, 16 SCBs >scbus0 at ahc0 bus 0 >sd0 at scbus0 target 0 lun 0 >sd0: type 0 fixed SCSI 2 >sd0: Direct-Access 4095MB (8388315 512 byte sectors) >vga0 rev 0 on pci0:13:0 >Probing for devices on the ISA bus: >sc0 at 0x60-0x6f irq 1 on motherboard >sc0: VGA color <16 virtual consoles, flags=0x0> >ed0 not found at 0x280 >ed1 not found at 0x300 >sio0 at 0x3f8-0x3ff irq 4 on isa >sio0: type 16550A >sio1 at 0x2f8-0x2ff irq 3 on isa >sio1: type 16550A >sio2: disabled, not probed. >lpt0 at 0x378-0x37f irq 7 on isa >lpt0: Interrupt-driven port >lp0: TCP/IP capable interface >psm0: disabled, not probed. >fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa >fdc0: NEC 72065B >fd0: 1.44MB 3.5in >wdc0 not found at 0x1f0 >wdc1 not found at 0x170 >aha0 not found at 0x330 >aic0 not found at 0x340 >wt0 not found at 0x300 >mcd0 not found at 0x300 >matcdc0 not found at 0x230 >scd0 not found at 0x230 >npx0 on motherboard >npx0: INT 16 interface >apm0: disabled, not probed. >changing root device to sd0a >Enabled INTs: 1, 2, 3, 4, 6, 7, 8, 18, 19, imen: 0x00f3fe21 >WARNING: / was not properly dismounted. >SMP: All idle procs online. >You can now activate SMP processing, use: sysctl -w kern.smp_active=2 >SMP: Starting 1st AP! >SMP: AP CPU #1 LAUNCHED!! Starting Scheduling... >SMP: TADA! CPU #1 made it into the scheduler!. >SMP: All 2 CPU's are online! >-- >Brian Litzinger >brian@mediacity.com Best regards. -------- Gennady B. Sorokopud - System programmer at NetVision Israel. E-Mail: Gennady Sorokopud PGP public key is available by fingering gena@netvision.net.il This message was sent at 09-May-97 11:09:06 by XFMail From owner-freebsd-smp Fri May 9 06:24:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA01330 for smp-outgoing; Fri, 9 May 1997 06:24:58 -0700 (PDT) Received: from wgold.demon.co.uk (wgold.demon.co.uk [158.152.96.124]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id GAA01317 for ; Fri, 9 May 1997 06:24:48 -0700 (PDT) Received: from wgold.demon.co.uk by wgold.demon.co.uk (NTMail 3.02.10) with ESMTP id ja001413 for ; Tue, 6 May 1997 18:41:20 +0100 Message-ID: <336F6D40.547D@westongold.com> Date: Tue, 06 May 1997 18:41:20 +0100 From: James Mansion Organization: Westongold Ltd X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: smp@FreeBSD.ORG Subject: Re: maptable of SuperMicro P6DNH References: <199705061634.KAA07279@Ilsa.StevesCafe.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Info: Westongold Ltd: +44 1992 620025 www.westongold.com Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I would have thought that you'd need to make sure that the SMP enabled kernel is running by default for the 3.x-release which makes it a production reality, or there will be issues relating to just what the 'stable' FBSD is. Given that the 'cost' of having SMP code in place should be low (and could be optimised further for the special case where the number of active CPUs is 1) is there a reason not to complete the integration to the point where there is no ifdef difference between SMP and UP source code? Is it just 'not done yet'? James Steve Passe wrote: > > Hi, > > >FreeBSD/SMP: Multiprocessor motherboard > > cpu0 (BSP): apic id: 0, version: 0x00040011 > > io0 (APIC): apic id: 2, version: 0x00170011 > >CPU: Pentium Pro (686-class CPU) > > you appear to only have 1 CPU on this board, is that correct? > if so I'm surprised it can run an SMP kernel at all! we have given zip > thought to such a thing... > -- > Steve Passe | powered by > smp@csn.net | Symmetric MultiProcessor FreeBSD -- Westongold Ltd C++/Java Multithread development and libraries +44 1920 444284 info@westongold.com From owner-freebsd-smp Fri May 9 07:36:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA06851 for smp-outgoing; Fri, 9 May 1997 07:36:56 -0700 (PDT) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA06792 for ; Fri, 9 May 1997 07:36:05 -0700 (PDT) Received: from arts.ratp.fr (arts.ratp.fr [193.106.40.1]) by shiva.jussieu.fr (8.8.5/jtpda-5.2) with ESMTP id QAA24969 for ; Fri, 9 May 1997 16:35:53 +0200 (METDST) Received: by arts.ratp.fr id QAA04516 for ; Fri, 9 May 1997 16:00:53 +0200 (DST) Received: from minos.noisy.ratp by arts.ratp.fr with SMTP id SAA004502 for ; Fri May 9 16:00:37 1997 Received: from fugue.noisy.ratp by minos.noisy.ratp with ESMTP id QAA14359 for ; Fri, 9 May 1997 16:00:35 +0200 (DST) Received: by fugue.noisy.ratp id QAA00307 ; Fri, 9 May 1997 16:00:18 +0200 (DST) From: Janick.Taillandier@ratp.fr (Janick Taillandier) Message-ID: <19970509160017.17618@fugue.noisy.ratp> Date: Fri, 9 May 1997 16:00:17 +0200 To: freebsd-smp@freebsd.org Subject: Re: Dell Optiplex GXPro Dual will not boot References: <199705082131.AA26049@iluvatar.unx.sas.com> <199705082258.QAA10996@Ilsa.StevesCafe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69e In-Reply-To: <199705082258.QAA10996@Ilsa.StevesCafe.com>; from Steve Passe on Thu, May 08, 1997 at 04:58:52PM -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, May 08, 1997 at 04:58:52PM -0600, Steve Passe wrote: > Hi, > > > this brand has worked in the past. it is dying just before attempting to boot > the APs. I suspect the BIOS might not have some necessary seting. check for > references to "APIC" and MP spec, making sure its 1.4 if availabel. > I am using an Optiplex GXPro with 2 P6 and have no problem to boot and run the SMP kernel. I didn't had time so far to upgrade to -current and I am still running the SMP kernel before Lite2 integration with user code from 961014 SNAP ! Janick Taillandier From owner-freebsd-smp Fri May 9 16:25:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA05431 for smp-outgoing; Fri, 9 May 1997 16:25:22 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA05426 for ; Fri, 9 May 1997 16:25:15 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.5/8.8.5) with ESMTP id RAA15100; Fri, 9 May 1997 17:25:00 -0600 (MDT) Message-Id: <199705092325.RAA15100@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: James Mansion cc: smp@FreeBSD.ORG Subject: Re: maptable of SuperMicro P6DNH In-reply-to: Your message of "Tue, 06 May 1997 18:41:20 BST." <336F6D40.547D@westongold.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 09 May 1997 17:25:00 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > Given that the 'cost' of having SMP code in place should be low (and > could be optimised further for the special case where the number of > active CPUs is 1) is there a reason not to complete the integration to > the point where there is no ifdef difference between SMP and UP source > code? I don't see it happening. There are major differences in the hardware on an SMP motherboard and a UP motherboard. The software differences are much more than just locking. A completely different INTerrupt sub-system is in order. Different scheduling strategies will be in place. The list goes on... Even if you could engineer it so that there was less than 5% cost at runtime, why should a UP user have to pay that cost. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-smp Fri May 9 17:47:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA08769 for smp-outgoing; Fri, 9 May 1997 17:47:56 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id RAA08756 for ; Fri, 9 May 1997 17:47:52 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA01343; Fri, 9 May 1997 17:43:20 -0700 From: Terry Lambert Message-Id: <199705100043.RAA01343@phaeton.artisoft.com> Subject: Re: maptable of SuperMicro P6DNH To: smp@csn.net (Steve Passe) Date: Fri, 9 May 1997 17:43:19 -0700 (MST) Cc: james@westongold.com, smp@FreeBSD.ORG In-Reply-To: <199705092325.RAA15100@Ilsa.StevesCafe.com> from "Steve Passe" at May 9, 97 05:25:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I don't see it happening. There are major differences in the hardware on > an SMP motherboard and a UP motherboard. The software differences are much > more than just locking. A completely different INTerrupt sub-system is in > order. Different scheduling strategies will be in place. The list goes on... > Even if you could engineer it so that there was less than 5% cost at runtime, > why should a UP user have to pay that cost. To encourage better (APIC-using) UP boards? Seriously, the MP boards are typically *better* than the UP boards because they have more hurdles. The UP boards *should* jump the same hurdles -- it would make for faster UP boards, for one thing, and faster generic OS code, for another. I'm surprised there isn't a push for this from MS on the basis of NT... heck, maybe there is? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Fri May 9 18:12:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA09676 for smp-outgoing; Fri, 9 May 1997 18:12:13 -0700 (PDT) Received: from cais.cais.com (root@cais.com [199.0.216.4]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA09665 for ; Fri, 9 May 1997 18:12:07 -0700 (PDT) Received: from earth.mat.net (root@earth.mat.net [205.252.122.1]) by cais.cais.com (8.8.5/8.7.3) with SMTP id VAA20660; Fri, 9 May 1997 21:12:03 -0400 (EDT) Received: from Journey2.mat.net (journey2.mat.net [205.252.122.116]) by earth.mat.net (8.6.12/8.6.12) with SMTP id VAA16454; Fri, 9 May 1997 21:12:01 -0400 Date: Fri, 9 May 1997 21:11:14 -0400 (EDT) From: Chuck Robey To: Terry Lambert cc: Steve Passe , james@westongold.com, smp@FreeBSD.ORG Subject: Re: maptable of SuperMicro P6DNH In-Reply-To: <199705100043.RAA01343@phaeton.artisoft.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 Fri, 9 May 1997, Terry Lambert wrote: > > I don't see it happening. There are major differences in the hardware on > > an SMP motherboard and a UP motherboard. The software differences are much > > more than just locking. A completely different INTerrupt sub-system is in > > order. Different scheduling strategies will be in place. The list goes on... > > Even if you could engineer it so that there was less than 5% cost at runtime, > > why should a UP user have to pay that cost. > > To encourage better (APIC-using) UP boards? > > Seriously, the MP boards are typically *better* than the UP boards > because they have more hurdles. The UP boards *should* jump the same > hurdles -- it would make for faster UP boards, for one thing, and > faster generic OS code, for another. I'm surprised there isn't a > push for this from MS on the basis of NT... heck, maybe there is? I don't know for sure, but I right now suspect FreeBSD is considerably ahead of MS in terms of stability on MP. I had to have a MS Windows environment this last semester, for an OS project I had to do. I tried installing NT on my SMP platform, which runs FreeBSD-SMP just ducky. Results were not good, it kept on panicing on install. I'm not a MS genius, and I had a friend who let me use her platform, so I let it go (I didn't want to run NT all that badly anyhow), but I am left with the feeling that maybe our SMP is more stable than their SMP. Of course, that's not really a surprise, is it? > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > > ----------------------------+----------------------------------------------- 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 picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-smp Fri May 9 23:02:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA21431 for smp-outgoing; Fri, 9 May 1997 23:02:52 -0700 (PDT) Received: from mx.serv.net (mx.serv.net [199.201.191.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA21426 for ; Fri, 9 May 1997 23:02:49 -0700 (PDT) Received: from MindBender.serv.net by mx.serv.net (8.7.5/SERV Revision: 2.30) id XAA13818; Fri, 9 May 1997 23:02:48 -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 XAA15693; Fri, 9 May 1997 23:00:43 -0700 (PDT) Message-Id: <199705100600.XAA15693@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: Host michaelv@localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: Chuck Robey cc: Terry Lambert , Steve Passe , james@westongold.com, smp@freebsd.org Subject: Re: maptable of SuperMicro P6DNH In-reply-to: Your message of Fri, 09 May 97 21:11:14 -0400. Date: Fri, 09 May 1997 23:00:10 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> > I don't see it happening. There are major differences in the hardware on >> > an SMP motherboard and a UP motherboard. The software differences are much >> > more than just locking. A completely different INTerrupt sub-system is in [...] >> Seriously, the MP boards are typically *better* than the UP boards >> because they have more hurdles. The UP boards *should* jump the same >> hurdles -- it would make for faster UP boards, for one thing, and >> faster generic OS code, for another. I'm surprised there isn't a >> push for this from MS on the basis of NT... heck, maybe there is? And it would make the hardware more expensive. And people wouldn't buy it. Then you would have SCSI and IDE in motherboard designs. >I don't know for sure, but I right now suspect FreeBSD is considerably >ahead of MS in terms of stability on MP. I had to have a MS Windows >environment this last semester, for an OS project I had to do. I tried >installing NT on my SMP platform, which runs FreeBSD-SMP just ducky. >Results were not good, it kept on panicing on install. Uh, I don't think so, Tim. I suspect you had a motherboard that simply wasn't supported. NT was designed from the very first byte of code to support SMP. NT's SMP is considerably finer-grained, more stable and mature than FreeBSD's. (Not to knock FreeBSD -- the SMP guys are doing good work, but... it has a ways to go.) I suspect you simply had a motherboard that wasn't supported. Microsoft releases a HAL (Hardware Abstraction Layer) that works for motherboards that support it, which is the big mainstream guys. Probably the stuff that is _strictly_ adherent to the Intel MP specs (though have no inside knowledge of the criteria). If a vendor has hardware that doesn't support the generic SMP HAL, they have to provide their own (which many vendors have done). Windows NT isn't Windows 95. Nobody gets upset if Windows 95 crashes every now and then. Believe me, _any_ crash and the NT guys are all over it. They take stability serious as a heart attack (to abuse a tired old cliche). I had them trying to get me to reproduce a crashing condition on my machine at home, so they could get a crash dump to analyze. I couldn't reproduce it. A friend of mine bought a SMP machine to run NT on. He couldn't get NT to boot on that either, without falling over shortly after booting. He had one of the top developers in the NT division at his house analyzing crash dumps. They concluded that the vendor had done something fishy in their motherboard, and were trying to work it out with them. I would suspect the many hundreds of multi-processor Intel and Alpha servers all over Microsoft, that simply run for many hundreds of days (similar to any large Unix shop) give testament to this fact. Please be serious. A multi-billion-dollar multi-national company, with some of the brightest software engineers in the industry is betting its future on NT. You think FreeBSD's SMP is better? I'm not trying to knock FreeBSD -- obviously I've been a raving BSD advocate for years. And I've been intending to pick up a used MP machine or motherboard for some time, just so I can play with FreeBSD SMP on it. And obviously there are many things about NT that are not popular in this forum. However, sometimes we all need to step back, and take a reality check, before diving into our passion. Hey, hate Microsoft all you want. Just realize that your hatred doesn't automatically mean that Microsoft is full of incompetent idiots. When they want to right good software, they have written some very very good software. ----------------------------------------------------------------------------- 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 Sat May 10 08:06:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA07539 for smp-outgoing; Sat, 10 May 1997 08:06:20 -0700 (PDT) Received: from ady.warp.starnets.ro (ady.warp.starnets.ro [193.226.124.33]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA07528 for ; Sat, 10 May 1997 08:05:38 -0700 (PDT) Received: from localhost (ady@localhost) by ady.warp.starnets.ro (8.8.5/8.8.5) with SMTP id RAA02879; Sat, 10 May 1997 17:58:47 +0300 (EEST) Date: Sat, 10 May 1997 17:58:47 +0300 (EEST) From: Penisoara Adrian Reply-To: Penisoara Adrian To: "Michael L. VanLoon -- HeadCandy.com" cc: Chuck Robey , Terry Lambert , Steve Passe , james@westongold.com, smp@FreeBSD.ORG Subject: Re: maptable of SuperMicro P6DNH In-Reply-To: <199705100600.XAA15693@MindBender.serv.net> 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 Fri, 9 May 1997, Michael L. VanLoon -- HeadCandy.com wrote: > [big snap] > >I don't know for sure, but I right now suspect FreeBSD is considerably > >ahead of MS in terms of stability on MP. I had to have a MS Windows > >environment this last semester, for an OS project I had to do. I tried > >installing NT on my SMP platform, which runs FreeBSD-SMP just ducky. > >Results were not good, it kept on panicing on install. > > Uh, I don't think so, Tim. Neither do I, it's my opinion. > I suspect you had a motherboard that simply wasn't supported. NT was > designed from the very first byte of code to support SMP. NT's SMP is > considerably finer-grained, more stable and mature than FreeBSD's. > (Not to knock FreeBSD -- the SMP guys are doing good work, but... it > has a ways to go.) > > I suspect you simply had a motherboard that wasn't supported. > Microsoft releases a HAL (Hardware Abstraction Layer) that works for > motherboards that support it, which is the big mainstream guys. > Probably the stuff that is _strictly_ adherent to the Intel MP specs > (though have no inside knowledge of the criteria). If a vendor has > hardware that doesn't support the generic SMP HAL, they have to > provide their own (which many vendors have done). > > Windows NT isn't Windows 95. Nobody gets upset if Windows 95 crashes > every now and then. Believe me, _any_ crash and the NT guys are all > over it. They take stability serious as a heart attack (to abuse a > tired old cliche). > > I had them trying to get me to reproduce a crashing condition on my > machine at home, so they could get a crash dump to analyze. I > couldn't reproduce it. A friend of mine bought a SMP > machine to run NT on. He couldn't get NT to boot on that either, > without falling over shortly after booting. He had one of the top > developers in the NT division at his house analyzing crash dumps. > They concluded that the vendor had done something fishy in their > motherboard, and were trying to work it out with them. > > I would suspect the many hundreds of multi-processor Intel and Alpha > servers all over Microsoft, that simply run for many hundreds of days > (similar to any large Unix shop) give testament to this fact. As we were speaking in stability terms, let me tell you something: Just yesterday my SMP machine (has still pre-Lite2 code) crashed not because of the SMP part but rather because of the SCSI subsystem (some trouble with SCBs while intensive I/O); but before that it runned perfectly smooth for over 12 days. The point is that the guys working on FreeBSD are really set for an solid UNIX OS but they do this for fun and not for money. Also it's well worth mentioning that Microsoft has always carefully chosen their engineers... Despite Microsoft's marketing style (IMHO it's way too commercial) I think we should respect their specialists. > > Please be serious. A multi-billion-dollar multi-national company, > with some of the brightest software engineers in the industry is > betting its future on NT. You think FreeBSD's SMP is better? Hmm, it could be, I think there are some bright brains around FreeBSD, but right now we can't say that (not yet :). > > I'm not trying to knock FreeBSD -- obviously I've been a raving BSD > advocate for years. And I've been intending to pick up a used MP > machine or motherboard for some time, just so I can play with FreeBSD > SMP on it. And obviously there are many things about NT that are not > popular in this forum. However, sometimes we all need to step back, > and take a reality check, before diving into our passion. > > Hey, hate Microsoft all you want. Just realize that your hatred > doesn't automatically mean that Microsoft is full of incompetent > idiots. When they want to right good software, they have written some > very very good software. They do write good software, the FreeBSD team does a good job but then again they have their own bugs (just think about IExplorer 3.0), FreeBSD has enough weak points... It's a never ending story. > > ----------------------------------------------------------------------------- > 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 Sat May 10 09:03:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA09315 for smp-outgoing; Sat, 10 May 1997 09:03:24 -0700 (PDT) Received: from tradeserv.com.tw (cjluh@[203.67.177.34]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA09310 for ; Sat, 10 May 1997 09:03:17 -0700 (PDT) Received: (from cjluh@localhost) by tradeserv.com.tw (8.8.5/8.8.5) id AAA22833 for freebsd-smp@freebsd.org; Sun, 11 May 1997 00:03:07 +0800 From: Cheng-Jye Luh Message-Id: <199705101603.AAA22833@tradeserv.com.tw> Subject: subscribe To: freebsd-smp@freebsd.org Date: Sun, 11 May 1997 00:03:07 +0800 (CST) X-Mailer: ELM [version 2.4 PL25] 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 subscribe From owner-freebsd-smp Sat May 10 12:15:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA17135 for smp-outgoing; Sat, 10 May 1997 12:15:12 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA17124 for ; Sat, 10 May 1997 12:15:06 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA04249; Sat, 10 May 1997 12:07:37 -0700 From: Terry Lambert Message-Id: <199705101907.MAA04249@phaeton.artisoft.com> Subject: Re: maptable of SuperMicro P6DNH To: michaelv@MindBender.serv.net (Michael L. VanLoon -- HeadCandy.com) Date: Sat, 10 May 1997 12:07:37 -0700 (MST) Cc: chuckr@mat.net, terry@lambert.org, smp@csn.net, james@westongold.com, smp@freebsd.org In-Reply-To: <199705100600.XAA15693@MindBender.serv.net> from "Michael L. VanLoon -- HeadCandy.com" at May 9, 97 11:00:10 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> Seriously, the MP boards are typically *better* than the UP boards > >> because they have more hurdles. The UP boards *should* jump the same > >> hurdles -- it would make for faster UP boards, for one thing, and > >> faster generic OS code, for another. I'm surprised there isn't a > >> push for this from MS on the basis of NT... heck, maybe there is? > > And it would make the hardware more expensive. And people wouldn't > buy it. Then you would have SCSI and IDE in motherboard designs. And then they'd move it into the "board chipset" ASIC's. And then, since silicon real-estate is silicon real-estate, no matter if you encode shiity designs or good designs in the dopant, it will cost the same per square millimeter for bot good and bad hardware. And then people will buy the good hardware. And we will all live happily ever after. Why does everyone think "better" means "more silicon". If programmers thought you had to go bigger to get better, then we'd have... well, MS-NT and USL-SVR4. 8-). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Sat May 10 16:23:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA29776 for smp-outgoing; Sat, 10 May 1997 16:23:31 -0700 (PDT) Received: from mx.serv.net (mx.serv.net [199.201.191.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA29768 for ; Sat, 10 May 1997 16:23:27 -0700 (PDT) Received: from MERCURY by mx.serv.net (8.7.5/SERV Revision: 2.30) id QAA06026; Sat, 10 May 1997 16:20:35 -0700 (PDT) Received: by MERCURY with Microsoft Mail id <01BC5D5E.4C9AE5A0@MERCURY>; Sat, 10 May 1997 16:22:05 -0700 Message-ID: <01BC5D5E.4C9AE5A0@MERCURY> From: "Adam J. Bartels" To: "'Michael L. VanLoon -- HeadCandy.com'" , Chuck Robey Cc: Terry Lambert , Steve Passe , "james@westongold.com" , "smp@FreeBSD.ORG" Subject: RE: maptable of SuperMicro P6DNH Date: Sat, 10 May 1997 15:42:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id QAA29770 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Michael is right. My production workstation is dual boot with NT 4.0 Server and FREEBSD SMP, and is the BDC for our LAN. HW profile: GA-586 DX(Taiwanese Tomcat ripoff with 430HX chipset. Cheap and works great!) w/dual 166 "classic"(no MMX) Pentiums, 512 pipeline, 64MB EDO, Adaptec 7880(same chipset as 2940 but onboard) which supports SCSI II and UWSCSI, 2 Quantum Atlas 2.25 HDs, ESS soundcard and Phillips 8X SCSI CDROM. NT Server is rock stable and rocketship fast with my current hardware. I have yet to get FREEBSD to run as it should with SMP. My uni-processor 2.2.1 ran great. Part of this is due to my lack of experience with UNIX. I'm sure as I learn more and the SMP kernel is further refined some of my problems will go away. I'm no Microsoft Minion, but I can tell you NT Server 4.0 is for real, and is fully capable of controlling any small to medium sized enterprise. Present build scales to 16 processors and 5.0 will scale to 64 with 64 bit optimization. Near future developments such as "Wolfpack", a control package to chain together multiple NT Servers(yes, hundreds) for large enterprise networks will offer a viable alternative to any other enterprise OS. Adam J. Bartels Aegis Technology Systems adam@aegis1.com