[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: [BUG 1282] time jump on live migrate root cause & proposed fixes
On Thu, 07 Aug 2008 11:25:34 +0100 Keir Fraser <keir.fraser@xxxxxxxxxxxxx> wrote: > It does look like the code should work. Yeah, it looks like it should. Unfortunately it doesn't :) > What kernel specifically have you reproduced this behaviour with? The current RHEL 5 kernel (2.6.18-92.1.6.el5xen). I have instrumented time_resume and am seeing something very strange. I have two systemtap hooks, one when entering the function and one when returning from the function. This output contains the trace info from two live migrates. As you can see, time_resume() manages to get a new system_timestamp from each host just fine, through get_time_values_from_xen(). However, the data that update_wallclock() retrieves from the HYPERVISOR_shared_info does not change. Even wc_version stays the same across both host systems! # ./time_resume.stap entering time_resume, secs = 1217875833, nsecs = 869795597 system_time = 237323812007279, shadow_tv_version = 350 leaving time_resume, secs = 1217875833, nsecs = 869795597 system_time = 604085945766733, shadow_tv_version = 350 entering time_resume, secs = 1217875833, nsecs = 869795597 system_time = 604262961766733, shadow_tv_version = 350 leaving time_resume, secs = 1217875833, nsecs = 869795597 system_time = 237501337935436, shadow_tv_version = 350 -- All rights reversed. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |