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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- References:
- Re: first bisection results in -mm3 [was: Re: 2.6.15-mm2: reiser3 oops on suspend and more (bonus oops shot!)]
- From: john stultz <[email protected]>
- Re: first bisection results in -mm3 [was: Re: 2.6.15-mm2: reiser3 oops on suspend and more (bonus oops shot!)]
- From: Mattia Dongili <[email protected]>
- Re: first bisection results in -mm3 [was: Re: 2.6.15-mm2: reiser3 oops on suspend and more (bonus oops shot!)]
- From: john stultz <[email protected]>
- Re: first bisection results in -mm3 [was: Re: 2.6.15-mm2: reiser3 oops on suspend and more (bonus oops shot!)]
- From: Mattia Dongili <[email protected]>
- Re: first bisection results in -mm3 [was: Re: 2.6.15-mm2: reiser3 oops on suspend and more (bonus oops shot!)]
- From: john stultz <[email protected]>
- Re: first bisection results in -mm3 [was: Re: 2.6.15-mm2: reiser3 oops on suspend and more (bonus oops shot!)]
- From: Mattia Dongili <[email protected]>
- Re: first bisection results in -mm3 [was: Re: 2.6.15-mm2: reiser3 oops on suspend and more (bonus oops shot!)]
- From: john stultz <[email protected]>
- Re: first bisection results in -mm3 [was: Re: 2.6.15-mm2: reiser3 oops on suspend and more (bonus oops shot!)]
- From: Mattia Dongili <[email protected]>
- Re: first bisection results in -mm3 [was: Re: 2.6.15-mm2: reiser3 oops on suspend and more (bonus oops shot!)]
- From: "Mattia Dongili" <[email protected]>
- Re: first bisection results in -mm3 [was: Re: 2.6.15-mm2: reiser3 oops on suspend and more (bonus oops shot!)]
- From: john stultz <[email protected]>
- Re: first bisection results in -mm3 [was: Re: 2.6.15-mm2: reiser3 oops on suspend and more (bonus oops shot!)]
- From: Mattia Dongili <[email protected]>
- Re: first bisection results in -mm3 [was: Re: 2.6.15-mm2: reiser3 oops on suspend and more (bonus oops shot!)]
- Prev by Date: Re: [PATCH/RFC] Shared page tables
- Next by Date: Re: [PATCH/RFC] Shared page tables
- Previous by thread: Re: first bisection results in -mm3 [was: Re: 2.6.15-mm2: reiser3 oops on suspend and more (bonus oops shot!)]
- Next by thread: Re: first bisection results in -mm3 [was: Re: 2.6.15-mm2: reiser3 oops on suspend and more (bonus oops shot!)]
- Index(es):
 |