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
|
Home