Re: 2.6.17-mm2 hrtimer code wedges at boot?

From: Valdis.Kletnieks@vt.edu
To: john stultz <johnstul@us.ibm.com>
Cc: Roman Zippel <zippel@linux-m68k.org>,
	Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org
Subject: Re: 2.6.17-mm2 hrtimer code wedges at boot?
Date: Fri, 30 Jun 2006 17:04:01 -0400	[thread overview]
Message-ID: <200606302104.k5UL41vs004400@turing-police.cc.vt.edu> (raw)
In-Reply-To: Your message of "Fri, 30 Jun 2006 12:26:09 PDT." <1151695569.5375.22.camel@localhost.localdomain>

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

On Fri, 30 Jun 2006 12:26:09 PDT, john stultz said:

> Its a little after the fact (since things have already gone awry), but
> it does show the multiplier is way out of bound.
> 
> I suspect the following patch will resolve it. The update callback
> hasn't kept up with the changes from Roman, and is a bit useless anyway.
> If the TSC is changing frequency, its unstable and we don't want to use
> it, so lets just mark it as such and move along.
> 
> I'll work on a patch to cleanup the update_callback code, but if this
> resolves the issue, it should be the safe short term fix for 2.6.18.

*AHA* I *found* the bugger, I think.

In kernel/timer.c, we have:

static void clocksource_adjust(struct clocksource *clock, s64 offset)
(s64 used for offset in multiple places).

However, in other places, offset is a 'cycle_t', which is:

include/linux/clocksource.h:typedef u64 cycle_t;

So it looks like a signed/unsigned screwage.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]