From owner-freebsd-sparc64@FreeBSD.ORG Sat Oct 6 06:23:42 2007 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30A4516A418; Sat, 6 Oct 2007 06:23:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id C53EC13C46A; Sat, 6 Oct 2007 06:23:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8p) with ESMTP id 213150321-1834499 for multiple; Sat, 06 Oct 2007 02:23:55 -0400 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l966NclQ060866; Sat, 6 Oct 2007 02:23:38 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-sparc64@freebsd.org Date: Sat, 6 Oct 2007 02:22:30 -0400 User-Agent: KMail/1.9.6 References: <46FEADFD.8020105@FreeBSD.org> <20071003132944.GA17342@alchemy.franken.de> In-Reply-To: <20071003132944.GA17342@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200710060222.31023.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Sat, 06 Oct 2007 02:23:38 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/4482/Fri Oct 5 18:43:49 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Marius Strobl Subject: Re: 7.0 broken on e4500 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2007 06:23:42 -0000 On Wednesday 03 October 2007 09:29:44 am Marius Strobl wrote: > On Sat, Sep 29, 2007 at 09:56:45PM +0200, Kris Kennaway wrote: > > I get this early during boot with a CVS kernel (updated from last December): > > > > > FreeBSD/SMP: Multiprocessor System Detected: 10 CPUs > > > panic: tsb_tte_enter: replacing valid kernel mapping > > > cpuid = 0 > > > KDB: enter: panic > > > [thread pid 0 tid 0 ] > > > Stopped at kdb_enter+0x68: ta %xcc, 1 > > > db> wh > > > Tracing pid 0 tid 0 td 0xc0744f80 > > > panic() at panic+0x204 > > > tsb_tte_enter() at tsb_tte_enter+0xdc > > > pmap_enter_locked() at pmap_enter_locked+0x2d0 > > > pmap_enter() at pmap_enter+0x64 > > > kmem_malloc() at kmem_malloc+0x6e0 > > > page_alloc() at page_alloc+0x28 > > > uma_large_malloc() at uma_large_malloc+0x44 > > > malloc() at malloc+0x1b0 > > > sf_buf_init() at sf_buf_init+0xf8 > > > mi_startup() at mi_startup+0x18c > > > btext() at btext+0x34 > > > > Do you by chance load the new kernel manually via the loader > prompt, with the old kernel being <= 8MB in size and the new > one > 8MB? I get this panic on an E220R at work, but my "new" kernel is smaller. > ll /boot/kernel/kernel* /boot/test/kernel* -r-xr-xr-x 1 root wheel 7821094 Feb 6 2007 /boot/kernel/kernel -r-xr-xr-x 1 root wheel 13902501 Feb 6 2007 /boot/kernel/kernel.symbols -r-xr-xr-x 1 root wheel 4534968 Oct 6 00:20 /boot/test/kernel -r-xr-xr-x 1 root wheel 10101980 Oct 6 00:20 /boot/test/kernel.symbols The working kernel (~7MB) is the GENERIC kernel, and the "test" kernel is the stripped down kernel for this machine. In my case I'm panicing in pmap_remove_tte() called from pmap_enter_locked(). I added some KTR traces to the pmap code to try and investigate, but I'm guessing the root problem is that the loader doesn't properly handle telling OFW about needing to change the mappings when unloading and then loading a new kernel? Hmm, it looks like currently the loader doesn't do any sort of MD callback when unloading a file, so the loader isn't going to free up the RAM it asked for from OFW for the old kernel. -- John Baldwin