search for: stime_local_stamp

Hi Ian/Stefano: I changed over to the PV clock for hybrid liked we talked at the hackathon. I still have the hang in update_wall_time() after dom0 switches to xen as clocksource. The source of hang seems to be in xen stime_local_stamp in cpu_time that suddenly jumps to a large 64bit value. I''ve been chasing to figure where that happens, and why for the hybrid and not PV. It appears the source of jump is time_calibration_std_rendezvous() in c->stime_master_stamp. Chasing that, seems to come from read_platform_stime...

flight 18092 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/18092/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-winxpsp3 8 guest-saverestore fail pass in 18090 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass

...while (new_mult < (1LL << 31)) { + new_shift -= 1; + new_mult = new_mult << 1; + } + + t->tsc_scale.mul_frac = new_mult; + t->tsc_scale.shift = new_shift; + local_irq_disable(); + rdtscll(curr_tsc); + t->local_tsc_stamp = curr_tsc; + t->stime_local_stamp = get_s_time(); + t->stime_master_stamp = read_platform_stime(); + local_irq_enable(); + + platform_time_calibration(); +} + /* Set clock to <secs,usecs> after 00:00:00 UTC, 1 January, 1970. */ void do_settime(unsigned long secs, unsigned long nsecs, u64 system_time_base) { @@...