on 15/08/2011 17:56 Steven Hartland said the following: > > ----- Original Message ----- From: "Andriy Gapon" <a...@freebsd.org> > To: "Steven Hartland" <kill...@multiplay.co.uk> > Cc: <freebsd-stable@FreeBSD.org> > 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" <a...@freebsd.org> >>> >>> >>>> 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 > <trap_pfault+307> > 0xffffff8d8f357220: 0x0 0xffffff8d8f357370 > 0xffffff8d8f357230: 0xffffff06b7f9c000 0x30 > 0xffffff8d8f357240: 0x100000000 0x0 > 0xffffff8d8f357250: 0x0 0x9 > 0xffffff8d8f357260: 0xc 0xffffff8d8f357370 > 0xffffff8d8f357270: 0xffffff06b7f9c000 0x0 > 0xffffff8d8f357280: 0xffffff8d8f357360 0xffffffff80580e0f <trap+991> > 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 <vmspace0> > 0xffffff8d8f357360: 0xffffff8d8f357430 0xffffffff80568f04 > <calltrap+8> > 0xffffff8d8f357370: 0xffffff070b5a48c0 0x3 > 0xffffff8d8f357380: 0xffffff8d8f357440 0x0 > 0xffffff8d8f357390: 0xffffff8d8f357440 0x30 > 0xffffff8d8f3573a0: 0xffffff06b7f9c000 0x4 > 0xffffff8d8f3573b0: 0xffffff8d8f357430 0xffffffff8083e920 <vmspace0> > 0xffffff8d8f3573c0: 0xffffff06b7f9c000 0xffffff070b5a48c0 > 0xffffff8d8f3573d0: 0xffffff06b7f9c000 0x0 > 0xffffff8d8f3573e0: 0xffffffff8083e920 <vmspace0> 0x1b00130000000c > 0xffffff8d8f3573f0: 0x30 0x3b003b00000001 > 0xffffff8d8f357400: 0x0 0xffffffff80384632 <lim_rlimit+18> > 0xffffff8d8f357410: 0x20 0x10206 > 0xffffff8d8f357420: 0xffffff8d8f357430 0x28 > 0xffffff8d8f357430: 0xffffff8d8f357450 0xffffffff80384681 > <lim_cur+17> > 0xffffff8d8f357440: 0x4 0xffffff070b5a48c0 > 0xffffff8d8f357450: 0xffffff8d8f357500 0xffffffff80543ffd > <vm_map_growstack+93> > 0xffffff8d8f357460: 0xffffff8d8f357470 0xffffff8d8f3576d8 > 0xffffff8d8f357470: 0xffffff8d8f357500 0xffffffff80544ef8 > <vm_map_lookup+808> [trim] -- Andriy Gapon _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"