From owner-freebsd-current@FreeBSD.ORG Tue Jul 22 20:41:41 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E57A137B401 for ; Tue, 22 Jul 2003 20:41:41 -0700 (PDT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64CFC43F75 for ; Tue, 22 Jul 2003 20:41:41 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) h6N3ffh5045369; Tue, 22 Jul 2003 20:41:41 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)h6N3feco045368; Tue, 22 Jul 2003 20:41:40 -0700 (PDT) Date: Tue, 22 Jul 2003 20:41:40 -0700 From: Steve Kargl To: John Reynolds Message-ID: <20030723034140.GA45356@troutmask.apl.washington.edu> References: <16157.34349.242563.217496@dolphin.home-net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16157.34349.242563.217496@dolphin.home-net> User-Agent: Mutt/1.4.1i cc: current@freebsd.org Subject: Re: should new-gcc kernels with -CURRENT still be panic()'ing right at boot? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2003 03:41:42 -0000 On Tue, Jul 22, 2003 at 06:45:01PM +0000, John Reynolds wrote: > Hi all, when the new gcc was imported I spotted a thread saying that the new > kernels *immediately* panicked (trap 12) upon booting. I too saw the same > behavior after a successful buildworld/buildkernel (with a config file > previously working just fine with 5.1-R sources). > > Has this been fixed? Can people build working kernels on i386? I've built several kernels without a problem. You need to (1) post the exact panic message, (2) read the section of the Handbook on debugging kernel panics, and (3) provide a backtrace. -- Steve