On Aug 16, 2010, at 11:39 PM, Kostik Belousov wrote: > 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.
(kgdb) disass 0xffffff8040d2cc83 0xffffff8040d2cca0 Dump of assembler code from 0xffffff8040d2cc83 to 0xffffff8040d2cca0: 0xffffff8040d2cc83: (bad) 0xffffff8040d2cc84: (bad) 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. > >> >> 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 (\__/) (='.'=) E[: | | | | :]З (")_(") _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"