The order of reading ar.itc is incorrect with respect to all other
variables in fsys_gettimeofday.  All variables involved in time
interpolation need to be protected by the sequence lock xtime_lock for
consistency check.  However, the first time that fsys_gettimeofday()
takes a time stamp, it reads the count outside the seq lock leading to
the following possible time leap into the future scenario:

fsys_gettimeofday:
  read ar.itc

  .... <context switch> ....

  read_seqbegin
    read all other variables (last_nsec_offset, jiffies, xtime)
    do time interpolation - elapsed_cycles become a large negative
       number and converting it to nsec overflows and make it a
       large positive number
  read_seqretry success
  updates last_nsec_offset (which is several seconds into the future).

All subsequent gettimeofday() calls will be wrong as well because
monotonic property kicks in.  It only self-corrects once that future
time actually arrives.

This patch fixes the problem (and moves one instruction to make some room).
Signed-off-by: Ken Chen <kenneth.w.chen@intel.com>
Signed-off-by: Asit Mallick <asit.k.mallick@intel.com>
Signed-off-by: David Mosberger <davidm@hpl.hp.com>