From owner-freebsd-smp Sat Feb 1 09:55:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA02027 for smp-outgoing; Sat, 1 Feb 1997 09:55:26 -0800 (PST) Received: from clem.systemsix.com (clem.systemsix.com [198.99.86.131]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA02022 for ; Sat, 1 Feb 1997 09:55:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by clem.systemsix.com (8.6.12/8.6.12) with SMTP id KAA02973; Sat, 1 Feb 1997 10:52:13 -0700 Message-Id: <199702011752.KAA02973@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: "John D. Smerdon" cc: smp@freebsd.org Subject: Re: Tyan Tomcat II SMP video problems In-reply-to: Your message of "Sat, 01 Feb 1997 11:57:44 EST." <3.0.32.19970201115741.00ad4210@smerdon.livonia.mi.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 01 Feb 1997 10:52:13 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, >I tried rebuilding kernels several times with no luck. I then compiled a >kernel without APIC_IO and the system booted without any problems. did you also have: options SMP_INVLTLB set when using APIC_IO? this is MANDATORY (but ONLY with APIC_IO). --- >Entering `sysctl -w smp_active=2` worked, but entering `ps aux` causes panic: > ><...> >current process = 5 (cpuidle0) >trapnumber = 29 >panic (cpu#0) Unknown/Reserved Trap this smells like hardware to me. I believe this board is the one that had a problem with its cache module. The solution (if your board is indeed affected) is to replace the cache module with a "good" one. whether that means "any new one" or a specific model made by tyan to fix the problem I have no idea. You will have to turn to the tyan mail list (or tyan) for that answer. you might try running with the external cache disabled in the BIOS if thats possible (just to test the theory, wouldn't be an acceptable long term solution). All this is just a theory, I could easily be barking up the wrong tree... --- >Searching through old SMP mail archives, I saw a message from Hidetoshi >Shimokawa (Sep 29, 1996) where he was having problems with another Tyan >board where the boot CPU was not #0. He had patches to some initialization >code and termination code that made sure the correct CPU is doing the init >and termination. This is not in the current sources. Any chance this is >related? no, we are past those issues in the current code. there is a table mapping physical CPU numbers to virtual numbers, insuring that the right one is selected. --- >mptable with and without APIC_IO is below. the only thing that jumps out is having ep0 on IRQ15, try to keep everything off of 14 & 15. -- Steve Passe | powered by smp@csn.net | FreeBSD