similar to: AW: Clocksources and other mysteries

After installing a Phenom II X4 processor (replacing a single core Semperon) I am getting these messages on the console and in dmesg: Warning Timer ISR/2: Time went backwards: delta=-250135996 delta_cpu=13864004 shadow=1355887856733 off=870052783 processed=1357008044419 cpu_processed=1356744044419 0: 1357004044419 1: 1356696044419 2: 1356744044419 3: 1356696044419 printk: 41 messages

Hi all, We recently upgrade from CentOS 5.8 to CentOS 5.9 on kernel-xen-2.6.18-348.3.1.el5, and after booting into the new kernel, noted large amounts of these messages every second or so in the logs: Mar 30 21:38:35 atlas2 kernel: Warning Timer ISR/0: Time went backwards: delta=-1393683849 delta_cpu=22316151 shadow=225003685197135 off=129240997 processed=225005208029053

I have problems to get Xen 3.0 working on my notebook (FSC AMILO Pro V3205). I already used different operating systems for the xen0 domain, like FC5, SUSE 10.1 und Debian SID (2.6.16-2-xen-smp) but i always run into the same trouble. When I try to start a xenU domain it always hangs and I get this: ----------------------------------------------------------------------- debian37:~# xm create

I''ve been looking into bug [1]#195 and I have a couple of questions on how timer interrupts and virqs are handled. Is it possible for dom0 linux to irq balance timer interrupts to different cpus? That is, if xen sends a VIRQ_TIMER to vcpu0, backed by cpu0, is it possible for that interrupt to be handled by vcpu1, backed by cpu1 ? After putting in some debug code in to timer_interrupt

Hi all, Using a slow serial console with sync_console on SMP leaves me with an unusable system: it gets into a flood of Timer ISR/0: Time went backwards: delta=-3566279 cpu_delta=16433721 shadow=2019998373 off=420435384 processed=2444000000 cpu_processed=2424000000 0: 2424000000 1: 2444000000 messages which swamps the console and leaves things almost, but not quite, completely hung. It is a

Enable cpufreq support in Xen for AMD Operton processors by: 1) Allowing the PowerNow! driver in dom0 to write to the PowerNow! MSRs. 2) Adding the cpufreq notifier chain to time-xen.c in dom0. On a frequency change, a platform hypercall is performed to scale the frequency multiplier in the hypervisor. 3) Adding a platform hypercall to the hypervisor the scale the frequency multiplier and reset

Hello ! Does anybody know how to build and use cpufreq support that should be in 3.2 since -unstable time ? Bye -- __________________________________________________ Ralf Schenk fon (02 41) 9 91 21-0 fax (02 41) 9 91 21-59 rs@databay.de Databay AG Hüttenstraße 7 D-52068 Aachen www.databay.de Vorstand: Jens Conze, Ralf Schenk, Aresch Yavari Aufsichtsratvorsitzender: Ansgar Vögeli

Jup, 64 Bit Kernel build is done now and works, but 32 Bit kernel config is different, as I use 64 Bit in Dom0 and DomU, 32 Bit only in DomU incl. DomU with DVB etc. XEN options are the same, it''s only the selection of drivers... Andrew, any idea? Boris, do you know a safe way to create a 64 Bit config out of a 32 Bit one? Sorry, I am not so used to kernel building... BR, Carsten.

Oh, thanks, Niraj. I overlooked this initially, because this code is not implemented in waldi 3.1-2 kernel, but only in 3.3-1. I''ll check it out tonight, as booting a new kernel per remote is a bit too dangerous. This would be exactly what I need. BR, Carsten. Von: Niraj Tolia Gesendet: Mit, 7.1.2009 22:53 An: Carsten Schiers Cc: jbeulich ; mark.langsdorf ; xen-devel Betreff:

Thanks Anna, this was also quite interesting for me. Did you mean that I just have to eliminate the else branch or raise arround "All devices behind the uppermost PCI/PCI-X bridge must be co-assigned to the same guest." or do I have to eliminate more in order to prevent an FLR (whatever that is). For my board it''s definitely necessary to move PCI devices in different guests,

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, independent_wallclock, ntpd,

Hi Ali, Thanks for bringing this up. You're definitely under very tight design constraints from the hardware. I can certainly sympathize. I think two design elements are being conflated here, and it would be worthwhile splitting them out. For correctness, you need to make sure any routines called from an ISR don't clobber equivalent routines called from mainline code. For

Use isr field instead of direct access to ioaddr. This way generalizes easily to virtio 1.0. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_pci.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c index 9be59d9..ee1b54c 100644 --- a/drivers/virtio/virtio_pci.c +++

Use isr field instead of direct access to ioaddr. This way generalizes easily to virtio 1.0. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_pci.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c index 9be59d9..ee1b54c 100644 --- a/drivers/virtio/virtio_pci.c +++

Use isr field instead of direct access to ioaddr. This way generalizes easily to virtio 1.0. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_pci.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c index 9be59d9..ee1b54c 100644 --- a/drivers/virtio/virtio_pci.c +++

I have a high end IBM system with 4 HT CPUs, am running xen-unstable with only Dom0 active, and I get lots of "Timer ISR/n: Time went backwards" messages. This is a short segment from dmesg: Timer ISR/1: Time went backwards: -259000 4465110000000 9741000 4465120000000 Timer ISR/6: Time went backwards: -224000 4465110000000 9776000 4465120000000 Timer ISR/6: Time went backwards: -159000

The behaviour of default ISRs as provided by the BIOS varies wildly between platforms. Some will simply iret, some will send EOI, some will send EOI and disable the interrupt at the PIC, some will crash the machine due to single-bit errors in the ISR address. When PXENV_UNDI_ISR_IN_START returns PXENV_UNDI_ISR_OUT_NOT_OURS, send the EOI ourselves rather than risking the unpredictable behaviour

Extended thanks to the llvm community for feedback in advance, and especially thanks to Jim for laying out a solution that captures all aspects of the problems that we are facing. After some discussions with our team, we have decided to do the following, but to avoid further conflict with llvm standards, I would like to get the blessing of llvm community, and in particular, Chris who at some point

On 07/13/2014 10:54 AM, syslinux-bot for Gene Cumm wrote: > Commit-ID: 3741886cb700e1017d70f1753f013fa10f4d9272 > Gitweb: http://www.syslinux.org/commit/3741886cb700e1017d70f1753f013fa10f4d9272 > Author: Gene Cumm <gene.cumm at gmail.com> > AuthorDate: Sun, 13 Jul 2014 11:18:50 -0400 > Committer: Gene Cumm <gene.cumm at gmail.com> > CommitDate: Sun, 13 Jul

On Sun, Jul 13, 2014 at 10:26 PM, H. Peter Anvin <hpa at zytor.com> wrote: > On 07/13/2014 10:54 AM, syslinux-bot for Gene Cumm wrote: >> Commit-ID: 3741886cb700e1017d70f1753f013fa10f4d9272 >> Gitweb: http://www.syslinux.org/commit/3741886cb700e1017d70f1753f013fa10f4d9272 >> Author: Gene Cumm <gene.cumm at gmail.com> >> AuthorDate: Sun, 13 Jul 2014