From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: [hybrid]: hang in update_wall_time Date: Wed, 21 Mar 2012 11:08:48 -0700 Message-ID: <20120321110848.1978c48d@mantra.us.oracle.com> References: <20120319183009.7b7c251d@mantra.us.oracle.com> <4F6859AB0200007800079895@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4F6859AB0200007800079895@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel , IanCampbell , "stefano.stabellini@eu.citrix.com" List-Id: xen-devel@lists.xenproject.org On Tue, 20 Mar 2012 09:19:23 +0000 "Jan Beulich" wrote: > >>> On 20.03.12 at 02:30, Mukesh Rathor ... > Your Dom0 hasn't possibly played with the HPET, and Xen at the same > time is using the HPET as clock source? (Preventing this is rather > difficult, as the HPET memory space - iirc - is just 1k, so excluding > Dom0 access to the full page isn't easily possible. Consequently, Xen > so far has been relying on Dom0 to not get in the way.) Pretty close. I debugged it finally, and the problem was the hybrid writing to the HPET while xen was using it. This was happening because ACPI was not properly initialized, and created a ripple effect where hpet_virt_address was set. In PV, it's not set and so hpet_late_init() bails. Anyways, I fixed it, and now to next one caused by proper initialization of ACPI... :). thanks, Mukesh