From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mukesh Rathor <mukesh.rathor@oracle.com>
Subject: [hybrid]: hang in update_wall_time
Date: Mon, 19 Mar 2012 18:30:09 -0700
Message-ID: <20120319183009.7b7c251d@mantra.us.oracle.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>, Ian Campbell <Ian.Campbell@citrix.com>, "stefano.stabellini@eu.citrix.com" <stefano.stabellini@eu.citrix.com>
List-Id: xen-devel@lists.xenproject.org

Hi Ian/Stefano:

I changed over to the PV clock for hybrid liked we talked at the
hackathon. I still have the hang in update_wall_time() after dom0
switches to xen as clocksource.

The source of hang seems to be in xen stime_local_stamp in cpu_time that
suddenly jumps to a large 64bit value. I've been chasing to figure
where that happens, and why for the hybrid and not PV. It appears the
source of jump is time_calibration_std_rendezvous()  in 
c->stime_master_stamp. Chasing that, seems to come from 
read_platform_stime(). The jump happens after switch to
xen clocksource in dom0.

I'll continue to debug, but let me know if you have any thoughts or
idea what might be going on.

thanks,
Mukesh