On Wed, Oct 06, 2010 at 11:47:05AM +0100, Ian Campbell wrote: > On Wed, 2010-10-06 at 09:33 +0100, Mark Adams wrote: > > Hi Ben, Thanks for your response. See my responses inline. > > > > On Wed, Oct 06, 2010 at 03:35:23AM +0100, Ben Hutchings wrote: > > > On Tue, 2010-10-05 at 09:31 +0100, Mark Adams wrote: > > > > Package: xen-linux-system-2.6.32-5-xen-amd64 > > > > Version: 2.6.32-21 > > > > Severity: important > > > > > > > > > > > > Hi, Did you receive this bug report? I hadn't received a bug ID even > > > > though receiving the copy of the original report. > > > > > > We don't have any other bug report with this description. > > > > > > > Likely because the address it was sent from originally was invalid. > > > > > > That would explain it. > > > > > > > ----------------- > > > > > > > > Hi All, > > > > > > > > > > > > > > > > > > > > > > > > Im running Xen 4.0.1-rc6 Debian squeeze with pvops 2.6.32-21 kernel. > > > > > > > > > > > > Today I noticed (when kerberos to the domain controllers stopped > > > > > > > > > > > > working..) that the clock was 50 minutes out in dom0 -- This caused the > > > > > > > > > > > > HVM windows domain controllers to have the wrong time. > > > > > > > > > > > > > > Since you appear to be in the UK, is it possible that the real-time > > > clock is set to local time (GMT+1) while Xen expects it to be GMT, or > > > vice versa? > > > > The clock is set with tzdata as BST yes, it is also set to this in the > > Windows server 2008 domU. We are using localtime=1 to match the clock > > in dom0 to domU. > > > > > > > > (This doesn't explain why it's 50 minutes out rather than 1 hour. But > > > ntpd will refuse to correct a large difference and the local clock may > > > then drift further.) > > > > > > [...] > > > > Can anyone confirm whether xen controls the time or the kernel? Also > > > > > > > > > > > > when I corrected the time in dom0 it was still wrong in HVM domU -- How > > > > > > > > > > > > long does it take for this to propogate? (I rebooted the VM's to > > > > correct > > > > > > > > it immediately). > > > > > > > > > > > [...] > > > > > > For HVM guests, the hypervisor emulates a standard PC real-time clock > > > and the guest uses that to initialise the system time, but there is no > > > way to force an update after the guest has booted unless the guest has > > > specific support for Xen; I assume Citrix does provide such software for > > > Windows but I don't know whether it is free software. > > > > The citrix WHQL drivers might have this functionality, I don't use them > > though - prefer the GPL PV drivers! (which don't have any clock support > > as far as I can tell) > > I think you can run a regular NTP client (assuming one exists for > Windows) in an HVM guest to keep wallclock time in sync. > > > > For PV guests, I assume you can force an update to the guest time using > > > the Xen management tools. > > > > > > Note, I'm just a general kernel maintainer and don't have any great > > > knowledge of Xen. > > I should know but time handling (particularly for HVM guests) is > something where I basically know enough to know that there is lots I > don't know ;-) > > Mark, you may find you get better answers/support from the xen-users > mailing list, or failing that, xen-devel. > > > All good, I have a feeling it might be a kernel issue rather than xen, > > but I'm still not sure what actually -controls- the time, is it the > > kernel? I think the key is in the log > > > > Oct 2 18:50:33 havhost1 kernel: [623480.977748] Clocksource tsc unstable > > (delta = -2999660303788 ns) > > > > > As this is when the clock went from 18:00 to 18:50 and started the chain > > of events (restarted the 2008 domU). Any ideas why this log occurred? > > The TSC appeared to go backwards by a fairly significant amount, which > has upset the kernel. > > The behaviour of the virtual TSC as seen by an HVM guest is controlled > by a combination of the tsc_mode setting in your domain configuration > and, I think, by the features of your specific hardware (some have > constant rate TSC, others advertise varying levels of synchronisation > between cores etc). It's then up to the guest kernel whether it even > uses TSC as a timesource at all and how it handles instability etc and > how it derives other time sources (such as the wallclock time) from it. > > Sorry this isn't more helpful, but as I say you will probably get better > answers on one of the Xen mailing lists.
Hi Ian, Thanks for your notes. I've already tried the xen-users list so I will try xen-devel to see if I can glean any more information about my issue. I will update the report here when I get any more information. Thanks, Mark > > Ian. > > -- > Ian Campbell > Current Noise: Trouble - Wickedness Of Man > > ok, I will not marry Jo-Con-El's cow. > -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101006110518.ga30...@campbell-lange.net
