Messages in this thread | | | Subject | Re: first bisection results in -mm3 [was: Re: 2.6.15-mm2: reiser3 oops on suspend and more (bonus oops shot!)] | From | john stultz <> | Date | Tue, 24 Jan 2006 16:12:09 -0800 |
| |
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
- 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/
| |