debugging frequent kernel panics on 8.2-RELEASE
Andriy Gapon
avg at FreeBSD.org
Mon Aug 15 15:36:36 UTC 2011
on 15/08/2011 17:56 Steven Hartland said the following:
>
> ----- Original Message ----- From: "Andriy Gapon" <avg at FreeBSD.org>
> To: "Steven Hartland" <killing at multiplay.co.uk>
> Cc: <freebsd-stable at 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" <avg at 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
More information about the freebsd-stable
mailing list