Don't clip the TSC-derived usec value to <1tick in gettimeofday.

This fixes some very odd gettimeofday() results when NTP is
adjtimex()ing the clock backwards.
Signed-off-by: Tim Deegan <Tim.Deegan@xensource.com>

diff --git a/arch/i386/kernel/time-xen.c b/arch/i386/kernel/time-xen.c
index f6707977aa48825a2de633448698fb5d2b41d5a6..750148353d7d6bd9ee612a77039d2fa2ef062adb 100644 (file)
--- a/arch/i386/kernel/time-xen.c
+++ b/arch/i386/kernel/time-xen.c
@@ -384,19 +384,7 @@ void do_gettimeofday(struct timeval *tv)
                usec = get_usec_offset(shadow);
                lost = jiffies - wall_jiffies;
 
-               /*
-                * If time_adjust is negative then NTP is slowing the clock
-                * so make sure not to go into next possible interval.
-                * Better to lose some accuracy than have time go backwards..
-                */
-               if (unlikely(time_adjust < 0)) {
-                       max_ntp_tick = (USEC_PER_SEC / HZ) - tickadj;
-                       usec = min(usec, max_ntp_tick);
-
-                       if (lost)
-                               usec += lost * max_ntp_tick;
-               }
-               else if (unlikely(lost))
+               if (unlikely(lost))
                        usec += lost * (USEC_PER_SEC / HZ);
 
                sec = xtime.tv_sec;