From owner-freebsd-alpha@FreeBSD.ORG Fri Feb 27 07:00:57 2004 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF3AF16A4CE; Fri, 27 Feb 2004 07:00:57 -0800 (PST) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25E0143D1D; Fri, 27 Feb 2004 07:00:55 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])i1RF0m5O014140; Sat, 28 Feb 2004 02:00:48 +1100 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i1RF0jch003096; Sat, 28 Feb 2004 02:00:46 +1100 Date: Sat, 28 Feb 2004 02:00:44 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Ken Smith In-Reply-To: <20040227041147.GC26920@electra.cse.Buffalo.EDU> Message-ID: <20040228010638.F2867@gamplex.bde.org> References: <20040227041147.GC26920@electra.cse.Buffalo.EDU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: freebsd-alpha@freebsd.org Subject: Re: Recent problems with -current on alpha... X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2004 15:00:58 -0000 On Thu, 26 Feb 2004, Ken Smith wrote: > With lots of help from Andrew Gallatin and Marcel Moolenaar I think I've > located the problem with -current on alpha and I have a very rough > patch that gets the cluster's Alpha reference machine to the point > it boots and runs. In a nutshell the promcons stuff used to allow > debugging info to be printed to the console from a very early point > in the boot doesn't work any more. Things like make_dev() require > the machine to have progressed to the point that more of the VM > system is functional than before (this seems to have begun with the > device megapatches). make_dev() doesn't need vm for the first DEVT_STASH (default 50) allocations. syscons console initialization depends on this. The unlogged reason that rev.1.412 of syscons.c didn't work is that it was committed before make_dev() could handle it, so the system crashed early iff syscons was the console. Perhaps the promcons initialization is even earlier than i386 console initialization. I'm not familiar with it, but it is hard for it to be much earlier -- i386 console initialization is done in the first C function called from locore. Another thing that can cause problems is using printf() before the console has been initialized. I hade a printf() in make_dev(). When syscons started calling make_dev() early, this printf() caused much the same crash as rev.1.412 of syscons.c. Hmm, it was actually the same crash. Both crashes were cause by a printf() in make_dev(), and both were fixed by removing the printf(). In -current, the removal was in rev.1.139 of kern_conf.c. > My patch moves the initialization of the promcons stuff until after > the VM system is initialzed and comments out all the printf()'s I > could find that might have happened before the console is initialized. This would break use of ddb until after the vm system is initialized (unless it is already broken). i386 console initialization tries hard to initiatialize the console as early as possible so that it can be used for debugging. This is less needed with gdb, but early printfs still need a console. The make_dev() line in promcons.c was last changed in Y2K, so it console initialization is apparently already done late for alphas (which is OK iff the firmware console is used early). The problem might be simply a stray printf done early. Try avoiding such printfs, and this works then debug why early printfs cause crashes. They should just go to a buffer that gets printed later, or at least get counter so that they can be warned about later. The buffer can't be the message buffer, since the message buffer is not initialized until later, at least on i386's. printf already takes care not to use a nonexistent message buffer but doesn't take care to warn about dropped messages. Bruce