ia64/xen-unstable

changeset 10593:7d3df6492d70

[XEN] Work around timeout bug in old Linux kernels where
timeout would erroneously be set far out in the future.
Signed-off-by: Keir Fraser <keir@xensource.com>
author kaf24@firebug.cl.cam.ac.uk
date Thu Jun 29 14:22:56 2006 +0100 (2006-06-29)
parents 2e5f6c68da5c
children c6ec3dd6fe7f
files xen/common/schedule.c
line diff
     1.1 --- a/xen/common/schedule.c	Thu Jun 29 11:31:10 2006 +0100
     1.2 +++ b/xen/common/schedule.c	Thu Jun 29 14:22:56 2006 +0100
     1.3 @@ -391,9 +391,30 @@ long do_set_timer_op(s_time_t timeout)
     1.4      struct vcpu *v = current;
     1.5  
     1.6      if ( timeout == 0 )
     1.7 +    {
     1.8          stop_timer(&v->timer);
     1.9 +    }
    1.10      else
    1.11 +    {
    1.12 +        if ( unlikely(timeout < 0) ||
    1.13 +             unlikely((uint32_t)((timeout - NOW()) >> 50) != 0) )
    1.14 +        {
    1.15 +            /*
    1.16 +             * Linux workaround: occasionally we will see timeouts a long way
    1.17 +             * in the future due to wrapping in Linux's jiffy time handling.
    1.18 +             * We check for tiemouts wrapped negative, and for positive
    1.19 +             * timeouts more than about 13 days in the future (2^50ns).
    1.20 +             * The correct fix is to trigger an interrupt in a short while
    1.21 +             * (since Linux in fact has pending work to do in this situation).
    1.22 +             */
    1.23 +            DPRINTK("Warning: huge timeout set by domain %d (vcpu %d):"
    1.24 +                    " %"PRIx64"\n",
    1.25 +                    v->domain->domain_id, v->vcpu_id, (uint64_t)timeout);
    1.26 +            timeout = NOW() + MILLISECS(10);
    1.27 +        }
    1.28 +
    1.29          set_timer(&v->timer, timeout);
    1.30 +    }
    1.31  
    1.32      return 0;
    1.33  }