What you are dealing with is a machine that is using ITC as a time bases. That is a special case. The fix should not affect machines that have a proper time source. More below. You can circumvent the compensation for ITC inaccuracies by specifying "nojitter" on the kernel command if you are willing to take the risk of slightly inaccurate time.
On Fri, 29 Jul 2005 [EMAIL PROTECTED] wrote: > The patch below makes things less bad by not letting Y & Z do the cmpxchg if > they are going to fail the read_seqretry() test anyway. But it is very ugly > to do this extra test on xtime_lock ... so I'm hoping that someone can come > up with something better. Well get a proper time source and do not use ITC for a time source in an SMP system. Got HPET hardware? > -extern unsigned long time_interpolator_get_offset(void); > +extern unsigned long time_interpolator_get_offset(long); This is going to cause unnecessary overhead for non ITC users. > - nsec = xtime.tv_nsec+time_interpolator_get_offset(); > + nsec = xtime.tv_nsec+time_interpolator_get_offset(seq); Here it is. > - offset = time_interpolator_get_offset(); > + offset = time_interpolator_get_offset(seq); and here again. > + /* > + * If our caller is going to ignore us and retry, then > + * don't burn up the bus with the cmpxchg > + */ > + if (seq && unlikely(read_seqretry(&xtime_lock, seq))) > + return now; Two read_seqretries() for one read_seqbegin()? That its unusual to say the least. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/