[Bug 193724] New: [panic] in tcp_discardcb (/usr/src/sys/netinet/tcp_subr.c:929)

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Wed Sep 17 21:58:53 UTC 2014


            Bug ID: 193724
           Summary: [panic] in tcp_discardcb
           Product: Base System
           Version: 10.0-RELEASE
          Hardware: amd64
                OS: Any
            Status: Needs Triage
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: girgen at FreeBSD.org


We got a spontaneous reboot on a producion system. I have a crash dump, can
someone perhaps make use of it to actually find the culprit. I'd rather see it
happen again.

I cannot find anything in the log files.

This is FreeBSD 10.0-RELEASE-p6

Kernel conf:
include GENERIC

cpu             HAMMER
ident           CAJA

# Virtual networking for jail
options         VIMAGE

# The nullFS to mount local directory
options         NULLFS

[girgen at caja /usr/obj/usr/src/sys/CAJA]$ kgdb kernel.debug /var/crash/vmcore.0
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:

Fatal trap 12: page fault while in kernel mode
cpuid = 22; apic id = 26
fault virtual address    = 0x20
fault code        = supervisor read data, page not present
instruction pointer    = 0x20:0xffffffff80a506e2
stack pointer            = 0x28:0xfffffe1835e5e780
frame pointer            = 0x28:0xfffffe1835e5e7f0
code segment        = base 0x0, limit 0xfffff, type 0x1b
            = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags    = interrupt enabled, resume, IOPL = 0
current process        = 84230 (httpd)
trap number        = 12
panic: page fault
cpuid = 22
KDB: stack backtrace:
#0 0xffffffff808eb720 at kdb_backtrace+0x60
#1 0xffffffff808b2de5 at panic+0x155
#2 0xffffffff80ca05b2 at trap_fatal+0x3a2
#3 0xffffffff80ca0889 at trap_pfault+0x2c9
#4 0xffffffff80ca0016 at trap+0x5e6
#5 0xffffffff80c872b2 at calltrap+0x8
#6 0xffffffff80a58d6e at tcp_usr_detach+0xde
#7 0xffffffff80923263 at sofree+0x163
#8 0xffffffff809237c2 at soclose+0x362
#9 0xffffffff808718c9 at _fdrop+0x29
#10 0xffffffff80874137 at closef+0x237
#11 0xffffffff80871b95 at closefp+0x95
#12 0xffffffff80ca0ea7 at amd64_syscall+0x357
#13 0xffffffff80c8759b at Xfast_syscall+0xfb
Uptime: 1d19h54m41s
Dumping 13667 out of 98244 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

Reading symbols from /boot/kernel/zfs.ko.symbols...done.
Loaded symbols for /boot/kernel/zfs.ko.symbols
Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
Loaded symbols for /boot/kernel/opensolaris.ko.symbols
Reading symbols from /boot/kernel/ng_bridge.ko.symbols...done.
Loaded symbols for /boot/kernel/ng_bridge.ko.symbols
Reading symbols from /boot/kernel/netgraph.ko.symbols...done.
Loaded symbols for /boot/kernel/netgraph.ko.symbols
Reading symbols from /boot/kernel/ng_eiface.ko.symbols...done.
Loaded symbols for /boot/kernel/ng_eiface.ko.symbols
Reading symbols from /boot/kernel/ng_ether.ko.symbols...done.
Loaded symbols for /boot/kernel/ng_ether.ko.symbols
Reading symbols from /boot/kernel/accf_data.ko.symbols...done.
Loaded symbols for /boot/kernel/accf_data.ko.symbols
Reading symbols from /boot/kernel/accf_http.ko.symbols...done.
Loaded symbols for /boot/kernel/accf_http.ko.symbols
Reading symbols from /boot/kernel/ums.ko.symbols...done.
Loaded symbols for /boot/kernel/ums.ko.symbols
Reading symbols from /boot/kernel/ng_socket.ko.symbols...done.
Loaded symbols for /boot/kernel/ng_socket.ko.symbols
#0  doadump (textdump=<value optimized out>) at pcpu.h:219
219        __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) list *0xffffffff80a506e2
0xffffffff80a506e2 is in tcp_discardcb (/usr/src/sys/netinet/tcp_subr.c:929).
924         * portion of the remainder of tcp_discardcb() to an asynchronous
925         * context that can callout_drain() and then continue.  Some care
926         * will be required to ensure that no further processing takes place
927         * on the tcpcb, even though it hasn't been freed (a flag?).
928         */
929        callout_stop(&tp->t_timers->tt_rexmt);
930        callout_stop(&tp->t_timers->tt_persist);
931        callout_stop(&tp->t_timers->tt_keep);
932        callout_stop(&tp->t_timers->tt_2msl);
933        callout_stop(&tp->t_timers->tt_delack);
Current language:  auto; currently minimal
(kgdb) backtrace
#0  doadump (textdump=<value optimized out>) at pcpu.h:219
#1  0xffffffff808b2a60 in kern_reboot (howto=260) at
#2  0xffffffff808b2e24 in panic (fmt=<value optimized out>) at
#3  0xffffffff80ca05b2 in trap_fatal (frame=<value optimized out>, eva=<value
optimized out>)
    at /usr/src/sys/amd64/amd64/trap.c:882
#4  0xffffffff80ca0889 in trap_pfault (frame=0xfffffe1835e5e6d0, usermode=0) at
#5  0xffffffff80ca0016 in trap (frame=0xfffffe1835e5e6d0) at
#6  0xffffffff80c872b2 in calltrap () at
#7  0xffffffff80a506e2 in tcp_discardcb (tp=0x0) at
#8  0xffffffff80a58d6e in tcp_usr_detach (so=<value optimized out>) at
#9  0xffffffff80923263 in sofree (so=0xfffff80934dac570) at
#10 0xffffffff809237c2 in soclose (so=<value optimized out>) at
#11 0xffffffff808718c9 in _fdrop (fp=0xfffff8002d9b3050, td=0xfffff80060425000)
at file.h:342
#12 0xffffffff80874137 in closef (fp=<value optimized out>, td=<value optimized
    at /usr/src/sys/kern/kern_descrip.c:2310
#13 0xffffffff80871b95 in closefp (fdp=0xfffff802fc70b800, fd=<value optimized
out>, fp=0xfffff8002d9b3050, 
    td=0xfffff80060425000, holdleaders=<value optimized out>) at
#14 0xffffffff80ca0ea7 in amd64_syscall (td=0xfffff80060425000, traced=0) at
#15 0xffffffff80c8759b in Xfast_syscall () at
#16 0x0000000801e6214a in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) quit

You are receiving this mail because:
You are the assignee for the bug.

More information about the freebsd-bugs mailing list