From owner-freebsd-stable@FreeBSD.ORG Mon Aug 16 19:43:42 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 932FF1065697 for ; Mon, 16 Aug 2010 19:43:42 +0000 (UTC) (envelope-from me@lexasoft.ru) Received: from relay.wahome.ru (relay.wahome.ru [95.211.21.141]) by mx1.freebsd.org (Postfix) with ESMTP id 555D28FC1E for ; Mon, 16 Aug 2010 19:43:42 +0000 (UTC) Received: from mmx.lexasoft.ru (mmx.lexasoft.ru [92.241.160.6]) by relay.wahome.ru (Postfix) with ESMTP id BA80E6B183A; Mon, 16 Aug 2010 23:42:22 +0400 (MSD) Received: from [92.241.160.200] (unknown [92.241.160.200]) by mmx.lexasoft.ru (Postfix) with ESMTPSA id A9ECD2848C; Mon, 16 Aug 2010 23:43:40 +0400 (MSD) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=utf-8 From: Alexey Tarasov In-Reply-To: <20100816193948.GW2396@deviant.kiev.zoral.com.ua> Date: Mon, 16 Aug 2010 23:43:39 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4212B9F7-9B4B-466F-8AB8-2DCCAC50E52E@lexasoft.ru> References: <20100816184818.GS2396@deviant.kiev.zoral.com.ua> <20100816193112.GV2396@deviant.kiev.zoral.com.ua> <55B93A70-9AD1-46EC-B1A0-FC73780ABCDE@lexasoft.ru> <20100816193948.GW2396@deviant.kiev.zoral.com.ua> To: Kostik Belousov X-Mailer: Apple Mail (2.1081) Cc: freebsd-stable@freebsd.org, Alexey Tarasov Subject: Re: STABLE kernel panic: privileged instruction fault 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: Mon, 16 Aug 2010 19:43:42 -0000 On Aug 16, 2010, at 11:39 PM, Kostik Belousov wrote: > On Mon, Aug 16, 2010 at 11:35:36PM +0400, Alexey Tarasov wrote: >>=20 >> On Aug 16, 2010, at 11:31 PM, Kostik Belousov wrote: >>=20 >>> On Mon, Aug 16, 2010 at 11:21:15PM +0400, Alexey Tarasov wrote: >>>> Hello Kostik! >>>>=20 >>>> On Aug 16, 2010, at 10:48 PM, Kostik Belousov wrote: >>>>=20 >>>>>>=20 >>>>> The backtrace make absolutely no sense. I would not trust kgdb = anyway. >>>>>=20 >>>>> Compile ddb in and do backtrace in console on the panic. Also, = disassemble >>>>> the kernel at the fault address. I am very curious which = instruction causes >>>>> this. This is stock GENERIC on the bare metal booted, right ? >>>>=20 >>>> Yes, stock GENERIC. >>>>=20 >>>> Please, check this out: >>>>=20 >>>> Dump of assembler code from 0xffffff0060c0b700 to = 0xffffff0060c0b780: >>>=20 >>> Would be nice if you keep all requested data in one place, so that >>> we do not need to search for the old mails to see the context. >>>=20 >>> According to your previous mail, the fault happen at the >>> address >>> instruction pointer =3D 0x20:0xffffff8040d2cc83 >>> Your disassembled the stack instead. Please just do >>> disass 0xffffff8040d2cc83,0xffffff8040d2cca0 >>> in kgdb. >>>=20 >>> But also, I want to see the backtrace and disassembly output from = ddb. >>=20 >> (kgdb) disass 0xffffff8040d2cc83,0xffffff8040d2cca0 >> No function contains specified address. > Err, it seems that old gdb accepts only spaces. Please try > disass 0xffffff8040d2cc83 0xffffff8040d2cca0 instead. (kgdb) disass 0xffffff8040d2cc83 0xffffff8040d2cca0 Dump of assembler code from 0xffffff8040d2cc83 to 0xffffff8040d2cca0: 0xffffff8040d2cc83: (bad) =20 0xffffff8040d2cc84: (bad) =20 0xffffff8040d2cc85: jg 0xffffff8040d2cc87 0xffffff8040d2cc87: add %al,(%rax) 0xffffff8040d2cc89: add %al,(%rax) 0xffffff8040d2cc8b: add %al,(%rax) 0xffffff8040d2cc8d: add %al,(%rax) 0xffffff8040d2cc8f: add %al,(%rax) 0xffffff8040d2cc91: add %al,(%rax) 0xffffff8040d2cc93: add %al,(%rax) 0xffffff8040d2cc95: add %al,(%rax) 0xffffff8040d2cc97: add %al,(%rcx) 0xffffff8040d2cc99: add %al,(%rax) 0xffffff8040d2cc9b: add %al,(%rax) 0xffffff8040d2cc9d: add %al,(%rax) 0xffffff8040d2cc9f: add %al,(%rax) End of assembler dump. >=20 >>=20 >> I will build kernel with DDB tomorrow, install it on some servers and = wait for the panic occurs. > Ok. Did you checked for such things as rootkits ? I am noticing such panics only on this model of supermicro servers for a = long! time under FreeBSD. This servers were tested on huge workload under Linux and there were no = problems. I've installed and run chkrootkit now, there are no rootkits. -- Alexey Tarasov (\__/)=20 (=3D'.'=3D)=20 E[: | | | | :]=D0=97=20 (")_(")