Date: Wed, 17 Aug 2011 14:12:31 +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: <4E4BA21F.6010805@FreeBSD.org> In-Reply-To: <6A7238AED44542A880B082A40304D940@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> <4E4AD35C.7020504@FreeBSD.org> <6A7238AED44542A880B082A40304D940@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
on 16/08/2011 23:43 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: Tuesday, August 16, 2011 9:30 PM
> Subject: Re: debugging frequent kernel panics on 8.2-RELEASE
>
>
>> on 15/08/2011 17:56 Steven Hartland said the following:
>>> (kgdb) x/512a 0xffffff8d8f357210
>> [snip]
>>
>> Can you please also provide the following for this core?
>> list *vm_map_growstack+93
>> list *lim_cur+17
>> list *lim_rlimit+18
>>
>> Also, it would be interesting to get panic output with DDB option.
>
> Here's the info:-
>
> (kgdb) list *vm_map_growstack+93
> 0xffffffff80543ffd is in vm_map_growstack (/usr/src/sys/vm/vm_map.c:3305).
> 3300 struct uidinfo *uip;
> 3301
> 3302 Retry:
> 3303 PROC_LOCK(p);
> 3304 stacklim = lim_cur(p, RLIMIT_STACK);
> 3305 vmemlim = lim_cur(p, RLIMIT_VMEM);
> 3306 PROC_UNLOCK(p);
> 3307
> 3308 vm_map_lock_read(map);
> 3309
> (kgdb) list *lim_cur+17
> 0xffffffff80384681 is in lim_cur (/usr/src/sys/kern/kern_resource.c:1150).
> 1145 rlim_t
> 1146 lim_cur(struct proc *p, int which)
> 1147 {
> 1148 struct rlimit rl;
> 1149
> 1150 lim_rlimit(p, which, &rl);
> 1151 return (rl.rlim_cur);
> 1152 }
> 1153
> 1154 /*
> (kgdb) list *lim_rlimit+18
> 0xffffffff80384632 is in lim_rlimit (/usr/src/sys/kern/kern_resource.c:1165).
> 1160 {
> 1161
> 1162 PROC_LOCK_ASSERT(p, MA_OWNED);
> 1163 KASSERT(which >= 0 && which < RLIM_NLIMITS,
> 1164 ("request for invalid resource limit"));
> 1165 *rlp = p->p_limit->pl_rlimit[which];
> 1166 if (p->p_sysent->sv_fixlimit != NULL)
> 1167 p->p_sysent->sv_fixlimit(rlp, which);
> 1168 }
> 1169
>
> I've yet to have the machine with DDB + expanded stack panic.
>
> I plan to leave it a day or so more then try a reboot to see if that
> triggers it. If not I'll drop the stack back down to 4 and see if that
> enables us to get another panic.
OK, thank you for continuing to debug this!
Another request: could you please execute the following commands in kgdb on the
above core file?
define allpcpu
set $i = 0
while ($i <= mp_maxid)
p *cpuid_to_pcpu[$i]
set $i = $i + 1
end
end
allpcpu
A little bit later I will send you another patch that, I hope, will produce better
diagnostics for this crash (without DDB in kernel).
--
Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E4BA21F.6010805>