Synaptics and keyboard losing interrupts w/ACPI ?

Synaptics and keyboard losing interrupts w/ACPI ?

[Karl Hegbloom]

I apologize if this this is an FAQ or has already been answered; the
sf.net list archive interface is... too feeble to suck.  I wish they
would switch to "lurker" (http://lurker.sourceforge.net/).

I've got a laptop that has a synaptics touchpad.  Every so often, with
every kernel I've tried up through 2.6.4, the pointer will suddenly leap
across the screen, and sometimes it will even push a GUI button there. 
Also, on occasion, a key will "stick down",,,,,,,,,,,, like that, until
I push another key.  Every now and then the keyboard quits working
entirely, and I must reboot to regain control.  When these things
happen, I see, in the logs:

Mar 29 08:04:37 localhost kernel: atkbd.c: Unknown key pressed (translated set 2, code 0x0 on isa0060/serio0).
Mar 29 08:04:37 localhost kernel: atkbd.c: Use 'setkeycodes 00 <keycode>' to make it known.
Mar 29 08:04:37 localhost kernel: atkbd.c: Unknown key pressed (translated set 2, code 0x0 on isa0060/serio0).
Mar 29 08:04:37 localhost kernel: atkbd.c: Use 'setkeycodes 00 <keycode>' to make it known.
Mar 29 08:04:37 localhost kernel: psmouse.c: TouchPad at isa0060/serio2/input0 lost synchronization, throwing 5 bytes away.
Mar 29 08:05:16 localhost kernel: Synaptics driver lost sync at byte 4
Mar 29 08:05:16 localhost kernel: Synaptics driver lost sync at byte 1
Mar 29 08:05:16 localhost last message repeated 3 times
Mar 29 08:05:16 localhost kernel: Synaptics driver resynced.

There is also a message about an unknown scancode that also mentions
that it's an XFree86 bug... that it should not access hardware
directly.  I also see that when I run the "console-tools" 'setkbdrate'
command, which uses /dev/port to set the key repeat rate.  The source
mentions that on some architectures there's an ioctl for doing that.  I
am fairly certain that this "XFree86 bug" is probably not related to the
other one or to ACPI.

I am not the only one who experiences this problem, and this model of
laptop is not the only one that supports this feature...  After
searching for those log messages at Google, I located several email
messages saying things like that APM introduces latency to turn it off,
and to try booting with "acpi=off" for similar reasons.

Sure enough, when I boot with "acpi=off", the problem disappears
entirely.  The touchpad works perfectly, and the keyboard is fine.

What I've decided is probably happening is that somewhere in the ACPI
system, code is running for too long with interrupts disabled, so
keyboard and touch-pad interrupts are being missed.  What I want to know
is, has this been reported before, and if so, has it been fixed since
stock 2.6.4 was released?  Will a patch from your sf site fix the
problem?

I sure wish I knew how to actually debug this kind of problem so that I
could provide more specific information or a patch.

-- 
If you feel like the machines are conspiring against you,
then it's time to perspire against the machines.




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: Synaptics and keyboard losing interrupts w/ACPI ?

[Randy.Dunlap]

On Sat, 03 Apr 2004 18:09:09 -0800 Karl Hegbloom <hegbloom-tbDHPZwbsQQ@public.gmane.org> wrote:

| I apologize if this this is an FAQ or has already been answered; the
| sf.net list archive interface is... too feeble to suck.  I wish they
| would switch to "lurker" (http://lurker.sourceforge.net/).

Yes, it needs help.  :(

| I've got a laptop that has a synaptics touchpad.  Every so often, with
| every kernel I've tried up through 2.6.4, the pointer will suddenly leap
| across the screen, and sometimes it will even push a GUI button there. 
| Also, on occasion, a key will "stick down",,,,,,,,,,,, like that, until
| I push another key.  Every now and then the keyboard quits working
| entirely, and I must reboot to regain control.  When these things
| happen, I see, in the logs:
| 
| Mar 29 08:04:37 localhost kernel: atkbd.c: Unknown key pressed (translated set 2, code 0x0 on isa0060/serio0).
| Mar 29 08:04:37 localhost kernel: atkbd.c: Use 'setkeycodes 00 <keycode>' to make it known.
| Mar 29 08:04:37 localhost kernel: atkbd.c: Unknown key pressed (translated set 2, code 0x0 on isa0060/serio0).
| Mar 29 08:04:37 localhost kernel: atkbd.c: Use 'setkeycodes 00 <keycode>' to make it known.
| Mar 29 08:04:37 localhost kernel: psmouse.c: TouchPad at isa0060/serio2/input0 lost synchronization, throwing 5 bytes away.
| Mar 29 08:05:16 localhost kernel: Synaptics driver lost sync at byte 4
| Mar 29 08:05:16 localhost kernel: Synaptics driver lost sync at byte 1
| Mar 29 08:05:16 localhost last message repeated 3 times
| Mar 29 08:05:16 localhost kernel: Synaptics driver resynced.
| 
| There is also a message about an unknown scancode that also mentions
| that it's an XFree86 bug... that it should not access hardware
| directly.  I also see that when I run the "console-tools" 'setkbdrate'
| command, which uses /dev/port to set the key repeat rate.  The source
| mentions that on some architectures there's an ioctl for doing that.  I
| am fairly certain that this "XFree86 bug" is probably not related to the
| other one or to ACPI.
| 
| I am not the only one who experiences this problem, and this model of
| laptop is not the only one that supports this feature...  After
| searching for those log messages at Google, I located several email
| messages saying things like that APM introduces latency to turn it off,
| and to try booting with "acpi=off" for similar reasons.
| 
| Sure enough, when I boot with "acpi=off", the problem disappears
| entirely.  The touchpad works perfectly, and the keyboard is fine.
| 
| What I've decided is probably happening is that somewhere in the ACPI
| system, code is running for too long with interrupts disabled, so
| keyboard and touch-pad interrupts are being missed.  What I want to know
| is, has this been reported before, and if so, has it been fixed since
| stock 2.6.4 was released?  Will a patch from your sf site fix the
| problem?
| 
| I sure wish I knew how to actually debug this kind of problem so that I
| could provide more specific information or a patch.

Have you tried any hints from the "2.6 input drivers FAQ"?
See http://lwn.net/Articles/69107/ or google for the string above.

--
~Randy


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: Synaptics and keyboard losing interrupts w/ACPI ?

[Karl Hegbloom]

On Sat, 2004-04-03 at 18:45, Randy.Dunlap wrote:
> On Sat, 03 Apr 2004 18:09:09 -0800 Karl Hegbloom <hegbloom-tbDHPZwbsQQ@public.gmane.org> wrote:
> | I've got a laptop that has a synaptics touchpad.  Every so often, with
> | every kernel I've tried up through 2.6.4, the pointer will suddenly leap
> | across the screen, and sometimes it will even push a GUI button there. 
> | Also, on occasion, a key will "stick down",,,,,,,,,,,, like that, until
> | I push another key.  Every now and then the keyboard quits working
> | entirely, and I must reboot to regain control.
>
> Have you tried any hints from the "2.6 input drivers FAQ"?
> See http://lwn.net/Articles/69107/ or google for the string above.

I've been booting with "acpi=off", but I'd rather have it enabled and
not causing this problem.  The kernel is compiled WITH the ACPI-PM timer
support.  Perhaps I should try building one without that?  HPET is very
new, am I correct?  This laptop does not seem to have one.  Would the
"unsynced tsc support" option (2.4) affect this?  IO-APIC?  I really
need to find out what class I need to take where they'll teach me what
all that stuff means!  It's embarrassing to have been around Linux this
long and not know what that stuff is.  Anyone know a good book where I
can read about it?  {Please.}

First I will try to turn off the battery monitor in the gkrellm that I
always have running.

cpufreq is enabled even without ACPI, and it's working fine; Centrino
enhanced.  That does not seem to be the cause of the problem.

-- 
If you feel like the machines are conspiring against you,
then it's time to perspire against the machines.




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: Synaptics and keyboard losing interrupts w/ACPI ?

[Karl Hegbloom]

On Sat, 2004-04-03 at 19:19, Karl Hegbloom wrote:
> On Sat, 2004-04-03 at 18:45, Randy.Dunlap wrote:
> > Have you tried any hints from the "2.6 input drivers FAQ"?
> > See http://lwn.net/Articles/69107/ or google for the string above.
>
> First I will try to turn off the battery monitor in the gkrellm that I
> always have running.

That cures it!  I can run with ACPI enabled as long as the gkrellm
battery monitor is not on.  The keyboard and synaptics losing sync thing
occurs only when I turn on the battery monitor.

So, something is the matter with the ACPI battery code!  I doubt I can
find it... but I'll look in there anyway just for some exposure. :-)

-- 
If you feel like the machines are conspiring against you,
then it's time to perspire against the machines.




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: Synaptics and keyboard losing interrupts w/ACPI ?

[Dmitry Torokhov]

On Saturday 03 April 2004 10:49 pm, Karl Hegbloom wrote:
> On Sat, 2004-04-03 at 19:19, Karl Hegbloom wrote:
> > On Sat, 2004-04-03 at 18:45, Randy.Dunlap wrote:
> > > Have you tried any hints from the "2.6 input drivers FAQ"?
> > > See http://lwn.net/Articles/69107/ or google for the string above.
> >
> > First I will try to turn off the battery monitor in the gkrellm that I
> > always have running.
> 
> That cures it!  I can run with ACPI enabled as long as the gkrellm
> battery monitor is not on.  The keyboard and synaptics losing sync thing
> occurs only when I turn on the battery monitor.

I think you can leave it on but you will have to increase the poll interval.
Setting it to 30 sec or even 1 min will probably let you have your Synaptics
working and still have an idea on battery level.
 
> So, something is the matter with the ACPI battery code!  I doubt I can
> find it... but I'll look in there anyway just for some exposure. :-)
> 

It is usually deep in the BIOS code, not something exposed in AML as far as
I can understand. Polling battery often takes long time, especially polling
full info as opposed to just state. :(

-- 
Dmitry


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: Synaptics and keyboard losing interrupts w/ACPI ?

[Karl Hegbloom]

On Sat, 2004-04-03 at 20:36, Dmitry Torokhov wrote:
> I think you can leave it on but you will have to increase the poll interval.
> Setting it to 30 sec or even 1 min will probably let you have your Synaptics
> working and still have an idea on battery level.

I will try this and see if it works, thank you.
 
> > So, something is the matter with the ACPI battery code!  I doubt I can
> > find it... but I'll look in there anyway just for some exposure. :-)
> 
> It is usually deep in the BIOS code, not something exposed in AML as far as
> I can understand. Polling battery often takes long time, especially polling
> full info as opposed to just state. :(

Is there any reason why the ACPI code cannot cache that info, rather
than looking it up each time the /proc file is accessed?  (which is what
I think it does now... am I right?)

-- 
If you feel like the machines are conspiring against you,
then it's time to perspire against the machines.




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: Synaptics and keyboard losing interrupts w/ACPI ?

[Dmitry Torokhov]

On Sunday 04 April 2004 12:16 am, Karl Hegbloom wrote:
> On Sat, 2004-04-03 at 20:36, Dmitry Torokhov wrote:
> > I think you can leave it on but you will have to increase the poll interval.
> > Setting it to 30 sec or even 1 min will probably let you have your Synaptics
> > working and still have an idea on battery level.
> 
> I will try this and see if it works, thank you.
>  
> > > So, something is the matter with the ACPI battery code!  I doubt I can
> > > find it... but I'll look in there anyway just for some exposure. :-)
> > 
> > It is usually deep in the BIOS code, not something exposed in AML as far as
> > I can understand. Polling battery often takes long time, especially polling
> > full info as opposed to just state. :(
> 
> Is there any reason why the ACPI code cannot cache that info, rather
> than looking it up each time the /proc file is accessed?  (which is what
> I think it does now... am I right?)
>
 
It sort of does.. that's why there /proc/acpi/battery/BATX/info (slow access,
mostly static data) and /proc/acpi/battery/BATX/state. Now if only
applications weren't reading both of them all the time...

-- 
Dmitry


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: Synaptics and keyboard losing interrupts w/ACPI ?

[Karl Hegbloom]

On Sat, 2004-04-03 at 21:29, Dmitry Torokhov wrote:
> On Sunday 04 April 2004 12:16 am, Karl Hegbloom wrote: 
> > Is there any reason why the ACPI code cannot cache that info, rather
> > than looking it up each time the /proc file is accessed?  (which is what
> > I think it does now... am I right?)
>
> It sort of does.. that's why there /proc/acpi/battery/BATX/info (slow access,
> mostly static data) and /proc/acpi/battery/BATX/state. Now if only
> applications weren't reading both of them all the time...

But the thing is that the kernel can know when a battery gets jacked in,
removed, or swapped for a fresh one, but a user space application
cannot.  If the application caches that information, there needs to be a
way for the kernel to notify it of a battery change.  But if the kernel
caches it, reading the battery information only when a new battery is
inserted, then returning that cached information on read of the "info"
file, the application need not concern itself with such things, and the
read can happen quickly.  Obviously the state information must be
updated each time it is requested.

-- 
If you feel like the machines are conspiring against you,
then it's time to perspire against the machines.




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: Synaptics and keyboard losing interrupts w/ACPI ?

[Dmitry Torokhov]

On Sunday 04 April 2004 12:54 am, Karl Hegbloom wrote:
> On Sat, 2004-04-03 at 21:29, Dmitry Torokhov wrote:
> > On Sunday 04 April 2004 12:16 am, Karl Hegbloom wrote: 
> > > Is there any reason why the ACPI code cannot cache that info, rather
> > > than looking it up each time the /proc file is accessed?  (which is what
> > > I think it does now... am I right?)
> >
> > It sort of does.. that's why there /proc/acpi/battery/BATX/info (slow access,
> > mostly static data) and /proc/acpi/battery/BATX/state. Now if only
> > applications weren't reading both of them all the time...
> 
> But the thing is that the kernel can know when a battery gets jacked in,
> removed, or swapped for a fresh one, but a user space application
> cannot.

It can, the kernel signals when a battery is inserted or removed through
/proc/acpi/event (normally acpid listens on it). The only change that may be
needed is to allow multiple applications read /proc/acpi/event simultaneously,
right now it only allows exclusive access.

-- 
Dmitry


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: Synaptics and keyboard losing interrupts w/ACPI ?

[Stefan Seyfried]

On Sun, Apr 04, 2004 at 01:06:15AM -0500, Dmitry Torokhov wrote:
> On Sunday 04 April 2004 12:54 am, Karl Hegbloom wrote:

> > But the thing is that the kernel can know when a battery gets jacked in,
> > removed, or swapped for a fresh one, but a user space application
> > cannot.
> 
> It can, the kernel signals when a battery is inserted or removed through
> /proc/acpi/event (normally acpid listens on it). The only change that may be

I have a machine here that throws a battery event whenever the charging state
changes (hp compaq nx5000), pretty neat.

> needed is to allow multiple applications read /proc/acpi/event simultaneously,
> right now it only allows exclusive access.

Or a more general daemon than acpid, that also cares for (and caches) battery
states, temperatures, etc....
-- 
Stefan Seyfried



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: Re: Synaptics and keyboard losing interrupts w/ACPI ?

[Karl Hegbloom]

On Sun, 2004-04-04 at 19:40, Stefan Seyfried wrote:
> > needed is to allow multiple applications read /proc/acpi/event simultaneously,
> > right now it only allows exclusive access.
> 
> Or a more general daemon than acpid, that also cares for (and caches) battery
> states, temperatures, etc....

If anyone implements this, please make it possible to disable the
battery checks as a workaround for machines where this causes the
problems I've described.

It seems that on some boards, the ACPI battery state calls (is it BIOS?
are those 32 bit, or what?) take too long and have interrupts locked out
during that time.  This is causing synaptics touch-pad pointer glitches,
keyboard bounce and lockout, and even network card lockup when under
heavy network load.

-- 
If you feel like the machines are conspiring against you,
then it's time to perspire against the machines.




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click