WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] repeatable time jump

To: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] repeatable time jump
From: Peri Hankey <mpah@xxxxxxxxxxxxxx>
Date: Sat, 02 Oct 2004 09:36:05 +0100
Cc: David Becker <becker@xxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx, Flavio Leitner <fbl@xxxxxxxxxxxxxxxx>
Delivery-date: Sat, 02 Oct 2004 09:49:18 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: <E1CDPE9-0007G8-00@xxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <E1CDPE9-0007G8-00@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040115
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;
<Prev in Thread] Current Thread [Next in Thread>