Re: KVM VM(windows xp) reseted when running geekbench for about 2 days
On Thu, Apr 18, 2013 at 12:00:49PM +, Zhanghaoyu (A) wrote: > I start 10 VMs(windows xp), then running geekbench tool on them, about 2 > days, one of them was reset, > I found the reset operation is done by > int kvm_cpu_exec(CPUArchState *env) > { > ... >switch (run->exit_reason) >... > case KVM_EXIT_SHUTDOWN: > DPRINTF("shutdown\n"); > qemu_system_reset_request(); > ret = EXCP_INTERRUPT; > break; > ... > } > > KVM_EXIT_SHUTDOWN exit reason was set previously in triple fault handle > handle_triple_fault(). > How do you know that reset was done here? This is not the only place where qemu_system_reset_request() is called. > What causes the triple fault? > Are you asking what is triple fault or why it happened in your case? For the former see here: http://en.wikipedia.org/wiki/Triple_fault For the later it is to late to tell after VM reset. You can run QEMU with -no-reboot -no-shutdown. VM will pause instead of rebooting and then you can examine what is going on. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: KVM VM(windows xp) reseted when running geekbench for about 2 days
On Apr 18, 2013, at 3:55 PM, Gleb Natapov wrote: > On Thu, Apr 18, 2013 at 12:00:49PM +, Zhanghaoyu (A) wrote: >> I start 10 VMs(windows xp), then running geekbench tool on them, about 2 >> days, one of them was reset, >> I found the reset operation is done by >> int kvm_cpu_exec(CPUArchState *env) >> { >>... >> switch (run->exit_reason) >> ... >>case KVM_EXIT_SHUTDOWN: >>DPRINTF("shutdown\n"); >>qemu_system_reset_request(); >>ret = EXCP_INTERRUPT; >>break; >>... >> } >> >> KVM_EXIT_SHUTDOWN exit reason was set previously in triple fault handle >> handle_triple_fault(). >> > How do you know that reset was done here? This is not the only place > where qemu_system_reset_request() is called. Make sure XP is not set to auto-reset in case of BSOD. Best regards, Yan. > >> What causes the triple fault? >> > Are you asking what is triple fault or why it happened in your case? > For the former see here: http://en.wikipedia.org/wiki/Triple_fault > For the later it is to late to tell after VM reset. You can run QEMU with > -no-reboot -no-shutdown. VM will pause instead of rebooting and then you > can examine what is going on. > > -- > Gleb. > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: KVM VM(windows xp) reseted when running geekbench for about 2 days
>> On Thu, Apr 18, 2013 at 12:00:49PM +, Zhanghaoyu (A) wrote: >>> I start 10 VMs(windows xp), then running geekbench tool on them, >>> about 2 days, one of them was reset, I found the reset operation is >>> done by int kvm_cpu_exec(CPUArchState *env) { >>>... >>> switch (run->exit_reason) >>> ... >>>case KVM_EXIT_SHUTDOWN: >>>DPRINTF("shutdown\n"); >>>qemu_system_reset_request(); >>>ret = EXCP_INTERRUPT; >>>break; >>>... >>> } >>> >>> KVM_EXIT_SHUTDOWN exit reason was set previously in triple fault handle >>> handle_triple_fault(). >>> >> How do you know that reset was done here? This is not the only place >> where qemu_system_reset_request() is called. I used gdb to debug QEMU process, and add a breakpoint in qemu_system_reset_request(), when the case occurred, backtrace shown as below, (gdb) bt #0 qemu_system_reset_request () at vl.c:1964 #1 0x7f9ef9dc5991 in kvm_cpu_exec (env=0x7f9efac47100) at /gt/qemu-kvm-1.4/qemu-kvm-1.4/kvm-all.c:1602 #2 0x7f9ef9d5b229 in qemu_kvm_cpu_thread_fn (arg=0x7f9efac47100) at /gt/qemu-kvm-1.4/qemu-kvm-1.4/cpus.c:759 #3 0x7f9ef898b5f0 in start_thread () from /lib64/libpthread.so.0 #4 0x7f9ef86fa84d in clone () from /lib64/libc.so.6 #5 0x in ?? () And, I add printk log in all place where KVM_EXIT_SHUTDOWN exit reason is set, only handle_triple_fault() was called. > >Make sure XP is not set to auto-reset in case of BSOD. No, winxp is not set to auto-reset in case of BSOD. No Winxp event log reported. > >Best regards, >Yan. > >> >>> What causes the triple fault? >>> >> Are you asking what is triple fault or why it happened in your case? What I asked is why triple fault happened in my case. >> For the former see here: http://en.wikipedia.org/wiki/Triple_fault >> For the later it is to late to tell after VM reset. You can run QEMU >> with -no-reboot -no-shutdown. VM will pause instead of rebooting and >> then you can examine what is going on. Great thanks, I'll run QEMU with -no-reboot -no-shutdown options, if VM paused in my case, what should I examined? Thanks, Zhang Haoyu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: KVM VM(windows xp) reseted when running geekbench for about 2 days
On Fri, Apr 19, 2013 at 01:05:08AM +, Zhanghaoyu (A) wrote: > >> On Thu, Apr 18, 2013 at 12:00:49PM +, Zhanghaoyu (A) wrote: > >>> I start 10 VMs(windows xp), then running geekbench tool on them, > >>> about 2 days, one of them was reset, I found the reset operation is > >>> done by int kvm_cpu_exec(CPUArchState *env) { > >>>... > >>> switch (run->exit_reason) > >>> ... > >>>case KVM_EXIT_SHUTDOWN: > >>>DPRINTF("shutdown\n"); > >>>qemu_system_reset_request(); > >>>ret = EXCP_INTERRUPT; > >>>break; > >>>... > >>> } > >>> > >>> KVM_EXIT_SHUTDOWN exit reason was set previously in triple fault handle > >>> handle_triple_fault(). > >>> > >> How do you know that reset was done here? This is not the only place > >> where qemu_system_reset_request() is called. > I used gdb to debug QEMU process, and add a breakpoint in > qemu_system_reset_request(), when the case occurred, backtrace shown as below, > (gdb) bt > #0 qemu_system_reset_request () at vl.c:1964 > #1 0x7f9ef9dc5991 in kvm_cpu_exec (env=0x7f9efac47100) > at /gt/qemu-kvm-1.4/qemu-kvm-1.4/kvm-all.c:1602 > #2 0x7f9ef9d5b229 in qemu_kvm_cpu_thread_fn (arg=0x7f9efac47100) > at /gt/qemu-kvm-1.4/qemu-kvm-1.4/cpus.c:759 > #3 0x7f9ef898b5f0 in start_thread () from /lib64/libpthread.so.0 > #4 0x7f9ef86fa84d in clone () from /lib64/libc.so.6 > #5 0x in ?? () > > And, I add printk log in all place where KVM_EXIT_SHUTDOWN exit reason is > set, only handle_triple_fault() was called. > > > >Make sure XP is not set to auto-reset in case of BSOD. > No, winxp is not set to auto-reset in case of BSOD. No Winxp event log > reported. > > > >Best regards, > >Yan. > > > >> > >>> What causes the triple fault? > >>> > >> Are you asking what is triple fault or why it happened in your case? > What I asked is why triple fault happened in my case. > >> For the former see here: http://en.wikipedia.org/wiki/Triple_fault > >> For the later it is to late to tell after VM reset. You can run QEMU > >> with -no-reboot -no-shutdown. VM will pause instead of rebooting and > >> then you can examine what is going on. > Great thanks, I'll run QEMU with -no-reboot -no-shutdown options, if VM > paused in my case, what should I examined? > Register state "info registers" in the monitor for each vcpu. Code around the instruction that faulted. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: KVM VM(windows xp) reseted when running geekbench for about 2 days
>> >> On Thu, Apr 18, 2013 at 12:00:49PM +, Zhanghaoyu (A) wrote: >> >>> I start 10 VMs(windows xp), then running geekbench tool on them, >> >>> about 2 days, one of them was reset, I found the reset operation >> >>> is done by int kvm_cpu_exec(CPUArchState *env) { >> >>>... >> >>> switch (run->exit_reason) >> >>> ... >> >>>case KVM_EXIT_SHUTDOWN: >> >>>DPRINTF("shutdown\n"); >> >>>qemu_system_reset_request(); >> >>>ret = EXCP_INTERRUPT; >> >>>break; >> >>>... >> >>> } >> >>> >> >>> KVM_EXIT_SHUTDOWN exit reason was set previously in triple fault handle >> >>> handle_triple_fault(). >> >>> >> >> How do you know that reset was done here? This is not the only >> >> place where qemu_system_reset_request() is called. >> I used gdb to debug QEMU process, and add a breakpoint in >> qemu_system_reset_request(), when the case occurred, backtrace shown >> as below, >> (gdb) bt >> #0 qemu_system_reset_request () at vl.c:1964 >> #1 0x7f9ef9dc5991 in kvm_cpu_exec (env=0x7f9efac47100) >> at /gt/qemu-kvm-1.4/qemu-kvm-1.4/kvm-all.c:1602 >> #2 0x7f9ef9d5b229 in qemu_kvm_cpu_thread_fn (arg=0x7f9efac47100) >> at /gt/qemu-kvm-1.4/qemu-kvm-1.4/cpus.c:759 >> #3 0x7f9ef898b5f0 in start_thread () from /lib64/libpthread.so.0 >> #4 0x7f9ef86fa84d in clone () from /lib64/libc.so.6 >> #5 0x in ?? () >> >> And, I add printk log in all places where KVM_EXIT_SHUTDOWN exit reason is >> set, only handle_triple_fault() was called. >> > >> >Make sure XP is not set to auto-reset in case of BSOD. >> No, winxp is not set to auto-reset in case of BSOD. No Winxp event log >> reported. >> > >> >Best regards, >> >Yan. >> > >> >> >> >>> What causes the triple fault? >> >>> >> >> Are you asking what is triple fault or why it happened in your case? >> What I asked is why triple fault happened in my case. >> >> For the former see here: http://en.wikipedia.org/wiki/Triple_fault >> >> For the later it is to late to tell after VM reset. You can run >> >> QEMU with -no-reboot -no-shutdown. VM will pause instead of >> >> rebooting and then you can examine what is going on. >> Great thanks, I'll run QEMU with -no-reboot -no-shutdown options, if VM >> paused in my case, what should I examined? >> >Register state "info registers" in the monitor for each vcpu. Code around the >instruction that faulted. I ran the QEMU with -no-reboot -no-shutdown options, the VM paused When the case happened, then I info registers in QEMU monitor, shown as below, CS =0008 00c09b00 DPL =0 CS32 [-RA] SS =0010 00c09300 DPL =0 DS [-WA] DS =0023 00c0f300 DPL =3 DS [-WA] FS =0030 ffdff000 1fff 00c09300 DPL =0 DS [-WA] GS = 00c0 LDT= 00c0 TR =0028 80042000 20ab 8b00 DPL=0 TSS32-busy GDT= 8003f000 03ff IDT= 8003f400 07ff CR0=8001003b CR2=760d7fe4 CR3=002ec000 CR4=06f8 DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER=0800 FCW=027f FSW= [ST=0] FTW=00 MXCSR=1f80 FPR0= FPR1= FPR2= FPR3= FPR4= FPR5= FPR6= FPR7= XMM00= XMM01= XMM02= XMM03= XMM04= XMM05= XMM06= XMM07= In normal case, info registers in QEMU monitor, shown as below CS =001b 00c0fb00 DPL=3 CS32 [-RA] SS =0023 00c0f300 DPL=3 DS [-WA] DS =0023 00c0f300 DPL=3 DS [-WA] FS =0038 7ffda000 0fff 0040f300 DPL=3 DS [-WA] GS = 0100 LDT= TR =0028 80042000 20ab 8b00 DPL=0 TSS32-busy GDT= 8003f000 03ff IDT= 8003f400 07ff CR0=80010031 CR2=0167fd20 CR3=0af00220 CR4=06f8 DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER=0800 FCW=027f FSW= [ST=0] FTW=00 MXCSR=1f80 FPR0=00a400a40a18 d830 FPR1=0012f9c07c90e900 e900 FPR2=7c910202 5d40 FPR3=01e27c903400 f808 FPR4=05230012f87a FPR5=7c905d40 0001 FPR6=0001 FPR7=a9dfde00 4018 XMM00=7c917d9a0012f8d47c90 XMM01=0012f8740012f8740012f87a7c90 XMM02=7c917de97c97b1787c917e3f0012f87a XMM03=0012fa687c80901a0012f9186cfd XMM04=7c9102027c9034007c9102087c90e900 XMM05=000c7c900012f9907c91017b XMM06=9a400012f8780012f878 XMM07=6365446c74527c91340500241f18 N.B. in two c
Re: KVM VM(windows xp) reseted when running geekbench for about 2 days
On Tue, Apr 23, 2013 at 08:21:29AM +, Zhanghaoyu (A) wrote: > >> >> On Thu, Apr 18, 2013 at 12:00:49PM +, Zhanghaoyu (A) wrote: > >> >>> I start 10 VMs(windows xp), then running geekbench tool on them, > >> >>> about 2 days, one of them was reset, I found the reset operation > >> >>> is done by int kvm_cpu_exec(CPUArchState *env) { > >> >>>... > >> >>> switch (run->exit_reason) > >> >>> ... > >> >>>case KVM_EXIT_SHUTDOWN: > >> >>>DPRINTF("shutdown\n"); > >> >>>qemu_system_reset_request(); > >> >>>ret = EXCP_INTERRUPT; > >> >>>break; > >> >>>... > >> >>> } > >> >>> > >> >>> KVM_EXIT_SHUTDOWN exit reason was set previously in triple fault > >> >>> handle handle_triple_fault(). > >> >>> > >> >> How do you know that reset was done here? This is not the only > >> >> place where qemu_system_reset_request() is called. > >> I used gdb to debug QEMU process, and add a breakpoint in > >> qemu_system_reset_request(), when the case occurred, backtrace shown > >> as below, > >> (gdb) bt > >> #0 qemu_system_reset_request () at vl.c:1964 > >> #1 0x7f9ef9dc5991 in kvm_cpu_exec (env=0x7f9efac47100) > >> at /gt/qemu-kvm-1.4/qemu-kvm-1.4/kvm-all.c:1602 > >> #2 0x7f9ef9d5b229 in qemu_kvm_cpu_thread_fn (arg=0x7f9efac47100) > >> at /gt/qemu-kvm-1.4/qemu-kvm-1.4/cpus.c:759 > >> #3 0x7f9ef898b5f0 in start_thread () from /lib64/libpthread.so.0 > >> #4 0x7f9ef86fa84d in clone () from /lib64/libc.so.6 > >> #5 0x in ?? () > >> > >> And, I add printk log in all places where KVM_EXIT_SHUTDOWN exit reason is > >> set, only handle_triple_fault() was called. > >> > > >> >Make sure XP is not set to auto-reset in case of BSOD. > >> No, winxp is not set to auto-reset in case of BSOD. No Winxp event log > >> reported. > >> > > >> >Best regards, > >> >Yan. > >> > > >> >> > >> >>> What causes the triple fault? > >> >>> > >> >> Are you asking what is triple fault or why it happened in your case? > >> What I asked is why triple fault happened in my case. > >> >> For the former see here: http://en.wikipedia.org/wiki/Triple_fault > >> >> For the later it is to late to tell after VM reset. You can run > >> >> QEMU with -no-reboot -no-shutdown. VM will pause instead of > >> >> rebooting and then you can examine what is going on. > >> Great thanks, I'll run QEMU with -no-reboot -no-shutdown options, if VM > >> paused in my case, what should I examined? > >> > >Register state "info registers" in the monitor for each vcpu. Code around > >the instruction that faulted. > > I ran the QEMU with -no-reboot -no-shutdown options, the VM paused When the > case happened, then I info registers in QEMU monitor, shown as below, > CS =0008 00c09b00 DPL =0 CS32 [-RA] > SS =0010 00c09300 DPL =0 DS [-WA] > DS =0023 00c0f300 DPL =3 DS [-WA] > FS =0030 ffdff000 1fff 00c09300 DPL =0 DS [-WA] > GS = 00c0 > LDT= 00c0 > TR =0028 80042000 20ab 8b00 DPL=0 TSS32-busy > GDT= 8003f000 03ff > IDT= 8003f400 07ff > CR0=8001003b CR2=760d7fe4 CR3=002ec000 CR4=06f8 > DR0= DR1= DR2= > DR3= > DR6=0ff0 DR7=0400 > EFER=0800 > FCW=027f FSW= [ST=0] FTW=00 MXCSR=1f80 > FPR0= FPR1= > FPR2= FPR3= > FPR4= FPR5= > FPR6= FPR7= > XMM00= XMM01= > XMM02= XMM03= > XMM04= XMM05= > XMM06= XMM07= > > In normal case, info registers in QEMU monitor, shown as below > CS =001b 00c0fb00 DPL=3 CS32 [-RA] > SS =0023 00c0f300 DPL=3 DS [-WA] > DS =0023 00c0f300 DPL=3 DS [-WA] > FS =0038 7ffda000 0fff 0040f300 DPL=3 DS [-WA] > GS = 0100 > LDT= > TR =0028 80042000 20ab 8b00 DPL=0 TSS32-busy > GDT= 8003f000 03ff > IDT= 8003f400 07ff > CR0=80010031 CR2=0167fd20 CR3=0af00220 CR4=06f8 > DR0= DR1= DR2= > DR3= > DR6=0ff0 DR7=0400 > EFER=0800 > FCW=027f FSW= [ST=0] FTW=00 MXCSR=1f80 > FPR0=00a400a40a18 d830 FPR1=0012f9c07c90e900 e900 > FPR2=7c910202 5d40 FPR3=01e27c903400 f808 > FPR4=05230012f87a FPR5=7c905d40 0001 > FPR6=0001 FPR7=a9dfde00 4018 > XMM00=7c917d9a0012f8d47c90 XMM01=0012f87
Re: KVM VM(windows xp) reseted when running geekbench for about 2 days
>> >> >> On Thu, Apr 18, 2013 at 12:00:49PM +, Zhanghaoyu (A) wrote: >> >> >>> I start 10 VMs(windows xp), then running geekbench tool on >> >> >>> them, about 2 days, one of them was reset, I found the reset >> >> >>> operation is done by int kvm_cpu_exec(CPUArchState *env) { >> >> >>>... >> >> >>> switch (run->exit_reason) >> >> >>> ... >> >> >>>case KVM_EXIT_SHUTDOWN: >> >> >>>DPRINTF("shutdown\n"); >> >> >>>qemu_system_reset_request(); >> >> >>>ret = EXCP_INTERRUPT; >> >> >>>break; >> >> >>>... >> >> >>> } >> >> >>> >> >> >>> KVM_EXIT_SHUTDOWN exit reason was set previously in triple fault >> >> >>> handle handle_triple_fault(). >> >> >>> >> >> >> How do you know that reset was done here? This is not the only >> >> >> place where qemu_system_reset_request() is called. >> >> I used gdb to debug QEMU process, and add a breakpoint in >> >> qemu_system_reset_request(), when the case occurred, backtrace >> >> shown as below, >> >> (gdb) bt >> >> #0 qemu_system_reset_request () at vl.c:1964 >> >> #1 0x7f9ef9dc5991 in kvm_cpu_exec (env=0x7f9efac47100) >> >> at /gt/qemu-kvm-1.4/qemu-kvm-1.4/kvm-all.c:1602 >> >> #2 0x7f9ef9d5b229 in qemu_kvm_cpu_thread_fn (arg=0x7f9efac47100) >> >> at /gt/qemu-kvm-1.4/qemu-kvm-1.4/cpus.c:759 >> >> #3 0x7f9ef898b5f0 in start_thread () from >> >> /lib64/libpthread.so.0 >> >> #4 0x7f9ef86fa84d in clone () from /lib64/libc.so.6 >> >> #5 0x in ?? () >> >> >> >> And, I add printk log in all places where KVM_EXIT_SHUTDOWN exit reason >> >> is set, only handle_triple_fault() was called. >> >> > >> >> >Make sure XP is not set to auto-reset in case of BSOD. >> >> No, winxp is not set to auto-reset in case of BSOD. No Winxp event log >> >> reported. >> >> > >> >> >Best regards, >> >> >Yan. >> >> > >> >> >> >> >> >>> What causes the triple fault? >> >> >>> >> >> >> Are you asking what is triple fault or why it happened in your case? >> >> What I asked is why triple fault happened in my case. >> >> >> For the former see here: >> >> >> http://en.wikipedia.org/wiki/Triple_fault >> >> >> For the later it is to late to tell after VM reset. You can run >> >> >> QEMU with -no-reboot -no-shutdown. VM will pause instead of >> >> >> rebooting and then you can examine what is going on. >> >> Great thanks, I'll run QEMU with -no-reboot -no-shutdown options, if VM >> >> paused in my case, what should I examined? >> >> >> >Register state "info registers" in the monitor for each vcpu. Code around >> >the instruction that faulted. >> >> I ran the QEMU with -no-reboot -no-shutdown options, the VM paused >> When the case happened, then I info registers in QEMU monitor, shown as >> below, CS =0008 00c09b00 DPL =0 CS32 [-RA] >> SS =0010 00c09300 DPL =0 DS [-WA] >> DS =0023 00c0f300 DPL =3 DS [-WA] >> FS =0030 ffdff000 1fff 00c09300 DPL =0 DS [-WA] >> GS = 00c0 >> LDT= 00c0 >> TR =0028 80042000 20ab 8b00 DPL=0 TSS32-busy >> GDT= 8003f000 03ff >> IDT= 8003f400 07ff >> CR0=8001003b CR2=760d7fe4 CR3=002ec000 CR4=06f8 >> DR0= DR1= DR2= >> DR3= DR6=0ff0 DR7=0400 >> EFER=0800 FCW=027f FSW= [ST=0] FTW=00 MXCSR=1f80 >> FPR0= FPR1= >> FPR2= FPR3= >> FPR4= FPR5= >> FPR6= FPR7= >> XMM00= >> XMM01= >> XMM02= >> XMM03= >> XMM04= >> XMM05= >> XMM06= >> XMM07= >> >> In normal case, info registers in QEMU monitor, shown as below CS >> =001b 00c0fb00 DPL=3 CS32 [-RA] >> SS =0023 00c0f300 DPL=3 DS [-WA] >> DS =0023 00c0f300 DPL=3 DS [-WA] >> FS =0038 7ffda000 0fff 0040f300 DPL=3 DS [-WA] >> GS = 0100 >> LDT= >> TR =0028 80042000 20ab 8b00 DPL=0 TSS32-busy >> GDT= 8003f000 03ff >> IDT= 8003f400 07ff >> CR0=80010031 CR2=0167fd20 CR3=0af00220 CR4=06f8 >> DR0= DR1= DR2= >> DR3= DR6=0ff0 DR7=0400 >> EFER=0800 FCW=027f FSW= [ST=0] FTW=00 MXCSR=1f80 >> FPR0=00a400a40a18 d830 FPR1=0012f9c07c90e900 e900 >> FPR2=7c910202 5d40 FPR3=01e27c903400 f808 >> FPR4=05230012f87a FPR5=7c905d40 0001 >> FPR6=0001 FPR7=a