search for: double_fault

Thanks Richard for a fast reply. Yes, indeed, im working on a nested environment. I try to run v2v inside a VM (L1) and to create an L2 by the conversion process. And on Intel. As I wrote, it fails once in few times, mainly when there is a memory pressure on L0. Kashyap, can you please share your experience? Why should it crash during nested conversion. I'm not too familiar with libguestfs

...164024b>] dump_stack+0x45/0x56 >> [ 12.645305] [<ffffffff8163c272>] panic+0xc8/0x1d7 >> [ 12.645305] [<ffffffff8163c8e5>] ? printk+0x67/0x69 >> [ 12.645305] [<ffffffff81048ae1>] df_debug+0x31/0x40 >> [ 12.645305] [<ffffffff810132ed>] do_double_fault+0x5d/0x80 >> [ 12.645305] [<ffffffff81650b88>] double_fault+0x28/0x30 >> [ 12.645305] <<EOE>> > > Correct. > > I encountered this same double_fault panic a week ago: > > > http://kashyapc.fedorapeople.org/temp/double-fault-panic-nested-kvm-en...

Do so by simply re-using _show_registers(). Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/xen/arch/x86/x86_64/traps.c +++ b/xen/arch/x86/x86_64/traps.c @@ -225,6 +225,7 @@ void double_fault(void); void do_double_fault(struct cpu_user_regs *regs) { unsigned int cpu; + unsigned long crs[8]; watchdog_disable(); @@ -235,22 +236,18 @@ void do_double_fault(struct cpu_user_reg /* Find information saved during fault and dump it to the console. */ printk("***...

...p_stack+0x45/0x56 >>> [ 12.645305] [<ffffffff8163c272>] panic+0xc8/0x1d7 >>> [ 12.645305] [<ffffffff8163c8e5>] ? printk+0x67/0x69 >>> [ 12.645305] [<ffffffff81048ae1>] df_debug+0x31/0x40 >>> [ 12.645305] [<ffffffff810132ed>] do_double_fault+0x5d/0x80 >>> [ 12.645305] [<ffffffff81650b88>] double_fault+0x28/0x30 >>> [ 12.645305] <<EOE>> >> >> Correct. >> >> I encountered this same double_fault panic a week ago: >> >> >> http://kashyapc.fedorapeople.org/t...

...645305] <#DF> [<ffffffff8164024b>] dump_stack+0x45/0x56 [ 12.645305] [<ffffffff8163c272>] panic+0xc8/0x1d7 [ 12.645305] [<ffffffff8163c8e5>] ? printk+0x67/0x69 [ 12.645305] [<ffffffff81048ae1>] df_debug+0x31/0x40 [ 12.645305] [<ffffffff810132ed>] do_double_fault+0x5d/0x80 [ 12.645305] [<ffffffff81650b88>] double_fault+0x28/0x30 [ 12.645305] <<EOE>> Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network...

...645305] <#DF> [<ffffffff8164024b>] dump_stack+0x45/0x56 [ 12.645305] [<ffffffff8163c272>] panic+0xc8/0x1d7 [ 12.645305] [<ffffffff8163c8e5>] ? printk+0x67/0x69 [ 12.645305] [<ffffffff81048ae1>] df_debug+0x31/0x40 [ 12.645305] [<ffffffff810132ed>] do_double_fault+0x5d/0x80 [ 12.645305] [<ffffffff81650b88>] double_fault+0x28/0x30 [ 12.645305] <<EOE>> [ 12.645305] Rebooting in 1 seconds..libguestfs: child_cleanup: 0x3a05f50: child process died libguestfs: sending SIGTERM to process 1526 libguestfs: trace: mount_ro = -1 (error) libgue...

...645305] <#DF> [<ffffffff8164024b>] dump_stack+0x45/0x56 [ 12.645305] [<ffffffff8163c272>] panic+0xc8/0x1d7 [ 12.645305] [<ffffffff8163c8e5>] ? printk+0x67/0x69 [ 12.645305] [<ffffffff81048ae1>] df_debug+0x31/0x40 [ 12.645305] [<ffffffff810132ed>] do_double_fault+0x5d/0x80 [ 12.645305] [<ffffffff81650b88>] double_fault+0x28/0x30 [ 12.645305] <<EOE>> [ 12.645305] Rebooting in 1 seconds..libguestfs: child_cleanup: 0x3a05f50: child process died libguestfs: sending SIGTERM to process 1526 libguestfs: trace: mount_ro = -1 (error) libgue...

...645305] <#DF> [<ffffffff8164024b>] dump_stack+0x45/0x56 [ 12.645305] [<ffffffff8163c272>] panic+0xc8/0x1d7 [ 12.645305] [<ffffffff8163c8e5>] ? printk+0x67/0x69 [ 12.645305] [<ffffffff81048ae1>] df_debug+0x31/0x40 [ 12.645305] [<ffffffff810132ed>] do_double_fault+0x5d/0x80 [ 12.645305] [<ffffffff81650b88>] double_fault+0x28/0x30 [ 12.645305] <<EOE>> [ 12.645305] Rebooting in 1 seconds..libguestfs: child_cleanup: 0x3a05f50: child process died libguestfs: sending SIGTERM to process 1526 libguestfs: trace: mount_ro = -1 (error) libgu...

This series consists of improvements to Xen''s ability to print traces of its own stack, and specifically for the stack overflow case to be able to use frame pointers in a debug build. I have dev tested the series in debug and non-debug cases, with and without memory guards, and I believe that all the stack traces look correct (given the available information Xen has), and that the

...140042] [<ffffffff8102c039>] show_regs+0x70/0x1d8 [ 4.140042] [<ffffffff810aa597>] ? atomic_notifier_call_chain+0xf/0x11 [ 4.140042] [<ffffffff8102cf01>] __die+0xaa/0xe9 [ 4.140042] [<ffffffff8102cf82>] die+0x42/0x5e [ 4.140042] [<ffffffff8102aadb>] do_double_fault+0x5f/0x61 [ 4.140042] [<ffffffff8185a39d>] double_fault+0x2d/0x40 [ 4.140042] <<EOE>> [ 4.140042] Code: 4d 8b 76 f8 e8 e4 f9 81 00 eb 09 41 f7 c6 ff 1f 00 00 74 33 85 db 74 13 f6 c3 03 75 0e 48 c7 c7 12 4a b8 81 31 c0 e8 c2 f9 81 00 <49> 8b 36 4d 8d 7e 08 48 c7 c...