search for: do_double_fault

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("*** DOUBLE FAULT ***\n");...

...sm/traps.h index 58d66fe..ca32508 100644 --- a/arch/x86/include/asm/traps.h +++ b/arch/x86/include/asm/traps.h @@ -68,7 +68,7 @@ dotraplinkage void do_segment_not_present(struct pt_regs *, long); dotraplinkage void do_stack_segment(struct pt_regs *, long); #ifdef CONFIG_X86_64 dotraplinkage void do_double_fault(struct pt_regs *, long); -asmlinkage __kprobes struct pt_regs *sync_regs(struct pt_regs *); +asmlinkage struct pt_regs *sync_regs(struct pt_regs *); #endif dotraplinkage void do_general_protection(struct pt_regs *, long); dotraplinkage void do_page_fault(struct pt_regs *, unsigned long); diff --...

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

...12.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...

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

...ff8164024b>] 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...

...12.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...

...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/t...

...12.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...

...12.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. However, I would greatly appreciate a second opinion on the

Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've tried to implement new NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined, it is easy to maintain. This series

Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've tried to implement new NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined, it is easy to maintain. This series

Hi, Here is the version 3 of NOKPORBE_SYMBOL series. Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've introduced NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined

Hi, Here is the version 3 of NOKPORBE_SYMBOL series. Currently the blacklist is maintained by hand in kprobes.c which is separated from the function definition and is hard to catch up the kernel update. To solve this issue, I've introduced NOKPROBE_SYMBOL() macro for making kprobe blacklist at build time. Since the NOKPROBE_SYMBOL() macros can be placed right after the function is defined

This patch series is a reworking of a series developed by Mukesh Rathor at Oracle. The entirety of the design and development was done by him; I have only reworked, reorganized, and simplified things in a way that I think makes more sense. The vast majority of the credit for this effort therefore goes to him. This version is labelled v13 because it is based on his most recent series, v11.

...4.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...