From owner-freebsd-ia64 Sat Oct 26 16:33:36 2002 Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0D8137B404 for ; Sat, 26 Oct 2002 16:33:31 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 027B543E42 for ; Sat, 26 Oct 2002 16:33:27 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 19BB32A88D; Sat, 26 Oct 2002 16:33:18 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Marcel Moolenaar Cc: ia64@FreeBSD.org Subject: Re: General exception due to infinite recursion In-Reply-To: <20021026215002.GA1276@athlon.pn.xcllnt.net> Date: Sat, 26 Oct 2002 16:33:18 -0700 From: Peter Wemm Message-Id: <20021026233318.19BB32A88D@canning.wemm.org> Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Marcel Moolenaar wrote: > Gang, > > I've been hitting the following a couple of times now: > > Fatal kernel trap (cpu 0): > > trap vector = 0x18 (General Exception) > cr.iip = 0xe00000000091ee70 > cr.ipsr = 0x101008026010 (mfl,ic,i,dt,rt,cpl=0,it,ri=0,bn) > cr.isr = 0x8000000030 (code=48,vector=0,ni,ei=0) > cr.ifa = 0xa000000034853f78 > cr.iim = 0x100000 > curthread = 0xa000000000206360 > pid = 2108, comm = as > > Stopped at slab_zalloc+0x5a0: [MFI] st8 [r40]=r32 > db> > > The faulting address is quite reasonable. If you do a trace you'll see > the following recurring pattern: > > : > pmap_enter(0xe000000000af1700, 0xa00000003ae04000, 0xe00000007e347170, 0x7, 0 x1, 0xe00000005fb7a040) at pmap_enter+0x460 > vm_fault(0xe00000007efbc000, 0xa00000003ae04000, 0x7, 0x1, 0xe000000001fd1b10 , 0x100100, 0x83c, 0xe000000000940670) at vm_fault+0x2430 > vm_fault_wire(0xe00000007efbc000, 0xa00000003ae04000, 0xa00000003ae06000, 0x0 ) at vm_fault_wire+0x60 > vm_map_wire(0xe00000007efbc000, 0xa00000003ae04000, 0xa00000003ae06000, 0x0) at vm_map_wire+0x3e0 > kmem_alloc(0xe00000007efbc000, 0x2000, 0xe00000007e347170, 0x2000, 0x3ae04000 , 0xffffffffffffffff, 0xe000000000ae7290, 0xe00000000093d0d0) at kmem_alloc +0x260 > pmap_allocf(0xe00000007efcae00, 0x2000) at pmap_allocf+0x40 > slab_zalloc(0xe00000007efcae00, 0x5, 0xe000000000d10000, 0xe00000007efca4b8) at slab_zalloc+0x210 > uma_zone_slab(0xe00000007efcae00, 0x1) at uma_zone_slab+0x230 > uma_zalloc_internal(0xe00000007efcae00, 0x0, 0x1, 0x17b7) at uma_zalloc_inter nal+0xc0 > uma_zalloc_arg(0xe00000007efcae00, 0x0, 0x1, 0xe00000007efcaf68) at uma_zallo c_arg+0x640 > get_pv_entry(0xe00000000093ed80, 0x285, 0xe00000007efcae00) at get_pv_entry+0 xd0 > pmap_insert_entry() at pmap_insert_entry+0x20 > pmap_enter(0xe000000000af1700, 0xa00000003ae02000, 0xe00000007e4514f8, 0x7, 0 x1, 0xe00000005fb7a020) at pmap_enter+0x460 > vm_fault(0xe00000007efbc000, 0xa00000003ae02000, 0x7, 0x1, 0xe000000001fd1c60 , 0x100100, 0x83c, 0xe000000000940670) at vm_fault+0x2430 > : > > For another strange reason, this happens quite often when compiling > modules/ispfw. > > I'll try to track it down... Are you using the ia64 patches from the p4 tree? There is lots of nastiness in the pte/pv allocator that breaks things. I've fixed it in the p4 tree, but Jeff Roberson wants to do it a bit differently. You may like to get the kernel parts from: http://people.freebsd.org/~peter/ia64.diff (beware of time_t change, you will probably want to back that out locally) The ia64 tinderbox builder runs a p4 based kernel and userland, but builds the plain cvs tree. It has never run into this problem. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message