Re: first bisection results in -mm3 [was: Re: 2.6.15-mm2: reiser3 oops on suspend and more (bonus oops shot!)]

[john stultz <johnstul@us.ibm.com>]

On Wed, 2006-01-25 at 00:04 +0100, Mattia Dongili wrote:
> On Tue, Jan 24, 2006 at 02:27:14PM -0800, john stultz wrote:
> > difficult spot is that if the cpufreq notification driver is a module,
> > then there will always be a window between the point at which we start
> > using the TSC to the point where we find out that the TSC is changing
> > frequency. Not sure what to do here just yet.
> 
> I was wondering if you could force an do_gettimeofday call quite early
> in order to lower tsc priority as soon as possible, but maybe I'm not
> entirely into that code :)

Well, it isn't do_gettimeofday that needs to be called, but we need a
way to decide if we should call tsc_mark_unstable(). Currently we do
that when we get a cpufreq transition notification if the cpu's TSC is
not constant.  The problem being: on your system, that notification
isn't called until after the cpufreq driver module loads. This is of
course, after we've started to use the TSC.

If the cpufreq driver loaded earlier, or we had some other way of
checking if the TSC was not constant, we could call tsc_mark_unstable()
then.

We'll probably have to do a manual check like what the cpufreq driver
does early on so we can have this info before we install the TSC
clocksource. I'll let you know when I have a patch to try.


> > Although I'm curious: Did the recent changes in 2.6.16-rc1-mm2 had any
> > effect on this issue?
> 
> no, I'm currently running it and the same behaviour still applies.

Drat. Well, thanks for testing.

-john

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/