2.6.11 acpi battery state readout as source of keyboard/touchpad troubles
In traceing the source of my sporadic synaptics touchpad troubles
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1 psmouse.c: TouchPad at isa0060/serio4/input0 - driver resynched.
and keyboard troubles (sporadically lost key up/down events) on an Acer Aspire 1520 (x86_64, latest bios v1.09) I did enable the report_lost_ticks option which did spit out stuff like the following at regular intervals:
time.c: Lost 17 timer tick(s)! rip handle_IRQ_event+0x20/0x60) time.c: Lost 8 timer tick(s)! rip handle_IRQ_event+0x20/0x60) time.c: Lost 19 timer tick(s)! rip handle_IRQ_event+0x20/0x60) time.c: Lost 8 timer tick(s)! rip handle_IRQ_event+0x20/0x60) time.c: Lost 18 timer tick(s)! rip handle_IRQ_event+0x20/0x60) time.c: Lost 8 timer tick(s)! rip handle_IRQ_event+0x20/0x60)
This looked suspiciously like it happended when the the kde laptop applet polled the battery status. So I did terminate the applet.
The result was no more lost ticks, no lost keyboard events and no more lost touchpad sync.
To verify ACPI battery data as the source of trouble i did a simple
cat /proc/acpi/battery/BAT0/state
which instantly resulted in:
time.c: Lost 19 timer tick(s)! rip handle_IRQ_event+0x20/0x60)
So it seems ACPI battery readout does cause some long running interrupt disable and that it causes nasty side effects for the 8042 input.
Note that doing
cat /proc/acpi/battery/BAT0/info
doesn't cause any trouble (battery alarm is unsupported).
I can ignore the lost ticks but the keyboard/touchpad problems caused by the state readout are definitely nasty.
Any ideas?
Signature · 8 lines
Andreas Steinmetz SPAMmers use robotrap-sy9/ueDX/[email protected] ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/Info/Sentarus/hamr30
Quoted 40 lines · Andreas Steinmetz
In traceing the source of my sporadic synaptics touchpad troubles
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1psmouse.c: TouchPad at isa0060/serio4/input0 - driver resynched.and keyboard troubles (sporadically lost key up/down events) on an Acer Aspire 1520 (
x86_64, latest bios v1.09) I did enable thereport_lost_ticksoption which did spit out stuff like the following at regular intervals:
time.c: Lost 17 timer tick(s)! riphandle_IRQ_event+0x20/0x60)time.c: Lost 8 timer tick(s)! riphandle_IRQ_event+0x20/0x60)time.c: Lost 19 timer tick(s)! riphandle_IRQ_event+0x20/0x60)time.c: Lost 8 timer tick(s)! riphandle_IRQ_event+0x20/0x60)time.c: Lost 18 timer tick(s)! riphandle_IRQ_event+0x20/0x60)time.c: Lost 8 timer tick(s)! riphandle_IRQ_event+0x20/0x60)This looked suspiciously like it happended when the the kde laptop applet polled the battery status. So I did terminate the applet.
The result was no more lost ticks, no lost keyboard events and no more lost touchpad sync.
To verify ACPI battery data as the source of trouble i did a simple
cat
/proc/acpi/battery/BAT0/statewhich instantly resulted in:
time.c: Lost 19 timer tick(s)! riphandle_IRQ_event+0x20/0x60)So it seems ACPI battery readout does cause some long running interrupt disable and that it causes nasty side effects for the 8042 input.
Note that doing
Quoted 8 lines
cat
/proc/acpi/battery/BAT0/infodoesn't cause any trouble (battery alarm is unsupported).
I can ignore the lost ticks but the keyboard/touchpad problems caused by the state readout are definitely nasty.
Any ideas?
Yes. I strongly suspect that your problems are caused by the embedded controller driver. On many laptop systems, the embedded controller is used to access and query the batter subsystem. Unfortunately, the driver code that performs embedded controller reads and writes currently uses a spinlock to prevent multiple accesses. A typical read/write operation can take around 2.5 ms, during which no interrupts can be serviced.
I've been trying to make noise about this problem on the ACPI mailing list, but progress on this issue is still glacial. Luming Yu has posted a patch to 2.6.11 that appears to resolve the interrupt blocking, but it has the side effect that embedded controller access becomes unacceptably slow.
cheers,
Rich
A message that is not in the archive (sent off-list or not yet received): 424AF9C3.4000905-sy9/ueDX/[email protected]
Quoted 2 lines · Andreas Steinmetz
So it seems ACPI battery readout does cause some long running interrupt disable and that it causes nasty side effects for the 8042 input.
This sounds like the smart battery EC spinlock woes. Someone released a patch to make it use semaphores instead, but it apparently slows access right down (although it won't freeze your machine in the meantime).
Oisín
-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today!
http://www.demarc.com/Info/Sentarus/hamr30
Hi!
Quoted 24 lines
In traceing the source of my sporadic synaptics touchpad troubles
psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1psmouse.c: TouchPad at isa0060/serio4/input0 - driver resynched.and keyboard troubles (sporadically lost key up/down events) on an Acer Aspire 1520 (
x86_64, latest bios v1.09) I did enable thereport_lost_ticksoption which did spit out stuff like the following at regular intervals:
time.c: Lost 17 timer tick(s)! riphandle_IRQ_event+0x20/0x60)time.c: Lost 8 timer tick(s)! riphandle_IRQ_event+0x20/0x60)time.c: Lost 19 timer tick(s)! riphandle_IRQ_event+0x20/0x60)time.c: Lost 8 timer tick(s)! riphandle_IRQ_event+0x20/0x60)time.c: Lost 18 timer tick(s)! riphandle_IRQ_event+0x20/0x60)time.c: Lost 8 timer tick(s)! riphandle_IRQ_event+0x20/0x60)This looked suspiciously like it happended when the the kde laptop applet polled the battery status. So I did terminate the applet.
Quoted 6 lines
The result was no more lost ticks, no lost keyboard events and no more lost touchpad sync.
To verify ACPI battery data as the source of trouble i did a simple
cat
/proc/acpi/battery/BAT0/state
...
CONFIG_ACPI_DEBUG enabled by chance?
Pavel
Signature · 1 line
Boycott Kodak -- for their patent abuse against Java.
Quoted 2 lines · Pavel Machek
CONFIG_ACPI_DEBUGenabled by chance?
Pavel
# CONFIG_ACPI_DEBUG is not set
Signature · 1 line
Andreas Steinmetz SPAMmers use [email protected]