From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754945AbZHTQxr (ORCPT ); Thu, 20 Aug 2009 12:53:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754585AbZHTQxq (ORCPT ); Thu, 20 Aug 2009 12:53:46 -0400 Received: from mtagate2.de.ibm.com ([195.212.17.162]:51495 "EHLO mtagate2.de.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751216AbZHTQxp (ORCPT ); Thu, 20 Aug 2009 12:53:45 -0400 Date: Thu, 20 Aug 2009 18:53:44 +0200 From: Martin Schwidefsky To: Thomas Gleixner Cc: Ingo Molnar , Peter Zijlstra , john stultz , linux-kernel@vger.kernel.org Subject: Re: [circular locking bug] Re: [patch 00/15] clocksource / timekeeping rework V4 (resend V3 + bug fix) Message-ID: <20090820185344.1c0e48f8@skybase> In-Reply-To: References: <1250300765.8269.29.camel@localhost.localdomain> <20090815095221.GA15831@elte.hu> <20090817094042.03fe5d38@skybase> <20090817092807.GA10460@elte.hu> <20090818170942.3ab80c91@skybase> <20090819202554.GA19482@elte.hu> <20090820112820.47d833c1@skybase> <20090820095821.GA29093@elte.hu> <20090820123547.1ef5a5e0@skybase> Organization: IBM Corporation X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.5; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 20 Aug 2009 18:14:07 +0200 (CEST) Thomas Gleixner wrote: > On Thu, 20 Aug 2009, Martin Schwidefsky wrote: > > On Thu, 20 Aug 2009 11:58:21 +0200 > > > There should be a time management kernel thread instead > > > (or workqueue), which does a proper state machine of all > > > these properties - without having to call this stuff from > > > within a timer handler. > > > > We could use that time managment kernel thread for the watchdog > > downgrade as well. Dunno if it is worth to create another kernel thread > > that just sits there doing nothing for 99.9% of the time. > > > > As for the fix: my brains starts to hurt looking at the pit clocksource > > code. Why does it set CLOCK_EVT_FEAT_ONESHOT but then unregisters the > > clocksource when the mode is set to CLOCK_EVT_MODE_ONESHOT?? That does > > not make any sense to me. I would have expected that the pit does not > > set CLOCK_EVT_MODE_ONESHOT. The timekeeping code wouldn't try use the > > clock for one-shot if the bit is not set. And to unregister the clock > > only because the mode is set to shutdown or unused doesn't seem to be > > necessary either. My fix would be to remove the CLOCK_EVT_MODE_ONESHOT > > bit from the features mask and to remove the clocksource_unregister > > from the set_mode callback. > > No. On UP machines we can run in oneshot mode with the PIT. > > The disable PIT clocksource hack was done in commit > 1a0c009ac53de4a7664a1239936f0bc258133156. Yes, in hindsight we should > have done 3f68535adad8dd89499505a65fb25d0e02d118cc in the first place. > > So now the simple and correct fix is to remove the unregister call. Sorry if I don't see the obvious but how can that work? If the pit as clocksource is switched to CLOCK_EVT_MODE_ONESHOT it simply vanishes. How is it possible that a UP machine runs with the PIT in oneshot mode? And yes, hindsight is easier than foresight. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin.