mouse and keyboard stop a while when some info requested to ACPI system and 'psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at' in dmesg

[Surricani]

I have ad Acer Aspire 1362LM. When the system try access the ACPI subsystem (e.g. battery status), the mouse stop working for some seconds, the keyboard too, and sometimes the sound and disk too. (just for some seconds..)

I patched the DSDT with a correct one, but nothing changed.

With dmesg I found:

[17180568.352000] psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4
[17180568.356000] psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
[17180568.364000] psmouse.c: TouchPad at isa0060/serio4/input0 - driver resynched.
[17180598.280000] rtc: lost some interrupts at 2048Hz.
[17180628.308000] rtc: lost some interrupts at 2048Hz.
[17180628.352000] psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
[17180628.356000] psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
[17180628.356000] psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
[17180628.356000] psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
[17180628.360000] psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
[17180628.368000] psmouse.c: TouchPad at isa0060/serio4/input0 - driver resynched.
[17180658.284000] rtc: lost some interrupts at 2048Hz.
[17180688.304000] rtc: lost some interrupts at 2048Hz.
[17180688.348000] psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
[17180688.352000] psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
[17180688.352000] psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
[17180688.352000] psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
[17180688.356000] psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
[17180688.364000] psmouse.c: TouchPad at isa0060/serio4/input0 - driver resynched.
[17180748.288000] rtc: lost some interrupts at 2048Hz.
[17180778.284000] rtc: lost some interrupts at 2048Hz.
[17180808.284000] rtc: lost some interrupts at 2048Hz.
[17180838.284000] rtc: lost some interrupts at 2048Hz.
[17180868.288000] rtc: lost some interrupts at 2048Hz.

I think is a Linux kernel bug...

[Surricani (surricani)]

I've find a solution.

I think is a Linux kernel problem with mouse's multiplexer.

I've added "i8042.nomux" to the booting kernel and the problem goes away.

[Emilio Pozuelo Monfort (pochu)]

Rejected, as nobody can confirm the bug and the submitter has found a workaround for his problem.

Feel free to reopen it if needed.

[mdrescher (drescher)]

I can confirm that behavior. On my acer TravelMate 370 I can see that in messages:

[...]
Jul 24 14:30:53 brain kernel: [16865.528000] psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
Jul 24 14:30:53 brain kernel: [16865.528000] psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
Jul 24 14:30:53 brain kernel: [16865.528000] psmouse.c: issuing reconnect request
Jul 24 14:35:24 brain kernel: [17136.924000] psmouse.c: TouchPad at isa0060/serio4/input0 lost synchronization, throwing 3 bytes away.
[...]

Soundsystem or disk seems not to be effected by this issue. The freeze takes some seconds up to some minutes. It can be 'unfreezed' immediatly by pushing the laptop lid button.
Sopping init's acpi services does not help, as it does removing asus_acpi.

uname -a
Linux brain 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux

[Paul Dufresne (paulduf)]

similar bugs are bug #46074, bug #12124, bug #60122.

[mdrescher (drescher)]

I'm not too sure about that relations.

And I'm sorry, I was lazy some days. But: I have new awarenesses:
- This freeze only occurs with an active pccard, option g3-card in slot 1 in my case.
- This freeze does not effect my USB mouse. Keyboard was not tested.

May be there is some trouble with Interrupts?
---
myname@mycomputer:~$ cat /proc/interrupts
           CPU0
  0: 509451 XT-PIC-XT timer
  1: 1968 XT-PIC-XT i8042
  2: 0 XT-PIC-XT cascade
  7: 1 XT-PIC-XT parport0
  8: 3 XT-PIC-XT rtc
  9: 17722 XT-PIC-XT acpi
 10: 24930 XT-PIC-XT uhci_hcd:usb3, ohci1394, yenta, yenta, eth1, Intel 82801DB-ICH4
 11: 0 XT-PIC-XT uhci_hcd:usb1, uhci_hcd:usb2, ehci_hcd:usb4, eth0
 12: 284980 XT-PIC-XT i8042
 14: 16224 XT-PIC-XT libata
 15: 0 XT-PIC-XT libata
NMI: 0
LOC: 0
ERR: 0
MIS: 0
---

Does some ACPI function some kind of 'interrupt reset', like, 'forget what you're waiting for, just go on'?

cheers!

[Paul Dufresne (paulduf)]

Marked this bug as affecting linux-source-2.6.20 package.
Assigning to me until satisfied it is complete enough (and follow kernel bug policy) to marked as Confirmed.

mdrescher, can you confirm like Surricani that booting with i8042.nomux kernel option remove the problem for you too?

You may know ACPI better than me guys, how do you make 'system try access the ACPI subsystem'?
Can the bug be initiated just be doing cat on some files in /proc?

[mdrescher (drescher)]

Paul, I can not confirm 'i8042.nomux' as a workaround.

ACPI: In my mind, all that power management stuff is driven by or through /proc/acpi.

[Paul Dufresne (paulduf)]

The fact that the workaround that was working for Original Poster does not for you suggest me you have a slightly different bug.
Please open a new bug, and then include the number of the bug here saying: 'I have open bug ####'.

To Surricani and you, please include the following information, Surricani here, mdrescher in your newly open bug,
please include the information requested at [WWW] https://wiki.ubuntu.com/DebuggingACPI as separate attachments.

[Paul Dufresne (paulduf)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!