Writing up my findings so far:
- this looks to be a m1.small instance (1 vcpu, 1.7GB memory)
- this instance type is a PV guest
So sched_clock (which is used by printk) will be using
paravirt_sched_clock which is set to xen_clocksource_read. The time info
is kept in a per-cpu variable (vcpu_info). This is initially part of the
hypervisor shared info but get changed later.
start_kernel()
...
setup_per_cpu_areas();
/* printks from above are ok */
smp_prepare_boot_cpu();
xen_smp_prepare_boot_cpu();
xen_setup_vcpu_info_placement();
/* vcpu_info changed */
xen_init_spinlocks();
/* printks from above call jumped in time */
So it looks like for some yet unknown reason, registering the vcpu_info
with the hypervisor is messing up the clocktime data.
@Joe, was this always happening (with the same instance type maybe) or
about how often. I am trying to get a feeling for whether it is some
race or maybe related to xen hypervisor version. Also will try to play
around with this on a local Xen host (but rather tomorrow).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1349883
Title:
dmesg time wildly incorrect on paravirtual EC2 instances.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1349883/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
