http://bugzilla.novell.com/show_bug.cgi?id=545191
User pgnet.dev@gmail.com added comment
http://bugzilla.novell.com/show_bug.cgi?id=545191#c6
--- Comment #6 from account disabled
With "others" I don't mean people using other distros - SLE11 is working fine for them, and as long as you use an up-to-date kernel, that's gonna be the same as SLE11's.
then more confusion ... something in my env is consistently problematic. i've now chatted with enough people across multiple distros, hardware, configs, etc to know that problems with timekeeping in xen are not uncommon. the whole business seems a bit of a mess, atm ...
in the Dom0 case, i suspect? captured via serial port? or are dmesg & xm dmesg output sufficient?
xm dmesg output will be sufficient if you make sure the log level is high enough, and no messages are discarded.
dmesg won't be enough - it's mainly the boot messages I'm after (i.e. /var/log/boot.msg).
i'll put that together in a minute, and post ...
But you asking this question makes me ask another one: Are you seeing this issue in Dom0, DomU, or both?
both. the problem i've reported above/here is 'just' Dom0. in DomU, if: /proc/sys/xen/independent_wallclock --> 0 /sys/devices/system/clocksource/clocksource0/current_clocksource --> xen then, of course, DomU simply tracks Dom0. checking sync between the two, DomU tracks Dom0 faithfully, without problem, in this case. in the DomU (paravirt) case where i've independent, ntp-driven clock, with, /proc/sys/xen/independent_wallclock --> 1 /sys/devices/system/clocksource/clocksource0/current_clocksource --> jiffies the DomU jitter is somewhat worse than the Dom0 jitter. and, as one might expect, sync is just as elusive. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.