I had a dream... well honestly this idea came to me around then. So I was fishing in the same availability zone to get another case of this (was not sure I could just go back to yours). Then installed a 12.04 (3.2.x) kernel and bingo, same problem. So at least I can stop trying to think of a way the changes between 3.2 and 3.13 may have caused this. And the reason I added the comment about the observation that it may not happen initially but then on a reboot and after that on every reboot was this: I have the feeling that the uptime of the host also is one part of the equation. So this seems:
- Intel CPU, the nonstop_tsc of the E5-2650 might be something to look at - A certain uptime of the host - Maybe the tsc/systime related code in the hypervisor Well, it could also be independent of the CPU and only rely on the uptime and it is just pure bad luck that the only hosts we currently find are of a certain type. Only way to prove or bust this would be to find a unaffected guest showing an uptime of those 58 days. Figuring out the involvement of the hypervisor code is nearly impossible as Amazon uses a special version of 3.4.3. -- 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
