Date: Sun, 4 Nov 2007 23:46:18 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: Kris Kennaway <kris@FreeBSD.org> Cc: freebsd-sparc64@FreeBSD.org, John Baldwin <jhb@FreeBSD.org> Subject: Re: 7.0 broken on e4500 Message-ID: <20071104224618.GD36824@alchemy.franken.de> In-Reply-To: <472E4573.3090708@FreeBSD.org> References: <46FEADFD.8020105@FreeBSD.org> <20071003132944.GA17342@alchemy.franken.de> <200710060222.31023.jhb@freebsd.org> <20071006132620.GF24840@alchemy.franken.de> <472DFC18.3080000@FreeBSD.org> <472E4573.3090708@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Nov 04, 2007 at 11:19:31PM +0100, Kris Kennaway wrote: > Kris Kennaway wrote: > >Marius Strobl wrote: > >>On Sat, Oct 06, 2007 at 02:22:30AM -0400, John Baldwin wrote: > >>>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. > >>> > >> > >>If the actual panic string is "vm_phys_paddr_to_vm_page: paddr <foo> > >>is not in any segment" than that's the problem I had in mind when > >>replying to Kris but unfortunately failed to describe the right > >>way around. > >> > >>>>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. > >>> > >> > >>Correct, the immediate problem (which I had a patch for somewhere) > >>is that in case the "old" kernel required more TLB slots to be used > >>than the "new" one one can't use the kernel end in order to determine > >>how many slots are used for the kernel map. As you describe the real > >>problem lies within the loader though. The funny thing is that no > >>arch except sparc64 and sun4v seems to rely on the kernel end > >>provided by the loader. > >>If no idea what's the cause of the problem Kris is seeing though. > >> > >>Marius > >> > >> > > > >FYI one of the e4500's is now booting again but another is still failing > >with the same panic: > > > >FreeBSD 8.0-CURRENT #44: Mon Nov 5 01:52:42 JST 2007 > > root@e4500-2.allbsd.org:/usr/src/sys/sparc64/compile/E4500_2 > >real memory = 9663676416 (9216 MB) > >avail memory = 9433554944 (8996 MB) > >cpu0: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >cpu1: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >cpu2: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >cpu3: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >cpu4: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >cpu5: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >cpu6: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >cpu7: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >cpu8: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >cpu9: Sun Microsystems UltraSparc-II Processor (400.00 MHz CPU) > >FreeBSD/SMP: Multiprocessor System Detected: 10 CPUs > >panic: tsb_tte_enter: replacing valid kernel mapping > >db> wh > >Tracing pid 0 tid 0 td 0xc056ad30 > >panic() at panic+0x248 > >tsb_tte_enter() at tsb_tte_enter+0xdc > >pmap_enter_locked() at pmap_enter_locked+0x318 > >pmap_enter() at pmap_enter+0x64 > >kmem_malloc() at kmem_malloc+0x644 > >page_alloc() at page_alloc+0x28 > >uma_large_malloc() at uma_large_malloc+0x44 > >malloc() at malloc+0x1a0 > >sf_buf_init() at sf_buf_init+0xe8 > >mi_startup() at mi_startup+0x1e8 > >btext() at btext+0x34 > > > >Kris > > > > Another runtime panic from a u60: > > panic() at panic+0x204 > _mtx_assert() at _mtx_assert+0xac > pmap_page_is_mapped() at pmap_page_is_mapped+0x38 > vm_page_free_toq() at vm_page_free_toq+0x4c > vm_page_free() at vm_page_free+0x10 > uma_small_free() at uma_small_free+0x1c > zone_drain() at zone_drain+0x2d0 > zone_foreach() at zone_foreach+0x6c > uma_reclaim() at uma_reclaim+0x20 > vm_pageout() at vm_pageout+0x9b8 > fork_exit() at fork_exit+0x9c > fork_trampoline() at fork_trampoline+0x8 > Have you asked alc@ about these? Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071104224618.GD36824>