Date: Mon, 15 Aug 2011 18:36:30 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Steven Hartland <killing@multiplay.co.uk> Cc: freebsd-stable@FreeBSD.org Subject: Re: debugging frequent kernel panics on 8.2-RELEASE Message-ID: <4E493CFE.6010207@FreeBSD.org> In-Reply-To: <570C5495A5E242F7946E806CA7AC5D68@multiplay.co.uk> References: <47F0D04ADF034695BC8B0AC166553371@multiplay.co.uk><A71C3ACF01EC4D36871E49805C1A5321@multiplay.co.uk><4E4380C0.7070908@FreeBSD.org><EBC06A239BAB4B3293C28D793329F9CA@multiplay.co.uk> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
on 15/08/2011 17:56 Steven Hartland said the following:
>
> ----- Original Message ----- From: "Andriy Gapon" <avg@FreeBSD.org>
> To: "Steven Hartland" <killing@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" <avg@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E493CFE.6010207>