[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] repeatable time jump
Ian
I think your patch was against an intermediate state - it doesn't patch
cleanly against xen-unstable-src-20041001 (yesterday's snapshot) - I
tried the patchwork jigsaw business but was getting confused. The
version I have corresponds to
21 hours iap10 1.1349.1.4
<http://xen.bkbits.net:8080/xeno-unstable.bk/cset@xxxxxxxxxx?nav=index.html%7CChangeSet@-4d>
Tiny time fix
in the BK changeset listing.
I made a minimal patch to time.c to ensure that it doesn't return
successive time values that are identical, which is what was causing the
rpm crashes that have been plaguing me, and attach it as a stopgap if
anyone else (Flavio?) is having touble with that.
With this patch, your test program shows that the problem has occured by
producing reams of 'gtod 1' messages, but at least rpm, yum, poldek,
urpmi etc remain usable.
This merely a stopgap, does nothing to advance progress towards a
rational understanding of time in the xenU domain, and may for all I
know have other damaging effects.
Thanks
Peri
Ian Pratt wrote:
" linux-2.6.8.1-xen-sparse/arch/xen/i386/kernel/time.c and see what
" comes out when you run your test. It's also interesting to see
" what output comes out after the time skip whenever you run date.
OK, I pulled and patched. I ran date in a loop as xenU was shutdown
and time jumped 4293 secs from 1096637912.846396000 to 1096642205.961018000
ntpd was running in xen0.
David, Peri:
I suspect you guys are seeing manifestations of the same
bug. It's odd that you only see it on some machines, but it might
be due to the relative error between the RTC and CPU clocks or
such like.
Please can you try the new patch which may give a little more
information.
Thanks,
Ian
---
/usr/groups/xeno/BK/xeno.bk/linux-2.6.8.1-xen-sparse/arch/xen/i386/kernel/time.c
2004-10-01 16:01:03.000000000 +0100
+++ arch/xen/i386/kernel/time.c 2004-10-01 16:10:06.000000000 +0100
@@ -114,28 +114,34 @@
#define NS_PER_TICK (1000000000ULL/HZ)
-#define HANDLE_USEC_UNDERFLOW(_tv) do { \
+#define HANDLE_USEC_UNDERFLOW(_tv) do { int i=0; \
while ((_tv).tv_usec < 0) { \
(_tv).tv_usec += USEC_PER_SEC; \
(_tv).tv_sec--; \
- } \
+ }if(i>100)printk(KERN_ALERT"USEC_UNDER %d\n",i); \
} while (0)
-#define HANDLE_USEC_OVERFLOW(_tv) do { \
+#define HANDLE_USEC_OVERFLOW(_tv) do { int i=0; \
while ((_tv).tv_usec >= USEC_PER_SEC) { \
(_tv).tv_usec -= USEC_PER_SEC; \
- (_tv).tv_sec++; \
- } \
+ (_tv).tv_sec++; i++; \
+ }if(i>100)printk(KERN_ALERT"USEC_OVER %d\n",i); \
} while (0)
static inline void __normalize_time(time_t *sec, s64 *nsec)
{
+int i=0,j=0;
while (*nsec >= NSEC_PER_SEC) {
(*nsec) -= NSEC_PER_SEC;
(*sec)++;
+ i++;
}
while (*nsec < 0) {
(*nsec) += NSEC_PER_SEC;
(*sec)--;
+ j++;
}
+
+if( i>100 || j>100 ) printk(KERN_ALERT"normalize time %d %d\n",i,j);
+
}
/* Does this guest OS track Xen time, or set its wall clock independently? */
@@ -155,6 +161,8 @@
*/
static void __get_time_values_from_xen(void)
{
+long last = shadow_tv.tv_sec;
+
shared_info_t *s = HYPERVISOR_shared_info;
do {
@@ -169,6 +177,7 @@
while (shadow_time_version != s->time_version1);
cur_timer->mark_offset();
+if( shadow_tv.tv_sec-last > 600 ) printk(KERN_ALERT"****
__get_time_values_from_xen(void) JUPMED!\n");
}
#define TIME_VALUES_UP_TO_DATE \
@@ -227,18 +236,26 @@
write_seqlock_irqsave(&xtime_lock, flags);
__get_time_values_from_xen();
write_sequnlock_irqrestore(&xtime_lock, flags);
+printk(KERN_ALERT"GTOD Try again %ld %lld\n", shadow_tv.tv_sec,
+ shadow_system_time);
continue;
}
} while (read_seqretry(&xtime_lock, seq));
+{
+int z=0;
while (usec >= USEC_PER_SEC) {
usec -= USEC_PER_SEC;
sec++;
+ z++;
}
+if(z>100) printk(KERN_ALERT"GTOD JUMP %d\n",z);
+}
/* Ensure that time-of-day is monotonically increasing. */
if ((sec < last_seen_tv.tv_sec) ||
((sec == last_seen_tv.tv_sec) && (usec < last_seen_tv.tv_usec))) {
+printk(KERN_ALERT"Clamp time %ld %ld\n",sec,last_seen_tv.tv_sec);
sec = last_seen_tv.tv_sec;
usec = last_seen_tv.tv_usec;
} else {
@@ -364,6 +381,7 @@
struct pt_regs *regs)
{
s64 delta;
+ unsigned int ticks = 0;
long sec_diff;
__get_time_values_from_xen();
@@ -378,9 +396,14 @@
/* Process elapsed jiffies since last call. */
while (delta >= NS_PER_TICK) {
+ ticks++;
delta -= NS_PER_TICK;
processed_system_time += NS_PER_TICK;
- do_timer_interrupt_hook(regs);
+ }
+
+ if (ticks != 0) {
+ jiffies_64 += ticks - 1;
+ do_timer_interrupt_hook(regs); /* implicit 'jiffies_64++' */
}
/*
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
--- xeno-unstable/linux-2.6.8.1-xen-sparse/arch/xen/i386/kernel/time.c
2004-10-01 04:00:16.000000000 +0100
+++ xeno-unstable-20041001/linux-2.6.8.1-xen-sparse/arch/xen/i386/kernel/time.c
2004-10-02 08:49:16.000000000 +0100
@@ -241,6 +241,10 @@
((sec == last_seen_tv.tv_sec) && (usec < last_seen_tv.tv_usec))) {
sec = last_seen_tv.tv_sec;
usec = last_seen_tv.tv_usec;
+ if((last_seen_tv.tv_usec += 1) >= USEC_PER_SEC) {
+ last_seen_tv.tv_sec+= 1;
+ last_seen_tv.tv_usec= 0;
+ }
} else {
last_seen_tv.tv_sec = sec;
last_seen_tv.tv_usec = usec;
|
