From owner-freebsd-stable@FreeBSD.ORG Tue Mar 27 16:08:06 2012 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA6EF1065672 for ; Tue, 27 Mar 2012 16:08:06 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 432558FC1D for ; Tue, 27 Mar 2012 16:08:05 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA10394; Tue, 27 Mar 2012 19:02:11 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4F71E482.7060509@FreeBSD.org> Date: Tue, 27 Mar 2012 19:02:10 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120314 Thunderbird/10.0.3 MIME-Version: 1.0 To: Volodymyr Kostyrko References: <4F71E14A.8010605@gmail.com> In-Reply-To: <4F71E14A.8010605@gmail.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stable@FreeBSD.org Subject: Re: trap 12 on 9.0 when memcache gets some load X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 16:08:07 -0000 on 27/03/2012 18:48 Volodymyr Kostyrko said the following: > Hi all. > > I'm just puzzled with this. At first I though this happens because of some memory > problems. But now project was moved to another server with some other brands for > motherboard/memory and different cpu's. And still once in an hour this happens again: > > == screenshot > current_process = 1935 (memcached) > trap number = 12 > panic: page fault > cpuid = 2 > KDB: stack backtrace: > #0 0xffffffff8038ab38 at kdb_backtrace+0x58 > #1 0xffffffff80358f80 at panic+0x190 > #2 0xffffffff80567b15 at trap_fatal+0x395 > #3 0xffffffff80567ce9 at trap_pfault+0x1c9 > #4 0xffffffff80567536 at trap+0x3a6 > #5 0xffffffff80552603 at calltrap+0x8 > #6 0xffffffff803b2c90 at socow_setup+0xd0 I think that zero-copy sockets are not regarded as a reliable feature. Not an expert, just my two cents. > #7 0xffffffff803bc12a at sosend_copyin+0x10a > #8 0xffffffff803bc7c6 at sosend_generic+0x4f6 > #9 0xffffffff803c2028 at kern_sendit+0x1e8 > #10 0xffffffff803c22a1 at sendit+0xd1 > #11 0xffffffff803c2331 at sys_sendmsg+0x61 > #12 0xffffffff805681c5 at amd64_syscall+0x2a5 > #13 0xffffffff805528eb at Xfast_syscall+0xfb > GEOM_MIRROR: Device beeb0swap: provider mirror/beeb0swap destroyed. > GEOM_MIRROR: Device beeb0swap destroyed. > GEOM_MIRROR: Device kohrah0swap: provider mirror/kohrah0swap destroyed. > GEOM_MIRROR: Device kohrah0swap destroyed. > Uptime: 1d10h46m37s > Dumping 9737 out of 12268 MB: > == > > And everything stalls. I have dumpdev_auto set at /etc/rc.conf and selected swap > device (kohrah0swap) size is 32Gb so it should save dumps but it doesn't. Next > time i'll try to give it raw volume for dump. > > The most curious thing for me is userland app crashing whole kernel. If I switch > to redis everything works like a charm. > -- Andriy Gapon