seqlock/unlock(&xtime_lock) problems cause keyboard, time skew problems

seqlock/unlock(&xtime_lock) problems cause keyboard, time skew problems

[Jerry Cooperstein]

Since 2.5.60 my thinkpad keyboard repeat rate has been erratic when
started up on battery power; plugging into AC after startup only makes
it worse.  Starting up on AC is fine.  Compiling without apm in any
form is fine.

I posted on this a month ago and noone had solutions although I got
several emails from folks with similarly afflicted machines.

Since then I've noticed that I also get a bad time skew, with the
system clock jumping forward.

I'm pretty sure the problem arose with the introduction of the
seqlock/unlock interface to protect xtime_lock instead of a regular rw
lock.  Short of trying to back the whole thing out, does any one have
similar observations, suggestions, solutions?

======================================================================
 Jerry Cooperstein,  Senior Consultant,  <coop@axian.com>
 Axian, Inc., Software Consulting and Training
 4800 SW Griffith Dr., Ste. 202,  Beaverton, OR  97005 USA
 http://www.axian.com/               
======================================================================

Re: seqlock/unlock(&xtime_lock) problems cause keyboard, time skew problems

[Stephen Hemminger]

On Tue, 2003-03-18 at 11:05, Jerry Cooperstein wrote:
> Since 2.5.60 my thinkpad keyboard repeat rate has been erratic when
> started up on battery power; plugging into AC after startup only makes
> it worse.  Starting up on AC is fine.  Compiling without apm in any
> form is fine.
> 
> I posted on this a month ago and noone had solutions although I got
> several emails from folks with similarly afflicted machines.
> 
> Since then I've noticed that I also get a bad time skew, with the
> system clock jumping forward.
> 
> I'm pretty sure the problem arose with the introduction of the
> seqlock/unlock interface to protect xtime_lock instead of a regular rw
> lock.  Short of trying to back the whole thing out, does any one have
> similar observations, suggestions, solutions?

Does this notebook vary the clock rate? If so then using TSC for 
time of day clock is probably a problem.  Try booting with notsc.

Re: seqlock/unlock(&xtime_lock) problems cause keyboard, time skew problems

[Jerry Cooperstein]

On Tue, Mar 18, 2003 at 12:32:24PM -0800, Stephen Hemminger wrote:
> On Tue, 2003-03-18 at 11:05, Jerry Cooperstein wrote:
> > Since 2.5.60 my thinkpad keyboard repeat rate has been erratic when
....

> 
> Does this notebook vary the clock rate? If so then using TSC for 
> time of day clock is probably a problem.  Try booting with notsc.

Yes the notebook varies the clock rate -- its about 150MHZ with
batter power, 500 MHZ on AC.

I tried booting with notsc, the results were:

for kernels through 2.5.63:  kernel panic on boot, message saying pentium+
requires tsc

for 2.5.64, 2.5.65:  no failure, but no help.

Merci

coop

======================================================================
 Jerry Cooperstein,  Senior Consultant,  <coop@axian.com>
 Axian, Inc., Software Consulting and Training
 4800 SW Griffith Dr., Ste. 202,  Beaverton, OR  97005 USA
 http://www.axian.com/               
======================================================================

Re: seqlock/unlock(&xtime_lock) problems cause keyboard, time skew problems

[john stultz]

Jerry Cooperstein wrote:

>> Does this notebook vary the clock rate? If so then using TSC for
>> time of day clock is probably a problem.  Try booting with notsc.
> 
> I tried booting with notsc, the results were:
> 
> for kernels through 2.5.63:  kernel panic on boot, message saying pentium+
> requires tsc
> 
> for 2.5.64, 2.5.65:  no failure, but no help.

Check the boot msgs. You're kernel is compiled w/ CONFIG_X86_TSC, so it
should print a warning as such stating it is ignoring the notsc option.

Try compiling the kernel for i386 and the kernel then boot w/ notsc. Do be
warned, if you're running w/ an i686 compiled glibc your box will hang
after the "Freeing unused kernel memory: " msg. 

Another thing to check is if the lost-tick compensation code is biting you.
Try commenting out the "detect_lost_tick()" call from timer_interrupt() in
arch/i386/kernel/time.c

Let me know if that changes anything.

thanks
-john

Re: seqlock/unlock(&xtime_lock) problems cause keyboard, time skew problems

[Jerry Cooperstein]

On Tue, Mar 18, 2003 at 03:34:32PM -0800, john stultz wrote:
... 
> Check the boot msgs. You're kernel is compiled w/ CONFIG_X86_TSC, so it
> should print a warning as such stating it is ignoring the notsc option.

yep, I missed it, the experiment was never performed.

> 
> Try compiling the kernel for i386 and the kernel then boot w/ notsc. Do be
> warned, if you're running w/ an i686 compiled glibc your box will hang
> after the "Freeing unused kernel memory: " msg. 

I compiled for no TSC using Stephen Hemminger's patch -- that worked.

> 
> Another thing to check is if the lost-tick compensation code is biting you.
> Try commenting out the "detect_lost_tick()" call from timer_interrupt() in
> arch/i386/kernel/time.c

I will try that out too, even though problem now seems 'solved.'

> 
> Let me know if that changes anything.
> 
> thanks
> -john

thanks

coop

[PATCH] boot time parameter to turn of TSC usage

[Stephen Hemminger]

For machines that don't want to cooperate and have bad TSC counter and/or
change CPU frequency without change support.

This fixes the problem on Jerry Cooperstein's PIII laptop.
Could be useful for other people and tech support situations.

Please consider applying.
Thanks
Steve


diff -Nru a/arch/i386/kernel/timers/timer_tsc.c b/arch/i386/kernel/timers/timer_tsc.c
--- a/arch/i386/kernel/timers/timer_tsc.c	Tue Mar 18 15:28:10 2003
+++ b/arch/i386/kernel/timers/timer_tsc.c	Tue Mar 18 15:28:10 2003
@@ -15,6 +15,7 @@
 #include <asm/processor.h>
 
 int tsc_disable __initdata = 0;
+static int tsc_clock_disable __initdata = 0;
 
 extern spinlock_t i8253_lock;
 
@@ -241,6 +242,13 @@
 };
 #endif
 
+/* Don't use TSC for time of day clock */
+static int __init tsc_noclock_setup(char *str)
+{
+	tsc_clock_disable = 1;
+	return 1;
+}
+__setup("notsclock", tsc_noclock_setup);
 
 static int init_tsc(void)
 {
@@ -273,7 +281,7 @@
 	cpufreq_register_notifier(&time_cpufreq_notifier_block, CPUFREQ_TRANSITION_NOTIFIER);
 #endif
 
-	if (cpu_has_tsc) {
+	if (cpu_has_tsc && !tsc_clock_disable) {
 		unsigned long tsc_quotient = calibrate_tsc();
 		if (tsc_quotient) {
 			fast_gettimeoffset_quotient = tsc_quotient;

Re: [PATCH] boot time parameter to turn of TSC usage

[Andrew Morton]

Stephen Hemminger <shemminger@osdl.org> wrote:
>
> For machines that don't want to cooperate and have bad TSC counter and/or
> change CPU frequency without change support.
> 
> This fixes the problem on Jerry Cooperstein's PIII laptop.
> Could be useful for other people and tech support situations.

Is there no way in which this can be auto-detected?

> +__setup("notsclock", tsc_noclock_setup);

People have recently worked to make Documentation/kernel-parameters.txt
relatively up-to-date.  Please try to remember to keep it in sync...

Re: [PATCH] boot time parameter to turn of TSC usage

[Stephen Hemminger]

On Tue, 2003-03-18 at 16:39, Andrew Morton wrote:
> Stephen Hemminger <shemminger@osdl.org> wrote:
> >
> > For machines that don't want to cooperate and have bad TSC counter and/or
> > change CPU frequency without change support.
> > 
> > This fixes the problem on Jerry Cooperstein's PIII laptop.
> > Could be useful for other people and tech support situations.
> 
> Is there no way in which this can be auto-detected?

Will leave that for someone with more direct knowledge access to
the chipset info.

> 
> > +__setup("notsclock", tsc_noclock_setup);
> 
> People have recently worked to make Documentation/kernel-parameters.txt
> relatively up-to-date.  Please try to remember to keep it in sync...
> 

--- kernel-parameters.txt.orig	2003-03-18 08:36:39.000000000 -0800
+++ kernel-parameters.txt.new	2003-03-18 17:01:32.000000000 -0800
@@ -627,7 +627,12 @@
 
 	nosync		[HW,M68K] Disables sync negotiation for all devices.
 
-	notsc		[BUGS=IA-32] Disable Time Stamp Counter
+	notsc		[BUGS=IA-32] Disable Time Stamp Counter.
+			Turns off TSC in processor. Kernel must
+			be compiled without TSC support.
+	
+	notsclock	[BUGS=IA-32] Tells kernel not to use 
+			Time Stamp Counter for gettimeofday. 
 
 	nousb		[USB] Disable the USB subsystem
 

Re: seqlock/unlock(&xtime_lock) problems cause keyboard, time skew problems

[Stephen Hemminger]

On Tue, 2003-03-18 at 12:59, Jerry Cooperstein wrote:
> On Tue, Mar 18, 2003 at 12:32:24PM -0800, Stephen Hemminger wrote:
> > On Tue, 2003-03-18 at 11:05, Jerry Cooperstein wrote:
> > > Since 2.5.60 my thinkpad keyboard repeat rate has been erratic when
> ....
> 
> > 
> > Does this notebook vary the clock rate? If so then using TSC for 
> > time of day clock is probably a problem.  Try booting with notsc.
> 
> Yes the notebook varies the clock rate -- its about 150MHZ with
> batter power, 500 MHZ on AC.

Part of the problem may be that the clock rate can change but the
cpu frequency code can't support the Intel SpeedStep.  

Maybe, someone with more direct experience with laptop's can help.

Re: seqlock/unlock(&xtime_lock) problems cause keyboard, time skew problems

[Jerry Cooperstein]

On Tue, Mar 18, 2003 at 03:29:11PM -0800, Stephen Hemminger wrote:
.....
> On Tue, 2003-03-18 at 14:58, Jerry Cooperstein wrote:
> > I tried turning on SpeedStep (which I didn't think I had...) and
> > I got:
> > 
> > cpufreq: Intel(R) SpeedStep(TM) for this chipset not (yet) available.
> 
> Unfortunately, Intel SpeedStep is proprietary and they won't tell Linux
> how to manage it.  The best thing might be to figure out how to force kernel
> not to use TSC on this beast.
> 
> Can you take CONFIG_X86_TSC out of your config.  Then the kernel shouldn't
> use TSC.

Well if you remove CONFIG_X86_TSC out of your .config file, the kernel
build always puts it back in (i guess it believes it knows best).  So
i just used your patch below, and indeed it does work; clock speed is
now normal as is keyboard repeat rate. Immediate problem solved 
--but case not closed. 

I have to go back and clean out the earlier patches which didn't help
on their own, but I doubt they make a difference.  I'll leave it to you
to submit this as patch to the kernel, as I'm not sure it is solving
or hiding the problem.  But it works for me:>

At any rate, there is something in the seqlock stuff that broke this
stuff.  I'll keep trying to figure out exactly what.  

Thanks for all your hard work.  I appreciate it.

======================================================================
 Jerry Cooperstein,  Senior Consultant,  <coop@axian.com>
 Axian, Inc., Software Consulting and Training
 4800 SW Griffith Dr., Ste. 202,  Beaverton, OR  97005 USA
 http://www.axian.com/               
======================================================================


> 
> Or try this patch and boot with "notsclock"
> 
> diff -Nru a/arch/i386/kernel/timers/timer_tsc.c b/arch/i386/kernel/timers/timer_tsc.c
> --- a/arch/i386/kernel/timers/timer_tsc.c	Tue Mar 18 15:28:10 2003
> +++ b/arch/i386/kernel/timers/timer_tsc.c	Tue Mar 18 15:28:10 2003
> @@ -15,6 +15,7 @@
>  #include <asm/processor.h>
>  
>  int tsc_disable __initdata = 0;
> +static int tsc_clock_disable __initdata = 0;
>  
>  extern spinlock_t i8253_lock;
>  
> @@ -241,6 +242,13 @@
>  };
>  #endif
>  
> +/* Don't use TSC for time of day clock */
> +static int __init tsc_noclock_setup(char *str)
> +{
> +	tsc_clock_disable = 1;
> +	return 1;
> +}
> +__setup("notsclock", tsc_noclock_setup);
>  
>  static int init_tsc(void)
>  {
> @@ -273,7 +281,7 @@
>  	cpufreq_register_notifier(&time_cpufreq_notifier_block, CPUFREQ_TRANSITION_NOTIFIER);
>  #endif
>  
> -	if (cpu_has_tsc) {
> +	if (cpu_has_tsc && !tsc_clock_disable) {
>  		unsigned long tsc_quotient = calibrate_tsc();
>  		if (tsc_quotient) {
>  			fast_gettimeoffset_quotient = tsc_quotient;
>