On Mon, Aug 16, 2010 at 11:35:36PM +0400, Alexey Tarasov wrote: > > On Aug 16, 2010, at 11:31 PM, Kostik Belousov wrote: > > > On Mon, Aug 16, 2010 at 11:21:15PM +0400, Alexey Tarasov wrote: > >> Hello Kostik! > >> > >> On Aug 16, 2010, at 10:48 PM, Kostik Belousov wrote: > >> > >>>> > >>> The backtrace make absolutely no sense. I would not trust kgdb anyway. > >>> > >>> 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 ? > >> > >> Yes, stock GENERIC. > >> > >> Please, check this out: > >> > >> Dump of assembler code from 0xffffff0060c0b700 to 0xffffff0060c0b780: > > > > 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. > > > > According to your previous mail, the fault happen at the > > address > > instruction pointer = 0x20:0xffffff8040d2cc83 > > Your disassembled the stack instead. Please just do > > disass 0xffffff8040d2cc83,0xffffff8040d2cca0 > > in kgdb. > > > > But also, I want to see the backtrace and disassembly output from ddb. > > (kgdb) disass 0xffffff8040d2cc83,0xffffff8040d2cca0 > No function contains specified address. Err, it seems that old gdb accepts only spaces. Please try disass 0xffffff8040d2cc83 0xffffff8040d2cca0 instead.
> > 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 ?
pgpTly6pt0t7A.pgp
Description: PGP signature
