Synaptics losing sync

Synaptics losing sync

[Ricardo Galli]

I've sent this report before. 

I repeat it just in case someone found a workaround, and because 
2.6.0-test9 gives other related errors as well (TSC error):

...
Synaptics driver lost sync at 1st byte
Synaptics driver lost sync at 1st byte
Synaptics driver lost sync at 1st byte
Synaptics driver lost sync at 4th byte
Synaptics driver lost sync at 1st byte
Synaptics driver lost sync at 1st byte
Synaptics driver lost sync at 1st byte
Synaptics driver lost sync at 1st byte
Synaptics driver resynced.
Losing too many ticks!
TSC cannot be used as a timesource. (Are you running with SpeedStep?)
Falling back to a sane timesource.
Synaptics driver lost sync at 1st byte
...

The laptop is a Dell X200 with APM and cpufreq enabled, and IO-apic 
disabled.

I tested with and w/o preemptive kernel and cpufreq with the same results. 

I also tried with 2.6.0-test9-bk4 (after last psmouse changes). I also 
tried modifying the sources and decreasing the synaptics' 80 packets per 
seconds to 40 packets but I still get the same errors.

Regards,

-- 
  ricardo galli       GPG id C8114D34
  http://mnm.uib.es/~gallir/

Re: Synaptics losing sync

[Peter Osterlund]

Ricardo Galli <gallir@uib.es> writes:

> I've sent this report before. 
> 
> I repeat it just in case someone found a workaround, and because 
> 2.6.0-test9 gives other related errors as well (TSC error):
> 
> ...
> Synaptics driver lost sync at 1st byte
> Synaptics driver lost sync at 1st byte
> Synaptics driver lost sync at 1st byte
> Synaptics driver lost sync at 4th byte
> Synaptics driver lost sync at 1st byte
> Synaptics driver lost sync at 1st byte
> Synaptics driver lost sync at 1st byte
> Synaptics driver lost sync at 1st byte
> Synaptics driver resynced.
> Losing too many ticks!
> TSC cannot be used as a timesource. (Are you running with SpeedStep?)
> Falling back to a sane timesource.
> Synaptics driver lost sync at 1st byte
> ...
> 
> The laptop is a Dell X200 with APM and cpufreq enabled, and IO-apic 
> disabled.
> 
> I tested with and w/o preemptive kernel and cpufreq with the same results. 

Did you try without APM? My laptop loses many clock ticks if I enable
APM. It works fine with ACPI though.

-- 
Peter Osterlund - petero2@telia.com
http://w1.894.telia.com/~u89404340

Re: Synaptics losing sync

[Ricardo Galli]

On Saturday 01 November 2003 22:04, Peter Osterlund shaped the electrons 
to shout:
> > The laptop is a Dell X200 with APM and cpufreq enabled, and IO-apic
> > disabled.
> >
> > I tested with and w/o preemptive kernel and cpufreq with the same
> > results.
>
> Did you try without APM? My laptop loses many clock ticks if I enable
> APM. It works fine with ACPI though.

It seems this is the problem, running with acpi during half an hour 
without any error. The synaptics mouse feels much "smoother" too.

But ACPI doesn't see the battery nor the power button in my laptop though. 

Thanks, after months trying the new synaptics driver, fianlly you pointed 
out the problem.

-- 
  ricardo galli       GPG id C8114D34
  http://mnm.uib.es/~gallir/

Re: Synaptics losing sync

[Ruben Puettmann]

You wrote  in linux.kernel:
> I've sent this report before. 
>
> I repeat it just in case someone found a workaround, and because 
> 2.6.0-test9 gives other related errors as well (TSC error):
>
> ...
> Synaptics driver lost sync at 1st byte
> Synaptics driver lost sync at 1st byte
> Synaptics driver lost sync at 1st byte
> Synaptics driver lost sync at 4th byte
> Synaptics driver lost sync at 1st byte
> Synaptics driver lost sync at 1st byte
> Synaptics driver lost sync at 1st byte
> Synaptics driver lost sync at 1st byte
> Synaptics driver resynced.
> Losing too many ticks!
> TSC cannot be used as a timesource. (Are you running with SpeedStep?)
> Falling back to a sane timesource.
> Synaptics driver lost sync at 1st byte
> ...
>
> The laptop is a Dell X200 with APM and cpufreq enabled, and IO-apic 
> disabled.
>
Here the same with IBM Thinkpad R40 2722GDG with APM cause ACPI is for
this laptop totaly broken.

                Ruben


-- 
Ruben Puettmann
ruben@puettmann.net
http://www.puettmann.net

Re: Synaptics losing sync

[Szymon Acedański]

Hi!

On Saturday 01 November 2003 23:37, Ruben Puettmann wrote:
> > ...
> > Synaptics driver lost sync at 1st byte
> > Synaptics driver resynced.
> > Losing too many ticks!
> > TSC cannot be used as a timesource. (Are you running with SpeedStep?)
> > Falling back to a sane timesource.
> > Synaptics driver lost sync at 1st byte
> > ...
> >

I can observe the same "Synaptics lost sync" messages on Acer TravelMate 242XC 
with ACPI enabled (without APM even compiled) on 2.6.0-test[0-9]. But I 
silently ignore these messages - touchpad works ok. I use an USB mouse, but 
messages appear even without it plugged.

"Losing too many ticks" exists when I'm running with cpufreq [p4_clockmod] and 
clock=tsc (default). This is because of rescaling TSC pitch by cpufreq, I 
think. If I specify in bootloader clock=hpet, problem disappears. [Am I doing 
right?]

I can provide more information if somebody is interested.

Cheers
Szymon

Re: Synaptics losing sync

[Ruben Puettmann]

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]

On Sun, Nov 02, 2003 at 10:48:33AM +0100, Szymon Aceda?ski wrote:

                hy,
 
> "Losing too many ticks" exists when I'm running with cpufreq [p4_clockmod] and 
> clock=tsc (default). This is because of rescaling TSC pitch by cpufreq, I 
> think. If I specify in bootloader clock=hpet, problem disappears. [Am I doing 
> right?]
> 
If I boot with clock=hpet the cpu MHz in cat /proc/cpuinfo is 0.

Kernel 2.6.0-tes8-bk1
IBM Thinkpad with PentiumM

                Ruben

-- 
Ruben Puettmann
ruben@puettmann.net
http://www.puettmann.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Synaptics losing sync

[Szymon Acedański]

On Monday 03 November 2003 14:25, you wrote:
> On Sun, Nov 02, 2003 at 10:48:33AM +0100, Szymon Aceda?ski wrote:
>
>                 hy,
>
> > "Losing too many ticks" exists when I'm running with cpufreq
> > [p4_clockmod] and clock=tsc (default). This is because of rescaling TSC
> > pitch by cpufreq, I think. If I specify in bootloader clock=hpet, problem
> > disappears. [Am I doing right?]
>
> If I boot with clock=hpet the cpu MHz in cat /proc/cpuinfo is 0.

Oh, yes. HPET timer needs ACPI support to work (also HPET is not present on 
many machines). You can probably find 'Warning: clock= override failed' in 
your dmesg. The default timer is then set to PIT. Determination of CPU clock 
when using PIT is not implemented in the kernel, so it's reported as zero in 
/proc/cpufreq. You may also find some patches around the LKML adding support 
for ACPI timer, but it needs ACPI itself. I didn't try it.

	Szymon