On the contrary I would say we can be quite sure this is *not* a re-introduction of the TSC problem. As I wrote in the other bug report, this time we do not have unusual high process times. In other words the time stays increments normally after boot. It is just this one jump at boot. And the jump is caused by the guest using the hosts uptime in the kernel. Visible effect is just the dmesg times being in the far(er) future. And the jump happens exactly at that time when the guest starts to use a time structure provided by the host. Normally that contains the hosts uptime but also a correcting offset which is supposed to adjust the time value to a zero value at the guests boot. Since I cannot reproduce this with my Xen guests (Xen 4.1 or later) this does indicate to me that maybe EC2 hosts toolstack have a bug there. I think I only saw the jump with EC2 Xen 3.x but since I don't know how to enforce landing on a certain Xen version in EC2 it would be really tedious for me to compare.
-- 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
