search for: int_ret_from_sys_call

...ension */ pushq $__USER32_DS CFI_ADJUST_CFA_OFFSET 8 @@ -123,7 +130,7 @@ sysenter_do_call: call *ia32_sys_call_table(,%rax,8) movq %rax,RAX-ARGOFFSET(%rsp) GET_THREAD_INFO(%r10) - cli + DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_OFF testl $_TIF_ALLWORK_MASK,threadinfo_flags(%r10) jnz int_ret_from_sys_call @@ -141,7 +148,7 @@ sysenter_do_call: CFI_REGISTER rip,rdx TRACE_IRQS_ON swapgs - sti /* sti only takes effect after the next instruction */ + ENABLE_INTERRUPTS(CLBR_NONE) /* sti only takes effect after the next instruction */ /* sysexit */ .byte 0xf, 0x35 @@ -199,7 +206,7 @@ ENTRY(i...

...ension */ pushq $__USER32_DS CFI_ADJUST_CFA_OFFSET 8 @@ -123,7 +130,7 @@ sysenter_do_call: call *ia32_sys_call_table(,%rax,8) movq %rax,RAX-ARGOFFSET(%rsp) GET_THREAD_INFO(%r10) - cli + DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_OFF testl $_TIF_ALLWORK_MASK,threadinfo_flags(%r10) jnz int_ret_from_sys_call @@ -141,7 +148,7 @@ sysenter_do_call: CFI_REGISTER rip,rdx TRACE_IRQS_ON swapgs - sti /* sti only takes effect after the next instruction */ + ENABLE_INTERRUPTS(CLBR_NONE) /* sti only takes effect after the next instruction */ /* sysexit */ .byte 0xf, 0x35 @@ -199,7 +206,7 @@ ENTRY(i...

Attached is a simple patch to fix the return value from the 64-bit kernel when you call with a bad system call number with tracing enabled (for either ptrace or audit). What should happen is that the user process gets a -ENOSYS return call from the syscall; what actually happens (only in the 64-bit kernel) is that you get back the system call number. The 32-bit kernel does not suffer from this

...ffffffff81b176d7>] ehci_hcd_init+0x6a/0x78 [ 0.706755] [<ffffffff81002164>] do_one_initcall+0x44/0x190 [ 0.706755] [<ffffffff81ae5ccb>] kernel_init+0xc8/0x14d [ 0.706755] [<ffffffff8162e474>] kernel_thread_helper+0x4/0x10 [ 0.706755] [<ffffffff8162c523>] ? int_ret_from_sys_call+0x7/0x1b [ 0.706755] [<ffffffff8162bafc>] ? retint_restore_args+0x5/0x6 [ 0.706755] [<ffffffff8162e470>] ? gs_change+0x13/0x13 [ 0.706755] ---[ end trace 55922f9402942cd3 ]--- DomU Orion: dmesg: [ 0.890404] ehci_hcd: USB 2.0 ''Enhanced'' Host Controller (E...

...fffffff81065042>] ? autoremove_wake_function+0x0/0x2e [ 173.233890] [<ffffffff811f1b78>] ? xenwatch_thread+0x0/0x14a [ 173.233902] [<ffffffff81064d75>] ? kthread+0x79/0x81 [ 173.233913] [<ffffffff81011baa>] ? child_rip+0xa/0x20 [ 173.233925] [<ffffffff81010d61>] ? int_ret_from_sys_call+0x7/0x1b [ 173.233937] [<ffffffff8101151d>] ? retint_restore_args+0x5/0x6 [ 173.233950] [<ffffffff8100e22f>] ? xen_restore_fl_direct_end+0x0/0x1 [ 173.233963] [<ffffffff81011ba0>] ? child_rip+0x0/0x20 [ 173.233971] Code: 41 5d c3 41 57 49 89 d7 41 56 41 55 49 89 fd 41 54 55...

...fff81065d0a>] ? autoremove_wake_function+0x0/0x2e [163440.613670] [<ffffffffa00b9344>] ? kjournald+0x0/0x226 [jbd] [163440.613675] [<ffffffff81065a3d>] ? kthread+0x79/0x81 [163440.613682] [<ffffffff81012baa>] ? child_rip+0xa/0x20 [163440.613688] [<ffffffff81011d61>] ? int_ret_from_sys_call+0x7/0x1b [163440.613693] [<ffffffff8101251d>] ? retint_restore_args+0x5/0x6 [163440.613699] [<ffffffff8102ddc0>] ? pvclock_clocksource_read+0x3a/0x8b [163440.613704] [<ffffffff81012ba0>] ? child_rip+0x0/0x20 [163440.613711] INFO: task rs:main Q:Reg:14995 blocked for more than 1...

...t;] ? add_wait_queue+0x60/0x60 [242640.332314] [<ffffffffa01b9550>] ? xen_blkif_be_int+0x30/0x30 [xen_blkback] [242640.332319] [<ffffffff81089fbc>] kthread+0x8c/0xa0 [242640.332326] [<ffffffff81664034>] kernel_thread_helper+0x4/0x10 [242640.332330] [<ffffffff816620e3>] ? int_ret_from_sys_call+0x7/0x1b [242640.332336] [<ffffffff81659dbc>] ? retint_restore_args+0x5/0x6 [242640.332340] [<ffffffff81664030>] ? gs_change+0x13/0x13 [242645.920070] block drbd1: Local backing block device frozen? [242657.952074] block drbd1: Local backing block device frozen? [242669.984072] block...

Hi, In view of the problems I was having with DomU network timeout after a live migration (I posted that problems here a while ago but never got anything except from private emails) I finally updated my Debian/Squeeze Dom0s last night to a new kernel, from 2.6.32-23 to 2.6.32-26. Now live migration just hangs...Any ideas? Xen-related Debian packages (all from Debian repositary, except drbd

...;ffffffff81065eb2>] ? autoremove_wake_function+0x0/0x2e [69204.815336] [<ffffffff810626ff>] ? worker_thread+0x0/0x21d [69204.815336] [<ffffffff81065be5>] ? kthread+0x79/0x81 [69204.815336] [<ffffffff81012baa>] ? child_rip+0xa/0x20 [69204.815336] [<ffffffff81011d61>] ? int_ret_from_sys_call+0x7/0x1b [69204.815336] [<ffffffff8101251d>] ? retint_restore_args+0x5/0x6 [69204.815336] [<ffffffff81012ba0>] ? child_rip+0x0/0x20 [69204.815336] Code: fe 0f b7 40 08 39 e8 74 04 0f 0b eb fe 48 8d 74 24 70 bf 01 00 00 00 89 6c 24 70 44 89 6c 24 74 e8 c3 f9 ff ff 85 c0 89 c6 74 04 &lt...

...d2c>] ? check_bugs+0x2b/0x2b [ 0.016351] [<ffffffff81002085>] ? do_one_initcall+0x75/0x12c [ 0.016383] [<ffffffff816abbcb>] ? kernel_init+0x8d/0x152 [ 0.016414] [<ffffffff81354174>] ? kernel_thread_helper+0x4/0x10 [ 0.016447] [<ffffffff81352233>] ? int_ret_from_sys_call+0x7/0x1b [ 0.016479] [<ffffffff8134d37c>] ? retint_restore_args+0x5/0x6 [ 0.016509] [<ffffffff81354170>] ? gs_change+0x13/0x13 [ 0.016545] ---[ end trace 4fbe30a09b2591f0 ]--- [ 0.016576] ... version: 0 [ 0.016605] ... bit width: 48...

...Apr 16 16:02:25 hypervisor3 kernel: [2441115.678981] [<ffffffff8105f2f1>] ? kthread+0x76/0x7e Apr 16 16:02:25 hypervisor3 kernel: [2441115.679025] [<ffffffff81354ab4>] ? kernel_thread_helper+0x4/0x10 Apr 16 16:02:25 hypervisor3 kernel: [2441115.679070] [<ffffffff81352b73>] ? int_ret_from_sys_call+0x7/0x1b Apr 16 16:02:25 hypervisor3 kernel: [2441115.679115] [<ffffffff8134dcbc>] ? retint_restore_args+0x5/0x6 Apr 16 16:02:25 hypervisor3 kernel: [2441115.679160] [<ffffffff81354ab0>] ? gs_change+0x13/0x13 Apr 16 16:02:25 hypervisor3 kernel: [2441115.679201] Code: be 01 00 00 00...

[This email is either empty or too large to be displayed at this time]

Use PM_FREEZE, PM_THAW and PM_RESTORE power events for suspend/resume/checkpoint functionality, instead of PM_SUSPEND and PM_RESUME. Use of these pm events fixes the Xen Guest hangup when taking checkpoints. When a suspend event is cancelled (while taking checkpoints once/continuously), we use PM_THAW instead of PM_RESUME. PM_RESTORE is used when suspend is not cancelled. See

...et_signal: 1: movl $_TIF_NEED_RESCHED,%edi /* Use IRET because user could have changed frame. This works because ptregscall_common has called FIXUP_TOP_OF_STACK. */ - cli + DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_OFF jmp int_with_check @@ -326,7 +334,7 @@ tracesys: */ .globl int_ret_from_sys_call int_ret_from_sys_call: - cli + DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_OFF testl $3,CS-ARGOFFSET(%rsp) je retint_restore_args @@ -347,20 +355,20 @@ int_careful: bt $TIF_NEED_RESCHED,%edx jnc int_very_careful TRACE_IRQS_ON - sti + ENABLE_INTERRUPTS(CLBR_NONE) pushq %rdi CFI_ADJUST...

...et_signal: 1: movl $_TIF_NEED_RESCHED,%edi /* Use IRET because user could have changed frame. This works because ptregscall_common has called FIXUP_TOP_OF_STACK. */ - cli + DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_OFF jmp int_with_check @@ -326,7 +334,7 @@ tracesys: */ .globl int_ret_from_sys_call int_ret_from_sys_call: - cli + DISABLE_INTERRUPTS(CLBR_NONE) TRACE_IRQS_OFF testl $3,CS-ARGOFFSET(%rsp) je retint_restore_args @@ -347,20 +355,20 @@ int_careful: bt $TIF_NEED_RESCHED,%edx jnc int_very_careful TRACE_IRQS_ON - sti + ENABLE_INTERRUPTS(CLBR_NONE) pushq %rdi CFI_ADJUST...

...ocess_timeout+0x0/0x10 [<ffffffff810e78d1>] ? bdi_start_fn+0x0/0xd0 [<ffffffff8112da32>] bdi_writeback_task+0x2c/0xb3 [<ffffffff810e793b>] bdi_start_fn+0x6a/0xd0 [<ffffffff810754b7>] kthread+0x6e/0x76 [<ffffffff81013daa>] child_rip+0xa/0x20 [<ffffffff81012f91>] ? int_ret_from_sys_call+0x7/0x1b [<ffffffff8101371d>] ? retint_restore_args+0x5/0x6 [<ffffffff81013da0>] ? child_rip+0x0/0x20 Code: 8d 04 85 f4 ff ff ff 85 c0 0f 49 d8 48 63 d3 e8 47 c7 07 00 49 8d 44 24 0c 49 89 47 10 eb 3a bb f4 ff ff ff e9 c2 00 00 00 75 04 <0f> 0b eb fe 41 0f b7 45 04 49 8d 7c 24 0c...

...c6fe>] ? do_scan_async+0x16/0x13a [scsi_mod] [ 375.435267] [<ffffffffa002c6e8>] ? do_scan_async+0x0/0x13a [scsi_mod] [ 375.513338] [<ffffffff8106683d>] ? kthread+0x79/0x81 [ 375.573729] [<ffffffff81012baa>] ? child_rip+0xa/0x20 [ 375.635158] [<ffffffff81011d61>] ? int_ret_from_sys_call+0x7/0x1b [ 375.709064] [<ffffffff8101251d>] ? retint_restore_args+0x5/0x6 [ 375.779850] [<ffffffff8100ee0f>] ? xen_restore_fl_direct_end+0x0/0x1 [ 375.856881] [<ffffffff8100ee0f>] ? xen_restore_fl_direct_end+0x0/0x1 [ 375.933915] [<ffffffff81012ba0>] ? child_rip+0x0/...

Hi everyone, I am working on a project whose goal is evaluating the performance of the vTPM Manager. For this project I am using Xen 4.1, Kernel 2.6.31.13 with Fedora11. I I finished all installation and configuration parts. Now I need to boot the system with Xen but while booting, it is freezing at the step "scrubbing free ram". What can be cause this problem and how can I figure it

Hi everyone, I am working on a project whose goal is evaluating the performance of the vTPM Manager. For this project I am using Xen 4.1, Kernel 2.6.31.13 with Fedora11. I I finished all installation and configuration parts. Now I need to boot the system with Xen but while booting, it is freezing at the step "scrubbing free ram". What can be cause this problem and how can I figure it

Hi, Is the http://xenbits.xensource.com/linux-2.6-xen.hg tree still being updated? if not, what''s the preferred Linux tree to track that has all of the Xen bits? Thanks, Muli _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel