Bug 164093

Does adding i8042.nomux=1 on the kernel command line help? If yes, please attach
the output of 'dmidecode' to this bug.

no, not really.
interesting thing: it seems to coincide with ACPI stuff:
Apr  6 20:15:45 linux-4t71 kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
Apr  6 20:15:45 linux-4t71 kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
Apr  6 20:15:45 linux-4t71 kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
Apr  6 20:15:45 linux-4t71 kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
Apr  6 20:15:45 linux-4t71 kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
Apr  6 20:15:45 linux-4t71 kernel: psmouse.c: issuing reconnect request
Apr  6 20:15:45 linux-4t71 kernel: ACPI: read EC, IB not empty
Apr  6 20:15:45 linux-4t71 kernel: ACPI: read EC, OB not full
Apr  6 20:15:45 linux-4t71 kernel: ACPI Exception (evregion-0409): AE_TIME, Returned by Handler for [EmbeddedControl] [20060127]
Apr  6 20:15:45 linux-4t71 kernel: ACPI Exception (dswexec-0458): AE_TIME, While resolving operands for [AE_NOT_CONFIGURED] [20060127]
Apr  6 20:15:45 linux-4t71 kernel: ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.PCI0.BAT0._BST] (Node ffff81001dfb7280), AE_TIME
Apr  6 20:15:45 linux-4t71 kernel: ACPI Exception (acpi_battery-0205): AE_TIME, Evaluating _BST [20060127]
Apr  6 20:15:45 linux-4t71 kernel: ACPI: read EC, IB not empty
Apr  6 20:15:45 linux-4t71 kernel: ACPI Exception (evregion-0409): AE_TIME, Returned by Handler for [EmbeddedControl] [20060127]
Apr  6 20:15:45 linux-4t71 kernel: ACPI Error (psparse-0517): Method parse/execution failed [\_TZ_.THRM._TMP] (Node ffff81001dfb5f40), AE_TIME
Apr  6 20:16:01 linux-4t71 dhclient: DHCPREQUEST on eth1 to 149.44.160.50 port 67
Apr  6 20:16:01 linux-4t71 dhclient: DHCPACK from 149.44.160.50
Apr  6 20:16:01 linux-4t71 dhclient: bound to 10.10.101.18 -- renewal in 1446 seconds.
Apr  6 20:18:09 linux-4t71 kernel: kfontinst[4339] general protection rip:2ac092ffdd70 rsp:7fff18c20130 error:0
Apr  6 20:22:45 linux-4t71 kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 4
Apr  6 20:22:45 linux-4t71 kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
Apr  6 20:22:45 linux-4t71 kernel: psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
Apr  6 20:22:45 linux-4t71 kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 4
Apr  6 20:22:45 linux-4t71 kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
Apr  6 20:22:45 linux-4t71 kernel: psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
Apr  6 20:24:45 linux-4t71 kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
Apr  6 20:24:45 linux-4t71 kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
Apr  6 20:24:45 linux-4t71 kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
Apr  6 20:24:45 linux-4t71 kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
Apr  6 20:24:45 linux-4t71 kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
Apr  6 20:24:45 linux-4t71 kernel: psmouse.c: issuing reconnect request
Apr  6 20:24:45 linux-4t71 kernel: ACPI: read EC, OB not full
Apr  6 20:24:45 linux-4t71 kernel: ACPI Exception (evregion-0409): AE_TIME, Returned by Handler for [EmbeddedControl] [20060127]
Apr  6 20:24:45 linux-4t71 kernel: ACPI Exception (dswexec-0458): AE_TIME, While resolving operands for [AE_NOT_CONFIGURED] [20060127]
Apr  6 20:24:45 linux-4t71 kernel: ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.PCI0.BAT0._BST] (Node ffff81001dfb7280), AE_TIME
Apr  6 20:24:45 linux-4t71 kernel: ACPI Exception (acpi_battery-0205): AE_TIME, Evaluating _BST [20060127]

Thomas, do the acpi errors trigger anything? Sometimes i also get "hanging" keys if this resync happens.

In fact, it seems easy to trigger with "watch cat /proc/acpi/battery/*", then if the touchpad hangs, i get 

present:                 yes
ERROR: Unable to read battery information
present:                 yes
ERROR: Unable to read battery status

from /proc/acpi/battery/*

ec_intr=0 seems to improve things => ACPI related?.
This is an AMD64 machine if that makes a difference. I'll open the bug to the public, maybe we'll get some more feedback.

Sadly, the ACPI EC and the i8042 are the same chip within the machine, with
two unrelated (but similar) interfaces. This way, if ACPI stalls the chip
somehow, it'll discard keyboard/mouse data, causing sync loss for the touchpad.

How much does ec_intr=0 improve things? How much does removing the EC support
completely improve things?

i did not see any resyncs with ec_intr=0, so it seems to fix it. Fortunately this is only a testmachine, so i have no definitive answer, but it surely makes it much better.
The touchpad is still too sensitive and has bad characteristics, but i don't think the kernel is to blame for that, the machine is just a hunk of crap ;-)

How do i disable EC support completely? Do i have to recompile the kernel for that?

There is no other way - you have to recompile the kernel with CONFIG_ACPI_EC set to off.

I doubt that this helps much, a kernel with EC off is no option and if ec_intr=0 helps a bit it should already be proved to be EC related.
Probably not loading ACPI modules or increasing thermal polling timeout also helps a bit.
I wonder whether these AE_TIME and wrong EC reads/writes could be related to this bug:
http://bugzilla.kernel.org/show_bug.cgi?id=5534
I currently compile a SUSE kernel with the attached patch from there (enable threaded ACPI controller method execution) it should be worth a try:
 - queued kernel-default for dist i386
 - queued kernel-default for dist x86_64
Your jobid is 'stravinsky-trenn-1'.

I assume this something to try past-code10 since i need to do update tests on this machine once i am back from vacation next week and this patch is probably not going into code10, isn't it? So i will test this after code10 is out and provide feedback upstream.

this is a SIS chipset, so no i2c_i801, but i2c_sis96x is loaded.
Removing i2c_sis96x.ko from the system did not help at all.

I think the machine is just simply crap. This is one of the entries in the latest BIOS changelog (the latest BIOS also did not help, of course):
--------------------------------------------------------------------------
current BIOS V1.04c
Known errors, problems and restrictions:
- The MS event viewer sporadically reports an ACPIEC error at system error
  records. This occurs when system is under heavy load (e.g. stresstest).
  But it does not influence the systems reliablility or performance. 
--------------------------------------------------------------------------

So the hardware is probably just plain broken by design(er).

I'm having the same problem, but it doesn't seem to be ACPI related, because I have no ACPI errors in system log.

I run SUSE v10.1 with kernel 2.6.16.13-4-default (i686 32bit) on an ACER TravelMate 382TMi. From my syslog:

06/02/2006 05:35:46 PM	vasily-zaitsev	kernel	psmouse.c: TouchPad at isa0060/serio4/input0 - driver resynched.
06/02/2006 05:35:46 PM	vasily-zaitsev	kernel	psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
06/02/2006 05:35:46 PM	vasily-zaitsev	kernel	psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4
06/02/2006 05:37:29 PM	vasily-zaitsev	kernel	psmouse.c: TouchPad at isa0060/serio4/input0 - driver resynched.
06/02/2006 05:37:29 PM	vasily-zaitsev	kernel	psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
06/02/2006 05:37:29 PM	vasily-zaitsev	kernel	psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4
06/02/2006 05:38:32 PM	vasily-zaitsev	kernel	psmouse.c: issuing reconnect request
06/02/2006 05:38:32 PM	vasily-zaitsev	kernel	psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
06/02/2006 05:38:32 PM	vasily-zaitsev	kernel	psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
06/02/2006 05:38:32 PM	vasily-zaitsev	kernel	psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
06/02/2006 05:38:32 PM	vasily-zaitsev	kernel	psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
06/02/2006 05:38:32 PM	vasily-zaitsev	kernel	psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
06/02/2006 05:40:15 PM	vasily-zaitsev	kernel	psmouse.c: TouchPad at isa0060/serio4/input0 - driver resynched.
06/02/2006 05:40:15 PM	vasily-zaitsev	kernel	psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 1
06/02/2006 05:40:15 PM	vasily-zaitsev	kernel	psmouse.c: TouchPad at isa0060/serio4/input0 lost sync at byte 4

John, have you checked that you run the latest available BIOS? If not better upgrade.
You may want to try: ec_intr=0 boot param.

You can also try to set:
THERMAL_POLLING_FREQUENCY="0" in /etc/sysconfig/powersave/thermal (reboot needed)

Latter could workaround your problem if it is related to thermal ec reads.

Thomas you have solved my problem, thanks !

I've tried to set THERMAL_POLLING_FREQUENCY="0" like you said and the problem is now gone.

Can you tell me something more about this "thermal ec reads" issue ?

Thank you again.

hi,


I also have a laptop here with exactly the same problems as mentioned in
the original bug. Note that when acpi=off is selected, the bug doesn't
roar it's ugly head. However, that work-around also causes the lsusb to
report 3 devices instead of 4 devices; also, when you use USB, the
device is not being recognized.

The laptop is an acer 1360wlmi.

The laptop is completely useless at this point. The kernel in use is
2.6.16.21-0.25-default

In the mean time, I will follow the suggestions and recompile the kernel
etc in order to see if that makes any differences.

I have added myself to the cc list for this bug.

ps, I didn't see ACPI related errors myself, only the well known psmouse.c touchpad at isa0060/serio/input0 lost sync at byte 1 (or 4) followed sometimes by unable to query synaptics hardware.

it can be directly seen when looking at vc10's messages and use the touchpad.

I'll report if a fix works.

Roeland: Does (one or both of) the workarounds from comment #13 also solve the problem for you?

it took some time to have all options to be done so far:

status:

ec_intr=0 boot param -- no help

THERMAL_POLLING_FREQUENCY="0" in /etc/sysconfig/powersave/thermal -- no help

combination of the two: -- no help. 

I took out the CONFIG_ACPI_EC out of .config, recompiled (that's why it took so long), (setting it to # CONFIG_ACPI_EC is not set), no help.

There is one option left and that's updating the BIOS but that may take some time due to the problem that I don't have windows not DOS at hand.

I can have it working OK, if acpi=off bootparam is issued but that directly takes out the USB stack for no apparent reason.

normally you see

Bus 004 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000

and an USB stick inserted works.

but when the acpi=off param is issued it changed to:

Bus 002 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000

"Bus 004" is gone and the USB stack is defunct.

Updating BIOS is a good idea :)
If you still have problems can you attach acpidump and complete dmesg output, pls.

there is a reference to EC in the bios update but it's for a different video combination. I'll let you know how it went.

ps it's a customers laptop, not mine.

Created attachment 101517 [details]
dmesg output just after boot

Created attachment 101518 [details]
acpidump output

ok I've updated the BIOS. The acer 1360 went from 1.06 to 1.11.
The above mentioned suggestions are still in effect; ec_intr=0 still set during boot, THERMAL_POLLING_FREQUENCY set to '0' and the kernel was custom rebuilt to have the CONFIG_ACPI_EC not set. 

Still the touchpad looses sync and the mouse stops.

find attached the dmesg out and the acpidump as requested.

as another sidenote, I have found the following laptop also to produce the stuttering. less noticeable but still does. This one has ec_intr set to 0 but no thhermal throttling option set nor changed kernel.

the model is an amilo d1840w also known as an uniwill 258SA0. Latest available BIOS. attached after this message are the dmesg and acpidump. Mybe it's of any use.

Created attachment 101519 [details]
dmesg just after boot amilo

Created attachment 101520 [details]
acpi output amilo

Comment #20 and #21 is about the Acer 1360 wmli and comment #24 and #25 is about the fsc amilo d1840 (unwill 258SA0), right?

About the Acer, this looks bad and needs to be fixed:
----------------------------------
setup_irq: irq handler mismatch
 [<c0131bb7>] setup_irq+0xd6/0xe9
 [<c01fe4aa>] serial8250_interrupt+0x0/0xca
 [<c0131c39>] request_irq+0x6f/0x8b
 [<c01fe2be>] serial8250_startup+0x289/0x475
 [<c01fac0e>] uart_startup+0x66/0xed
 [<c01fb7ee>] uart_open+0x187/0x38d
 [<c01e6c5a>] tty_ldisc_enable+0x1e/0x20
 [<c01e75b8>] init_dev+0x34c/0x45a
 [<c01e99b9>] tty_open+0x185/0x2dd
 [<c0151852>] chrdev_open+0xc1/0xf6
 [<c0151791>] chrdev_open+0x0/0xf6
 [<c0149773>] __dentry_open+0xb7/0x186
 [<c01498a6>] nameidata_to_filp+0x19/0x28
 [<c01498e1>] do_filp_open+0x2c/0x32
 [<c0149925>] do_sys_open+0x3e/0xb0
 [<c01499c4>] sys_open+0x16/0x18
 [<c010299b>] sysenter_past_esp+0x54/0x79
----------------------------------
Just an assumption, but can you try to not use wlan and avoid loading of any wlan modules and try whether the irq error goes away, pls. Hmm vojtech might have another idea, I am no expert in irq assigning...

Can you also try to not load all ACPI modules at all by:
  - removing fan, thermal and processor from INITRD_MODULES in
    /etc/sysconfig/kernel -> then invoke mkinitrd

  - set ACPI_MODULES="NONE" in /etc/sysconfig/powersave/common

Then restart and have a look with lsmod that none of these modules are loaded:
button, battery, fan, thermal, processor, ac, acpi_*
Does the mouse work ok then?

ok, here we go. I left everything as in comment 22 for the acer 1360. 

I removed fan, thermal and processor; via82cxxx jbd and ext3 stay; ran mkinird; I also set ACPI_MODULES to none and  restarted. All, except processor were gone in the list of modules. lsmod | grep processor reported powernow_k8.

So far, without wifi, it seems to work like it should.

comment 24/25 are for the amilo. I'll leave that alone for a while and/or experiment with the above settings.

I now assume that we gradually have to re-enable modules to see which particular module causes the mouse loosing sync behaviour ?

Can you check whether the wifi stuff produces the irq mess stated in #26, pls and whether the mouse is working with ACPI modules but wifi disabled (or do it the other way around if that's easier, remove the ACPI_MODULES="NONE", restart acpid,hal and powersaved (evtl. you also have to restart dbus if it gets messed up). Then check whether ACPI modules ac,button,thermal,fan,battery got loaded and whether the mouse problem appears even without wifi).

I wonder whether this has something to do with your mouse issue or whether we have two separated issues (one messing up serial driver (wifi) and one related to ACPI EC reads/writes that break mouse (one of the ACPI modules, most likely battery or thermal, possibly ac)).

1) The IRQ mess doesn't seem to happen when comment #27 is in effect.

2) if ACPI_MODULES="" is reinstated instead of NONE _and_ the wifi card is inserted, the IRQ mess appears when booting.

3) if ACPI_MODULES="" is reinstated instead of NONE and the wifi card is inserted 
after booting, the IRQ mess doesn't seem to happen

4) if ACPI_MODULES="" is reinstated wether the card is inserted before, after boot or not at all, the mouse looses sync.

if 2/3/4 is being done, ac, button, thermal, fan and battery are loaded.
e.g. changing "" to NONE will affect the mouse problem.

observatins so far: 

if I remove thermal from the list of ACPI_MODULES in /etc/sysconfig/powersave/common (or in fact, any random entry)

a) the mouse sometimes looses sync but it's workable
b) the IRQ mess only happens if the card is inserted at boottime
   e.g. if later put in, no weird mess seen.

Ok I already thought something like that, so we have two separate bugs here:

1) The wifi card messing up serial interupt when inserted at boot time (or similar), you might want to open a new bug for that if you miss some functionality, this issue won't be discussed in this bug.

2) The "known problem" that mouse/kbd and ACPI drivers don't like each other on some machines. This is what is the bug about. Often (always until now?) this is could be workarounded with kernel param ec_intr=0 (maybe this works on the amilo?). BTW: This bug is set to OpenSUSE 10.1, just want to be sure you are not working on a 10.2 AlphaX.

I don't know enough about the mouse/kbd internals, I think discussing that here does not make much sense, I will ask on mailing list and come back in some days, sry.

It would be interessting to know whether the problem still exists on latest kernels. AFAIK there is a udev incompatibility avoiding easy installation of a new kernel rpm, also not sure whether upgrading kernel.rpm and udev.rpm is enough to get it working.

Whoever has a free partition and is willing to install a 10.2 Alpha4/5 and report back whether the symptoms are still the same with the latest kernels (pls also test whether ec_intr=0 boot param and rmmod thermal workarounds still work the same there) that would help.

Ok wait a sec. I found two things in Acer DSDT that could be related:

1) 
   DSDT.dsl  2420:    Field (ERAM, AnyAcc, Lock, Preserve)
   Error    4074 -           ^ Host Operation Region requires ByteAcc access
This one should get workarounded by kernel, but you never know...

2) One System IO variable (BCMD, it's quite often used also to read thermal stuff) is double declared in different scopes. I like to rename this to be sure the ACPI interpreter doesn't get the scope wrong.

I will attach a modified DSDT table: DSDT.aml to test. Can you pls:
  - copy it to /etc/DSDT.aml
  - set ACPI_DSDT="/etc/DSDT.aml" in /etc/sysconfig/kernel
  - invoke mkinitrd
  - reboot.

Check whether the DSDT really has been replaced by searching for DSDT (or similar) in dmesg. There must be line like: DSDT replaced by custom table (or similar...).
Is it better now?
You should revert the change after testing by removing the entry and invoke mkinitrd again after testing.

Created attachment 101671 [details]
modified and compiled DSDT to test

- fixed AnyAccess to ByteAccess in EC region/field
  declaration.

- renamed BCMD declaration in PCI0 namespace to XXXX
  to avoid possible name clash with \_SB.BCMD
  declaration.

This is only ment for roelands Acer 1360 wlmi (I took the one from comment #21, this hopefully is acpidump from new BIOS?), the DSDT must match the BIOS, pls don't test on the other ACER.

on comment #31: yes this is suse 10.1, original master and updated to the latest code. I'll raise another bug for the IRQ mess.

I first will have to revert all changes back so to test the modified DSDT. Takes some time. ok here it is. I reverted everything. the DSDT is being replaced as dmesg reported Table [DSDT] replaced by host OS.

comment #35: yes this is the dump of the laptop with the right BIOS.

so far it looses sync once in a while. It's compareable with comment #30

ok, sorry, I'll have to refine it. It works better but still too much lost syncs. I"ll check if all stuff is really reverted and report tomorrow morning.

sorry for the long delay, being ill doesn't help me a lot here.

In the mean time the laptop has been picked up by the customer. I still had to f I remove thermal from the list of ACPI_MODULES in /etc/sysconfig/powersave/common (or in fact, any random entry) to have the laptop to work "normal".

Can you try this kernel:
ftp.suse.com/pub/projects/kernel/kotd/sles10-i386/SLES10_SP1_BRANCH/kernel-default.i586.rpm
(or the right flavored kernel for the machine smp/x86_64).

This change (rpm -qp --changlog kernel-xy.rpm |less) could potentially fix it:

* Thu Nov 02 2006 - trenn@suse.de

- patches.fixes/acpi_fix_ec_issue.patch: Fix battery/AC status
  update (#6455 (kernel.org)).

Helmut has the machine right now. Helmut, please test (or give the machine to me :-)

As a sidenote, I fed my Amilo D1840W with OpenSUE 10.2 DVD download and will report if that stuttering still happens.

Is this is still a problem with 10.2?

Yes it does. It doesn't happen often but it does fail at times. I didn't look at the logs to support it but it definitely has the same problems. 

We've made further changes to prevent this in 10.3 and 11.0. Please check with the new distribution(s).

Any update here please?

Closing as NORESPONSE.

I got the laptop back here and spooled 11.0 on it. I'll report if it's still there.