| Message ID | 20140625202650.GC13845@pd.tnic (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Jun 25, 2014 at 10:26:50PM +0200, Borislav Petkov wrote: > On Wed, Jun 25, 2014 at 05:32:28PM +0200, Borislav Petkov wrote: > > Hi guys, > > > > so I'm looking at this splat below when booting current linus+tip/master > > in a kvm guest. Initially I thought this is something related to the > > PARAVIRT gunk but it happens with and without it. > > Ok, here's a cleaner splat. I went and rebuilt qemu to latest master > from today to rule out some breakage there but it still fires. Ok, another observation: I was using qemu from sources from the other day: v2.0.0-1806-g2b5b7ae917e8 Switching back to the installed one: $ qemu-system-x86_64 --version QEMU emulator version 1.7.1 (Debian 1.7.0+dfsg-6), Copyright (c) 2003-2008 Fabrice Bellard fixes the issue. Joerg says I should bisect but I'm busy with other stuff. If people are interested in chasing this further, I could free up some time to do so...
Il 27/06/2014 12:18, Borislav Petkov ha scritto: > Joerg says I should bisect but I'm busy with other stuff. If people are > interested in chasing this further, I could free up some time to do > so... Please first try "-M pc-1.7" on the 2.0 QEMU. If it fails, please do bisect it. A QEMU bisection between one release only usually takes only half an hour or so for me. I use ../configure --target-list=x86_64-softmmu && make distclean && ../configure --target-list=x86_64-softmmu && make -j8 subdir-x86_64-softmmu Until it's below 50 commits. After that point just "make -j8 subdir-x86_64-softmmu" should do. This ensures that build system changes do not bite you as you move back and forth in time. Thanks! Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jun 27, 2014 at 01:41:30PM +0200, Paolo Bonzini wrote: > Il 27/06/2014 12:18, Borislav Petkov ha scritto: > >Joerg says I should bisect but I'm busy with other stuff. If people are > >interested in chasing this further, I could free up some time to do > >so... > > Please first try "-M pc-1.7" on the 2.0 QEMU. If it fails, please do bisect > it. A QEMU bisection between one release only usually takes only half an > hour or so for me. > > I use > > ../configure --target-list=x86_64-softmmu && make distclean && > ../configure --target-list=x86_64-softmmu && > make -j8 subdir-x86_64-softmmu > > Until it's below 50 commits. After that point just "make -j8 > subdir-x86_64-softmmu" should do. This ensures that build system changes do > not bite you as you move back and forth in time. Ok, thanks for the help. However, as it always happens, right after sending the mail, I triggered it with the qemu installed on the system too :-( I.e., qemu 1.7.1. So we will try to debug the #DF first to find out why kvm is injecting it in the first place. I'll keep you posted.
Il 27/06/2014 13:55, Borislav Petkov ha scritto: > On Fri, Jun 27, 2014 at 01:41:30PM +0200, Paolo Bonzini wrote: >> Il 27/06/2014 12:18, Borislav Petkov ha scritto: >>> Joerg says I should bisect but I'm busy with other stuff. If people are >>> interested in chasing this further, I could free up some time to do >>> so... >> >> Please first try "-M pc-1.7" on the 2.0 QEMU. If it fails, please do bisect >> it. A QEMU bisection between one release only usually takes only half an >> hour or so for me. >> >> I use >> >> ../configure --target-list=x86_64-softmmu && make distclean && >> ../configure --target-list=x86_64-softmmu && >> make -j8 subdir-x86_64-softmmu >> >> Until it's below 50 commits. After that point just "make -j8 >> subdir-x86_64-softmmu" should do. This ensures that build system changes do >> not bite you as you move back and forth in time. > > Ok, thanks for the help. > > However, as it always happens, right after sending the mail, I triggered > it with the qemu installed on the system too :-( I.e., qemu 1.7.1. :) Can you try gathering a trace? (and since those things get huge, you can send it to me offlist) Also try without ept and see what happens. Also, perhaps you can bisect between Linus's tree and tip? And finally, what is the host kernel? Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jun 27, 2014 at 02:01:43PM +0200, Paolo Bonzini wrote: > Can you try gathering a trace? (and since those things get huge, you > can send it to me offlist) Also try without ept and see what happens. Yeah, Joerg just sent me a diff on how to intercept #DF. I'll add a tracepoint so that it all goes into the trace together. > Also, perhaps you can bisect between Linus's tree and tip? Yep, that's next if we don't get smart from the #DF trace. > And finally, what is the host kernel? 3.16-rc2+ - "+" is tip/master from the last weekend with a couple of patches to arch/x86/ from me which should be unrelated (yeah, we've heard that before :-)). Thanks for the suggestions, I'm going for a run now but after I get back, debugging session starts with host and guest rebuilt afresh. :-) Stay tuned.
diff --git a/arch/x86/kernel/dumpstack_64.c b/arch/x86/kernel/dumpstack_64.c index 1abcb50b48ae..dd8e0eec071e 100644 --- a/arch/x86/kernel/dumpstack_64.c +++ b/arch/x86/kernel/dumpstack_64.c @@ -286,7 +286,7 @@ show_stack_log_lvl(struct task_struct *task, struct pt_regs *regs, } if (i && ((i % STACKSLOTS_PER_LINE) == 0)) pr_cont("\n"); - pr_cont(" %016lx", *stack++); + pr_cont(" %016lx", (((unsigned long)stack <= 0x00007fffffffffffUL) ? -1 : *stack++)); touch_nmi_watchdog(); } preempt_enable();