Dtrace panic'ed

[Andrew Gallatin]

Artem Belevich wrote:
 >> --- trap 0xc, rip = 0xffffffff80e33187, rsp = 0xfffffffe4004aa70, rbp =
 >> 0xfffffffe4004aa80 ---
 >> cyclic_disable_xcall() at cyclic_disable_xcall+0x7
 >> smp_rendezvous_action() at smp_rendezvous_action+0xb3
 >> Xrendezvous() at Xrendezvous+0x64
 >
 > It seems to be the same issue that few other folks including myself
 > have seen. Search -current archives around October for 'hotkernel in
 > the subject.

Ah, I see.

 > By the way, if you dump stack tracess for all processes, do you see
 > any of them in smp_tlb_shootdown ?

No idea.  I've rebooted, and am poking around in gdb.  I thought
that getting backtraces for everything from gdb was i386 specific,
and I'm on amd64.

I'm pretty weak on amd64 assembly language, but I think I know enough
to think that this very weird.  In my case, I'm also seeing a 0x20
faulting address, and the instruction pointer is here:

       push   %rbp
       mov    (%rdi),%rax
       mov    %rsp,%rbp
-->   mov    0x20(%rax),%rax
       mov    0x30(%rax),%rdi
       mov    0x18(%rax),%r11

If I look at the caller:

(kgdb) p/x local_func_arg
$2 = 0xffffffff226567c0

That matches %rdi. in the cyclic_disable_xcall() function.

Then if I then dereference this, I get something which is
non-null.

(kgdb) p/x *(long *)0xffffffff226567c0
$3 = 0xffffffff22656820

I was expecting it to be 0, given the faulting address
of 0x20.  But it wasn't.

Drew