Date: Sat, 6 Oct 2007 02:22:30 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-sparc64@freebsd.org Cc: Marius Strobl <marius@alchemy.franken.de> Subject: Re: 7.0 broken on e4500 Message-ID: <200710060222.31023.jhb@freebsd.org> In-Reply-To: <20071003132944.GA17342@alchemy.franken.de> References: <46FEADFD.8020105@FreeBSD.org> <20071003132944.GA17342@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200710060222.31023.jhb>