debugging frequent kernel panics on 8.2-RELEASE

[Andriy Gapon]

on 16/08/2011 23:43 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: 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