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
