From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030222AbWGFFnm (ORCPT ); Thu, 6 Jul 2006 01:43:42 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030232AbWGFFnm (ORCPT ); Thu, 6 Jul 2006 01:43:42 -0400 Received: from e1.ny.us.ibm.com ([32.97.182.141]:48044 "EHLO e1.ny.us.ibm.com") by vger.kernel.org with ESMTP id S1030231AbWGFFnk (ORCPT ); Thu, 6 Jul 2006 01:43:40 -0400 Subject: Re: 2.6.17-mm2 hrtimer code wedges at boot? From: john stultz To: Valdis.Kletnieks@vt.edu Cc: Roman Zippel , Andrew Morton , linux-kernel@vger.kernel.org In-Reply-To: <1152148332.24656.125.camel@cog.beaverton.ibm.com> References: <20060624061914.202fbfb5.akpm@osdl.org> <200606262141.k5QLf7wi004164@turing-police.cc.vt.edu> <200606271643.k5RGh9ZQ004498@turing-police.cc.vt.edu> <200606271907.k5RJ7kdg003953@turing-police.cc.vt.edu> <1151453231.24656.49.camel@cog.beaverton.ibm.com> <200606292307.k5TN7MGD011615@turing-police.cc.vt.edu> <1151695569.5375.22.camel@localhost.localdomain> <200606302104.k5UL41vs004400@turing-police.cc.vt.edu> <200607050429.k654TXUr012316@turing-police.cc.vt.edu> <1152147114.24656.117.camel@cog.beaverton.ibm.com> <1152148332.24656.125.camel@cog.beaverton.ibm.com> Content-Type: text/plain Date: Wed, 05 Jul 2006 22:43:36 -0700 Message-Id: <1152164616.5730.6.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2006-07-05 at 18:12 -0700, john stultz wrote: > On Wed, 2006-07-05 at 17:51 -0700, john stultz wrote: > > I quickly revived my P-D adjustment patch and it does not appear to > > suffer from the same problem with the above droptick change (although > > its only been lightly tested). > > > > I realize you may have a more trivial change to this issue, but would > > you consider my method again? > > > > Vladis: Mind trying the following patch to see if it affects the > > behavior. > > Bah! Never mind. Don't bother, trying it. I take that back. :) Vladis, would you still try that patch to see if it helps? > Of course, only after I send the mail, the same problem reproduces > itself w/ my patch! In my rush to finish up for dinner, I fat-fingered the droptick code (forgot the static!) so I wasn't ever get timer ticks. :( Then after I fixed that, I noticed long-ish stalls starting X or switching between X and VT consoles. However after digging into it I realized the issue is that xtime is only being updated every 100 ticks, and nanosleep used xtime (via hrtimers), so it was getting the extra 100tick latency on every call. So just to be fair, I double checked the following patch against mainline, saw the hang Vladis was seeing, then applied it to my earlier patch along with this patch and the system booted fine w/ no stalls. thanks -john Patch to trigger the boot hang against vanilla 2.6.18-rc1 diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c index d17766d..3f516f6 100644 --- a/kernel/hrtimer.c +++ b/kernel/hrtimer.c @@ -132,7 +132,7 @@ static void hrtimer_get_softirq_time(str do { seq = read_seqbegin(&xtime_lock); - xtim = timespec_to_ktime(xtime); + xtim = ktime_get_real(); tomono = timespec_to_ktime(wall_to_monotonic); } while (read_seqretry(&xtime_lock, seq)); diff --git a/kernel/timer.c b/kernel/timer.c index 396a3c0..5394104 100644 --- a/kernel/timer.c +++ b/kernel/timer.c @@ -1090,6 +1090,9 @@ static void clocksource_adjust(struct cl static void update_wall_time(void) { cycle_t offset; + static int droptick; + if(droptick++%100) + return; clock->xtime_nsec += (s64)xtime.tv_nsec << clock->shift;