From owner-freebsd-stable@FreeBSD.ORG Mon Aug 15 15:36:35 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0624106566B; Mon, 15 Aug 2011 15:36:35 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 019128FC0A; Mon, 15 Aug 2011 15:36:34 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA15475; Mon, 15 Aug 2011 18:36:31 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E493CFE.6010207@FreeBSD.org> Date: Mon, 15 Aug 2011 18:36:30 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Steven Hartland References: <47F0D04ADF034695BC8B0AC166553371@multiplay.co.uk><4E4380C0.7070908@FreeBSD.org> <4E43E272.1060204@FreeBSD.org> <62BF25D0ED914876BEE75E2ADF28DDF7@multiplay.co.uk> <4E440865.1040500@FreeBSD.org> <6F08A8DE780545ADB9FA93B0A8AA4DA1@multiplay.co.uk> <4E441314.6060606@FreeBSD.org> <2C4B0D05C8924F24A73B56EA652FA4B0@multiplay.co.uk> <4E48D967.9060804@FreeBSD.org> <9D034F992B064E8092E5D1D249B3E959@multiplay.co.uk> <4E490DAF.1080009@FreeBSD.org> <796FD5A096DE4558B57338A8FA1E125B@multiplay.co.uk> <4E491D01.1090902@FreeBSD.org> <570C5495A5E242F7946E806CA7AC5D68@multiplay.co.uk> In-Reply-To: <570C5495A5E242F7946E806CA7AC5D68@multiplay.co.uk> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: debugging frequent kernel panics on 8.2-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 15:36:36 -0000 on 15/08/2011 17:56 Steven Hartland said the following: > > ----- Original Message ----- From: "Andriy Gapon" > To: "Steven Hartland" > Cc: > Sent: Monday, August 15, 2011 2:20 PM > Subject: Re: debugging frequent kernel panics on 8.2-RELEASE > > >> on 15/08/2011 15:51 Steven Hartland said the following: >>> ----- Original Message ----- From: "Andriy Gapon" >>> >>> >>>> on 15/08/2011 13:34 Steven Hartland said the following: >>>>> (kgdb) list *0xffffffff8053b691 >>>>> 0xffffffff8053b691 is in vm_fault (/usr/src/sys/vm/vm_fault.c:239). >>>>> 234 /* >>>>> 235 * Find the backing store object and offset into it to begin the >>>>> 236 * search. >>>>> 237 */ >>>>> 238 fs.map = map; >>>>> 239 result = vm_map_lookup(&fs.map, vaddr, fault_type, &fs.entry, >>>>> 240 &fs.first_object, &fs.first_pindex, &prot, &wired); >>>>> 241 if (result != KERN_SUCCESS) { >>>>> 242 if (result != KERN_PROTECTION_FAILURE || >>>>> 243 (fault_flags & VM_FAULT_WIRE_MASK) != >>>>> VM_FAULT_USER_WIRE) { >>>>> >>>> >>>> Interesting... thanks! [snip] > (kgdb) x/512a 0xffffff8d8f357210 This is not conclusive, but that stack looks like the following recursive chain: vm_fault -> {vm_map_lookup, vm_map_growstack} -> trap -> trap_pfault -> vm_fault So I suspect that increasing kernel stack size won't help here much. Where does this chain come from? I have no answer at the moment, maybe other developers could help here. I suspect that we shouldn't be getting that trap in vm_map_growstack or should handle it in a different way. > 0xffffff8d8f357210: 0xffffff8d8f357280 0xffffffff805807d3 > 0xffffff8d8f357220: 0x0 0xffffff8d8f357370 > 0xffffff8d8f357230: 0xffffff06b7f9c000 0x30 > 0xffffff8d8f357240: 0x100000000 0x0 > 0xffffff8d8f357250: 0x0 0x9 > 0xffffff8d8f357260: 0xc 0xffffff8d8f357370 > 0xffffff8d8f357270: 0xffffff06b7f9c000 0x0 > 0xffffff8d8f357280: 0xffffff8d8f357360 0xffffffff80580e0f > 0xffffff8d8f357290: 0x0 0x0 > 0xffffff8d8f3572a0: 0x80074e49e 0x2 > 0xffffff8d8f3572b0: 0x80071cba0 0x80071cdc0 > 0xffffff8d8f3572c0: 0x80071c9a0 0x0 > 0xffffff8d8f3572d0: 0x0 0x0 > 0xffffff8d8f3572e0: 0x0 0x0 > 0xffffff8d8f3572f0: 0x0 0x0 > 0xffffff8d8f357300: 0x80074e49e 0x1 > 0xffffff8d8f357310: 0x80071cba0 0x80071cdc0 > 0xffffff8d8f357320: 0x80071c9a0 0x0 > 0xffffff8d8f357330: 0x0 0x4 > 0xffffff8d8f357340: 0xffffff070b5a48c0 0xffffff06b7f9c000 > 0xffffff8d8f357350: 0x0 0xffffffff8083e920 > 0xffffff8d8f357360: 0xffffff8d8f357430 0xffffffff80568f04 > 0xffffff8d8f357370: 0xffffff070b5a48c0 0x3 > 0xffffff8d8f357380: 0xffffff8d8f357440 0x0 > 0xffffff8d8f357390: 0xffffff8d8f357440 0x30 > 0xffffff8d8f3573a0: 0xffffff06b7f9c000 0x4 > 0xffffff8d8f3573b0: 0xffffff8d8f357430 0xffffffff8083e920 > 0xffffff8d8f3573c0: 0xffffff06b7f9c000 0xffffff070b5a48c0 > 0xffffff8d8f3573d0: 0xffffff06b7f9c000 0x0 > 0xffffff8d8f3573e0: 0xffffffff8083e920 0x1b00130000000c > 0xffffff8d8f3573f0: 0x30 0x3b003b00000001 > 0xffffff8d8f357400: 0x0 0xffffffff80384632 > 0xffffff8d8f357410: 0x20 0x10206 > 0xffffff8d8f357420: 0xffffff8d8f357430 0x28 > 0xffffff8d8f357430: 0xffffff8d8f357450 0xffffffff80384681 > 0xffffff8d8f357440: 0x4 0xffffff070b5a48c0 > 0xffffff8d8f357450: 0xffffff8d8f357500 0xffffffff80543ffd > > 0xffffff8d8f357460: 0xffffff8d8f357470 0xffffff8d8f3576d8 > 0xffffff8d8f357470: 0xffffff8d8f357500 0xffffffff80544ef8 > [trim] -- Andriy Gapon