Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 16 Aug 2010 23:43:39 +0400
From:      Alexey Tarasov <me@lexasoft.ru>
To:        Kostik Belousov <kostikbel@gmail.com>
Cc:        freebsd-stable@freebsd.org, Alexey Tarasov <me@lexasoft.ru>
Subject:   Re: STABLE kernel panic: privileged instruction fault
Message-ID:  <4212B9F7-9B4B-466F-8AB8-2DCCAC50E52E@lexasoft.ru>
In-Reply-To: <20100816193948.GW2396@deviant.kiev.zoral.com.ua>
References:  <D3520B14-5DB1-42B7-8D21-731D0BD45788@lexasoft.ru> <20100816184818.GS2396@deviant.kiev.zoral.com.ua> <E14B2DF6-3908-4429-A916-7A8731F7D510@lexasoft.ru> <20100816193112.GV2396@deviant.kiev.zoral.com.ua> <55B93A70-9AD1-46EC-B1A0-FC73780ABCDE@lexasoft.ru> <20100816193948.GW2396@deviant.kiev.zoral.com.ua>

next in thread | previous in thread | raw e-mail | index | archive | help

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
(")_(")




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4212B9F7-9B4B-466F-8AB8-2DCCAC50E52E>