* Linux 2.6.32: revert upstream patch

489fb490dbf8dab0249ad82b56688ae3842a79e8.  It causes the DomU clock
  to jump into the future and freeze after being saved and restored
  across a Dom0 reboot.  See 

    http://lists.xensource.com/archives/html/xen-devel/2010-10/msg00498.html
    http://lists.xensource.com/archives/html/xen-devel/2010-10/msg01174.html

svn path=/nixpkgs/trunk/; revision=24473

pkgs/os-specific/linux/kernel/patches.nix

@@ -199,20 +199,24 @@ in
     };
 
   guruplug_defconfig =
-    {
-      # Default configuration for the GuruPlug.  From
+    { # Default configuration for the GuruPlug.  From
       # <http://www.openplug.org/plugwiki/images/c/c6/Guruplug-patchset-2.6.33.2.tar.bz2>.
       name = "guruplug-defconfig";
       patch = ./guruplug-defconfig.patch;
     };
 
   guruplug_arch_number =
-    {
-      # Hack to match the `arch_number' of the U-Boot that ships with the
+    { # Hack to match the `arch_number' of the U-Boot that ships with the
       # GuruPlug.  This is only needed when using this specific U-Boot
       # binary.  See
       # <http://www.plugcomputer.org/plugwiki/index.php/Compiling_Linux_Kernel_for_the_Plug_Computer>.
       name = "guruplug-arch-number";
       patch = ./guruplug-mach-type.patch;
     };
+
+  revert_pvclock_sync =
+    { name = "revert-pvclock-sync";
+      patch = ./revert-pvclock-sync.patch;
+    };
+  
 }

pkgs/os-specific/linux/kernel/revert-pvclock-sync.patch

@@ -0,0 +1,46 @@
+diff -ru -x '*~' linux-2.6.32.24-orig/arch/x86/kernel/pvclock.c linux-2.6.32.24/arch/x86/kernel/pvclock.c
+--- linux-2.6.32.24-orig/arch/x86/kernel/pvclock.c	2010-10-01 22:51:56.000000000 +0200
++++ linux-2.6.32.24/arch/x86/kernel/pvclock.c	2010-10-25 14:02:14.000000000 +0200
+@@ -109,14 +109,11 @@
+ 	return pv_tsc_khz;
+ }
+ 
+-static atomic64_t last_value = ATOMIC64_INIT(0);
+-
+ cycle_t pvclock_clocksource_read(struct pvclock_vcpu_time_info *src)
+ {
+ 	struct pvclock_shadow_time shadow;
+ 	unsigned version;
+ 	cycle_t ret, offset;
+-	u64 last;
+ 
+ 	do {
+ 		version = pvclock_get_time_values(&shadow, src);
+@@ -126,27 +123,6 @@
+ 		barrier();
+ 	} while (version != src->version);
+ 
+-	/*
+-	 * Assumption here is that last_value, a global accumulator, always goes
+-	 * forward. If we are less than that, we should not be much smaller.
+-	 * We assume there is an error marging we're inside, and then the correction
+-	 * does not sacrifice accuracy.
+-	 *
+-	 * For reads: global may have changed between test and return,
+-	 * but this means someone else updated poked the clock at a later time.
+-	 * We just need to make sure we are not seeing a backwards event.
+-	 *
+-	 * For updates: last_value = ret is not enough, since two vcpus could be
+-	 * updating at the same time, and one of them could be slightly behind,
+-	 * making the assumption that last_value always go forward fail to hold.
+-	 */
+-	last = atomic64_read(&last_value);
+-	do {
+-		if (ret < last)
+-			return last;
+-		last = atomic64_cmpxchg(&last_value, last, ret);
+-	} while (unlikely(last != ret));
+-
+ 	return ret;
+ }
+ 

pkgs/top-level/all-packages.nix

@@ -4584,6 +4584,7 @@ let
         kernelPatches.cifs_timeout
         kernelPatches.no_xsave
         kernelPatches.dell_rfkill
+        kernelPatches.revert_pvclock_sync
       ];
   };