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 Tue, 2006-01-24 at 15:48 -0800, john stultz wrote:
> 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.

Mattia,
	Just to verify I'm not barking up the wrong tree here, could you try
building w/ CONFIG_X86_SPEEDSTEP_ICH=y instead of as a module?

This should force the cpufreq driver to load earlier, and hopefully
we'll get a notification earlier as well.

thanks
-john