ports/113430: Kernel Panic with emulators/qemu on AMD64 SMP

[Juergen Lock]

On Fri, Jun 08, 2007 at 03:10:10PM +0000, Allan Jude wrote:
>  I recreated it again, and the 'stopped at' in the kernel panic is:
>  
>  userret+0x22	movq	0(%rdi),%rbx

Ok so apparently userret was called with a bogus td arg, can you find
out from where?  (there should be a return address on the stack, userret
here starts with a sub $0x28,%rsp (hmm, no frame pointer?) so add that or
whatever yours subtracts.)

 Btw,

>  fault virtual address   = 0x202
>  fault code              = supervisor read, page not present
>[...]
>  #9  0xffffffff80650f5d in trap (frame=
>        {tf_rdi = 0xffffff012f655720, tf_rsi = 0x4, tf_rdx = 0x46, tf_rcx
>[...]

 shouldnt tf_rdi here be rdi at the time of the fault, i.e. 0x202?
Anyone know why its different?  Also, as mentioned above userret doesnt
save a frame pointer here (rbp) and indeed,

>  0xffffff012f655720, tf_rax = 0x2, tf_rbx = 0xf4240, tf_rbp =
>  0xffffffffb38f5d10, tf_r10 = 0xffffff012b39e108, tf_r11 = 0x2, tf_r12 =
>[...]
>  tf_rflags = 0x10282, tf_rsp = 0xffffffffb38f5bb0, tf_ss =

 tf_rbp seems to be way off compared to tf_rsp, are parts of the kernel
now compiled with -fomit-frame-pointer?  (even for a debug kernel?)
This may explain why we dont see who called userret in the kgdb backtrace...