Fix next_timer_interrupt() in patch and update caller

to deal with the case of existing pending timers.
Fixes a dom0 hang at boot time on some HPs where some
dubious USB code is invoked from pci_init() that
potentially calls msleep(10) a few times.
Signed-off-by: Emmanuel Ackaouy <ack@xensource.com>

diff --git a/linux-2.6-xen-sparse/arch/i386/kernel/time-xen.c b/linux-2.6-xen-sparse/arch/i386/kernel/time-xen.c
index fbc9f999efbc45624b954741281ce00cb9c84af7..d21a9560b184f3cde568733b7ad38148d9234882 100644 (file)
--- a/linux-2.6-xen-sparse/arch/i386/kernel/time-xen.c
+++ b/linux-2.6-xen-sparse/arch/i386/kernel/time-xen.c
@@ -989,12 +989,11 @@ static void stop_hz_timer(void)
 
        smp_mb();
 
-       /* Leave ourselves in 'tick mode' if rcu or softirq pending. */
-       if (rcu_needs_cpu(cpu) || local_softirq_pending()) {
+       /* Leave ourselves in 'tick mode' if rcu or softirq or timer pending. */
+       if (rcu_needs_cpu(cpu) || local_softirq_pending() ||
+           (j = next_timer_interrupt(), time_before_eq(j, jiffies))) {
                cpu_clear(cpu, nohz_cpu_mask);
                j = jiffies + 1;
-       } else {
-               j = next_timer_interrupt();
        }
 
        BUG_ON(HYPERVISOR_set_timer_op(jiffies_to_st(j)) != 0);

diff --git a/patches/linux-2.6.16.13/fix-hz-suspend.patch b/patches/linux-2.6.16.13/fix-hz-suspend.patch
new file mode 100644 (file)
index 0000000..a90c308
--- /dev/null
+++ b/patches/linux-2.6.16.13/fix-hz-suspend.patch
@@ -0,0 +1,22 @@
+diff -pruN ../pristine-linux-2.6.16.13/kernel/timer.c ./kernel/timer.c
+--- ../pristine-linux-2.6.16.13/kernel/timer.c 2006-05-02 14:38:44.000000000 -0700
++++ ./kernel/timer.c   2006-06-28 09:57:51.000000000 -0700
+@@ -555,7 +555,17 @@ found:
+       }
+       spin_unlock(&base->t_base.lock);
+ 
+-      if (time_before(hr_expires, expires))
++      /*
++       * If timers are pending, "expires" will be in the recent past
++       * of "jiffies". If there are no hr_timers registered, "hr_expires"
++       * will be "jiffies + MAX_JIFFY_OFFSET"; this is *just* short of being
++       * considered to be before "jiffies". This makes it very likely that
++       * "hr_expires" *will* be considered to be before "expires".
++       * So we must check when there are pending timers (expires <= jiffies)
++       * to ensure that we don't accidently tell the caller that there is
++       * nothing scheduled until half an epoch (MAX_JIFFY_OFFSET)!
++       */
++      if (time_before(jiffies, expires) && time_before(hr_expires, expires))
+               return hr_expires;
+ 
+       return expires;