RELENG_6 network stack locking problems? (Was: no core file handler recognizes format)

[Maxim Konovalov]

On Fri, 12 May 2006, 18:40-0700, Avleen Vig wrote:

> On Sat, May 13, 2006 at 02:39:19AM +0400, Stanislav Sedov wrote:
> > You should use kgdb rather the gdb. GDB doesn't recognizes kernel
> > dumps format by default.
>
> Ah thank you!
>
> Here's the information I found.
> Any help that anyone can provide will go into a nice little "crash
> debugging for beginners" document which I've started working on :-)
>
>
>
> Ok kgdb tells me:
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0x58
> fault code              = supervisor write, page not present
> instruction pointer     = 0x20:0xc06005aa
> stack pointer           = 0x28:0xd6c13ad0
> frame pointer           = 0x28:0xd6c13b00
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 25911 (python)
> trap number             = 12
> panic: page fault
> Uptime: 14h49m8s
> Dumping 511 MB (2 chunks)
>   chunk 0: 1MB (159 pages) ... ok
>   chunk 1: 511MB (130800 pages) 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15
>
> #0  doadump () at pcpu.h:165
> 165     pcpu.h: No such file or directory.
>         in pcpu.h
>
> The few lines before trap() was called look like this:
>
> #5  0xc071a38d in trap (frame=
>       {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 0, tf_esi = 0, tf_ebp = -691979520, tf_isp = -691979588, tf_ebx = -691979136, tf_edx = -691978864, tf_ecx = 0, tf_eax = 8, tf_trapno = 12, tf_err = 2, tf_eip = -1067448918, tf_cs = 32, tf_eflags = 66183, tf_esp = -691979136, tf_ss = -691979544})
>     at /usr/src/sys/i386/i386/trap.c:434
> #6  0xc070814a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
> #7  0xc06005aa in ip_ctloutput (so=0x8, sopt=0xd6c13c80)
>     at /usr/src/sys/netinet/ip_output.c:1210

Yes, it is known issue, see kern/97095.  Perhaps kern/96413 is related
too.  I'm trying to get inpcb locking logic at the moment.  We need
Robert Watson attention :-)

-- 
Maxim Konovalov