From owner-freebsd-smp Sun Sep 22 02:52:15 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id CAA06299 for smp-outgoing; Sun, 22 Sep 1996 02:52:15 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id CAA06268 for ; Sun, 22 Sep 1996 02:52:11 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id CAA00353; Sun, 22 Sep 1996 02:51:56 -0700 From: Terry Lambert Message-Id: <199609220951.CAA00353@phaeton.artisoft.com> Subject: Re: multithreading in the kernel and applications. To: jmb@freefall.freebsd.org (Jonathan M. Bresler) Date: Sun, 22 Sep 1996 02:51:56 -0700 (MST) Cc: terry@lambert.org, bad@owl.WPI.EDU, freebsd-smp@FreeBSD.org In-Reply-To: <199609220252.TAA04067@freefall.freebsd.org> from "Jonathan M. Bresler" at Sep 21, 96 07:52:32 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 > > Mutexes is meant to refer to "mutual exclusion locks which function > > between processors". > > > > Semaphores is meant to refer to "mutual exclusion locks which do > > not use memory shared between CPU's for their implementation". > > > > If you lock with a semaphore, you don't lock out other CPU's from > > accessing the same object (ie: they may have stale cache data), > > but mutexes invoke a bus abritration cycle to make sure there are > > no stale caches on other processors. > > > > isnt that an implementation issue, whatever form of mutex is > used a data structure must be shared among the processors > and if cached must be either flushed or invalidated (hopefully > via a hardware protocol such as MESI) > > what method are you referring to that does not require > shared data? are there any papers available about it? or > am i misunderstanding you? A hierarchy with intention modes. IF you invoke a mutex without sharing which is an inferior node in a hierarchy of nodes, where some superior node is a mutext *with* sharing, THEN as long as the superior node has an intention mode established, the actual locking can be local to the inferior node. And thus local to a single processor and image of cache coherency... no additional bus arbitration need take place. In effect, you would establish a hierarchy of per-CPU "top level in the context of a single CPU" mutexes which could be used without forcing an update cycle. to the top level ("system wide") mutex. > > Yes. A processor can "enter" an execution context. If the execution > > contexts are arbitrated in the kernel via inter-CPU mutexes, then > > multipl CPU's can enter execution contexts in kernel space at the > > same time. > > i have not yet read the smp source in FreeBSD. what > granulaarity of laocking are we using? what structures > are currently protected? do both cpus have the same > "privilege" or "priority" ( i am missing the correct term > here) can both field interrupts for instance? Locking occurs at system call trap, interrupt handling, and as the result of processor/mmu exceptions. In other words, we are using the lowest possible locking granularity which can still be called SMP. User space is reeentrant, but the kernel is not. 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 Sun Sep 22 08:13:50 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA03247 for smp-outgoing; Sun, 22 Sep 1996 08:13:50 -0700 (PDT) Received: (from jmb@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA03219; Sun, 22 Sep 1996 08:13:48 -0700 (PDT) From: "Jonathan M. Bresler" Message-Id: <199609221513.IAA03219@freefall.freebsd.org> Subject: Re: multithreading in the kernel and applications. To: terry@lambert.org (Terry Lambert) Date: Sun, 22 Sep 1996 08:13:46 -0700 (PDT) Cc: terry@lambert.org, bad@owl.WPI.EDU, freebsd-smp@FreeBSD.org In-Reply-To: <199609220951.CAA00353@phaeton.artisoft.com> from "Terry Lambert" at Sep 22, 96 02:51:56 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert wrote: > A hierarchy with intention modes. "intention modes". uh oh, another term i have never heard before. what is an "intention mode" and how is one coded? > IF you invoke a mutex without sharing which is an inferior node in how can you have a "mutex without sharing"? if the data structure that supports the mutex is not accessible to all processors, how can it be used to acheive mutual exclusion? the mutual exclusion primatives that i know rely on a datum that has at least two states: locked and unlocked. each processor must read-modify-write the datum in order to obtain the lock. > a hierarchy of nodes, where some superior node is a mutext *with* > sharing, THEN as long as the superior node has an intention mode > established, the actual locking can be local to the inferior node. superior node: shared uncached (or consistency protocol allows sharing) contains structure (called intention mode), perhaps many of these, each indicates a different purpose for obtaining the lock in the superior node? counted semaphore or multireader lock????? inferior node: shared uncached (or consistency protocol allows sharing) binary semaphore SO, proc A can lock the superior node, set an "intention mode" to write some files "A's file". proc B comes along sees the superior node locked and bumps the lock count then sets a different "intention mode" which indicates it wants to write "B's file" (use inode addresses for vnode addresses or some unique thing as the "intention mode" data????? or even the address of the inferior node. yeah thats better) then you only have to obtain an exclusive lock on the inferior node??? > And thus local to a single processor and image of cache coherency... > no additional bus arbitration need take place. because coherency is enforced at the superior node?? since no one else is using my "intention mode"??? sounds interesting, but only for SOFTWARE MAINTAINED cache coherency or systems that allow you to set the hardare coherency protocol on a page by page basis. ala MIPS 4000, you set the superior node to uncached and the inferior to noncoherent?? but if this is what you are talking about, it doesnt apply to the intel processors does it? does intel support more than one consistency protocol? could be, but i thought that it only supported the MESI write-invalidate cache coherency protocol. > In effect, you would establish a hierarchy of per-CPU "top level in > the context of a single CPU" mutexes which could be used without > forcing an update cycle. to the top level ("system wide") mutex. you are talking software cache coherency, no? intel gives us hardware cache coherency. why do we want to incur the penalties of software cache coherency: user shared memory cant be cached (this breaks the programming paradigm which relies upon the operating system to serialize access to memory, files, etc--this is the essence of the problem with file i/o and mmap calls), spin locks can never be cached (so each processor has to hammer the bus while trying to obtain a spin lock, rather than just hammering its own cache), process data must be flushed when a process migrates from one processor to another (more bus transactions, rather than letting the other processor take the cache lines are needed). even if we can arrange to cache some of this list, we must flush that section of the cache before releasing the lock. given the processor speed that we are using and the bus speeds that we are limited to, memory and i/o bandwidth seems to be very scarce, something that we must husband, least the system spin like a whirling derivsh trying to obtain the required locks to perform some real work ;( terry, help me out here. i dont understand what you are saying. jmb From owner-freebsd-smp Sun Sep 22 15:47:23 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA26896 for smp-outgoing; Sun, 22 Sep 1996 15:47:23 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA26865 for ; Sun, 22 Sep 1996 15:47:16 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA01210; Sun, 22 Sep 1996 15:46:48 -0700 From: Terry Lambert Message-Id: <199609222246.PAA01210@phaeton.artisoft.com> Subject: Re: multithreading in the kernel and applications. To: jmb@freefall.freebsd.org (Jonathan M. Bresler) Date: Sun, 22 Sep 1996 15:46:47 -0700 (MST) Cc: terry@lambert.org, bad@owl.WPI.EDU, freebsd-smp@FreeBSD.org In-Reply-To: <199609221513.IAA03219@freefall.freebsd.org> from "Jonathan M. Bresler" at Sep 22, 96 08:13:46 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 > > A hierarchy with intention modes. > > "intention modes". uh oh, another term i have never heard before. > what is an "intention mode" and how is one coded? IR Intention to establish a read lock R A read lock IW Intention to establish a write lock W A write lock IX Intention to establish an exclusive lock X An exclusive lock Think of it as "madvise" for locking: I intend a read lock, then I read lock Etc. > > IF you invoke a mutex without sharing which is an inferior node in > > how can you have a "mutex without sharing"? if the data structure > that supports the mutex is not accessible to all processors, how > can it be used to acheive mutual exclusion? the mutual exclusion > primatives that i know rely on a datum that has at least two states: > locked and unlocked. each processor must read-modify-write the datum > in order to obtain the lock. Say I have the following lock hierarchy: Hierarchy root o IX <- shared (MESI/MEI required) / \ [ protects system wide memory pool ] / \ / \ / \ CPU1 o IX IX o CPU 2 <- CPU local (unshared) [ protects per CPU memory pools ] I can assert the CPU 2 X lock to access the CPU 2 local pool without asserting the system wide lock. (in the example above, the "root" actually would be an inferior node of the system wide lock that was the root of the hierarchy for all subsystems). Since both the CPU1 and CPU2 locks may simultaneously hold an intention to exclude, there is no need to update the shared lock to convert a per CPU lock (IX -> X, IR ->R, IW -> W). This is a six state lock system; there is more complex mapping which is possible (8 state [ IRW -> RW ], or 12 state [ IIX -> IX -> X ], or 16 state ...). > > a hierarchy of nodes, where some superior node is a mutext *with* > > sharing, THEN as long as the superior node has an intention mode > > established, the actual locking can be local to the inferior node. > > superior node: > shared > uncached (or consistency protocol allows sharing) > contains structure (called intention mode), perhaps > many of these, each indicates a different purpose > for obtaining the lock in the superior node? > counted semaphore or multireader lock????? > > inferior node: > shared > uncached (or consistency protocol allows sharing) > binary semaphore may also be a counting semaphore (for multiple reader) > > SO, proc A can lock the superior node, set an "intention mode" > to write some files "A's file". It is not a file locking mechanism. It is a context synchronization mechanism. But the principles apply. > proc B comes along sees the superior node locked > and bumps the lock count then sets a different > "intention mode" which indicates it wants to write > "B's file" (use inode addresses for vnode addresses or > some unique thing as the "intention mode" data????? > or even the address of the inferior node. yeah thats better) > then you only have to obtain an exclusive lock on the inferior node??? Yes. > > And thus local to a single processor and image of cache coherency... > > no additional bus arbitration need take place. > > because coherency is enforced at the superior node?? Because conflicts are commutitive or associative in nature, and only conflicts which are associative between CPU's need to have a conflict resoloution take place (bus arbitration plus synchornization of a shared obejct of some kind -- condition variable, semaphore, etc.). Most of the intention modes can be permanently established at system initialization time. > sounds interesting, but only for SOFTWARE MAINTAINED cache coherency > or systems that allow you to set the hardare coherency protocol on > a page by page basis. ala MIPS 4000, you set the superior node to > uncached and the inferior to noncoherent?? No, you don't need to associate the locking with hardware enforcement of the locking modes. You have propagation and inheritance on your side. You inherit association down and you propagate intention up. [ ... ] > > In effect, you would establish a hierarchy of per-CPU "top level in > > the context of a single CPU" mutexes which could be used without > > forcing an update cycle. to the top level ("system wide") mutex. > > you are talking software cache coherency, no? No, I'm talking about shared region cache coherency, and definiing what needs to be shared and what doesn't, and the protocol necessary for mving an object from one location in the hierarchy to another. See the memory pool example above. It is more interesting to talk about how you can avoid the need for sharing than it is to discuss how to make sharing more efficient. It solves the same problem, but at a different level. > given the processor speed that we are using and the bus > speeds that we are limited to, memory and i/o bandwidth > seems to be very scarce, something that we must husband, > least the system spin like a whirling derivsh trying to > obtain the required locks to perform some real work ;( Yes. Exactly. You wish to be able to access memory without invoking MEI/MESI synchronization phases. If you are operating in the L1 cache (where you will hopefully spend most of your time), then you only bang on memory bandwidth for objects which you have in common with other CPU's. You can't avoid the overhead of loading your L1 cache from memory or the L2 cache: the processor must have data on which to operate. But the overhead of traditional SMP implementations is primarily bus arbitration for inter-CPU synchronization, much of which is unnecessary. For instance, to get a page on SVR4, you must hit a global mutex and each processor must invalidate the cache data (or update it) for the shared memory region where the mutext lives, even if they don't have to suspend trying to hit the same mutex. It's *this* overhead that I want to avoid. Hopefully the picture makes things clearer. 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 Sun Sep 22 15:53:52 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA29178 for smp-outgoing; Sun, 22 Sep 1996 15:53:52 -0700 (PDT) Received: from po1.glue.umd.edu (po1.glue.umd.edu [129.2.128.44]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA29151 for ; Sun, 22 Sep 1996 15:53:47 -0700 (PDT) Received: from packet.eng.umd.edu (packet.eng.umd.edu [129.2.98.184]) by po1.glue.umd.edu (8.7.5/8.7.3) with ESMTP id SAA09064; Sun, 22 Sep 1996 18:53:42 -0400 (EDT) Received: from localhost (chuckr@localhost) by packet.eng.umd.edu (8.7.5/8.7.3) with SMTP id SAA31984; Sun, 22 Sep 1996 18:53:41 -0400 (EDT) X-Authentication-Warning: packet.eng.umd.edu: chuckr owned process doing -bs Date: Sun, 22 Sep 1996 18:53:41 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@packet.eng.umd.edu To: Steve Passe cc: freebsd-smp@freebsd.org, "Jordan K. Hubbard" Subject: Re: Web Page for SMP kernel In-Reply-To: <199609220126.TAA26075@clem.systemsix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 21 Sep 1996, Steve Passe wrote: > Hi, > > I started an SMP kernel web page to gather together info on the topic: > > http://www.freebsd.org/~fsmp/SMP/SMP.html > > It's still VERY green, at this point I am more interested in getting > useful info on it than making it "artistically polished". > Let's not advertise it outside the freebsd-smp list for a little while... > Send comments, and most importantly, send info for inclusion. > In particular, we need to flesh out the list of known working hardware. I use lynx most often, because my net connectivity isn't the best ... I have a couple of pages that I think ought to be referenced from your page. One is Tom's hardware page, for obvious reasons:
  • Tom's Hardware & Performance Guide The other one maybe qualifies as what you wanted : > In particular, we need to flesh out the list of known working hardware. How about this one:
  • SMP Motherboards I was all ready to go and buy the Tyan Titan Pro (and mortgage my future for it) when I read about the new Via chipset. Now I'm waiting for results from either Tom's Hardware page, or maybe Grimes will get it tested. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and n3lxx, both FreeBSD (301) 220-2114 | version 2.2 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-smp Mon Sep 23 12:21:11 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA29561 for smp-outgoing; Mon, 23 Sep 1996 12:21:11 -0700 (PDT) Received: from uhf.wdc.net (uhf.wdc.net [198.147.74.44]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA29467 for ; Mon, 23 Sep 1996 12:21:01 -0700 (PDT) Received: (from bad@localhost) by uhf.wdc.net (8.7.5/8.6.12) id OAA00400; Mon, 23 Sep 1996 14:20:27 -0400 (EDT) Date: Mon, 23 Sep 1996 14:20:26 -0400 (EDT) From: Bernie Doehner To: freebsd-smp@freebsd.org Subject: recommendations on inexpensive dual Pentium MB's. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Terry and others: Thanks for your comments. I have a lot to learn from you. One thing that I have definitely learned is that SMP FreeBSD is currently NOT a stable platform and I should probably stay away from it for the main server at my house. But, I am quite interested in learning more about SMP and parallel processing, so I'd like to get a dual Pentium capable motherboard, but run it in single CPU (non-SMP) mode till the SMP FreeBSD kernel becomes more mature and/or supports higher granularity. I have read the http://www.freebsd.org/~fsmp/SMP/SMP.html page, and saw several good candidate boards. Does anyone have any recommendations on distributors who carry these motherboards at reasonable prices? By reasonable I mean < $180. (For example: Computer Geeks carries the Micronics dual Pentium board for $150 but I want to stay away from it because noone seems to have tested it yet - it also doesn't run anything faster than 100 MHz. and I can't use my non-parity RAM with it). Thanks. Bernie bad@uhf.wdc.net From owner-freebsd-smp Mon Sep 23 14:29:43 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA13320 for smp-outgoing; Mon, 23 Sep 1996 14:29:43 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA13268 for ; Mon, 23 Sep 1996 14:29:39 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.6/CET-v2.1) with SMTP id VAA17415; Mon, 23 Sep 1996 21:29:24 GMT Date: Tue, 24 Sep 1996 06:29:23 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: Bernard Armin Doehner , freebsd-smp@freebsd.org Subject: Re: multithreading in the kernel and applications. In-Reply-To: <199609202207.PAA03109@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, 20 Sep 1996, Terry Lambert wrote: > For us, the ability to support multiple kernel contexts means that > it would be a good idea to let the kernel be per CPU reentrant to > get us the greatest possible concurrency. > Don't you mean parallelism instead of concurrency? Regards, Mike Hancock From owner-freebsd-smp Mon Sep 23 14:56:45 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA25956 for smp-outgoing; Mon, 23 Sep 1996 14:56:45 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA25914 for ; Mon, 23 Sep 1996 14:56:41 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA02880; Mon, 23 Sep 1996 14:55:49 -0700 From: Terry Lambert Message-Id: <199609232155.OAA02880@phaeton.artisoft.com> Subject: Re: multithreading in the kernel and applications. To: michaelh@cet.co.jp (Michael Hancock) Date: Mon, 23 Sep 1996 14:55:48 -0700 (MST) Cc: terry@lambert.org, bad@owl.WPI.EDU, freebsd-smp@freebsd.org In-Reply-To: from "Michael Hancock" at Sep 24, 96 06:29:23 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 > > For us, the ability to support multiple kernel contexts means that > > it would be a good idea to let the kernel be per CPU reentrant to > > get us the greatest possible concurrency. > > > > Don't you mean parallelism instead of concurrency? No. Parallelism does not cover interleaving I/O in a single thread (making that thread more concurrent). The thread that makes the requests would be inherently parallel already, since the task which it wishes to accomplish is capable of being parallelized. The degree to which it actually gets parallelized in practice is its concurrency. Consider a "team" program written using async I/O instead of using multiple processes (or threads). It can "read" as fast as it can queue the system calls, and it can "write" as fast as the buffer data from the reads becomes valid. The reads and writes occur concurrently, but only a single read and a single write (of different buffers) effectively occur in parallel. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Mon Sep 23 17:14:28 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA16866 for smp-outgoing; Mon, 23 Sep 1996 17:14:28 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA16820; Mon, 23 Sep 1996 17:14:21 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.6/CET-v2.1) with SMTP id AAA18152; Tue, 24 Sep 1996 00:14:15 GMT Date: Tue, 24 Sep 1996 09:14:14 +0900 (JST) From: Michael Hancock To: Terry Lambert cc: freebsd-smp@freebsd.org, FreeBSD Hackers Subject: Re: multithreading in the kernel and applications. In-Reply-To: <199609232155.OAA02880@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 [Cross-posted to hackers, I lost the relevant thread there.] On Mon, 23 Sep 1996, Terry Lambert wrote: > > > For us, the ability to support multiple kernel contexts means that > > > it would be a good idea to let the kernel be per CPU reentrant to > > > get us the greatest possible concurrency. > > > > > > > Don't you mean parallelism instead of concurrency? > > No. Parallelism does not cover interleaving I/O in a single thread > (making that thread more concurrent). The thread that makes the > requests would be inherently parallel already, since the task which > it wishes to accomplish is capable of being parallelized. The degree > to which it actually gets parallelized in practice is its concurrency. > > Consider a "team" program written using async I/O instead of using > multiple processes (or threads). It can "read" as fast as it can > queue the system calls, and it can "write" as fast as the buffer data > from the reads becomes valid. The reads and writes occur concurrently, > but only a single read and a single write (of different buffers) > effectively occur in parallel. Interesting, I read another message, that I've lost, where you were griping about UI threads starving for CPU. M LWP's (kernel threads), N user threads where N > M, N-M threads starve, etc. One view of concurrency in this model is the ability of a process to fill its quantum. i.e. a multi-threaded process with one LWP uses the user thread scheduler to schedule an available thread when the current thread blocks without having to make a context switch. I think your message was implying that that UI threads don't work as designed and are broken. Your model, Plan 9?, assumes a 1 to 1 mapping of kernel threads to user threads and the argument to the context switching overhead is to fix the context switching overhead so that performance isn't an issue. No? Regards, Mike Hancock From owner-freebsd-smp Mon Sep 23 17:59:14 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA05428 for smp-outgoing; Mon, 23 Sep 1996 17:59:14 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id RAA05395; Mon, 23 Sep 1996 17:59:09 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA03200; Mon, 23 Sep 1996 17:58:17 -0700 From: Terry Lambert Message-Id: <199609240058.RAA03200@phaeton.artisoft.com> Subject: Re: multithreading in the kernel and applications. To: michaelh@cet.co.jp (Michael Hancock) Date: Mon, 23 Sep 1996 17:58:17 -0700 (MST) Cc: terry@lambert.org, freebsd-smp@freebsd.org, Hackers@freebsd.org In-Reply-To: from "Michael Hancock" at Sep 24, 96 09:14:14 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 > > Consider a "team" program written using async I/O instead of using > > multiple processes (or threads). It can "read" as fast as it can > > queue the system calls, and it can "write" as fast as the buffer data > > from the reads becomes valid. The reads and writes occur concurrently, > > but only a single read and a single write (of different buffers) > > effectively occur in parallel. > > Interesting, I read another message, that I've lost, where you were > griping about UI threads starving for CPU. M LWP's (kernel threads), N > user threads where N > M, N-M threads starve, etc. Yes. This is my favorite "stump the USL threads guys" argument. 8-). > One view of concurrency in this model is the ability of a process to fill > its quantum. i.e. a multi-threaded process with one LWP uses the user > thread scheduler to schedule an available thread when the current thread > blocks without having to make a context switch. Yes. That's the one I advocate. You want to fill as much of your quantum as possible given the task you are mapping quantum into, not dependent upon the system call interface. > I think your message was implying that that UI threads don't work as > designed and are broken. More that kernel threads don't work as designed, and are broken. The POSIX threading is OK -- as far as it goes, since for some things it's concurrent. But given a choice, I'd pick user threads over kernel threads. > Your model, Plan 9?, assumes a 1 to 1 mapping of kernel threads to user > threads and the argument to the context switching overhead is to fix the > context switching overhead so that performance isn't an issue. No? Actually, I'd like to see the thread blocked at the system call interface; I guess, technically, this would be kernel threading because the thread scheduler would be in system space. But like the FreeBSD SMP as it currently stands, the reentrancy would not go below the trap code. So you'd convert a blocking call into a non-blocking call, the generation of a context record, and a context switch (which would be active on the call return to user space. The difference here is that system calls would *always* be non-blocking. This beats the PTHREADS stuff by a large number of potential blocking operations which can be converted instead of some trivial I/O operations and little else. I implemented a prototype in prerelease UnixWare 2.x; I'll probably get around to reimplementing it for FreeBSD some day soon. 8-|. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-smp Mon Sep 23 23:38:57 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA25260 for smp-outgoing; Mon, 23 Sep 1996 23:38:57 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA25236; Mon, 23 Sep 1996 23:38:54 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.7.6/8.7.3) with ESMTP id XAA00598; Mon, 23 Sep 1996 23:38:00 -0700 (PDT) Message-Id: <199609240638.XAA00598@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Michael Hancock cc: Terry Lambert , freebsd-smp@freebsd.org, FreeBSD Hackers Subject: Re: multithreading in the kernel and applications. In-reply-to: Your message of "Tue, 24 Sep 1996 09:14:14 +0900." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Sep 1996 23:37:59 -0700 From: Amancio Hasty Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >From The Desk Of Michael Hancock : > [Cross-posted to hackers, I lost the relevant thread there.] > > On Mon, 23 Sep 1996, Terry Lambert wrote: > > > > > For us, the ability to support multiple kernel contexts means that > > > > it would be a good idea to let the kernel be per CPU reentrant to > > > > get us the greatest possible concurrency. > > > > > > > > > > Don't you mean parallelism instead of concurrency? > > > > No. Parallelism does not cover interleaving I/O in a single thread > > (making that thread more concurrent). The thread that makes the > > requests would be inherently parallel already, since the task which > > it wishes to accomplish is capable of being parallelized. The degree > > to which it actually gets parallelized in practice is its concurrency. > > > > Consider a "team" program written using async I/O instead of using > > multiple processes (or threads). It can "read" as fast as it can > > queue the system calls, and it can "write" as fast as the buffer data > > from the reads becomes valid. The reads and writes occur concurrently, > > but only a single read and a single write (of different buffers) > > effectively occur in parallel. Yes, I can imgine such programs as "team" or an osi file server which I work on 10 years ago for VMS . A single file server was able to serve up multiple connections with no problems . Regards, Amancio From owner-freebsd-smp Tue Sep 24 14:23:21 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA03466 for smp-outgoing; Tue, 24 Sep 1996 14:23:21 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA03414 for ; Tue, 24 Sep 1996 14:23:06 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA04679; Tue, 24 Sep 1996 14:19:52 -0700 From: Terry Lambert Message-Id: <199609242119.OAA04679@phaeton.artisoft.com> Subject: Book reference you requested To: martin@laurin.teuto.de (Martin Husemann) Date: Tue, 24 Sep 1996 14:19:52 -0700 (MST) Cc: terry@lambert.org, curt@portal.ca, chuckr@eng.umd.edu, smp@freebsd.org In-Reply-To: <01BBA9DF.9D734900@laurin.teuto.de> from "Martin Husemann" at Sep 24, 96 06:14:13 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 Sorry for the delay; here is the reference for the book all of you said you were interested in: Publication reference: Unix Systems for Modern Architectures Author: Curt Schimmel Publisher: Addison-Wesley ISBN: 0-201-63338-8 URL: http://aw.com/cp/schimmel.html (Addison Wesley) Reviews: http://www.ssc.com/lj/issue9/br9.html (Linux Jouranl) http://www.software.ibm.com/torcas/gwilson/reviews/schimmel.txt Related resources: http://supr.scm.liv.ac.uk/~ismith/msc.html http://www-cgi.cs.cmu.edu/afs/cs/project/mach/public/www/doc/books.html http://www.chorus.com/Products/Datasheets/nucleusv3.html http://www.tdb.uu.se/vb/VB94/vb.10.html http://199.125.99.2/art/9401/sec8/art3.htm http://www.comp.lancs.ac.uk/computing/users/pr/www/chorus/4.html http://fnctsrv0.chips.ibm.com/products/ppc/Developers/ppctools-78.html UC Santa Barbra (ftp.cs.ucsb.edu in ~ftp/techreports): o TRCS94-20.ps Message Dispatch on Modern Computer Architectures [Driesen, Hoelzle, Vitek] o TRCS95-01.ps Separation Constraint Partitioning - A New Algorithm for Partitioning Non-strict Programs into Sequential Threads o TRCS94-25.ps Active Messages Implementations for the Meiko CS-2 HERE IS A SMALL URL BIBLIOGRAPHY OF LOCKING, PARALLELISM, AND CONCURRENCY: Intention mode locking: http://www.cs.sandia.gov/ISUG/html/priol/section3_2.html http://jazz.external.hp.com/training/sqltables/c5s17.html http://jazz.external.hp.com/training/sqltables/c5s21.html http://jazz.external.hp.com/training/sqltables/c5s22.html http://jazz.external.hp.com/training/sqltables/c5s23.html http://jazz.external.hp.com/training/sqltables/c5s49.html http://ftp.digital.com/pub/Digital/CRL/tech-reports/92.9.ps.Z Graph closure and parallelism, deadlock avoidance: http://www.cs.hut.fi/~enu/tc.html http://sunsite.anu.edu.au/mirrors/dblp/dblp/db/deductive/closure.html http://cs-tr.cs.cornell.edu/Dienst/Repository/2.0/Body/ncstrl.cornell/TR86-759/ocr http://www.cs.hut.fi/~psu/VK94/node28.html http://www.cs.sunysb.edu/~algorith/major_section/1.4.shtml http://sdmc.iss.nus.sg/kleisli/kleisli/Theory.html http://karl.cs.flinders.edu.au/research/AI/SICStus/3.2/sicstus_26.html http://rodin.wustl.edu/~kevin/dissert/node13.html http://info.gte.com/dblp/db/indices/a-tree/s/Schipper:Gideon_L=_V=.html http://dimacs.rutgers.edu/~etessami/etessami_talk_9_13.html http://www.cs.rochester.edu/u/leblanc/csc173/graphs/tc.html http://www.cs.nthu.edu.tw/document/Faculty/wtchen.html http://docs.dcs.napier.ac.uk/DOCS/GET/lehmann76a/document.html http://cs.smith.edu/~thiebaut/transputer/chapter9/chap9-6.htm http://www-cse.ucsd.edu/users/jdm/Papers/red/node6.html http://www.brics.dk/~thore/Papers/lowerbounds.html http://www.cs.hut.fi/~enu/thesis.html http://www.cs.sunysb.edu/~algorith/files/transitive-closure.shtml http://www.brics.dk/~thore/Papers/dtc.html http://www.vlsi.polymtl.ca/dagenais/ELE6813/notes/chap9/subsectionstar3_1_8.html http://www.ifi.uni-klu.ac.at/Manuals/Sicstus/library_10.html http://www.cs.auckland.ac.nz/~jeremy/projects/rtc.html General Concurrency theory: http://boole.stanford.edu/pub/ABSTRACTS 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 Sep 24 18:36:12 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA23833 for smp-outgoing; Tue, 24 Sep 1996 18:36:12 -0700 (PDT) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA23723 for ; Tue, 24 Sep 1996 18:36:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id TAA16391; Tue, 24 Sep 1996 19:33:59 -0600 Message-Id: <199609250133.TAA16391@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Terry Lambert cc: martin@laurin.teuto.de (Martin Husemann), curt@portal.ca, chuckr@eng.umd.edu, smp@freebsd.org Subject: Re: Book reference you requested In-reply-to: Your message of "Tue, 24 Sep 1996 14:19:52 PDT." <199609242119.OAA04679@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 Sep 1996 19:33:59 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, > Sorry for the delay; here is the reference for the book all of you > said you were interested in: I've added this list to: http://www.freebsd.org/~fsmp/SMP/threads.html -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Wed Sep 25 07:54:45 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA27180 for smp-outgoing; Wed, 25 Sep 1996 07:54:45 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id HAA27150 for ; Wed, 25 Sep 1996 07:54:40 -0700 (PDT) Received: from sci.brooklyn.cuny.edu by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0v5vMD-00091QC; Wed, 25 Sep 96 07:54 PDT Received: from robeson.sci.brooklyn.cuny.edu by sci.brooklyn.cuny.edu (4.1/SMI-4.1a) id AA08399; Wed, 25 Sep 96 10:50:51 EDT Received: by robeson.sci.brooklyn.cuny.edu (SMI-8.6/SMI-SVR4) id KAA17618; Wed, 25 Sep 1996 10:49:00 -0400 Date: Wed, 25 Sep 1996 10:49:00 -0400 Message-Id: <199609251449.KAA17618@robeson.sci.brooklyn.cuny.edu> From: Dayton Clark To: freebsd-smp@freebsd.org Subject: QuadPro Motherboard Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Folks, We've got an attractive quote on 4CPU systems with QuadPro motherboards which use the Orion chipset. I plan to try Freebsd-SMP on one of them, at least for awhile. Questions: o I know the Orion chipset has a bad rap. Does the B0 release fix the problems? I/O bandwidth is not a major concern for our applications but interprocessor communication is. Putting aside the 4MB/sec I/O limit, are the chipset OK? o Any comments/experience/suggestions regarding QuadPro motherboards in general? o I've been searching Intel web site for their comments on the Orion chipset. Where are they located? thanks dayton Dayton Clark CIS Department dayton@brooklyn.cuny.edu Brooklyn College/CUNY 1-718-951-4811 Brooklyn, New York 11210 1-718-951-4842 (fax) From owner-freebsd-smp Wed Sep 25 15:01:33 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA23711 for smp-outgoing; Wed, 25 Sep 1996 15:01:33 -0700 (PDT) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA23667 for ; Wed, 25 Sep 1996 15:01:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id QAA21840; Wed, 25 Sep 1996 16:01:11 -0600 Message-Id: <199609252201.QAA21840@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Dayton Clark cc: freebsd-smp@FreeBSD.org Subject: Re: QuadPro Motherboard In-reply-to: Your message of "Wed, 25 Sep 1996 10:49:00 EDT." <199609251449.KAA17618@robeson.sci.brooklyn.cuny.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Sep 1996 16:01:11 -0600 Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi, Dayton Clark said: > We've got an attractive quote on 4CPU systems with QuadPro > motherboards which use the Orion chipset. I plan to try Freebsd-SMP > on one of them, at least for awhile. Questions: > > o I know the Orion chipset has a bad rap. Does the B0 release fix > the problems? I/O bandwidth is not a major concern for our > applications but interprocessor communication is. Putting aside > the 4MB/sec I/O limit, are the chipset OK? looking at the Intel website you'd think the 450GX/450KX were new generation chips without any problems: http://www.intel.com/design/pcisets/PRODBREF/PCI_PPRO.HTM Rod (or anyone else), is this improved silicon, or the old Orion chipset with new hype? > o Any comments/experience/suggestions regarding QuadPro motherboards > in general? do you have a URL to their site? > o I've been searching Intel web site for their comments on the Orion > chipset. Where are they located? 1: (above reference) 2: http://www.intel.com/design/pcisets/INDEX.HTM#A8 3: http://www.intel.com/product/general/450gx.HTM 4: http://www.intel.com/product/general/450kx.HTM If anybody has URLs for the datasheets for the 450xx line please let me know. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Wed Sep 25 15:57:36 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA21531 for smp-outgoing; Wed, 25 Sep 1996 15:57:36 -0700 (PDT) Received: from uruk.org (uruk.org [198.145.95.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id PAA21472 for ; Wed, 25 Sep 1996 15:57:28 -0700 (PDT) From: erich@uruk.org Received: from loopback (loopback [127.0.0.1]) by uruk.org (8.7.4/8.7.3) with SMTP id PAA16923; Wed, 25 Sep 1996 15:57:33 -0700 (PDT) Message-Id: <199609252257.PAA16923@uruk.org> X-Authentication-Warning: uruk.org: Host loopback [127.0.0.1] didn't use HELO protocol To: Dayton Clark cc: freebsd-smp@freebsd.org Subject: Re: QuadPro Motherboard In-reply-to: Your message of "Wed, 25 Sep 1996 10:49:00 EDT." <199609251449.KAA17618@robeson.sci.brooklyn.cuny.edu> Date: Wed, 25 Sep 1996 15:57:28 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Dayton Clark writes: > We've got an attractive quote on 4CPU systems with QuadPro > motherboards which use the Orion chipset. I plan to try Freebsd-SMP > on one of them, at least for awhile. Uhh... as far as I know, no P6 motherboard will work with FreeBSD-SMP. The problem is that FreeBSD-SMP has a hard-coded value for the local APIC address, and while the Pentium has this same hard-coded limitation, the Pentium Pro does not (and in fact many systems relocate it). The MP spec has an entry for this value. Linux-SMP had the same problem before I started work on it. > o I know the Orion chipset has a bad rap. Does the B0 release fix > the problems? I/O bandwidth is not a major concern for our > applications but interprocessor communication is. Putting aside > the 4MB/sec I/O limit, are the chipset OK? The B0 is *much* nicer. I've gotten some really good performance numbers out of it. Unfortunately, it was tuned for large transactions on the I/O bus, so (I think) small transfers may not do as well as even the high-end Pentium chipsets. Natoma is clearly better for small I/O transactions. > o Any comments/experience/suggestions regarding QuadPro motherboards > in general? I've never talked to anyone who has used one, but the motherboard is probably similar to the Intel Alder motherboard (the AMI Goliath was), and it's a screamer. > o I've been searching Intel web site for their comments on the Orion > chipset. Where are they located? I think you have to get the chipset specs for that. Intel is unfortunately tight-lipped about such information about any of their chips (I think the big-company syndrome has gotten to them pretty bad). -- 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 Wed Sep 25 17:01:48 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA19376 for smp-outgoing; Wed, 25 Sep 1996 17:01:48 -0700 (PDT) Received: from po1.glue.umd.edu (po1.glue.umd.edu [129.2.128.44]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA19329 for ; Wed, 25 Sep 1996 17:01:43 -0700 (PDT) Received: from skipper.eng.umd.edu (skipper.eng.umd.edu [129.2.103.24]) by po1.glue.umd.edu (8.8.Beta.6/8.7.3) with ESMTP id UAA11170; Wed, 25 Sep 1996 20:01:40 -0400 (EDT) Received: from localhost (chuckr@localhost) by skipper.eng.umd.edu (8.7.5/8.7.3) with SMTP id UAA07540; Wed, 25 Sep 1996 20:01:40 -0400 (EDT) X-Authentication-Warning: skipper.eng.umd.edu: chuckr owned process doing -bs Date: Wed, 25 Sep 1996 20:01:39 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@skipper.eng.umd.edu To: erich@uruk.org cc: Dayton Clark , freebsd-smp@freebsd.org Subject: Re: QuadPro Motherboard In-Reply-To: <199609252257.PAA16923@uruk.org> 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, 25 Sep 1996 erich@uruk.org wrote: > > Dayton Clark writes: > > > We've got an attractive quote on 4CPU systems with QuadPro > > motherboards which use the Orion chipset. I plan to try Freebsd-SMP > > on one of them, at least for awhile. > > Uhh... as far as I know, no P6 motherboard will work with FreeBSD-SMP. Oh, really? I have been tottering on the edge, about ready to buy a new motherboard exclusively for running FreeBSD-smp, and I was thinking PPro, because I always upgrade as current as I can. Then PPro smp boards are out? I'm NOT a kernel hacker, I'm not capable of figuring out and fixing such bugs myself (altho I'd get the board and run tests forever, if anyone else wanted to help). I'd even get the board and loan it out for a month or two, while someone more knowledgeable fixed things. But if it doesn't run at all, well .... > The problem is that FreeBSD-SMP has a hard-coded value for the local APIC > address, and while the Pentium has this same hard-coded limitation, > the Pentium Pro does not (and in fact many systems relocate it). > -- > 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" > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and n3lxx, both FreeBSD (301) 220-2114 | version 2.2 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-smp Wed Sep 25 18:01:36 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA29337 for smp-outgoing; Wed, 25 Sep 1996 18:01:36 -0700 (PDT) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [204.214.4.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA29297 for ; Wed, 25 Sep 1996 18:01:30 -0700 (PDT) Received: from bonsai.hiwaay.net by fly.HiWAAY.net; (8.7.5/1.1.8.2/21Sep95-1003PM) id UAA12268; Wed, 25 Sep 1996 20:00:52 -0500 (CDT) Message-ID: <3249D57C.62319AC4@hiwaay.net> Date: Wed, 25 Sep 1996 19:59:40 -0500 From: Steve Price X-Mailer: Mozilla 2.02 (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: erich@uruk.org CC: freebsd-smp@freebsd.org Subject: Re: QuadPro Motherboard References: <199609252257.PAA16923@uruk.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk erich@uruk.org wrote: > > Uhh... as far as I know, no P6 motherboard will work with > FreeBSD-SMP. > [snipola] Is this really true? I am within a whisker of buying a Dual PPro 200 and this would definitely affect my decision. Steve From owner-freebsd-smp Wed Sep 25 18:14:20 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA05949 for smp-outgoing; Wed, 25 Sep 1996 18:14:20 -0700 (PDT) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA05900 for ; Wed, 25 Sep 1996 18:14:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id TAA22702; Wed, 25 Sep 1996 19:13:45 -0600 Message-Id: <199609260113.TAA22702@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Chuck Robey cc: erich@uruk.org, Dayton Clark , freebsd-smp@freebsd.org Subject: Re: QuadPro Motherboard In-reply-to: Your message of "Wed, 25 Sep 1996 20:01:39 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Sep 1996 19:13:45 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, >> Uhh... as far as I know, no P6 motherboard will work with FreeBSD-SMP. > >Oh, really? I have been tottering on the edge, about ready to buy a new >motherboard exclusively for running FreeBSD-smp, and I was thinking PPro, this is not a show stopper. The code I have listed on SMP.html as test1 has the beginnings of functions to parse the MP for this type information. In particular I am parsing out the CPU APIC IDs and building a physical tp logical table that is used for all the cpunumber stuff. The local apic is mapped to its own page and changing this from the hard address to a parsed address would take me about 5 minutes. There might be a little more work in the code that is used during startup (ie b4 we are in protected mode/paging), but again this should be minor. >out? I'm NOT a kernel hacker, I'm not capable of figuring out and fixing >such bugs myself (altho I'd get the board and run tests forever, if anyone >else wanted to help). I'd even get the board and loan it out for a month I'll be glad to help you deal with this issue. -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Wed Sep 25 18:18:32 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA08001 for smp-outgoing; Wed, 25 Sep 1996 18:18:32 -0700 (PDT) Received: from uruk.org (uruk.org [198.145.95.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA07967 for ; Wed, 25 Sep 1996 18:18:28 -0700 (PDT) From: erich@uruk.org Received: from loopback (loopback [127.0.0.1]) by uruk.org (8.7.4/8.7.3) with SMTP id SAA17253; Wed, 25 Sep 1996 18:20:05 -0700 (PDT) Message-Id: <199609260120.SAA17253@uruk.org> X-Authentication-Warning: uruk.org: Host loopback [127.0.0.1] didn't use HELO protocol To: Chuck Robey cc: Dayton Clark , freebsd-smp@freebsd.org, Steve Price Subject: FreeBSD-SMP and Pentium Pro (was -> Re: QuadPro Motherboard) In-reply-to: Your message of "Wed, 25 Sep 1996 20:01:39 EDT." Date: Wed, 25 Sep 1996 18:20:04 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Chuck Robey writes: > On Wed, 25 Sep 1996 erich@uruk.org wrote: > > > > > Dayton Clark writes: > > > > > We've got an attractive quote on 4CPU systems with QuadPro > > > motherboards which use the Orion chipset. I plan to try Freebsd-SMP > > > on one of them, at least for awhile. > > > > Uhh... as far as I know, no P6 motherboard will work with FreeBSD-SMP. > > Oh, really? I have been tottering on the edge, about ready to buy a new > motherboard exclusively for running FreeBSD-smp, and I was thinking PPro, > because I always upgrade as current as I can. Then PPro smp boards are > out? I'm NOT a kernel hacker, I'm not capable of figuring out and fixing > such bugs myself (altho I'd get the board and run tests forever, if anyone > else wanted to help). I'd even get the board and loan it out for a month > or two, while someone more knowledgeable fixed things. But if it doesn't > run at all, well .... Wow, I didn't think I'd cause this kind of widespread panic ;-) Seriously, though... this isn't a huge show-stopper by any means. There are 2 things necessary to fix working with most P6 systems: -- Changing the local APIC to a variable (right now it is hard-coded), or simply changing the page address it is mapped at to take this into account. -- For many dual-P6 motherboards, support booting off of a CPU local APIC which is != 0. Many P6 motherboards have the boot CPU as #1, and the secondary CPU as #0. This might be harder to fix. BTW, I'll have a finished "generic" startup sequence available in a few days on my web site. It is similar to but somewhat more generic than the Linux-SMP CPU startup code. -- 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 Wed Sep 25 18:23:19 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA10588 for smp-outgoing; Wed, 25 Sep 1996 18:23:19 -0700 (PDT) Received: from po1.glue.umd.edu (po1.glue.umd.edu [129.2.128.44]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA10568 for ; Wed, 25 Sep 1996 18:23:16 -0700 (PDT) Received: from skipper.eng.umd.edu (skipper.eng.umd.edu [129.2.103.24]) by po1.glue.umd.edu (8.8.Beta.6/8.7.3) with ESMTP id VAA12657; Wed, 25 Sep 1996 21:22:59 -0400 (EDT) Received: from localhost (chuckr@localhost) by skipper.eng.umd.edu (8.7.5/8.7.3) with SMTP id VAA07492; Wed, 25 Sep 1996 21:22:58 -0400 (EDT) X-Authentication-Warning: skipper.eng.umd.edu: chuckr owned process doing -bs Date: Wed, 25 Sep 1996 21:22:56 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@skipper.eng.umd.edu To: erich@uruk.org cc: Dayton Clark , freebsd-smp@freebsd.org, Steve Price Subject: Re: FreeBSD-SMP and Pentium Pro (was -> Re: QuadPro Motherboard) In-Reply-To: <199609260120.SAA17253@uruk.org> 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, 25 Sep 1996 erich@uruk.org wrote: > Wow, I didn't think I'd cause this kind of widespread panic ;-) Erich, the cost of that damn dual PPro board is so high (mostly the cost the the 2 Ppro's) that I have to take it seriously. That's a major portion of the reason that I've been foot dragging on doing it, because I'm worried about getting a $2k motherboard/doorstop. > > Seriously, though... this isn't a huge show-stopper by any means. There > are 2 things necessary to fix working with most P6 systems: > > -- Changing the local APIC to a variable (right now it is hard-coded), > or simply changing the page address it is mapped at to take this > into account. > > -- For many dual-P6 motherboards, support booting off of a CPU local APIC > which is != 0. Many P6 motherboards have the boot CPU as #1, and > the secondary CPU as #0. This might be harder to fix. > > > BTW, I'll have a finished "generic" startup sequence available in a few > days on my web site. It is similar to but somewhat more generic than the > Linux-SMP CPU startup code. > > -- > 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" > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and n3lxx, both FreeBSD (301) 220-2114 | version 2.2 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-smp Wed Sep 25 18:27:58 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA13023 for smp-outgoing; Wed, 25 Sep 1996 18:27:58 -0700 (PDT) Received: from fly.HiWAAY.net (fly.HiWAAY.net [204.214.4.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA12890 for ; Wed, 25 Sep 1996 18:27:43 -0700 (PDT) Received: from bonsai.hiwaay.net by fly.HiWAAY.net; (8.7.5/1.1.8.2/21Sep95-1003PM) id UAA04060; Wed, 25 Sep 1996 20:24:07 -0500 (CDT) Message-ID: <3249DAF0.695678E2@hiwaay.net> Date: Wed, 25 Sep 1996 20:22:56 -0500 From: Steve Price X-Mailer: Mozilla 2.02 (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: erich@uruk.org CC: freebsd-smp@freebsd.org Subject: Re: FreeBSD-SMP and Pentium Pro (was -> Re: QuadPro Motherboard) References: <199609260120.SAA17253@uruk.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk erich@uruk.org wrote: > > Wow, I didn't think I'd cause this kind of widespread panic ;-) > > Seriously, though... this isn't a huge show-stopper by any means. There > are 2 things necessary to fix working with most P6 systems: > > -- Changing the local APIC to a variable (right now it is hard-coded), > or simply changing the page address it is mapped at to take this > into account. > > -- For many dual-P6 motherboards, support booting off of a CPU local APIC > which is != 0. Many P6 motherboards have the boot CPU as #1, and > the secondary CPU as #0. This might be harder to fix. > > BTW, I'll have a finished "generic" startup sequence available in a few > days on my web site. It is similar to but somewhat more generic than the > Linux-SMP CPU startup code. > > -- > 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" Are you planning on providing the fixes to the other problems that you mentioned as well? ;) Steve From owner-freebsd-smp Wed Sep 25 21:30:13 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id VAA12527 for smp-outgoing; Wed, 25 Sep 1996 21:30:13 -0700 (PDT) Received: from databus.databus.com (databus.databus.com [198.186.154.34]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id VAA12475 for ; Wed, 25 Sep 1996 21:30:04 -0700 (PDT) From: Barney Wolff To: freebsd-smp@freebsd.org Date: Thu, 26 Sep 1996 00:21 EDT Subject: Re: FreeBSD-SMP and Pentium Pro (was -> Re: QuadPro Motherboard) Content-Type: text/plain Message-ID: <324a06bf0.2d93@databus.databus.com> Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Date: Wed, 25 Sep 1996 21:22:56 -0400 (EDT) > From: Chuck Robey > > Erich, the cost of that damn dual PPro board is so high (mostly the cost > the the 2 Ppro's) that I have to take it seriously. That's a major > portion of the reason that I've been foot dragging on doing it, because > I'm worried about getting a $2k motherboard/doorstop. Well, it's not THAT bad. I can report one experimental point: I have installed and run 2.1.5-release (non-smp) on a Supermicro P6DNE with 2 cpus installed. So at most you're out the price of 1 P6, which can always be used in a second machine. Barney Wolff From owner-freebsd-smp Thu Sep 26 00:26:35 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA04519 for smp-outgoing; Thu, 26 Sep 1996 00:26:35 -0700 (PDT) Received: from critter.tfs.com ([140.145.230.252]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA04469; Thu, 26 Sep 1996 00:26:26 -0700 (PDT) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id JAA04233; Thu, 26 Sep 1996 09:25:52 +0200 (MET DST) To: erich@uruk.org cc: Dayton Clark , freebsd-smp@freebsd.org Subject: Re: QuadPro Motherboard In-reply-to: Your message of "Wed, 25 Sep 1996 15:57:28 PDT." <199609252257.PAA16923@uruk.org> Date: Thu, 26 Sep 1996 09:25:52 +0200 Message-ID: <4231.843722752@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199609252257.PAA16923@uruk.org>, erich@uruk.org writes: > >Dayton Clark writes: > >> We've got an attractive quote on 4CPU systems with QuadPro >> motherboards which use the Orion chipset. I plan to try Freebsd-SMP >> on one of them, at least for awhile. > >Uhh... as far as I know, no P6 motherboard will work with FreeBSD-SMP. it worked fine on the HP 2xP6/150 I tried it on... -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-smp Thu Sep 26 00:45:44 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA20056 for smp-outgoing; Thu, 26 Sep 1996 00:45:44 -0700 (PDT) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA20005 for ; Thu, 26 Sep 1996 00:45:38 -0700 (PDT) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.7.6/8.7.3) with ESMTP id PAA00409; Thu, 26 Sep 1996 15:44:58 +0800 (WST) Message-Id: <199609260744.PAA00409@spinner.DIALix.COM> X-Mailer: exmh version 1.6.7 5/3/96 To: Poul-Henning Kamp cc: erich@uruk.org, Dayton Clark , freebsd-smp@freebsd.org Subject: Re: QuadPro Motherboard In-reply-to: Your message of "Thu, 26 Sep 1996 09:25:52 +0200." <4231.843722752@critter.tfs.com> Date: Thu, 26 Sep 1996 15:44:57 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Poul-Henning Kamp wrote: > In message <199609252257.PAA16923@uruk.org>, erich@uruk.org writes: > > > >Dayton Clark writes: > > > >> We've got an attractive quote on 4CPU systems with QuadPro > >> motherboards which use the Orion chipset. I plan to try Freebsd-SMP > >> on one of them, at least for awhile. > > > >Uhh... as far as I know, no P6 motherboard will work with FreeBSD-SMP. > > it worked fine on the HP 2xP6/150 I tried it on... There is a tweakable #define in the current boot code that tells the booting cpu the apic ID of the other cpu. Normally, this is 1, but if the boot cpu is #1 (or something else), then the boot cpu can start cpu #0 or whatever. It's not pretty but it should work enough to be usable. > -- > Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. > http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. > whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, In c. > Future will arrive by its own means, progress not so. Cheers, -Peter From owner-freebsd-smp Thu Sep 26 07:30:33 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id HAA12828 for smp-outgoing; Thu, 26 Sep 1996 07:30:33 -0700 (PDT) Received: from uruk.org (uruk.org [198.145.95.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id HAA12790 for ; Thu, 26 Sep 1996 07:30:28 -0700 (PDT) From: erich@uruk.org Received: from loopback (loopback [127.0.0.1]) by uruk.org (8.7.4/8.7.3) with SMTP id HAA19077; Thu, 26 Sep 1996 07:31:39 -0700 (PDT) Message-Id: <199609261431.HAA19077@uruk.org> X-Authentication-Warning: uruk.org: Host loopback [127.0.0.1] didn't use HELO protocol To: Peter Wemm , Poul-Henning Kamp cc: Dayton Clark , freebsd-smp@freebsd.org Subject: Re: QuadPro Motherboard In-reply-to: Your message of "Thu, 26 Sep 1996 15:44:57 +0800." <199609260744.PAA00409@spinner.DIALix.COM> Date: Thu, 26 Sep 1996 07:31:34 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Peter Wemm writes: > Poul-Henning Kamp wrote: > > In message <199609252257.PAA16923@uruk.org>, erich@uruk.org writes: > > > > > >Dayton Clark writes: > > > > > >> We've got an attractive quote on 4CPU systems with QuadPro > > >> motherboards which use the Orion chipset. I plan to try Freebsd-SMP > > >> on one of them, at least for awhile. > > > > > >Uhh... as far as I know, no P6 motherboard will work with FreeBSD-SMP. > > > > it worked fine on the HP 2xP6/150 I tried it on... Interesting!!! All the Pentium Pro boxes I tried Linux on when I was testing it had the local APIC at a different address than the default, so the "#define" as it currently is simply failed to work. Did you change the local APIC address? > There is a tweakable #define in the current boot code that tells the > booting cpu the apic ID of the other cpu. Normally, this is 1, but if the > boot cpu is #1 (or something else), then the boot cpu can start cpu #0 or > whatever. > > It's not pretty but it should work enough to be usable. Again, that's only part of it. To get my big test box to work (it has CPUs numbered 0, 1, 2, and 4, with the boot CPU as #0), the main thing I had to do to get 2 CPUs running was change the local APIC address. On all the Pentium Pro boxes I've tried, it was always 0xFEC08000 instead of the default 0xFEE0000. NOTE that the I/O APIC defaults to 0xFEC00000. I think since you can relocate the local APIC, they did that in many of the Pentium Pro designs to fragment the address space as little as possible. -- 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 Sep 26 09:27:05 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA18122 for smp-outgoing; Thu, 26 Sep 1996 09:27:05 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id JAA18091 for ; Thu, 26 Sep 1996 09:27:00 -0700 (PDT) Received: by agora.rdrop.com (Smail3.1.29.1 #17) id m0v6JH8-000927C; Thu, 26 Sep 96 09:26 PDT Message-Id: From: garyh@agora.rdrop.com (Gary Hanson) Subject: mptable results for IBM 704 (dual PPro) To: freebsd-smp@freebsd.org Date: Thu, 26 Sep 1996 09:26:58 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24 ME8a] 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 Enclosed is the long (and mostly boring) output of mptable.c on a 2 processor IBM 704 system (Orion B0 chipset). This is with the system set to MPS 1.1; with MPS 1.4, the system repeats mostly the same things over-and-over-and-over, 89K worth. If I send the mptable output to a file, I get "Warning: EBDA support is BROKEN!!!" on the screen, but I don't seem to see that without redirecting stdout. --Gary Hanson -------------------------------------------------------------------------- Found MP Table in BIOS, physical addr: 0x000f78c0 -------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000f78c0 signature: '_MP_' length: 16 bytes version: 1.1 checksum: 0x4c mode: Virtual Wire -------------------------------------------------------------------------- MP Config Table Header: physical address: 0x000f78d0 signature: 'PCMP' base table length: 252 version: 1.1 checksum: 0xb0 OEM ID: 'INTEL ' Product ID: 'ALDER ' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 23 local APIC address: 0xfec08000 extended table length: 0 extended table checksum: 0 -------------------------------------------------------------------------- MP Config Base Table Entries: -- Processor apic ID: 0, version: 17 CPU is usable, CPU is the bootstrap processor family: 6, model: 1, stepping: 7 feature flags: 0x0000fbff -- Processor apic ID: 1, version: 17 CPU is usable, CPU is NOT the bootstrap processor family: 6, model: 1, stepping: 7 feature flags: 0x0000fbff -- Bus bus ID: 0, bus type: PCI -- Bus bus ID: 1, bus type: PCI -- Bus bus ID: 18, bus type: EISA -- I/O APIC apic ID: 14, version: 17 APIC is usable apic address: 0xfec00000 -- I/O INT INT type: 0, flags: 0x0005 source bus ID: 18, IRQ: 1 destination APIC ID: 14, INT: 1 -- I/O INT INT type: 0, flags: 0x0005 source bus ID: 18, IRQ: 0 destination APIC ID: 14, INT: 2 -- I/O INT INT type: 0, flags: 0x0005 source bus ID: 18, IRQ: 3 destination APIC ID: 14, INT: 3 -- I/O INT INT type: 0, flags: 0x0005 source bus ID: 18, IRQ: 4 destination APIC ID: 14, INT: 4 -- I/O INT INT type: 0, flags: 0x0005 source bus ID: 18, IRQ: 5 destination APIC ID: 14, INT: 5 -- I/O INT INT type: 0, flags: 0x0005 source bus ID: 18, IRQ: 6 destination APIC ID: 14, INT: 6 -- I/O INT INT type: 0, flags: 0x0005 source bus ID: 18, IRQ: 7 destination APIC ID: 14, INT: 7 -- I/O INT INT type: 0, flags: 0x0005 source bus ID: 18, IRQ: 8 destination APIC ID: 14, INT: 8 -- I/O INT INT type: 0, flags: 0x000d source bus ID: 18, IRQ: 9 destination APIC ID: 14, INT: 9 -- I/O INT INT type: 0, flags: 0x000d source bus ID: 18, IRQ: 10 destination APIC ID: 14, INT: 10 -- I/O INT INT type: 0, flags: 0x000d source bus ID: 18, IRQ: 11 destination APIC ID: 14, INT: 11 -- I/O INT INT type: 0, flags: 0x0005 source bus ID: 18, IRQ: 12 destination APIC ID: 14, INT: 12 -- I/O INT INT type: 0, flags: 0x0005 source bus ID: 18, IRQ: 13 destination APIC ID: 14, INT: 13 -- I/O INT INT type: 0, flags: 0x0005 source bus ID: 18, IRQ: 14 destination APIC ID: 14, INT: 14 -- I/O INT INT type: 0, flags: 0x0005 source bus ID: 18, IRQ: 15 destination APIC ID: 14, INT: 15 -- Local INT INT type: 3, flags: 0x0005 source bus ID: 18, IRQ: 0 destination APIC ID: 255, INT: 0 -- Local INT INT type: 1, flags: 0x0005 source bus ID: 0, IRQ: 0 destination APIC ID: 255, INT: 1 -------------------------------------------------------------------------- From owner-freebsd-smp Thu Sep 26 10:05:55 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA07768 for smp-outgoing; Thu, 26 Sep 1996 10:05:55 -0700 (PDT) Received: from critter.tfs.com ([140.145.230.177]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA07692; Thu, 26 Sep 1996 10:05:48 -0700 (PDT) Received: from critter.tfs.com (localhost.tfs.com [127.0.0.1]) by critter.tfs.com (8.7.5/8.7.3) with ESMTP id QAA05177; Thu, 26 Sep 1996 16:33:34 +0200 (MET DST) To: erich@uruk.org cc: Peter Wemm , Dayton Clark , freebsd-smp@freebsd.org Subject: Re: QuadPro Motherboard In-reply-to: Your message of "Thu, 26 Sep 1996 07:31:34 PDT." <199609261431.HAA19077@uruk.org> Date: Thu, 26 Sep 1996 16:33:34 +0200 Message-ID: <5175.843748414@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199609261431.HAA19077@uruk.org>, erich@uruk.org writes: >> > >Uhh... as far as I know, no P6 motherboard will work with FreeBSD-SMP. >> > >> > it worked fine on the HP 2xP6/150 I tried it on... > >Interesting!!! All the Pentium Pro boxes I tried Linux on when I was >testing it had the local APIC at a different address than the default, >so the "#define" as it currently is simply failed to work. > >Did you change the local APIC address? no, only the cpuID, the BP is #1. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-smp Thu Sep 26 13:35:59 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA00957 for smp-outgoing; Thu, 26 Sep 1996 13:35:59 -0700 (PDT) Received: from po2.glue.umd.edu (po2.glue.umd.edu [129.2.128.45]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA00918 for ; Thu, 26 Sep 1996 13:35:53 -0700 (PDT) Received: from skipper.eng.umd.edu (skipper.eng.umd.edu [129.2.103.24]) by po2.glue.umd.edu (8.7.5/8.7.3) with ESMTP id QAA23199; Thu, 26 Sep 1996 16:35:49 -0400 (EDT) Received: from localhost (chuckr@localhost) by skipper.eng.umd.edu (8.7.5/8.7.3) with SMTP id QAA10963; Thu, 26 Sep 1996 16:35:49 -0400 (EDT) X-Authentication-Warning: skipper.eng.umd.edu: chuckr owned process doing -bs Date: Thu, 26 Sep 1996 16:35:42 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@skipper.eng.umd.edu To: Barney Wolff cc: freebsd-smp@freebsd.org Subject: Re: FreeBSD-SMP and Pentium Pro (was -> Re: QuadPro Motherboard) In-Reply-To: <324a06bf0.2d93@databus.databus.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, 26 Sep 1996, Barney Wolff wrote: > > Date: Wed, 25 Sep 1996 21:22:56 -0400 (EDT) > > From: Chuck Robey > > > > Erich, the cost of that damn dual PPro board is so high (mostly the cost > > the the 2 Ppro's) that I have to take it seriously. That's a major > > portion of the reason that I've been foot dragging on doing it, because > > I'm worried about getting a $2k motherboard/doorstop. > > Well, it's not THAT bad. I can report one experimental point: I have > installed and run 2.1.5-release (non-smp) on a Supermicro P6DNE with > 2 cpus installed. So at most you're out the price of 1 P6, which can > always be used in a second machine. It is that bad if the goal is to run smp, and it fails because of something uncorrectable. Unless you happen to have a seond machine around that happens to have a space slot for a PPro (unlikely). > > Barney Wolff > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and n3lxx, both FreeBSD (301) 220-2114 | version 2.2 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-smp Thu Sep 26 14:03:06 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA13771 for smp-outgoing; Thu, 26 Sep 1996 14:03:06 -0700 (PDT) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA13720 for ; Thu, 26 Sep 1996 14:02:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id PAA28605; Thu, 26 Sep 1996 15:01:51 -0600 Message-Id: <199609262101.PAA28605@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: garyh@agora.rdrop.com (Gary Hanson) cc: freebsd-smp@FreeBSD.org Subject: Re: mptable results for IBM 704 (dual PPro) In-reply-to: Your message of "Thu, 26 Sep 1996 09:26:58 PDT." Mime-Version: 1.0 Content-Type: text/plain Date: Thu, 26 Sep 1996 15:01:51 -0600 Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi, > Enclosed is the long (and mostly boring) output of mptable.c on a 2 boring to you perhaps, but quite useful to me. > processor IBM 704 system (Orion B0 chipset). This is with the system set > to MPS 1.1; with MPS 1.4, the system repeats mostly the same things > over-and-over-and-over, 89K worth. I think that is because EBDA support in mptable is 'broken'. I'm assumming that the 1.1 spec doesn't deal will EBDA (or at least the implimentors of this BIOS chose to ignore EBDA when emulating 1.1, but use it for 1.4). Unfortunately Intel doesn't post the 1.1 spec anymore. If someone has an archive copy please email it to me. The 'broken-ness' of the program is that I couldn't seem to access the EBDA pointer @ 40:e0h (0x04e0) from /dev/kmem. If someone will tell me the trick to this I will fix this bug. > > If I send the mptable output to a file, I get "Warning: EBDA support is > BROKEN!!!" on the screen, but I don't seem to see that without > redirecting stdout. that line goes to stderr, the rest to stdout. I'm guessing it just scrolls by so fast it gets lost in the second (non-redirected) case. > Found MP Table in BIOS, physical addr: 0x000f78c0 > ... > version: 1.1 > checksum: 0xb0 > OEM ID: 'INTEL ' > Product ID: 'ALDER ' > ... > local APIC address: 0xfec08000 > ... > -- > Processor > apic ID: 0, version: 17 > CPU is usable, CPU is the bootstrap processor > ... > -- > Processor > apic ID: 1, version: 17 > CPU is usable, CPU is NOT the bootstrap processor > ... > I/O APIC > apic ID: 14, version: 17 > APIC is usable > apic address: 0xfec00000 from the above we see that the CPU APIC numbering will not break the current SMP kernel, ie boot CPU == 0, 2nd CPU == 1. But they chose to relocate the CPU APIC address from the standard address (0xfee0000) to 0xfec08000 as erich predicted. This will break the current SMP kernel. I am currently working on this problem and expect to be finished with it today. It turned out to be harder that I predicted previously because of a "chicken and egg" problem. Out of curiousity, have you ever attempted to run the FreeBSD SMP kernel on this hardware? If so, with what results? -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Thu Sep 26 15:24:28 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA26119 for smp-outgoing; Thu, 26 Sep 1996 15:24:28 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA26080 for ; Thu, 26 Sep 1996 15:24:22 -0700 (PDT) Received: by agora.rdrop.com (Smail3.1.29.1 #17) id m0v6Oqm-000926C; Thu, 26 Sep 96 15:24 PDT Message-Id: From: garyh@agora.rdrop.com (Gary Hanson) Subject: Re: mptable results for IBM 704 (dual PPro) To: smp@csn.net (Steve Passe) Date: Thu, 26 Sep 1996 15:24:08 -0700 (PDT) Cc: freebsd-smp@FreeBSD.org In-Reply-To: <199609262101.PAA28605@clem.systemsix.com> from "Steve Passe" at Sep 26, 96 03:01:51 pm X-Mailer: ELM [version 2.4 PL24 ME8a] 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 > > Enclosed is the long (and mostly boring) output of mptable.c > > boring to you perhaps, but quite useful to me. :-) I expected so. > Out of curiousity, have you ever attempted to run the FreeBSD SMP > kernel on this hardware? Nope, not yet. Not enough spare time, no CVS tree, etc. RSN... --Gary Hanson From owner-freebsd-smp Thu Sep 26 18:13:27 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA07159 for smp-outgoing; Thu, 26 Sep 1996 18:13:27 -0700 (PDT) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA07093 for ; Thu, 26 Sep 1996 18:13:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id TAA29868 for ; Thu, 26 Sep 1996 19:13:16 -0600 Message-Id: <199609270113.TAA29868@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: freebsd-smp@freebsd.org Subject: improved MP parse code for SMP kernel Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 26 Sep 1996 19:13:16 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, as promised, I have finished the code that: 1: handles non-standard CPU/IO APIC addresses. 2: automatically boots all APs, reguardless of their physical APIC ID numbering. Note that trying to use more than 2 CPUs will most likely break something else, I can't test that part. you can find this code at: http://www.freebsd.org/~fsmp/SMP/SMP.html as "test2". It replaces "test1", ie don't install test1 b4 unstalling test2. I have tested it on a clean SMP kernel as supped last nite, but since my board uses all the defaults I can't fully test the new functionality. Let me know how it flies... -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Thu Sep 26 20:21:28 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA14628 for smp-outgoing; Thu, 26 Sep 1996 20:21:28 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA14591 for ; Thu, 26 Sep 1996 20:21:21 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.7.5/8.6.9) id WAA23599; Thu, 26 Sep 1996 22:19:20 -0500 (EST) From: "John S. Dyson" Message-Id: <199609270319.WAA23599@dyson.iquest.net> Subject: Re: mptable results for IBM 704 (dual PPro) To: smp@csn.net (Steve Passe) Date: Thu, 26 Sep 1996 22:19:19 -0500 (EST) Cc: garyh@agora.rdrop.com, freebsd-smp@FreeBSD.org In-Reply-To: <199609262101.PAA28605@clem.systemsix.com> from "Steve Passe" at Sep 26, 96 03:01:51 pm Reply-To: dyson@FreeBSD.org X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > > The 'broken-ness' of the program is that I couldn't seem to access the > EBDA pointer @ 40:e0h (0x04e0) from /dev/kmem. If someone will tell me > the trick to this I will fix this bug. > Oh ohhh.... You cannot map page 0 on the system :-(. I think that a work around (fix in the future) is in order. :-). BDE has been bugging me about this for quite a while... John From owner-freebsd-smp Fri Sep 27 20:19:31 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA17765 for smp-outgoing; Fri, 27 Sep 1996 20:19:31 -0700 (PDT) Received: from bluenose.na.tuns.ca (bluenose.na.tuns.ca [134.190.50.184]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA17724 for ; Fri, 27 Sep 1996 20:19:25 -0700 (PDT) Received: (from smp@localhost) by bluenose.na.tuns.ca (8.7.5/8.7.3) id AAA22972 for FreeBSD-smp@Freefall.cdrom.com; Sat, 28 Sep 1996 00:04:16 -0300 (ADT) From: "J.M. Chuang" Message-Id: <199609280304.AAA22972@bluenose.na.tuns.ca> Subject: Tyan S1662 Titan Pro To: FreeBSD-smp@freefall.freebsd.org Date: Sat, 28 Sep 1996 00:04:15 -0300 (ADT) X-Mailer: ELM [version 2.4ME+ PL13 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, Everybody: After struggling with FreeBSD-smp and Tyan S1662 Titan Pro for few days, there are some successes. Here is the configuration of my system: --------------------------------------------------------------- 1. Tyan S1662 Titan Pro Motherboard + 2 Pentium Pro-200 CPU's 2. FreeBSD-smp + FreeBSD-current + test2 (suped at Sept. 27, 1996) --------------------------------------------------------------- There were a lots of warning messages when kernel was compiled. After the system booted up, the second CPU was lunched by sysctl -w kern_smp.active=2 The system was up for about an hour. The file systems were gradually messed up and the shared library libc.so.3.0 was damaged. Eventually, the system dies. There were a lots of coredumps and segmentation faults from running utilities such as perl, tcsh,... Hope it helps the development of FreeBSD-smp. The mptable is shown below. Thanks Jim -------------------------------------------------------------------------- Found MP Table in BIOS, physical addr: 0x000f08c0 -------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000f08c0 signature: '_MP_' length: 16 bytes version: 1.1 checksum: 0xb8 mode: Virtual Wire -------------------------------------------------------------------------- MP Config Table Header: physical address: 0x000f08d4 signature: 'PCMP' base table length: 292 version: 1.1 checksum: 0xaf OEM ID: 'OEM00000' Product ID: 'PROD00000000' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 28 local APIC address: 0xfee00000 extended table length: 0 extended table checksum: 0 -------------------------------------------------------------------------- MP Config Base Table Entries: -- Processor apic ID: 1, version: 17 CPU is usable, CPU is the bootstrap processor family: 6, model: 1, stepping: 7 feature flags: 0x0000fbff -- Processor apic ID: 0, version: 17 CPU is usable, CPU is NOT the bootstrap processor family: 6, model: 1, stepping: 7 feature flags: 0x0000fbff -- Bus bus ID: 0, bus type: ISA -- Bus bus ID: 1, bus type: PCI -- I/O APIC apic ID: 2, version: 17 APIC is usable apic address: 0xfec00000 -- I/O INT INT type: 3, flags: 0x0000 source bus ID: 0, IRQ: 0 destination APIC ID: 2, INT: 0 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 1 destination APIC ID: 2, INT: 1 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 0 destination APIC ID: 2, INT: 2 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 3 destination APIC ID: 2, INT: 3 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 4 destination APIC ID: 2, INT: 4 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 5 destination APIC ID: 2, INT: 5 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 6 destination APIC ID: 2, INT: 6 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 7 destination APIC ID: 2, INT: 7 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 8 destination APIC ID: 2, INT: 8 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 9 destination APIC ID: 2, INT: 9 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 10 destination APIC ID: 2, INT: 10 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 11 destination APIC ID: 2, INT: 11 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 12 destination APIC ID: 2, INT: 12 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 13 destination APIC ID: 2, INT: 13 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 14 destination APIC ID: 2, INT: 14 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 15 destination APIC ID: 2, INT: 15 -- I/O INT INT type: 0, flags: 0x000f source bus ID: 1, IRQ: 56 destination APIC ID: 2, INT: 16 -- I/O INT INT type: 0, flags: 0x000f source bus ID: 1, IRQ: 52 destination APIC ID: 2, INT: 17 -- I/O INT INT type: 0, flags: 0x000f source bus ID: 1, IRQ: 48 destination APIC ID: 2, INT: 18 -- I/O INT INT type: 0, flags: 0x000f source bus ID: 1, IRQ: 44 destination APIC ID: 2, INT: 19 -- I/O INT INT type: 2, flags: 0x0000 source bus ID: 0, IRQ: 0 destination APIC ID: 2, INT: 23 -- Local INT INT type: 3, flags: 0x0005 source bus ID: 0, IRQ: 0 destination APIC ID: 255, INT: 0 -- Local INT INT type: 1, flags: 0x0005 source bus ID: 0, IRQ: 0 destination APIC ID: 255, INT: 1 -------------------------------------------------------------------------- From owner-freebsd-smp Fri Sep 27 20:23:44 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA19906 for smp-outgoing; Fri, 27 Sep 1996 20:23:44 -0700 (PDT) Received: from friley10.res.iastate.edu (friley10.res.iastate.edu [129.186.78.10]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA19871 for ; Fri, 27 Sep 1996 20:23:41 -0700 (PDT) Received: from friley10.res.iastate.edu (loopback [127.0.0.1]) by friley10.res.iastate.edu (8.7.6/8.7.3) with ESMTP id WAA01286 for ; Fri, 27 Sep 1996 22:26:18 -0500 (CDT) Message-Id: <199609280326.WAA01286@friley10.res.iastate.edu> To: freebsd-smp@FreeBSD.ORG Subject: Adding a second CPU Date: Fri, 27 Sep 1996 22:26:18 -0500 From: "Ric Flinn" Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I currently have an ASUS dual pentium motherboard with one pentium 90 cpu. I would like to add a second cpu; what requirements does the second cpu have to meet to be compatible with the first? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Ric Flinn http://friley10.res.iastate.edu/~rmf rmf@iastate.edu I'm stuck in a parallel universe. Sucks to be me. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From owner-freebsd-smp Fri Sep 27 20:40:20 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA00612 for smp-outgoing; Fri, 27 Sep 1996 20:40:20 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id UAA00571 for ; Fri, 27 Sep 1996 20:40:16 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id UAA00517; Fri, 27 Sep 1996 20:39:25 -0700 From: Terry Lambert Message-Id: <199609280339.UAA00517@phaeton.artisoft.com> Subject: Re: Adding a second CPU To: rmf@friley10.res.iastate.edu (Ric Flinn) Date: Fri, 27 Sep 1996 20:39:25 -0700 (MST) Cc: freebsd-smp@FreeBSD.ORG In-Reply-To: <199609280326.WAA01286@friley10.res.iastate.edu> from "Ric Flinn" at Sep 27, 96 10:26:18 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 currently have an ASUS dual pentium motherboard with one pentium 90 cpu. > I would like to add a second cpu; what requirements does the second cpu > have to meet to be compatible with the first? WARNING: | Bill's problem, I think, is that he bought a dual-pentium motherboard... | and it turns out that the machine will only accept two processors if | they're both at the same stepping, and he can't run them at higher than | 120MHz (I think it was). When he bought the system, however, he asked | if he could just get a second processor, and they told him yes, even | though he was buying it with a 133MHz processor... It should probably be identical to the first processor. You should look at the Intel WWW site. Some Pentiums are not SMP capable. 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 Sep 27 22:38:40 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA09334 for smp-outgoing; Fri, 27 Sep 1996 22:38:40 -0700 (PDT) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [204.214.4.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA09293; Fri, 27 Sep 1996 22:38:36 -0700 (PDT) Received: from bonsai.hiwaay.net by fly.HiWAAY.net; (8.7.5/1.1.8.2/21Sep95-1003PM) id AAA16382; Sat, 28 Sep 1996 00:38:28 -0500 (CDT) Message-ID: <324CB998.773C2448@hiwaay.net> Date: Sat, 28 Sep 1996 00:37:28 -0500 From: Steve Price X-Mailer: Mozilla 2.02 (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: hackers@freebsd.org, freebsd-smp@freebsd.org Subject: NetBSD ==> FreeBSD make(1) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi all, I just spent the better part of a week merging in some pretty interesting stuff from NetBSD's make. Anybody that would like to help me flesh it out before I commit it can drop me a line and I will send it to you. I would've attached the patch, but it is about 4000 lines long and I didn't want to inundate those that don't want it. For those who do, I can send you a tarball or better yet if you have an account on freefall I can put a tarball in my home directory and you can retrieve it from there. BTW, I am about half way through a 'make world' now and it is chugging right along. :) After this it's off to ports-land to randomly compile some stuff and see what happens. Steve From owner-freebsd-smp Fri Sep 27 22:38:31 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA09224 for smp-outgoing; Fri, 27 Sep 1996 22:38:31 -0700 (PDT) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id WAA09163 for ; Fri, 27 Sep 1996 22:38:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id XAA07782; Fri, 27 Sep 1996 23:38:16 -0600 Message-Id: <199609280538.XAA07782@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: "J.M. Chuang" cc: FreeBSD-smp@freefall.freebsd.org Subject: Re: Tyan S1662 Titan Pro In-reply-to: Your message of "Sat, 28 Sep 1996 00:04:15 -0300." <199609280304.AAA22972@bluenose.na.tuns.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Sep 1996 23:38:15 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, >The system was up for about an hour. The file systems were gradually >messed up and the shared library libc.so.3.0 was damaged. Eventually, >the system dies. There were a lots of coredumps and segmentation faults >from running utilities such as perl, tcsh,... how long/well does it run the standard (non SMP) kernel? >Processor > apic ID: 1, version: 17 > CPU is usable, CPU is the bootstrap processor >Processor > apic ID: 0, version: 17 > CPU is usable, CPU is NOT the bootstrap processor here we have reverse ordering of the APIC IDs so the changes in test2 (or manually changing constants in several places) are definately necessary. > local APIC address: 0xfee00000 > I/O APIC > apic ID: 2, version: 17 > APIC is usable > apic address: 0xfec00000 both APIC addresses are standard, so that doesn't come into play. the real question is whether my changes are causing you problems. can you run this system for a while with the GENERIC kernel and see what happens? also, carefully look thru your BIOS to see what cache options you have. on another system we had to change from "write-back' to 'write-thru' you might try running with cache turned off to see if that stabalizes the system. >sysctl -w kern_smp.active=2 when you do this do you see a message about "SECOND CPU LAUNCHED" on the console? -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Fri Sep 27 23:03:17 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA28898 for smp-outgoing; Fri, 27 Sep 1996 23:03:17 -0700 (PDT) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA28833 for ; Fri, 27 Sep 1996 23:03:12 -0700 (PDT) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.7.6/8.7.3) with ESMTP id NAA17823; Sat, 28 Sep 1996 13:59:05 +0800 (WST) Message-Id: <199609280559.NAA17823@spinner.DIALix.COM> X-Mailer: exmh version 1.6.7 5/3/96 To: Terry Lambert cc: rmf@friley10.res.iastate.edu (Ric Flinn), freebsd-smp@FreeBSD.ORG Subject: Re: Adding a second CPU In-reply-to: Your message of "Fri, 27 Sep 1996 20:39:25 MST." <199609280339.UAA00517@phaeton.artisoft.com> Date: Sat, 28 Sep 1996 13:59:05 +0800 From: Peter Wemm Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Terry Lambert wrote: > > I currently have an ASUS dual pentium motherboard with one pentium 90 cpu. > > I would like to add a second cpu; what requirements does the second cpu > > have to meet to be compatible with the first? > > WARNING: > > | Bill's problem, I think, is that he bought a dual-pentium motherboard... > | and it turns out that the machine will only accept two processors if > | they're both at the same stepping, and he can't run them at higher than > | 120MHz (I think it was). When he bought the system, however, he asked > | if he could just get a second processor, and they told him yes, even > | though he was buying it with a 133MHz processor... On this note, if you're using an ASUS PCI/E-P54NP4 neptune based board, there is no programmable clock generator, just a 60MHz crystal that can be replaced with a 66MHz crystal if you want to go from 90MHZ to 100Mhz, or 120 to 133, etc. It will drive dual pentiums at 133Mhz quite happily, provided you can get a 66Mhz crystal and have a recent-enough flash bios update. (I use 0311-6, which fixes all my "hang-on-reboot" problems and supposedly supports 120/133Mhz) Cheers, -Peter From owner-freebsd-smp Sat Sep 28 01:11:33 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA28269 for smp-outgoing; Sat, 28 Sep 1996 01:11:33 -0700 (PDT) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.225.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id BAA28204 for ; Sat, 28 Sep 1996 01:11:26 -0700 (PDT) Received: from gilberto.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id KAA29534 for ; Sat, 28 Sep 1996 10:11:42 +0200 Received: (from kuku@localhost) by gilberto.physik.rwth-aachen.de (8.6.11/8.6.9) id KAA25068 for freebsd-smp@freebsd.org; Sat, 28 Sep 1996 10:18:02 +0200 Date: Sat, 28 Sep 1996 10:18:02 +0200 From: Christoph Kukulies Message-Id: <199609280818.KAA25068@gilberto.physik.rwth-aachen.de> To: freebsd-smp@freebsd.org Subject: NT an 4 processors Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Sorry for the subject - I know you are all working hard on FreeMSD SMP Someone here is praising NT and having it run on a 4 processor board. Is there some striking argument against doing multiprocessing under NT? My arguments are always: 1) NT doesn't have remote administrability (not telnet service) 2) NT doesn't have to plethora of tools like shells, networking tools. NFS, etc. 3) NT doesn't have the good support that a free OS has - for whatever reasons. 4) NT costs license fees to Bill Gates. Any more cons? pros: 1) NT was designed for SMP resp. is SMP capable out of the box. The wind is blowing into my face now here - It's getting harder to withstand all these arguments based on precalculations that NT will become the future OS even in the scientific computing world. Former VMS crews at CERN are already weaponing for taking over the computing world with NT. And I'm only waiting for the day when CERN says: "We are only developing under NT and our CERNlib is only maintained under NT". --Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-smp Sat Sep 28 08:05:53 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA12105 for smp-outgoing; Sat, 28 Sep 1996 08:05:53 -0700 (PDT) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [204.214.4.2]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA12075; Sat, 28 Sep 1996 08:05:49 -0700 (PDT) Received: from bonsai.hiwaay.net by fly.HiWAAY.net; (8.7.5/1.1.8.2/21Sep95-1003PM) id KAA13214; Sat, 28 Sep 1996 10:04:59 -0500 (CDT) Message-ID: <324D3E61.4A7B7C1D@hiwaay.net> Date: Sat, 28 Sep 1996 10:04:01 -0500 From: Steve Price X-Mailer: Mozilla 2.02 (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: hackers@freebsd.org, freebsd-smp@freebsd.org CC: bill@thuvia.qstools.com Subject: Re: NetBSD ==> FreeBSD make(1) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Here is a brief list of the changes to make(1). Add these directives: .ORDER ; control build order of targets .PARALLEL ; not fully implemented .PHONY ; always out of date target .WAIT ; more parallel-related stuff Add these command line arguments: -B ; set backward compatibility mode -m directory ; override the default system include path Also, tons of stuff to better support SunOS/SVSV-based machines, and scads of job-control related fixes/enhancements. Steve From owner-freebsd-smp Sat Sep 28 08:36:23 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA29806 for smp-outgoing; Sat, 28 Sep 1996 08:36:23 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA29755 for ; Sat, 28 Sep 1996 08:36:18 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.7.5/8.6.9) id KAA01191; Sat, 28 Sep 1996 10:35:38 -0500 (EST) From: "John S. Dyson" Message-Id: <199609281535.KAA01191@dyson.iquest.net> Subject: Re: NT an 4 processors To: kuku@gilberto.physik.rwth-aachen.de (Christoph Kukulies) Date: Sat, 28 Sep 1996 10:35:38 -0500 (EST) Cc: freebsd-smp@freebsd.org In-Reply-To: <199609280818.KAA25068@gilberto.physik.rwth-aachen.de> from "Christoph Kukulies" at Sep 28, 96 10:18:02 am Reply-To: dyson@freebsd.org X-Mailer: ELM [version 2.4 PL24 ME8] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Sorry for the subject - I know you are all working hard on FreeMSD SMP > Someone here is praising NT and having it run on a 4 processor board. > > Is there some striking argument against doing multiprocessing under NT? > > My arguments are always: > > 1) NT doesn't have remote administrability (not telnet service) > > 2) NT doesn't have to plethora of tools like shells, networking tools. > NFS, etc. > > 3) NT doesn't have the good support that a free OS has - for whatever reasons. > > 4) NT costs license fees to Bill Gates. > > Any more cons? > SMP doesn't help the problems with the NT VM system handling heavy loads. John From owner-freebsd-smp Sat Sep 28 08:46:57 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA06522 for smp-outgoing; Sat, 28 Sep 1996 08:46:57 -0700 (PDT) Received: from uno.sat.t.u-tokyo.ac.jp (uno.sat.t.u-tokyo.ac.jp [133.11.70.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA04865 for ; Sat, 28 Sep 1996 08:44:13 -0700 (PDT) Received: by uno.sat.t.u-tokyo.ac.jp (8.7.3+2.6Wbeta5/8.7.3) with ESMTP id AAA01959; Sun, 29 Sep 1996 00:43:05 +0900 (JST) To: freebsd-smp@freebsd.org Subject: Re: Tyan S1662 Titan Pro X-Mailer: Mew version 1.06 on Emacs 19.28.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sun, 29 Sep 1996 00:43:05 +0900 Message-ID: <1957.843925385@sat.t.u-tokyo.ac.jp> From: Hidetoshi Shimokawa Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, this is my first mail to freebsd-smp. I finally succeeded to run smp-kernel on Tyan S1662 Titan Pro yesterday. It needs some efforts to run stably. As you know, the main problem is that boot cpu id is not 0 but 1. I made some fixes against current smp code (no test1 or test2). - change CPUNBR in mpcore.c - stop cpu0 when smp is inactive in init_main.c - tsleep when boot() is called on cpu0 in kern_shutdown.c these changes are trivial, ad-hoc, and not generic. With only above changes, the kernel had difficuties to change smp_acitve value. It often causes problem in shutdown sequence. I don't know why, but while system is idle, processes is likely to run on cpu0. So boot() in kern_shutdown is usually called on cpu0 and it will do tsleep, but cpu1 never comes up. I guess if boot cpu id is 0, boot() is usually called on boot cpu and it doesn't matter at all. I looked into this problem and I found a potential bug in handing smp_atctive. Here is the code from init_main.c (I added BOOTCPU macro) if ((smp_active == 0) && (cpunumber() != BOOTCPU)) { get_mplock(); printf("cpu#%d freezing; mp_lock: %08x\n",cpunumber(), \ mp_lock); wakeup((caddr_t)&smp_active); rel_mplock(); .... this code is excuted when smp_active = 0, but when smp_active = 0, get_mplock does nothing :-( (look at MPgetlock in mplock.s). I think this causes the problem. my solution is.. - introduce new state smp_active=1, this means only boot cpu is allowed to run, and when boot() is called, smp_active is set to 1. smp_active is 0 only after booting up and once second cpu is lunched, smp_active should change among 1 and 2. I'm not familiar with kernel prgramming, MP and even assembler, I may be misunderstanding something. FYI, host: jp.freebsd.org Tyan S1662 Titan Pro 2 PentiumPro (256KB cache, 233MHz overclocking :-) To build SMP kernel with NetBSD make 168.004s real 238.468s user 70.809s system 184% pmake -j 6 Diffs, have a fun! *** i386/i386/mpcore.s.orig Thu Sep 12 11:40:59 1996 --- i386/i386/mpcore.s Fri Sep 27 02:02:33 1996 *************** *** 159,167 **** movsb ret - /* #define CPUNBR 0x00000000 - */ #ifndef CPUNBR #define CPUNBR 0x01000000 --- 159,165 ---- *** kern/init_main.c.orig Thu Sep 12 11:41:16 1996 --- kern/init_main.c Sat Sep 28 15:40:17 1996 *************** *** 719,731 **** rel_mplock(); while (1) { ! if (smp_active == 0 && cpunumber() != 0) { get_mplock(); printf("cpu#%d freezing; mp_lock: %08x\n", cpunumber(), mp_lock); wakeup((caddr_t)&smp_active); rel_mplock(); ! while (smp_active == 0) { __asm __volatile("" : : : "memory"); } get_mplock(); --- 719,732 ---- rel_mplock(); while (1) { ! #define BOOTCPU 1 ! if ((smp_active == 1) && (cpunumber() != BOOTCPU)) { get_mplock(); printf("cpu#%d freezing; mp_lock: %08x\n", cpunumber(), mp_lock); wakeup((caddr_t)&smp_active); rel_mplock(); ! while (smp_active < 2) { __asm __volatile("" : : : "memory"); } get_mplock(); *** kern/kern_shutdown.c.orig Thu Sep 12 11:41:17 1996 --- kern/kern_shutdown.c Fri Sep 27 22:50:38 1996 *************** *** 171,181 **** #ifdef SMP int c, spins; - smp_active = 0; spins = 100; printf("boot() called on cpu#%d\n", cpunumber()); ! while ((c = cpunumber()) != 0) { if (spins-- < 1) { printf("timeout waiting for cpu zero!\n"); break; --- 171,183 ---- #ifdef SMP int c, spins; spins = 100; + if (smp_active) smp_active = 1; + printf("boot() called on cpu#%d\n", cpunumber()); ! #define BOOTCPU 1 ! while ((c = cpunumber()) != BOOTCPU) { if (spins-- < 1) { printf("timeout waiting for cpu zero!\n"); break; /\ Hidetoshi Shimokawa \/ simokawa@sat.t.u-tokyo.ac.jp PGP public key: finger -l simokawa@sat.t.u-tokyo.ac.jp From owner-freebsd-smp Sat Sep 28 09:03:34 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA17258 for smp-outgoing; Sat, 28 Sep 1996 09:03:34 -0700 (PDT) Received: from spinner.DIALix.COM (root@spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA17209 for ; Sat, 28 Sep 1996 09:03:30 -0700 (PDT) Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.8.0/8.8.0) with ESMTP id AAA24915; Sun, 29 Sep 1996 00:02:48 +0800 (WST) Message-Id: <199609281602.AAA24915@spinner.DIALix.COM> X-Mailer: exmh version 1.6.7 5/3/96 To: Hidetoshi Shimokawa cc: freebsd-smp@freebsd.org Subject: Re: Tyan S1662 Titan Pro In-reply-to: Your message of "Sun, 29 Sep 1996 00:43:05 +0900." <1957.843925385@sat.t.u-tokyo.ac.jp> Date: Sun, 29 Sep 1996 00:02:47 +0800 From: Peter Wemm Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hidetoshi Shimokawa wrote: > Hi, this is my first mail to freebsd-smp. Welcome aboard! :-) > this code is excuted when smp_active = 0, but when smp_active = 0, > get_mplock does nothing :-( (look at MPgetlock in mplock.s). > I think this causes the problem. Aha!! That's probably it!! :-) > my solution is.. > - introduce new state smp_active=1, this means only boot cpu is > allowed to run, and when boot() is called, smp_active is set to 1. Sounds good to me. I'll have a shot at it now. Cheers, -Peter From owner-freebsd-smp Sat Sep 28 09:23:30 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA00217 for smp-outgoing; Sat, 28 Sep 1996 09:23:30 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA00173 for ; Sat, 28 Sep 1996 09:23:26 -0700 (PDT) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by who.cdrom.com (8.7.5/8.6.11) with SMTP id JAA15846 for ; Sat, 28 Sep 1996 09:21:52 -0700 (PDT) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA11956; Sat, 28 Sep 1996 12:20:02 -0400 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Sat, 28 Sep 1996 12:20 EDT Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.7.5/8.7.3) with ESMTP id IAA05830; Sat, 28 Sep 1996 08:42:24 -0400 (EDT) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id IAA02863; Sat, 28 Sep 1996 08:41:58 -0400 (EDT) Date: Sat, 28 Sep 1996 08:41:58 -0400 (EDT) From: Thomas David Rivers Message-Id: <199609281241.IAA02863@lakes.water.net> To: sprice@hiwaay.net, ponds!FreeBSD.org!freebsd-smp@ucbvax.Berkeley.EDU, ponds!FreeBSD.org!hackers@ucbvax.Berkeley.EDU Subject: Re: NetBSD ==> FreeBSD make(1) Content-Type: text Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Hi all, > > I just spent the better part of a week merging in some pretty > interesting stuff from NetBSD's make. Anybody that would like > to help me flesh it out before I commit it can drop me a line and > I will send it to you. I would've attached the patch, but it is > about 4000 lines long and I didn't want to inundate those that > don't want it. For those who do, I can send you a tarball or > better yet if you have an account on freefall I can put a tarball > in my home directory and you can retrieve it from there. > > BTW, I am about half way through a 'make world' now and it is > chugging right along. :) After this it's off to ports-land to > randomly compile some stuff and see what happens. > > Steve > Can you describe just what these "interesting" things are. I've seriously modifed make(1) to "automagically" handle RCS repositories, version selection rules, etc... (essentially the basis of a rather nice Configuration Management system.) So, I'd be interested in whatever changes you made... - Dave R. - From owner-freebsd-smp Sat Sep 28 10:10:50 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA24354 for smp-outgoing; Sat, 28 Sep 1996 10:10:50 -0700 (PDT) Received: from mail0.iij.ad.jp (root@mail0.iij.ad.jp [192.244.176.61]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA24320 for ; Sat, 28 Sep 1996 10:10:42 -0700 (PDT) Received: from uucp1.iij.ad.jp (uucp1.iij.ad.jp [192.244.176.73]) by mail0.iij.ad.jp (8.6.12+2.4W/3.3W9-MAIL) with ESMTP id CAA01847 for ; Sun, 29 Sep 1996 02:10:38 +0900 Received: (from uucp@localhost) by uucp1.iij.ad.jp (8.6.12+2.4W/3.3W9-UUCP) with UUCP id CAA18686 for FreeBSD-smp@freefall.freebsd.org; Sun, 29 Sep 1996 02:10:39 +0900 Received: by forusgw.forus.or.jp (8.6.12/1.0ForUs) id BAA03651; Sun, 29 Sep 1996 01:38:41 +0900 Received: (from uucp@localhost) by skuld.yggdrasil.forus.or.jp (8.7.5/3.3W9-skuld) with UUCP id AAA21364 for FreeBSD-smp@freefall.freebsd.org; Sun, 29 Sep 1996 00:57:05 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by urd.yggdrasil.forus.or.jp (8.7.5/3.3W9-urd) with SMTP id BAA25131 for ; Sun, 29 Sep 1996 01:01:20 +0900 (JST) Message-Id: <199609281601.BAA25131@urd.yggdrasil.forus.or.jp> X-Authentication-Warning: urd.yggdrasil.forus.or.jp: Host localhost [127.0.0.1] didn't use HELO protocol To: FreeBSD-smp@freefall.freebsd.org Subject: Tyan S1562D Tomcat2 Date: Sun, 29 Sep 1996 01:01:20 +0900 From: ODA Kazutoshi Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hello, My system configuration is Tyan S1562D Tomcat2 + 2 P54C/100, supped FreeBSD-current + FreeBSD-SMP + test2. After sysctl launched second CPU, I tested kernel make. > =========> SECOND CPU LAUNCHED!! <========= > cpunumber=1 mp_lock=1000001 It work fine about ten minutes, and ld got signal 11. Following make cause signal immediately. > pid 6177 (ld), uid 0: exited on signal 11 (core dumped) And I carelessly edited /etc/make.conf!, saving file destroyed /etc/{daily,ttys} on vi. > bad block 3145728, ino 3979 > uid 0 on /: bad block > bad block 6291456, ino 3979 > uid 0 on /: bad block The following is shown at shutdown, and freeze. > boot() called on cpu#1 > oops, I'm on cpu#1, I need to be on zero! > cpu#1 freezing; mp_lock: 01000001 mptable shown: Warning: EBDA support is BROKEN!!! -------------------------------------------------------------------------- Found MP Table in BIOS, physical addr: 0x000f0c80 -------------------------------------------------------------------------- MP Floating Pointer Structure: location: BIOS physical address: 0x000f0c80 signature: '_MP_' length: 16 bytes version: 1.1 checksum: 0xf4 mode: Virtual Wire -------------------------------------------------------------------------- MP Config Table Header: physical address: 0x000f0c94 signature: 'PCMP' base table length: 292 version: 1.1 checksum: 0xa5 OEM ID: 'OEM00000' Product ID: 'PROD00000000' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 28 local APIC address: 0xfee00000 extended table length: 0 extended table checksum: 0 -------------------------------------------------------------------------- MP Config Base Table Entries: -- Processor apic ID: 0, version: 17 CPU is usable, CPU is the bootstrap processor family: 5, model: 2, stepping: 1 feature flags: 0x000007bf -- Processor apic ID: 1, version: 17 CPU is usable, CPU is NOT the bootstrap processor family: 5, model: 2, stepping: 1 feature flags: 0x000007bf -- Bus bus ID: 0, bus type: ISA -- Bus bus ID: 1, bus type: PCI -- I/O APIC apic ID: 2, version: 17 APIC is usable apic address: 0xfec00000 -- I/O INT INT type: 3, flags: 0x0000 source bus ID: 0, IRQ: 0 destination APIC ID: 2, INT: 0 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 1 destination APIC ID: 2, INT: 1 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 0 destination APIC ID: 2, INT: 2 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 3 destination APIC ID: 2, INT: 3 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 4 destination APIC ID: 2, INT: 4 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 5 destination APIC ID: 2, INT: 5 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 6 destination APIC ID: 2, INT: 6 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 7 destination APIC ID: 2, INT: 7 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 8 destination APIC ID: 2, INT: 8 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 9 destination APIC ID: 2, INT: 9 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 10 destination APIC ID: 2, INT: 10 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 11 destination APIC ID: 2, INT: 11 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 12 destination APIC ID: 2, INT: 12 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 13 destination APIC ID: 2, INT: 13 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 14 destination APIC ID: 2, INT: 14 -- I/O INT INT type: 0, flags: 0x0000 source bus ID: 0, IRQ: 15 destination APIC ID: 2, INT: 15 -- I/O INT INT type: 0, flags: 0x000f source bus ID: 1, IRQ: 80 destination APIC ID: 2, INT: 16 -- I/O INT INT type: 0, flags: 0x000f source bus ID: 1, IRQ: 76 destination APIC ID: 2, INT: 17 -- I/O INT INT type: 0, flags: 0x000f source bus ID: 1, IRQ: 72 destination APIC ID: 2, INT: 18 -- I/O INT INT type: 0, flags: 0x000f source bus ID: 1, IRQ: 68 destination APIC ID: 2, INT: 19 -- I/O INT INT type: 2, flags: 0x0000 source bus ID: 0, IRQ: 0 destination APIC ID: 2, INT: 23 -- Local INT INT type: 3, flags: 0x0005 source bus ID: 0, IRQ: 0 destination APIC ID: 255, INT: 0 -- Local INT INT type: 1, flags: 0x0005 source bus ID: 0, IRQ: 0 destination APIC ID: 255, INT: 1 -------------------------------------------------------------------------- -- ODA, Kazutoshi okaz@yggdrasil.forus.or.jp From owner-freebsd-smp Sat Sep 28 10:50:38 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA25730 for smp-outgoing; Sat, 28 Sep 1996 10:50:38 -0700 (PDT) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA25671 for ; Sat, 28 Sep 1996 10:50:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id LAA13295; Sat, 28 Sep 1996 11:50:23 -0600 Message-Id: <199609281750.LAA13295@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: ODA Kazutoshi cc: FreeBSD-smp@freefall.freebsd.org Subject: Re: Tyan S1562D Tomcat2 In-reply-to: Your message of "Sun, 29 Sep 1996 01:01:20 +0900." <199609281601.BAA25131@urd.yggdrasil.forus.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 28 Sep 1996 11:50:22 -0600 Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, >My system configuration is > Tyan S1562D Tomcat2 + 2 P54C/100, > supped FreeBSD-current + FreeBSD-SMP + test2. > >After sysctl launched second CPU, I tested kernel make. >> =========> SECOND CPU LAUNCHED!! <========= >> cpunumber=1 mp_lock=1000001 > >It work fine about ten minutes, and ld got signal 11. looking at the mp table output you sent it appears that the kernel should work for you without applying test[123]. Please try it that way: FreeBSD-current + FreeBSD-SMP and report how it works. test2 has already been reported to work on a Tomcat II, but with an earlier -current. I need to determine if its the latest -current or test2. thanx in advance, -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Sat Sep 28 11:25:01 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA23394 for smp-outgoing; Sat, 28 Sep 1996 11:25:01 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA23368 for ; Sat, 28 Sep 1996 11:24:59 -0700 (PDT) Received: from uno.sat.t.u-tokyo.ac.jp (uno.sat.t.u-tokyo.ac.jp [133.11.70.160]) by who.cdrom.com (8.7.5/8.6.11) with ESMTP id LAA16002 for ; Sat, 28 Sep 1996 11:20:01 -0700 (PDT) Received: by uno.sat.t.u-tokyo.ac.jp (8.7.3+2.6Wbeta5/8.7.3) with ESMTP id CAA04174; Sun, 29 Sep 1996 02:44:19 +0900 (JST) To: freebsd-smp@freebsd.org Subject: Re: Tyan S1562D Tomcat2 X-Mailer: Mew version 1.06 on Emacs 19.28.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sun, 29 Sep 1996 02:44:18 +0900 Message-ID: <4172.843932658@sat.t.u-tokyo.ac.jp> From: Hidetoshi Shimokawa Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, okaz> My system configuration is okaz> Tyan S1562D Tomcat2 + 2 P54C/100, okaz> supped FreeBSD-current + FreeBSD-SMP + test2. okaz> okaz> After sysctl launched second CPU, I tested kernel make. okaz> > =========> SECOND CPU LAUNCHED!! <========= okaz> > cpunumber=1 mp_lock=1000001 okaz> okaz> It work fine about ten minutes, and ld got signal 11. okaz> Following make cause signal immediately. okaz> > pid 6177 (ld), uid 0: exited on signal 11 (core dumped) I haven't seen this problem on my Titan Pro. It seems test2's problem, Steve? Steve put test3 on his page. I'll try it tomorrow. okaz> The following is shown at shutdown, and freeze. okaz> > boot() called on cpu#1 okaz> > oops, I'm on cpu#1, I need to be on zero! okaz> > cpu#1 freezing; mp_lock: 01000001 This can be fixed by my patch against init_main.c and kern_shutdown.c. take care to set BOOTCPU macro. /\ Hidetoshi Shimokawa \/ simokawa@sat.t.u-tokyo.ac.jp PGP public key: finger -l simokawa@sat.t.u-tokyo.ac.jp From owner-freebsd-smp Sat Sep 28 12:01:07 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA22115 for smp-outgoing; Sat, 28 Sep 1996 12:01:07 -0700 (PDT) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA21980 for ; Sat, 28 Sep 1996 12:00:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id NAA13635; Sat, 28 Sep 1996 13:00:53 -0600 Message-Id: <199609281900.NAA13635@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: freebsd-smp@freebsd.org cc: Hidetoshi Shimokawa Subject: Re: Tyan S1562D Tomcat2 In-reply-to: Your message of "Sun, 29 Sep 1996 02:44:18 +0900." <4172.843932658@sat.t.u-tokyo.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 28 Sep 1996 13:00:53 -0600 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, >I haven't seen this problem on my Titan Pro. >It seems test2's problem, Steve? >Steve put test3 on his page. I'll try it tomorrow. thats the question b4 the house. what I need is for people to: 1: run the base SMP kernel, ie no testxxx code applied. 2: run the same kernel, but with test3 applied. Note that after adding the test3 files you MUST: "config ; cd ../../;make depend && make && make install 3: let me know what works and what doesn't tia... -- Steve Passe | powered by smp@csn.net | FreeBSD From owner-freebsd-smp Sat Sep 28 12:30:12 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA15987 for smp-outgoing; Sat, 28 Sep 1996 12:30:12 -0700 (PDT) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA15961 for ; Sat, 28 Sep 1996 12:30:09 -0700 (PDT) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id VAA24025 for smp@FreeBSD.ORG; Sat, 28 Sep 1996 21:15:56 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by klemm.gtn.com (8.7.6/8.7.3) with SMTP id VAA07488 for ; Sat, 28 Sep 1996 21:22:54 +0200 (MET DST) Date: Sat, 28 Sep 1996 21:22:54 +0200 (MET DST) From: Andreas Klemm To: smp@FreeBSD.ORG Subject: Re: Welcome to freebsd-smp In-Reply-To: <199609281658.JAA18095@freefall.freebsd.org> Message-ID: X-try-apsfilter: ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz X-Fax: +49 2137 2018 X-Phone: +49 2137 2020 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 28 Sep 1996 Majordomo@FreeBSD.ORG wrote: > Welcome to the freebsd-smp mailing list! [...] > To get the code, you need a supfile entry something like this: > > src-sys release=smp host=sup.FreeBSD.org hostbase=/home base=/home/smp \ > prefix=/home/smp delete old use-rel-suffix Is there a possibility to get the cvs files via cvsup, as well ?! I'm asking, because I already get the "current's" cvs repository for src and ports via cvsup. Would be fine, to get the smp stuff the same way... -- andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.de pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< From owner-freebsd-smp Sat Sep 28 13:08:42 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA14930 for smp-outgoing; Sat, 28 Sep 1996 13:08:42 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA14895 for ; Sat, 28 Sep 1996 13:08:37 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA03204; Sat, 28 Sep 1996 13:07:12 -0700 From: Terry Lambert Message-Id: <199609282007.NAA03204@phaeton.artisoft.com> Subject: Re: NT an 4 processors To: kuku@gilberto.physik.rwth-aachen.de (Christoph Kukulies) Date: Sat, 28 Sep 1996 13:07:12 -0700 (MST) Cc: freebsd-smp@freebsd.org In-Reply-To: <199609280818.KAA25068@gilberto.physik.rwth-aachen.de> from "Christoph Kukulies" at Sep 28, 96 10:18:02 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 > Sorry for the subject - I know you are all working hard on FreeMSD SMP > Someone here is praising NT and having it run on a 4 processor board. > > Is there some striking argument against doing multiprocessing under NT? > > My arguments are always: > > 1) NT doesn't have remote administrability (not telnet service) > > 2) NT doesn't have to plethora of tools like shells, networking tools. > NFS, etc. > > 3) NT doesn't have the good support that a free OS has - for whatever reasons. > > 4) NT costs license fees to Bill Gates. > > Any more cons? The ActiveX Template Library (ATL) and other developement tools under NT do not support the "free threading" model necessary to take advantage of the extra processors. Microsoft threading models: o Single threaded Only one thread may enter the COM server o Apartment model Multiple threads per serve, but only one object per thread; thread is dedicated o Rental model [available as Alpha software to Microsoft partners ] [model used by "Viper" framework, which has not yet been deployed] Objects are still non-reentrant -- multiple threads per server, multiple threads per object, but Viper framework must be used to maintain state and lock entrancy. o Free threading [ available if you disassemble Microsoft code and write your code in assembly as well (questionable legality) ] Multiple threads, object multiply entrant -- this is "good" threading. Curently supported only for hand-crafted code, generally in assembly language. DAO (Data Access Objects) are not thread reeentrant (read the VC++ 4.2 documentation on MFC for DAO and other objects). It is impossible to produce an ActiveX container object unless you are Microsoft (In the online documentation in VC++ 4.2, search for "ActiveX", and note the last two sentences of the second paragraph of the first query hit you get back). Therefore, if you are a software company, you can produce plug-in modules for Microsoft software, but can't plug modules (ActiveX/COM servers) into your own software. Congradulations, you are now a second source value added software house for Microsoft. > pros: > > 1) NT was designed for SMP resp. is SMP capable out of the box. It's SMP capable out of the box, anyway. The scheduler design is questionably serializing. > The wind is blowing into my face now here - It's getting > harder to withstand all these arguments based on precalculations > that NT will become the future OS even in the scientific computing > world. Former VMS crews at CERN are already weaponing for taking over > the computing world with NT. And I'm only waiting for the day when > CERN says: "We are only developing under NT and our CERNlib is > only maintained under NT". NT Workstation will certainly replace Window 95 in 2-3 years, tops. However, there are severe licensing restrictions on use of NT Workstation for providing services, and the NT Server software is prohibitively expensive. 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 Sep 28 15:22:11 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA27000 for smp-outgoing; Sat, 28 Sep 1996 15:22:11 -0700 (PDT) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA26049 for ; Sat, 28 Sep 1996 15:20:34 -0700 (PDT) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA24349; Sat, 28 Sep 1996 18:20:02 -0400 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Sat, 28 Sep 1996 18:20 EDT Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.7.5/8.7.3) with ESMTP id QAA12247; Sat, 28 Sep 1996 16:51:18 -0400 (EDT) Received: (from rivers@localhost) by lakes.water.net (8.7.5/8.6.9) id QAA03444; Sat, 28 Sep 1996 16:50:53 -0400 (EDT) Date: Sat, 28 Sep 1996 16:50:53 -0400 (EDT) From: Thomas David Rivers Message-Id: <199609282050.QAA03444@lakes.water.net> To: sprice@hiwaay.net, ponds!freebsd.org!freebsd-smp, ponds!freebsd.org!hackers Subject: Re: NetBSD ==> FreeBSD make(1) Cc: ponds!thuvia.qstools.com!bill Content-Type: text Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Here is a brief list of the changes to make(1). > > Add these directives: > > .ORDER ; control build order of targets > .PARALLEL ; not fully implemented > .PHONY ; always out of date target > .WAIT ; more parallel-related stuff > > Add these command line arguments: > > -B ; set backward compatibility mode > -m directory ; override the default system include path > > Also, tons of stuff to better support SunOS/SVSV-based machines, > and scads of job-control related fixes/enhancements. > > Steve > I'd be interested in your job-control related fixes - I've just started that task myself (porting our Make to HP/UX 9.05), so I'd rather not re-invent the wheel... :-) - Thanks - - Dave R. - From owner-freebsd-smp Sat Sep 28 23:57:31 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA01841 for smp-outgoing; Sat, 28 Sep 1996 23:57:31 -0700 (PDT) Received: (from peter@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA01762 for freebsd-smp; Sat, 28 Sep 1996 23:57:27 -0700 (PDT) Date: Sat, 28 Sep 1996 23:57:27 -0700 (PDT) From: Peter Wemm Message-Id: <199609290657.XAA01762@freefall.freebsd.org> To: freebsd-smp Subject: cvs commit: CVSROOT avail Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk peter 96/09/28 23:57:25 Modified: . avail Log: oops, forgot to resync this file with the main repository's avail list Revision Changes Path 1.2 +11 -2 CVSROOT/avail