[Bug 293382] Dead lock and kernel crash around closefp_impl

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293382

--- Comment #6 from Paul <devgs@ukr.net> ---
Finally caught another crash. Alas I was a bit busy at the time and only
reporting back now.

The bad thing is: somehow it did not produce the /var/crash/vmcore.1. After the
reboot it has spitted out:

Starting syslogd.
savecore 1735 - - reboot after panic: general protection fault
Mar  3 12:14:25 frv21 savecore[1735]: reboot after panic: general protection
fault
savecore 1735 - - writing core to /var/crash/textdump.tar.1
Writing crash summary to /var/crash/core.txt.1.
Starting chronyd.

but...

$ cat core.txt.1
/var/crash/vmcore.1 not found


Available files are:

config.txt     core.txt.1     ddb.txt        msgbuf.txt     panic.txt     
textdump.tar.1


Last messages:

$ tail -n 50 msgbuf.txt
<5>Limiting tcp reset response from 67253 to 49997 packets/sec
<5>Limiting tcp reset response from 67169 to 49995 packets/sec
<5>Limiting tcp reset response from 65293 to 49993 packets/sec
<5>Limiting tcp reset response from 64794 to 50015 packets/sec
<5>Limiting tcp reset response from 65880 to 50012 packets/sec
<5>Limiting tcp reset response from 65243 to 50000 packets/sec
<5>Limiting tcp reset response from 71695 to 49993 packets/sec
<5>Limiting tcp reset response from 79815 to 49998 packets/sec
<5>Limiting tcp reset response from 71724 to 49997 packets/sec
<5>Limiting tcp reset response from 67537 to 50005 packets/sec
<5>Limiting tcp reset response from 65417 to 50000 packets/sec
<5>Limiting tcp reset response from 75635 to 50009 packets/sec
<5>Limiting tcp reset response from 71016 to 50005 packets/sec
<5>Limiting tcp reset response from 78743 to 49986 packets/sec
<4>TCP syncache overflow detected; using syncookies for the next 15 seconds
<118>Mar  3 00:40:02 frv21 kernel: TCP syncache overflow detected; using
syncookies for the next 15 seconds


Fatal trap 9: general protection fault while in kernel mode
cpuid = 3; apic id = 03
instruction pointer     = 0x20:0xffffffff80b590fd
stack pointer           = 0x28:0xfffffe07e5854d70
frame pointer           = 0x28:0xfffffe07e5854d70
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         = 86706 (<redacted-3>)
rdi: deadc0dedeadc0f6 rsi: 0000000000000004 rdx: ffffffff811ab239
rcx: 0000000000000122  r8: 0000000000000001  r9: ffffffff81e1cba8
rax: fffff801be6b4000 rbx: 00000000000774c3 rbp: fffffe07e5854d70
r10: 0000000000000000 r11: 0000000000000004 r12: fffff8010bbfa418
r13: fffff84f0bab13c0 r14: 00000000000774c3 r15: fffff8010bbfa400
trap number             = 9
panic: general protection fault
cpuid = 3
time = 1772532522
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe07e5854af0
vpanic() at vpanic+0x161/frame 0xfffffe07e5854c20
panic() at panic+0x43/frame 0xfffffe07e5854c80
trap_fatal() at trap_fatal+0x68/frame 0xfffffe07e5854ca0
calltrap() at calltrap+0x8/frame 0xfffffe07e5854ca0
--- trap 0x9, rip = 0xffffffff80b590fd, rsp = 0xfffffe07e5854d70, rbp =
0xfffffe07e5854d70 ---
__mtx_assert() at __mtx_assert+0x3d/frame 0xfffffe07e5854d70
knote_fdclose() at knote_fdclose+0x12e/frame 0xfffffe07e5854dc0
closefp_impl() at closefp_impl+0x96/frame 0xfffffe07e5854e00
amd64_syscall() at amd64_syscall+0x15a/frame 0xfffffe07e5854f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe07e5854f30
--- syscall (6, FreeBSD ELF64, close), rip = 0x82d3ea32a, rsp = 0x860151bb8,
rbp = 0x860151bd0 ---


Crash point still looks the same.

We aren't sure why there is no core dump. Have we configured/built the kernel
improperly?
But, the last time, only one of the two crashes have produced it. 
Seems like it chance related and we have to keep trying?

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