From owner-freebsd-sparc64@FreeBSD.ORG Mon Mar 15 23:16:00 2004 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77E9416A4CE for ; Mon, 15 Mar 2004 23:16:00 -0800 (PST) Received: from electra.cse.Buffalo.EDU (electra.cse.Buffalo.EDU [128.205.32.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FCCD43D3F for ; Mon, 15 Mar 2004 23:16:00 -0800 (PST) (envelope-from kensmith@cse.Buffalo.EDU) Received: from electra.cse.Buffalo.EDU (kensmith@localhost [127.0.0.1]) i2G7Fx2Z017214; Tue, 16 Mar 2004 02:15:59 -0500 (EST) Received: (from kensmith@localhost) by electra.cse.Buffalo.EDU (8.12.10/8.12.9/Submit) id i2G7FxbH017213; Tue, 16 Mar 2004 02:15:59 -0500 (EST) Date: Tue, 16 Mar 2004 02:15:59 -0500 From: Ken Smith To: Marcel Moolenaar Message-ID: <20040316071558.GA17054@electra.cse.Buffalo.EDU> References: <20040316055650.GA15182@electra.cse.Buffalo.EDU> <20040316064541.GA12961@dhcp01.pn.xcllnt.net> <20040316070004.GA16684@electra.cse.Buffalo.EDU> <20040316070937.GA13045@dhcp01.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040316070937.GA13045@dhcp01.pn.xcllnt.net> User-Agent: Mutt/1.4.1i cc: Ken Smith cc: freebsd-sparc64@freebsd.org Subject: Re: Console patch part II... X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2004 07:16:00 -0000 On Mon, Mar 15, 2004 at 11:09:37PM -0800, Marcel Moolenaar wrote: > Where is the problem exactly? Is it syscons again (like on alpha)? It's the same problem as on alpha. See sys/sparc64/sparc64/machdep.c and search for where cninit() gets called. As far as I can tell that needs to be moved to after mutex_init(), or at least to after where the proc0 info gets set up. There are a *ton* of potential calls to panic() between where cninit() is now and where it "should" be moved to. I tried moving just the setup of proc0 stuff and the section after it that talks about the per-cpu pages to above where cninit() is now to see if I could get away without moving cninit() but that didn't work. Quite a bit of stuff that happens after where cninit() is now looks like it effects the stuff I think needs to appear before cninit()... -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel |