From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: The HPET issue on Linux Date: Wed, 6 Jan 2010 12:09:57 +0200 Message-ID: <20100106100957.GF4905@redhat.com> References: <201001061748.52689.sheng@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Beth Kon , kvm@vger.kernel.org To: Sheng Yang Return-path: Received: from mx1.redhat.com ([209.132.183.28]:51729 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755656Ab0AFKKL (ORCPT ); Wed, 6 Jan 2010 05:10:11 -0500 Content-Disposition: inline In-Reply-To: <201001061748.52689.sheng@linux.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Jan 06, 2010 at 05:48:52PM +0800, Sheng Yang wrote: > Hi Beth > > I still found the emulated HPET would result in some boot failure. For > example, on my 2.6.30, with HPET enabled, the kernel would fail check_timer(), > especially in timer_irq_works(). > > The testing of timer_irq_works() is let 10 ticks pass(using mdelay()), and > want to confirm the clock source with at least 5 ticks advanced in jiffies. > I've checked that, on my machine, it would mostly get only 4 ticks when HPET > enabled, then fail the test. On the other hand, if I using PIT, it would get > more than 10 ticks(maybe understandable if some complementary ticks there). Of > course, extend the ticks count/mdelay() time can work. > > I think it's a major issue of HPET. And it maybe just due to a too long > userspace path for interrupt injection... If it's true, I think it's not easy > to deal with it. > PIT tick are reinjected automatically, HPET should probably do the same although it may just create another set of problems. -- Gleb.