search for: show_registers

...t, I suggest adding tracing to >vmx_vmexit_handler() to dump registers on every MSR write. >Something like >this early on in the function: > if ( reason == EXIT_REASON_MSR_WRITE ) { > printk("regs==%p, guest_regs==%p\n", &regs, >guest_cpu_user_regs()); > show_registers(&regs); > } > >This will let us see if the EAX/EDX are garbage on entry to C code >immediately after VMEXIT. This patch doesn''t help, after applying it, all is OK. -Xin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com ht...

...14857 kernel: e8cffd7c c011bd9b e8ca6000 e8c6f788 e8c6f740 e8cffd90 c011be50 e8c6f740 14857 kernel: e8cffde8 00007ff0 e8cffe20 c0170a8a e8c6f740 e8c6f740 c030b547 e8cffdb8 14857 kernel: Call Trace: 14857 kernel: [<c01058bd>] show_stack_log_lvl+0xcd/0x120 14857 kernel: [<c0105abb>] show_registers+0x1ab/0x240 14857 kernel: [<c0105dc1>] die+0x111/0x240 14857 kernel: [<c01130a7>] do_page_fault+0x5f7/0x931 14857 kernel: [<c01052ab>] error_code+0x2b/0x30 14857 kernel: [<c011bd9b>] __mmdrop+0x1b/0x50 14857 kernel: [<c011be50>] mmput+0x80/0xa0 14857 kernel: [&lt...

...000, task 000001032c2e5030) Stack: 0000003000000008 00000102fc7a6e88 00000102fc7a6dc8 0000000000000013 0000000000000000 0000000000000046 0000000000029bd5 0000000000000046 0000000000000004 ffffffff8031fad8 Call Trace:<ffffffff80111860>{show_stack+241} <ffffffff8011198a>{show_registers+277} <ffffffff80111c91>{die_nmi+130} <ffffffff8011d055>{nmi_watchdog_tick+210} <ffffffff8011255e>{default_do_nmi+112} <ffffffff8011d10b>{do_nmi+115} <ffffffff80111173>{paranoid_exit+0} <ffffffff8030a9aa>{.text.lock.spinlock+46}...

...l2e_rw_fault: 400 0xffff83000017d0c0 l2e_rw_fault: 400 0xffff830000188881 l2e_rw_fault: 400 0xffff830000196219 handle_mmio: 400 0xffff8300001356d4 load_segments: 384 0xffff8300001b9363 show_registers: 384 0xffff8300001b9a60 show_registers: 384 0xffff830000116079 do_multicall: 376 0xffff8300001166bb do_multicall: 376 0xffff830000165c39 resync_all: 376 0xffff83000016683f resync_all:...

...tack: 00000000 d06cea20 2f001020 c8b04780 c0403f1c c028cbfa 0002f001 0000000d ffffffff 08b78020 00000052 00000001 00000028 0000005e 00008b85 d21fe000 00000006 c0457824 0000011d c0453240 00283d58 e01c3a6e c0403cec da6bccd0 Call Trace: [<c0109c51>] show_stack+0x80/0x96 [<c0100de1>] show_registers+0x15a/0x1d1 [<c010a001>] die+0x106/0x1c4 [<c010a4aa>] do_invalid_op+0xb5/0xbf [<c010985b>] error_code+0x2b/0x30 [<c028cbfa>] net_rx_action+0x484/0x4df [<c01239a9>] tasklet_action+0x7b/0xe0 [<c0123533>] __do_softirq+0x6f/0xef [<c0123632>] do_softirq+0...

...tack: 00000000 d06cea20 2f001020 c8b04780 c0403f1c c028cbfa 0002f001 0000000d ffffffff 08b78020 00000052 00000001 00000028 0000005e 00008b85 d21fe000 00000006 c0457824 0000011d c0453240 00283d58 e01c3a6e c0403cec da6bccd0 Call Trace: [<c0109c51>] show_stack+0x80/0x96 [<c0100de1>] show_registers+0x15a/0x1d1 [<c010a001>] die+0x106/0x1c4 [<c010a4aa>] do_invalid_op+0xb5/0xbf [<c010985b>] error_code+0x2b/0x30 [<c028cbfa>] net_rx_action+0x484/0x4df [<c01239a9>] tasklet_action+0x7b/0xe0 [<c0123533>] __do_softirq+0x6f/0xef [<c0123632>] do_softirq+0...

...e same results. Not sure where to go with this(?). Should I post this on a kernel mailing list? Or somewhere else? Call Trace: [<C040502c>] dump_trace+0x8c/0x96 [<c0405046>] show_trace_log_lvl+0x10/0x20 [<c04050e2>] show_stack_log_lvl+0x8c/0x94 [<c040520f>] show_registers+0x125/0x191 [<c0404c3b>] kernel_thread_helper+0x7/0x10 [<c0405411>] die+0x196/0x296 [<c05fd73f>] do_page_fault+0x3ea/0x4b8 [<c0434d15>] kthread+0x0/0xeb [<c05fd355>] do_page_fault+0x0/0x4b8 [<c0404a71>] error_code+0x39/0x40 [<c0434d15>]...

...5f8 c003bec4 c1114400 00000000 00000001 c003beac c020543f c1114400 00000000 00000001 00000000 00000000 00000000 c1170000 00000000 c003bec4 c02083d8 00000000 ffffffed c1138b80 00000001 c003bef4 Call Trace: [<c0109faf>] show_stack+0x7f/0xa0 [<c010a14f>] show_registers+0x15f/0x1e0 [<c010a384>] die+0xf4/0x180 [<c01155e4>] do_page_fault+0x4b4/0x761 [<c0109c37>] error_code+0x2b/0x30 [<c020543f>] vc_allocate+0x8f/0x150 [<c02083d8>] con_open+0x48/0xb0 [<c01f8b60>] tty_open+0x1b0/0x330...

...5f8 c003bec4 c1114400 00000000 00000001 c003beac c020543f c1114400 00000000 00000001 00000000 00000000 00000000 c1170000 00000000 c003bec4 c02083d8 00000000 ffffffed c1138b80 00000001 c003bef4 Call Trace: [<c0109faf>] show_stack+0x7f/0xa0 [<c010a14f>] show_registers+0x15f/0x1e0 [<c010a384>] die+0xf4/0x180 [<c01155e4>] do_page_fault+0x4b4/0x761 [<c0109c37>] error_code+0x2b/0x30 [<c020543f>] vc_allocate+0x8f/0x150 [<c02083d8>] con_open+0x48/0xb0 [<c01f8b60>] tty_open+0x1b0/0x330...

changeset: 8830:fcc833cbaf82 tag: tip user: kaf24@firebug.cl.cam.ac.uk date: Mon Feb 13 10:41:23 2006 +0100 summary: Return real error code from Xen /dev/mem, not EAGAIN. x460: x86_32: Status: - dom0 boots fine - xend loads fine - single HVM domain loads fine - Multiple HVM domains load fine - destruction of any HVM domain causes dom0 to reboot Issues affecting

...h > --- a/xen/include/asm-x86/processor.h   Wed Feb 24 11:10:09 2010 +0000 > +++ b/xen/include/asm-x86/processor.h   Wed Feb 24 11:11:05 2010 +0000 > @@ -532,6 +532,7 @@ void show_stack_overflow(unsigned int cp >  void show_stack_overflow(unsigned int cpu, unsigned long esp); >  void show_registers(struct cpu_user_regs *regs); >  void show_execution_state(struct cpu_user_regs *regs); > +#define dump_execution_state() run_in_exception_handler(show_execution_state) >  void show_page_walk(unsigned long addr); >  asmlinkage void fatal_trap(int trapnr, struct cpu_user_regs *regs); >...

...) { case 0: case 2: case 4: diff -r 93d95f6dd693 -r 0339f85f6068 xen/arch/x86/x86_64/traps.c --- a/xen/arch/x86/x86_64/traps.c Fri Jan 11 16:22:57 2013 -0800 +++ b/xen/arch/x86/x86_64/traps.c Fri Jan 11 16:24:00 2013 -0800 @@ -127,10 +127,10 @@ void show_registers(struct cpu_user_regs fault_crs[0] = read_cr0(); fault_crs[3] = read_cr3(); fault_crs[4] = read_cr4(); - fault_regs.ds = read_segment_register(ds); - fault_regs.es = read_segment_register(es); - fault_regs.fs = read_segment_register(fs); - fault...

...98afc b0383f40 b0395746 00000032 b0398cfc 00000000 00000000 e84824c0 ca281dc0 bf4a483c c13bcf60 b01317c2 bf4a483c 00000000 00000000 e84824c0 ffffffe4 bf4a483c c13bcf80 b01458ce e84824c0 dce74d9c 00000001 a7004000 Call Trace: [<b01032cb>] show_stack+0xab/0xf0 [<b0103494>] show_registers+0x164/0x200 [<b01036a8>] die+0xc8/0x150 [<b01037b9>] do_trap+0x89/0xd0 [<b0103b1a>] do_invalid_op+0xaa/0xc0 [<b0102eef>] error_code+0x4f/0x54 [<b01458ce>] msync_interval+0x8e/0xd0 [<b0145a6f>] sys_msync+0x15f/0x171 [<b0102c69>] syscall_call+0x7/0xb C...

...b1 00009e5c 000000c8 ffff0292 9e7000c0 00000001 530a0000 00200016 00b8467c 00000000 bc569ebc b0111311 00000060 bc569ebc 00200292 b11e007b 0020007b 00000000 b1292d98 00000000 00000000 a7df0000 bc560000 bc569f1a Call Trace: [<b010425b>] show_stack+0x9b/0xb0 [<b01043ab>] show_registers+0x11b/0x190 [<b0104575>] die+0xb5/0x130 [<b0104d1a>] do_general_protection+0x13a/0x160 [<b0103e5f>] error_code+0x4f/0x60 [<ffff0292>] 0xffff0292 Code: Bad EIP value.

...000 Oct 20 16:52:24 pototogorri kernel: 00000010 c8ebc7e0 00000048 c4c99cb0 c4c99cfc c0262297 c8ebc7e0 c155b6a0 Oct 20 16:52:24 pototogorri kernel: Call Trace: Oct 20 16:52:24 pototogorri kernel: [<c010707b>] show_stack+0x9b/0xb0 Oct 20 16:52:24 pototogorri kernel: [<c01071cb>] show_registers+0x11b/0x180 Oct 20 16:52:24 pototogorri kernel: [<c0107310>] die+0x50/0xb0 Oct 20 16:52:24 pototogorri kernel: [<c0117280>] do_page_fault+0x330/0x5b8 Oct 20 16:52:24 pototogorri kernel: [<c0106cbd>] error_code+0x2d/0x40 Oct 20 16:52:24 pototogorri kernel: [<c0268a62>] tc...

...14>] serial8250_console_write+0x0/0x1bc [<021d9314>] serial8250_console_write+0x0/0x1bc [<02123bc0>] kernel_text_address+0x2b/0x37 [<0210605a>] print_context_stack+0x37/0x44 [<021060ba>] show_trace+0x53/0x77 [<02106159>] show_stack+0x7b/0x81 [<02106250>] show_registers+0xde/0x177 [<021063a7>] die+0x59/0xaf [<021146f3>] do_page_fault+0x2f7/0x446 [<02192ba5>] __delay+0x9/0xa [<021d948a>] serial8250_console_write+0x176/0x1bc [<021d9314>] serial8250_console_write+0x0/0x1bc [<02115e8c>] __wake_up_common+0x32/0x54 [<0210736...

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

...00001 00000000 c3913f28 c010e3ba 00000007 00000001 00000007       c3913f34 c010e425 c03bd804 c3913f48 c012fae8 ffffffea 00000001 c568c570       c3913f7c c013b889 c3913fc0 00000002 00000001 00000000 00000003 00000000 Call Trace:  [<c0105401>] show_stack_log_lvl+0xa1/0xe0  [<c01055f1>] show_registers+0x181/0x200  [<c0105810>] die+0x100/0x1a0  [<c01156f6>] do_page_fault+0x3c6/0x8b1  [<c0105067>] error_code+0x2b/0x30  [<c010e3ba>] cache_remove_dev+0x2a/0x60  [<c010e425>] cacheinfo_cpu_callback+0x35/0x40  [<c012fae8>] notifier_call_chain+0x18/0x40  [<c013b889...

...800 Oct 14 16:09:27 pototogorri kernel: 00000010 dce34a40 00000048 c204dcb0 c204dcfc c0262297 dce34a40 ddeca280 Oct 14 16:09:27 pototogorri kernel: Call Trace: Oct 14 16:09:27 pototogorri kernel: [<c010707b>] show_stack+0x9b/0xb0 Oct 14 16:09:27 pototogorri kernel: [<c01071cb>] show_registers+0x11b/0x180 Oct 14 16:09:27 pototogorri kernel: [<c0107310>] die+0x50/0xb0 Oct 14 16:09:27 pototogorri kernel: [<c0117280>] do_page_fault+0x330/0x5b8 Oct 14 16:09:27 pototogorri kernel: [<c0106cbd>] error_code+0x2d/0x40 Oct 14 16:09:27 pototogorri kernel: [<c0268a62>] tc...

Hi, For various bad reasons I must run a kernel 2.2.X and I tried to get it running on Xen 3.0.3. The virtual machine freeze every 28s (or less) for 1-3 secs which makes it unusable as demonstrated by: # while true; do date; sleep 1; done Thu Oct 26 18:03:36 PDT 2006 <missing> Thu Oct 26 18:03:38 PDT 2006 or # ping my-xen 64 bytes from 172.21.1.102: icmp_seq=0 ttl=255 time=8.5 ms 64