[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] Time goes backwards in dom0 in xen-unstable



Back to the first hmmm...  The same problem
arose after about three hours.  Exactly the
same symptoms.  Note that my test VM has
4 vcpus but is otherwise unremarkable.

I'll try again with tip (post-rc2) tomorrow.

> -----Original Message-----
> From: Dan Magenheimer 
> Sent: Wednesday, April 15, 2009 11:12 AM
> To: Dan Magenheimer; Keir Fraser; Xen-Devel (E-mail); Tian, Kevin
> Subject: RE: [Xen-devel] Time goes backwards in dom0 in xen-unstable
> 
> 
> Double hmmm... after destroying the domain and restarting
> it has been running fine for over two hours.  So
> apparently it was a coincidence.
> 
> > -----Original Message-----
> > From: Dan Magenheimer 
> > Sent: Wednesday, April 15, 2009 8:59 AM
> > To: Dan Magenheimer; Keir Fraser; Xen-Devel (E-mail); Tian, Kevin
> > Subject: RE: [Xen-devel] Time goes backwards in dom0 in xen-unstable
> > 
> > 
> > Hmmm... after only a few minutes with cpuidle=off,
> > my test domPV froze up after printing a number of
> > call traces starting with:
> > 
> > INFO: task xxx:nnn blocked for more than 480 seconds.
> > 
> > At the top of all of the traces is either
> > getnstimeofday+51 or io_schedule+44.
> > 
> > (Note that this PV domain is a 2.6.29 kernel... don't
> > know if the messages are the same on an older kernel.)
> > 
> > > -----Original Message-----
> > > From: Dan Magenheimer 
> > > Sent: Wednesday, April 15, 2009 8:22 AM
> > > To: Keir Fraser; Xen-Devel (E-mail); Tian, Kevin
> > > Subject: RE: [Xen-devel] Time goes backwards in dom0 in 
> xen-unstable
> > > 
> > > 
> > > I can confirm that cpuidle=off makes the timer_interrupt
> > > scaleability problem go away.
> > > 
> > > It also appears that the max cycles for the MSI
> > > interrupts becomes reasonably small again.  Was
> > > this expected?
> > > 
> > > I'll leave it running for awhile but may not be
> > > able to confirm the "Time went backwards" error
> > > goes away as it seemed to appear only after a
> > > random long period of time.
> > > 
> > > (BTW, Kevin, hpetbroadcast did not make the problem
> > > go away.)
> > > 
> > > Dan
> > > 
> > > > -----Original Message-----
> > > > From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> > > > Sent: Wednesday, April 15, 2009 1:31 AM
> > > > To: Dan Magenheimer; Xen-Devel (E-mail)
> > > > Subject: Re: [Xen-devel] Time goes backwards in dom0 in 
> > xen-unstable
> > > > 
> > > > 
> > > > On 14/04/2009 20:36, "Dan Magenheimer" 
> > > > <dan.magenheimer@xxxxxxxxxx> wrote:
> > > > 
> > > > > I'm seeing some "Time went backwards" errors reported
> > > > > in dom0 in near-tip (c/s 19515) xen-unstable build.
> > > > > It's rare and random and not reproducible, but here's
> > > > > the report that just showed up.  There was no load
> > > > > running at the time.
> > > > > 
> > > > > I can move to 3.4-rc1 if that would be helpful but I
> > > > > don't remember seeing any time-related changes recently.
> > > > > 
> > > > > This was on my dual-core test machine which reports
> > > > > lots of power management info during Xen boot.
> > > > 
> > > > If you specify 'cpuidle=off' as a Xen boot parameter, does 
> > > > that make the
> > > > timer_interrupt scalability problem go away, and this 
> > time backwards
> > > > problem? I was going to enable by default in 3.4 but could go 
> > > > the other way.
> > > > 
> > > >  -- Keir
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > > > http://lists.xensource.com/xen-devel
> > > >
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.