Thanks Kevin for catching that. I fixed it using spin_lock_irqsave
and spin_unlock_irqrestore and have already seen stime going
backwards... I haven't retested all the clocksources and smp.
but it doesn't appear that the incorrect enablement of
interrupts was the problem.
It's interesting that the problem occurs even with one processor.
Hopefully that will make it easier to debug.
Updated debug patch attached.
Thanks,
Dan
> -----Original Message-----
> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> Sent: Saturday, July 26, 2008 12:51 AM
> To: Tian, Kevin; dan.magenheimer@xxxxxxxxxx; Xen-Devel (E-mail)
> Cc: Dave Winchell
> Subject: Re: s_time going backwards on same processor?
>
>
> The code should be using spin_lock_irqsave/spin_unlock_irqrestore.
>
> As it is it's incorrect and could cause odd behaviour. I
> don't know whether
> that would extend to seeing time goes backwards as often as
> Dan reports, but
> obviously the test has to be re-run.
>
> -- Keir
>
> On 26/7/08 03:23, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>
> > In a quick glimpse, your measure_stime_skew has interrupt
> > enabled absolutely at exit, instead of restoring previous
> > setting. Would it be a trouble-maker? I have no latest code
> > at hand, but at least for what I can check:
> >
> > in local_time_calibration:
> >
> > local_irq_disable();
> > curr_master_stime = read_platform_stime();
> > curr_local_stime = get_s_time();
> > rdtscll(curr_tsc);
> > local_irq_enable();
> >
> > with your patch, interrupt is enabled after get_s_time, which
> > then may have curr_tsc read out from a different time point...
> >
> > Thanks,
> > Kevin
> >
> >> From: Dan Magenheimer [mailto:dan.magenheimer@xxxxxxxxxx]
> >> Sent: 2008年7月26日 9:47
> >>
> >> OK, I am definitely recording stime going backwards
> >> observed with the attached patch. I have recorded dozens
> >> over a few hours. It appears to have no
> >> obvious pattern between reports, but one thing
> >> is consistent: In all cases, t->tsc_scale.shift
> >> is -1. I'll try to run some more tests over the
> >> weekend (e.g. with different clocksources... this
> >> is with clocksource=hpet), but thought I'd report
> >> what I have seen. I'm running on a dual-core single
> >> socket ("Conroe").
> >>
> >> Dan
> >>
> >> P.S. If you try the patch, ensure you set
> >> the boot parameter "measurestime".
> >>
> >>> -----Original Message-----
> >>> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> >>> Sent: Wednesday, July 23, 2008 1:06 AM
> >>> To: dan.magenheimer@xxxxxxxxxx; Xen-Devel (E-mail)
> >>> Cc: Dave Winchell
> >>> Subject: Re: s_time going backwards on same processor?
> >>>
> >>>
> >>> On 22/7/08 22:58, "Dan Magenheimer"
> >>> <dan.magenheimer@xxxxxxxxxx> wrote:
> >>>
> >>>> I *do* know that get_s_time() on different processors
> >>>> can have this behavior and I know it is possible for
> >>>> hvm_get_guest_time() to go backwards (timer_mode=0),
> >>>> but I thought s_time was monotonically non-decreasing
> >>>> on any given processor and that read_platform_stime()
> >>>> is also monotonically non-decreasing.
> >>>>
> >>>> Does dom0 maybe have direct hardware access to the hardware
> >>>> platform timer that xen system time is dependent on?
> >>>
> >>> No matter what happens to the underlying platform timer,
> it should be
> >>> impossible for Xen system time to go backwards on any given
> >>> processor. The
> >>> calibration function never sets the TSC and system timestamps
> >>> for the next
> >>> time record any earlier than current TSC value and current
> >>> computed system
> >>> time value. Hence it should be impossible for system time to
> >>> be computed as
> >>> earlier than that time record.
> >>>
> >>> -- Keir
> >>>
> >>>
> >>>
> >>
>
>
>
checkbackwards.patch
Description: Binary data
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home