Subject: Re: kern/11742: possible panic from kernel ntp
To: None <dogcow@redback.com>
From: Manuel Bouyer <bouyer@antioche.lip6.fr>
List: netbsd-bugs
Date: 12/14/2000 23:35:00
On Thu, Dec 14, 2000 at 02:02:18PM -0800, dogcow@redback.com wrote:
> >Description:
> Got a panic from what looks like possibly kernel ntp-related lossage?
> (there's also the second panic after the first panic relating to wdc not
> flushing properly, but that's not relevant to this pr.)
> 
> (gdb) up
> #8  0xc0141011 in panic () at ../../../../kern/subr_prf.c:240
> 240             cpu_reboot(bootopt, NULL);
> (gdb) up
> #9  0xc01fb6e1 in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -1067465520, 
>       tf_esi = 1172, tf_ebp = -911626444, tf_ebx = -911626476, tf_edx = 52, 
>       tf_ecx = -911626472, tf_eax = -1070766124, tf_trapno = 6, tf_err = 2, 
>       tf_eip = -1072089200, tf_cs = 8, tf_eflags = 66182, tf_esp = 0, 
>       tf_ss = -2147483648, tf_vm86_es = -1072382728, tf_vm86_ds = 17520, 
>       tf_vm86_fs = 16072, tf_vm86_gs = 52})
>     at ../../../../arch/i386/i386/trap.c:308
> 308                     panic("trap");
> (gdb) up
> #10 0xc0100cfd in calltrap ()
> (gdb) up
> #11 0xc01953ed in tcp_fasttimo () at ../../../../netinet/tcp_timer.c:165
> 165                     (void) tcp_output(tp);
> (gdb) print tp
> $1 = (struct tcpcb *) 0x0
> (gdb) up
> #12 0xc014bd25 in pffasttimo (arg=0x0) at ../../../../kern/uipc_domain.c:294
> 294                                     (*pr->pr_fasttimo)();
> (gdb) up
> #13 0xc012d9ed in softclock () at ../../../../kern/kern_clock.c:921
> 921                                     (*func)(arg);
> (gdb) up
> #14 0xc012d87b in hardclock (frame=0xc9a9afac)
>     at ../../../../kern/kern_clock.c:855
> 855                             softclock();
> (gdb) up
> #15 0xc022c493 in clockintr (arg=0xc9a9afac)
>     at ../../../../arch/i386/isa/clock.c:409
> 409             hardclock(frame);
> (gdb) up
> #16 0xc0100ec4 in Xintr0 ()
> (gdb) up
> Initial frame selected; you cannot go up.

What make you think ntp is involved ? This looks like a bug in the TCP stack
(maybe a missing spl protection).

--
Manuel Bouyer <bouyer@antioche.eu.org>
--