From owner-freebsd-smp Sat Nov 16 18:31:00 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA16318 for smp-outgoing; Sat, 16 Nov 1996 18:31:00 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id SAA16289 for ; Sat, 16 Nov 1996 18:30:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id TAA00833; Sat, 16 Nov 1996 19:30:13 -0700 Message-Id: <199611170230.TAA00833@clem.systemsix.com> X-Authentication-Warning: clem.systemsix.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 From: Steve Passe To: Erich Boleyn cc: smp@FreeBSD.org Subject: Re: Can test again... In-reply-to: Your message of "Sat, 16 Nov 1996 17:33:44 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 16 Nov 1996 19:30:13 -0700 Sender: owner-smp@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Hi, >I grabbed the SMP tree, and have been hacking on it a bit. > >What I've noticed so far are: > > -- mptable-2.0.2.c AND the kernel : Both do the MPS floating pointer > probe wrong. They are searching on 4-byte boundaries (it should > be 16-byte boundaries), and search too many areas. This caused > my test machine to not be recognized correctly. > > The proper probe sequence is to search (again, on 16-byte > boundaries): > > If you find it anywhere else, it might be a false report (as > mentioned, it did on my test box). You may be right about the 16-byte boundaries, I'll think about that a little. mptable purposely searches areas it shouldn't. Unfortunately there is the MP spec, and there is the way various manufactures have implimented it. I would have to review my collection of mptable outputs to verify that it can indeed be that strict in search areas. This is the 1st report of a found "false" area, usual problem is not finding it at all. Please give me info about: what board are you using? which area was probed, finding a "false" MP fps? --- > -- If you have more than NCPU cpus it dies instead of just ignoring > the other CPUs. are you saying that when you set NCPU==2, but there are 3/4 actual CPUs that this happens? > -- If NCPU is greater than 2, then it dies trying to activate the > 3rd CPU. is this a restatement of the previous statement? It is known that 3/4 CPUs are not supported. Peter was last working on that, I'm not sure what the current status is... --- > I've hacked it so that can only activate 2 CPUs, and that seems to work for the moment. send the patch when you can. also please send your mptable output: mptable -verbose -dmesg --- > I'll try out the IO APIC stuff and see about getting EISA interrupts. any insight here would be most appreciated! -- Steve Passe | powered by smp@csn.net | FreeBSD