search for: clocksources

Hi, all -- I''m in the process of configuring a new machine for use as a Xen server, and am having some rather significant stability issues. The hardware/distro/kernel info is: opensuse 10.3 Linux offxen2 2.6.22.5-31-xen #1 SMP 2007/09/21 22:29:00 UTC x86_64 x86_64 x86_64 GNU/Linux 2 x Dual-Core AMD Opteron(tm) Processor 2212 HE 8 x 2GB PC2-5300 RAM Xen 3.1.0_15042-51 I currently have

...nt timekeeping_notify(struct clocksource *clock); --- a/kernel/time/Kconfig +++ b/kernel/time/Kconfig @@ -12,6 +12,10 @@ config CLOCKSOURCE_WATCHDOG config ARCH_CLOCKSOURCE_DATA bool +# Architecture has extra clocksource init called from registration +config ARCH_CLOCKSOURCE_INIT + bool + # Clocksources require validation of the clocksource against the last # cycle update - x86/TSC misfeature config CLOCKSOURCE_VALIDATE_LAST_CYCLE --- a/kernel/time/clocksource.c +++ b/kernel/time/clocksource.c @@ -937,6 +937,8 @@ int __clocksource_register_scale(struct { unsigned long flags; + clocksource_a...

...nt timekeeping_notify(struct clocksource *clock); --- a/kernel/time/Kconfig +++ b/kernel/time/Kconfig @@ -12,6 +12,10 @@ config CLOCKSOURCE_WATCHDOG config ARCH_CLOCKSOURCE_DATA bool +# Architecture has extra clocksource init called from registration +config ARCH_CLOCKSOURCE_INIT + bool + # Clocksources require validation of the clocksource against the last # cycle update - x86/TSC misfeature config CLOCKSOURCE_VALIDATE_LAST_CYCLE --- a/kernel/time/clocksource.c +++ b/kernel/time/clocksource.c @@ -937,6 +937,8 @@ int __clocksource_register_scale(struct { unsigned long flags; + clocksource_a...

Dear fellow Xen''ers! I''m having a problem with my new Xen-enabled colocation server.. I hope ( at least ;) ) one of you guys know how to fix this problem.. For a certain amount of time ( 1-2 days ) the domU runs fine.. until the console starts spitting out messages like these: [80182.004456] clocksource/0: Time went backwards: delta=-6917292717540055641 shadow=80182004054805

Hello, I was thinking of creating a wiki page about Xen clocksources and timekeeping.. including dom0, PV guests and HVM guests. Dan and Jeremy: You guys might have some ideas for this page.. please let me know your thoughts :) Subjects to cover: - Xen hypervisor clocksources (hpet, acpi_pm, pit) - Xen dom0 clocksource, ntpd, etc - Xen PV guest clocksources,...

When booting 2.6.37 (from kernel.org) under Xen 4.1, there are apparently issues with timer interrupts being delivered to the dom0. Repeatedly causing an interrupt (for example, the ACPI power button) will allow the system to boot, as does adding "clocksource=jiffies" to the kernel command line. This is only present under Xen, not when booting the same kernel on real hardware. When boot

On 21/11/2015 00:05, Ming Lin wrote: > [ 1.752129] Freeing unused kernel memory: 420K (ffff880001b97000 - ffff880001c00000) > [ 1.986573] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x30e5c9bbf83, max_idle_ns: 440795378954 ns > [ 1.988187] clocksource: Switched to clocksource tsc > [ 3.235423] clocksource: timekeeping watchdog: Marking clocksource 'tsc'

On Debian Squeeze (2.6.32-5) running Xen 4.0, I have created 2 Ubuntu Lucid Lynx (Ubuntu 10.04) vms. The vms, in a stress test, pass a large file between them via nfs file sharing. A previous entry in this forum helped to establish that some ethernet cards improve VM IO performance. However, our box installed with better intel nics is still rebooting under heavy VM IO loads. The kernel call

https://bugs.freedesktop.org/show_bug.cgi?id=98709 Bug ID: 98709 Summary: [NV50] clocksource: timekeeping watchdog on CPU2: Marking clocksource 'tsc' as unstable because the skew is too large Product: Mesa Version: 12.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status:

Hi All, I''m new to Xen and... Happy New Year! After restarting dom-0, my dom-u prints this in console once every second, [55082.616234] __ratelimit: 1503 messages suppressed [55082.616234] clocksource/0: Time went backwards: ret=380ab26c53a I resolved this by following the instructions in "http://wiki.debian.org/Xen", which is basically changing clocksource to

On Thu, 30 Sep 2010 14:02:34 +0800, gang.wei@intel.com wrote: > I am the original developer of HPET broadcast code. > > First of all, to disable HPET broadcast, no additional patch is required. > Please simply add option "cpuidle=off" or "max_cstate=1" at xen cmdline in > /boot/grub/grub.conf. > > Second, I noticed that the issue just occur on

...only works if the kernel and hypervisor have non-drifting timebases. I think its too fragile for a clockevent implementation to assume that a particular clocksource is in use to get reliable results. Or perhaps this is a property of the whole clock subsystem: that clockevents must be paired with clocksources. But its not obvious to me that this enforced, or even acknowledged. (Of course, if the drift can be characterized, then you can compensate for it, but this seems too complex to be the right answer. And drift compensation is numerically much simpler for small 32-bit deltas compared to 64-bit abs...

...only works if the kernel and hypervisor have non-drifting timebases. I think its too fragile for a clockevent implementation to assume that a particular clocksource is in use to get reliable results. Or perhaps this is a property of the whole clock subsystem: that clockevents must be paired with clocksources. But its not obvious to me that this enforced, or even acknowledged. (Of course, if the drift can be characterized, then you can compensate for it, but this seems too complex to be the right answer. And drift compensation is numerically much simpler for small 32-bit deltas compared to 64-bit abs...

Wei Liu <wei.liu at kernel.org> writes: > Signed-off-by: Wei Liu <wei.liu at kernel.org> > --- > drivers/clocksource/hyperv_timer.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/clocksource/hyperv_timer.c b/drivers/clocksource/hyperv_timer.c > index 09aa44cb8a91..fe96082ce85e 100644 > --- a/drivers/clocksource/hyperv_timer.c > +++

Hi there, I''m trying to find out if theres anything wrong with using extra = "clocksource=jiffies" in domU configuration. It seems to fix some problems we''ve had with live migration. Thanks. -- Please remember that an email is just like a postcard; it is not confidential nor private nor secure and can be read by many other people than the intended recipient.

On 20/11/2015 09:11, Ming Lin wrote: > On Thu, 2015-11-19 at 11:37 +0100, Paolo Bonzini wrote: >> >> On 18/11/2015 06:47, Ming Lin wrote: >>> @@ -726,7 +798,11 @@ static void nvme_process_db(NvmeCtrl *n, hwaddr addr, int val) >>> } >>> >>> start_sqs = nvme_cq_full(cq) ? 1 : 0; >>> - cq->head = new_head;

On 20/11/2015 09:11, Ming Lin wrote: > On Thu, 2015-11-19 at 11:37 +0100, Paolo Bonzini wrote: >> >> On 18/11/2015 06:47, Ming Lin wrote: >>> @@ -726,7 +798,11 @@ static void nvme_process_db(NvmeCtrl *n, hwaddr addr, int val) >>> } >>> >>> start_sqs = nvme_cq_full(cq) ? 1 : 0; >>> - cq->head = new_head;

Hi all, If you are using the kernel divider= option in your vmware quest, you are probably aware of the bugs reported at: https://bugzilla.redhat.com/show_bug.cgi?id=315471 Someone @redhat "confirmed" the fix is in the test kernel -92. I tried it but it seems to have the same problem as before - when used with clocksource=pit, it hangs on bootup. Wonder if some of you can test this

I am attaching a clocksource driver for HyperV. Signed-off-by: K. Y. Srinivasan <ksrinivasan at novell.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hyperv_clocksource.patch Url: http://lists.linux-foundation.org/pipermail/virtualization/attachments/20100405/80968881/attachment-0001.txt

I am attaching a clocksource driver for HyperV. Signed-off-by: K. Y. Srinivasan <ksrinivasan at novell.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hyperv_clocksource.patch Url: http://lists.linux-foundation.org/pipermail/virtualization/attachments/20100405/80968881/attachment-0001.txt