They're pretty intermittent, so its hard to give an exact guess. The host
system is a dual xeon 2.4 with HTT.. here's some info:
Host:
vlink:~# xm info
system : Linux
host : vlink
release : 2.6.9-xen0
version : #4 Fri Dec 3 22:00:29 EST 2004
machine : i686
cores : 2
hyperthreads_per_core : 2
cpu_mhz : 2399
memory : 1023
free_memory : 622
vlink:~# xm list
Name Id Mem(MB) CPU State Time(s) Console
Domain-0 0 123 0 r---- 65.2
vlink 3 255 1 -b--- 27.1 9603
vlink:~# cat /proc/interrupts
CPU0
14: 20730 Phys-irq ide0
18: 435145 Phys-irq eth1
19: 467659 Phys-irq eth0
128: 1 Dynamic-irq misdirect
129: 41 Dynamic-irq ctrl-if
130: 136374838 Dynamic-irq timer
131: 40 Dynamic-irq console
132: 0 Dynamic-irq net-be-dbg
133: 11859 Dynamic-irq blkif-backend
134: 1439 Dynamic-irq vif3.0
NMI: 0
ERR: 0
Guest Info:
iad1-uml:/var/log# cat /proc/interrupts
CPU0
128: 1 Dynamic-irq misdirect
129: 19804 Dynamic-irq ctrl-if
130: 118967169 Dynamic-irq timer
131: 10672 Dynamic-irq blkif
132: 1705 Dynamic-irq eth0
NMI: 0
ERR: 0
Thanks,
Jeremy
Keir Fraser said:
>
> How often do you get these messages? It is only showing you to be out
> by about 130us, but I don't really see how even that can happen. Also,
> the rate at which the below stream is coming out is about one error
> per 15us, which is very rapid indeed. Is this running on CPU0 or CPU1
> (on an SMP system)?
>
> You might want to try changing the start of do_timer_interrupt() in
> arch/xen/i386/kernel/time.c to what I have attached just below.
>
> Another thing is to build Xen with performance counters (perfc=y make)
> and then use the xenperf utility to see how many times Xen's scheduler
> is being entered (this might account for the high rate of timer
> interrupts you are seeing). Also looking at cat /proc/interrupts in
> DOM1 may be interesting...
>
> -- Keir
>
> static inline void do_timer_interrupt(int irq, void *dev_id,
> struct pt_regs *regs)
> {
> time_t wtm_sec, sec;
> s64 delta, nsec;
> long sec_diff, wtm_nsec;
> /* XXX New declarations below. */
> static s64 pdelta, pshadow, pprocessed, poffset;
>
> do {
> __get_time_values_from_xen();
>
> delta = (s64)(shadow_system_time +
> ((s64)cur_timer->get_offset() *
> (s64)NSEC_PER_USEC) -
> processed_system_time);
> }
> while (!TIME_VALUES_UP_TO_DATE);
>
> if (unlikely(delta < 0)) {
> printk("Timer ISR: Time went backwards: %lld %lld %lld
> %lld\n",
> delta, shadow_system_time,
> ((s64)cur_timer->get_offset() *
> (s64)NSEC_PER_USEC),
> processed_system_time);
> /* XXX New printk below. &/
> printk(" ** %lld %lld %lld %lld\n",
> pdelta, pshadow, pprocessed, poffset);
> return;
> }
>
> /* XXX New assignments below. */
> pdelta = delta;
> pshadow = shadow_system_time;
> pprocessed = processed_system_time;
> poffset = (s64)cur_timer->get_offset();
>
>
>> Hello All,
>>
>> I'm getting the following error from one of my guest domains (domain
>> 1)..
>>
>> Dec 12 16:41:00 iad1-uml kernel: Timer ISR: Time went backwards: -124000
>> 1367865
>> 0000000 9876000 13678660000000
>> Dec 12 16:41:00 iad1-uml kernel: Timer ISR: Time went backwards: -109000
>> 1367865
>> 0000000 9891000 13678660000000
>> Dec 12 16:41:00 iad1-uml kernel: Timer ISR: Time went backwards: -94000
>> 13678650
>> 000000 9906000 13678660000000
>> Dec 12 16:41:00 iad1-uml kernel: Timer ISR: Time went backwards: -82000
>> 13678650
>> 000000 9918000 13678660000000
>> Dec 12 16:41:00 iad1-uml kernel: Timer ISR: Time went backwards: -66000
>> 13678650
>> 000000 9934000 13678660000000
>> Dec 12 16:41:00 iad1-uml kernel: Timer ISR: Time went backwards: -52000
>> 13678650
>> 000000 9948000 13678660000000
>> Dec 12 16:41:00 iad1-uml kernel: Timer ISR: Time went backwards: -37000
>> 13678650
>> 000000 9963000 13678660000000
>> Dec 12 16:41:00 iad1-uml kernel: Timer ISR: Time went backwards: -24000
>> 13678650
>> 000000 9976000 13678660000000
>> Dec 12 16:41:00 iad1-uml kernel: Timer ISR: Time went backwards: -6000
>> 136786500
>> 00000 9994000 13678660000000
>>
>> Anyone else seen this or know what to do about it?
>>
>> The main system isn't experiencing any related errors of this sort....
>>
>> Thanks,
>> Jeremy
>>
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://productguide.itmanagersjournal.com/
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxxxx
>> https://lists.sourceforge.net/lists/listinfo/xen-devel
>
>
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Home