On Mon, Jan 18, 2010 at 9:21 AM, mail ignored <0.bugs.only.0@xxxxxxxxx> wrote:
>> For example, you could try clocksource=acpi, or clocksource=pit. And then
>> check that the 'Platform timer is...' line from Xen boot output changes
>> correspondingly.
>
> checking those now ... will report results in a bit.
both seem to work ...
booting to,
 /xen.gz ... clocksource=acpi ...
then,
 xm dmesg | grep -i timer
 (XEN) ACPI: PM-Timer IO Port: 0x808
 (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
 (XEN) Platform timer is 3.579MHz ACPI PM Timer
 (XEN) HPET: 4 timers in total, 3 timers will be used for broadcast
 (XEN) mcheck_poll: Machine check polling timer started.
~ 15 minutes, quiet/stable operation @ stratum=2, full reach.
 assID=0 status=0684 leap_none, sync_ntp, 8 events, event_peer/strat_chg,
 version="ntpd 4.2.4p8@xxxxxx Mon Dec 28 17:26:30 UTC 2009 (1)",
 processor="x86_64", system="Linux/2.6.31.8-0.1-xen", leap=00, stratum=2,
 precision=-20, rootdelay=13.970, rootdispersion=26.079, peer=33500,
 refid=216.218.254.202,
 reftime=ceff1d2c.ddbe13c0 Mon, Jan 18 2010 9:47:24.866, poll=6,
 clock=ceff1e07.464f2053 Mon, Jan 18 2010 9:51:03.274, state=4,
 offset=15.245, frequency=24.962, jitter=10.571, noise=17.706,
 stability=7.306
 remote refid st t when poll reach delay offset 
jitter
 
==============================================================================
 -clock.fmt.he.ne .PPS. 1 u 41 64 377 16.047 20.346 
10.336
 -otc2.psu.edu 130.207.244.240 2 u 39 64 377 100.626 14.538 
 5.387
 +clock.isc.org .GPS. 1 u 54 64 377 15.174 -0.843 
10.578
 *clock.sjc.he.ne .CDMA. 1 u 26 64 377 13.970 12.255 
 7.051
 zorro.sf-bay.or 216.218.254.202 2 u 31 64 377 16.489 13.730 
 5.781
 +nist1.aol-ca.tr .ACTS. 1 u 15 64 377 14.891 5.947 
14.596
booting to,
 /xen.gz ... clocksource=pit ...
 xm dmesg | grep -i timer
 (XEN) ACPI: PM-Timer IO Port: 0x808
 (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1
 (XEN) Platform timer is 1.193MHz PIT
 (XEN) mcheck_poll: Machine check polling timer started.
~ 20 minutes, quiet/stable operation @ stratum=2, full reach.
 assID=0 status=0654 leap_none, sync_ntp, 5 events, event_peer/strat_chg,
 version="ntpd 4.2.4p8@xxxxxx Mon Dec 28 17:26:30 UTC 2009 (1)",
 processor="x86_64", system="Linux/2.6.31.8-0.1-xen", leap=00, stratum=2,
 precision=-20, rootdelay=16.981, rootdispersion=31.958, peer=63536,
 refid=207.200.81.113,
 reftime=ceff2377.503b4ceb Mon, Jan 18 2010 10:14:15.313, poll=6,
 clock=ceff240e.fa89c747 Mon, Jan 18 2010 10:16:46.978, state=4,
 offset=9.641, frequency=4.070, jitter=12.958, noise=6.244,
 stability=0.834
 remote refid st t when poll reach delay offset 
jitter
 
==============================================================================
 +clock.fmt.he.ne .PPS. 1 u 30 64 177 15.250 8.422 
 9.657
 +otc2.psu.edu 147.84.59.145 2 u 33 64 177 99.375 10.359 
 8.906
 +clock.isc.org .GPS. 1 u 25 64 177 13.060 2.679 
 9.501
 +clock.sjc.he.ne .CDMA. 1 u 22 64 177 15.097 10.608 
 7.866
 +zorro.sf-bay.or 216.218.254.202 2 u 27 64 177 15.082 9.639 
 8.443
 *nist1.aol-ca.tr .ACTS. 1 u 23 64 177 16.981 15.780 
 7.743
seemingly, _nothing_ to do with the kernel, then. rather overriding
whatever xen's default clocksource is does the trick.
i'll still take a look over longer term @ Dom0, and see if there's any
strangeness in DomU time ...
thanks!
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel