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...
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
