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?
--
Andreas Steinmetz SPAMmers use [email protected]
Andreas Steinmetz wrote:
> 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?
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
Hi!
> 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
...
CONFIG_ACPI_DEBUG enabled by chance?
Pavel
--
Boycott Kodak -- for their patent abuse against Java.
Pavel Machek wrote:
> CONFIG_ACPI_DEBUG enabled by chance?
> Pavel
# CONFIG_ACPI_DEBUG is not set
--
Andreas Steinmetz SPAMmers use [email protected]