Bug 7277 - PS2 Touchpad (Synaptics) disappears after wake-up from S3 suspend
Summary: PS2 Touchpad (Synaptics) disappears after wake-up from S3 suspend
Status: REJECTED DUPLICATE of bug 7977
Alias: None
Product: Drivers
Classification: Unclassified
Component: Input Devices (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Dmitry Torokhov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-06 16:23 UTC by Daniel Wagenaar
Modified: 2007-04-28 12:49 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.18
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
test patch (445 bytes, patch)
2006-10-09 01:09 UTC, Shaohua
Details | Diff
dmesg after applying the patch (36.79 KB, text/plain)
2006-10-09 17:42 UTC, Tarmo T
Details
acpidump output (124.78 KB, text/plain)
2006-10-09 18:28 UTC, Tarmo T
Details
my small dsdt changes to silence iasl compiler warnings (641 bytes, text/plain)
2006-10-09 18:32 UTC, Tarmo T
Details
dmesg showing a session without psmouse module (36.98 KB, text/plain)
2006-10-09 20:15 UTC, Tarmo T
Details
Fiddle with reset logic (540 bytes, patch)
2006-11-16 07:53 UTC, Dmitry Torokhov
Details | Diff

Description Daniel Wagenaar 2006-10-06 16:23:47 UTC
Most recent kernel where this bug did not occur: n/a
Distribution: Ubuntu 6.06
Hardware Environment: Gateway MX6121 laptop with Intel ICH6 chipset
Software Environment: -
Problem Description: When laptop wakes up from S3 suspend (suspend to RAM),
the Synaptics touchpad does not work anymore. Other than that, system works
fine. "dmesg" reports:

  [  516.968000] pnp: Device 00:07 does not support activation.
  [  516.968000] pnp: Device 00:08 does not support activation.

Device 00:08 is the Synaptics touchpad. The file /sys/bus/pnp/devices/00:08/id
reads:

  SYN0402
  SYN0400
  SYN0002
  PNP0f13

The file /sys/bus/pnp/devices/00:08/resources reads:

  state = active
  irq 12

Neither changes as a result of the sleep/wakeup.

The clearest change that I see is in /sys/devices/platform/i8042/serio0, which
corresponds to the touchpad (its "description" file reads "i8042 Aux Port").
Before suspend, it contains the following files: 

  bind_mode
  bus -> ../../../../bus/serio
  description
  driver -> ../../../../bus/serio/drivers/psmouse
  drvctl
  id
  input:event1 -> ../../../../class/input/input1/event1
  input:input1 -> ../../../../class/input/input1
  input:mouse0 -> ../../../../class/input/input1/mouse0
  modalias
  power
  protocol
  rate
  resetafter
  resolution
  resync_time
  subsystem -> ../../../../bus/serio
  uevent                                                      

After resume, the files "input:event1", "input:input1", "input:mouse0",
"protocol", "rate", "resetafter", "resolution", and "resynctime" have disappeared.

Steps to reproduce:

(1) rmmod acpi_cpufreq, if loaded. (With acpi_cpufreq loaded, the system refuses
to sleep. This seems to be an unrelated problem.)
(2) echo -n "mem" > /sys/power/state
[The computer sleeps and its power light blinks.]
(3) Press the power button.
[The computer wakes up.]

Any advice on how to further trace this problem down would be very much
appreciated. Note that this is not the same bug as #1279, which was fixed
earlier in the 2.6.x kernel series.
Comment 1 Tarmo T 2006-10-08 12:47:52 UTC
I have the same issue, laptop is produced by some small manufacturer "Sabio
digital" model "SD-MW1 PM" but rebranded by a small local shop.
I'm currently using kernel 2.6.18 and this issue also existed on 2.6.17.

My workaround is to use USB mouse but I'd prefer not doing it while running on
battery because for some reason enabling USB increases battery usage by 300
mA/h. I also know that with suspend2 this issue does not exist but using
suspend-to-ram is quite a bit faster and likely uses a bit less battery and with
everything else working perfectly it would be a waste to not use STR.

While trying to debug the issue I tried removing the pnp_can_write check in
pnp_start_dev (drivers/pnp/manager.c) so PNP_WRITE capability would not be
checked for, but as expected, it did not help:

i8042 kbd 00:07: resuming
pnp: Res cnt 3
pnp: res cnt 3
pnp: Encode io
pnp: Encode io
pnp: Encode irq
pnp: Failed to activate device 00:07.
i8042 aux 00:08: resuming
pnp: Res cnt 1
pnp: res cnt 1
pnp: Encode irq
pnp: Failed to activate device 00:08.

So what could be the reason that PS/2 can not be activated after hibernate?,
surely it should be possible or otherwise the laptop should not advertise S3
support at all?
Comment 2 Shaohua 2006-10-09 01:09:32 UTC
Created attachment 9189 [details]
test patch

How about this patch?
If the device isn't writeable (eg, its status is always present), restartting
is meanless and wrong.
Comment 3 Tarmo T 2006-10-09 17:41:50 UTC
Thanks for the patch. It did make the "does not support activation" message go
away, but didn't actually fix the problem. What I noticed now is the following:

When booting, dmesg contains this:
pnp: the driver 'i8042 kbd' has been registered
pnp: match found with the PnP device '00:07' and the driver 'i8042 kbd'
pnp: the driver 'i8042 aux' has been registered
pnp: match found with the PnP device '00:08' and the driver 'i8042 aux'
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
PM: Adding info for platform:i8042
serio: i8042 AUX port at 0x60,0x64 irq 12
PM: Adding info for serio:serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
PM: Adding info for serio:serio1

So the keyboard is using IRQ 1 and the touchpad is using IRQ 12. I confirmed
this by looking at /proc/interrupts and indeed IRQ 12 interrupts were generated
when using the touchpad (as a sidenote, does pushing the touchpad button really
have to generate more than a few hundred interrupts? the keyboard seems to work
fine with only a few interrupts per click).

When removing psmouse module IRQ 12 was also removed from /proc/interrupts and
when adding the module back the IRQ was added back. But after hibernating if
psmouse happend to be loaded during hibernation IRQ 12 remained in
/proc/interrupts but did not increase the counter when attempting to use the
touchpad and if psmouse was rmmod'ed before hibernate and inserted after
resuming IRQ 12 was not added at all to /proc/interrupts. 

I'll attach a complete dmesg (which includes the hibernation process), please
ask if there is anything else that I could provide to help solve this issue.
Comment 4 Tarmo T 2006-10-09 17:42:56 UTC
Created attachment 9195 [details]
dmesg after applying the patch
Comment 5 Shaohua 2006-10-09 18:20:29 UTC
Can you give me the acpidump output? I'd like check it.
Comment 6 Tarmo T 2006-10-09 18:28:03 UTC
Created attachment 9196 [details]
acpidump output
Comment 7 Tarmo T 2006-10-09 18:31:51 UTC
Hopefully this is not a problem, but I have made two small changes to my dsdt so
iasl compiler would not show any warnings, I'll attach the diff and if you think
this could be a problem I'll try without loading the changed dsdt.

Also, as you can see from the dmesg, I've set acpi_os_name="Microsoft Windows
XP" this is just an attempt to fix this issue but does not appear to help, so
I'll remove this and try again if you think it could cause your patch to not
help with the issue.
Comment 8 Tarmo T 2006-10-09 18:32:36 UTC
Created attachment 9197 [details]
my small dsdt changes to silence iasl compiler warnings
Comment 9 Shaohua 2006-10-09 18:47:23 UTC
>But after hibernating if
psmouse happend to be loaded during hibernation IRQ 12 remained in
/proc/interrupts but did not increase the counter when attempting to use the
touchpad and if psmouse was rmmod'ed before hibernate and inserted after
resuming IRQ 12 was not added at all to /proc/interrupts. 

can you have more detail about this? hibernation == s3?
Comment 10 Tarmo T 2006-10-09 18:55:02 UTC
hibernation == s3 (suspend-to-ram), yes.
Comment 11 Tarmo T 2006-10-09 19:33:26 UTC
I think I was wrong about the psmouse module behaviour, I tried it again and
IRQ12 was always missing in /proc/interrupts after resuming from S3. I could be
wrong but I think hibernate-script reloads the module always because it is
blacklisted as not supporting suspend/resume well.

I also tried without modifying the dsdt_table and without acpi_os_name kernel
parameter, this did not change the behaviour.
Comment 12 Shaohua 2006-10-09 19:56:11 UTC
Does psmouse work without load/unlaod between s3?
SO you always unload psmous before suspend and reload it after resume? But 
your dmesg shows 
i8042 kbd 00:07: resuming
i8042 aux 00:08: resuming
so, this suggests you didn't unload the driver.
Comment 13 Tarmo T 2006-10-09 20:13:44 UTC
I can't be sure if the module is always unloaded because I'm not familiar with
how hibernate-script works exactly, but I did just try this:

Removed psmouse.ko completely, rebooted, the module was now not loaded
automatically on boot; suspended to S3; resumed. Now when I put the module back
and loaded it the touchpad still did not start. And those two dmesg lines were
still there so they don't seem to depend on psmouse module at all. I'll attach a
full dmesg of the session (note that there is no "Synaptics Touchpad" line
demonstrating that the psmouse module was never successfully loaded, the psmouse
module was first loaded at the end of this dmesg log and it did not add anything
to it).
Comment 14 Tarmo T 2006-10-09 20:15:02 UTC
Created attachment 9198 [details]
dmesg showing a session without psmouse module
Comment 15 Tarmo T 2006-10-09 20:16:16 UTC
I'll now try and see if I can make hibernate-script not touch psmouse module at
all and see if it works if it won't get unloaded at all.
Comment 16 Tarmo T 2006-10-09 20:29:45 UTC
Not unloading psmouse at all for before S3 did change the dmesg output a bit,
but all other symptoms remained the same. The lines the change in dmesg seems to
be this:

i8042 i8042: resuming
psmouse serio0: resuming
synaptics reset failed
synaptics reset failed
synaptics reset failed
Unable to query Synaptics hardware.
atkbd serio1: resuming

Those psmouse and synaptics lines were not there before.
Comment 17 Shaohua 2006-10-09 20:33:12 UTC
Ok, this suggests it's not an issue in pnpacpi, proberly you report this to 
input driver maintainer.
Comment 18 Tarmo T 2006-10-09 20:59:19 UTC
Couldn't you reassign this bug?
Comment 19 Rafael J. Wysocki 2006-11-15 04:44:52 UTC
On recent HP boxes (eg. HPC nx6325) the psmouse module has to be unloaded before
the suspend to avoid synaptic-related problems during/after the resume.

I think these issues may be related and I think the are related to ACPI (or at
leas to the BIOS).
Comment 20 Dmitry Torokhov 2006-11-15 06:27:37 UTC
Tarmo,

Based on the excerpt from the log you provided psmouse could not get any 
response from your touchpad. You also mentioned that all psmouse attributes 
(resetafter, rate) disappeared from sysfs. That means that AUX port on your 
laptop is not responsing at all after resume. I believe the problem lies in 
lower layers, such as ACPI and PNP.

Rafael,

What kind of problems do you see on nx6325? Do you own this box?
Comment 21 Tarmo T 2006-11-15 06:41:53 UTC
Dmitry, did you read David's last comments? he seems to think just the opposite,
that the problem is not pnpacpi.
Comment 22 Dmitry Torokhov 2006-11-15 07:08:37 UTC
Yes I did, however I am not sure how he came to this conclusion. From what I 
see after resume AUX port is dead - it is not responding to psmouse attempts to 
reinitialize hardware connected to it. Not only native Synaptics protocol is 
not working but even standard PS/2 emulation is not working either. That 
suggests that the port is disabled/not resumed properly somewhere in the lower 
layers...

I wonder if you could compile in PnPBIOS support and try booting with 
pnpacpi=off and see if it changes anything.
Comment 23 Rafael J. Wysocki 2006-11-15 15:28:31 UTC
Referring to Comment #20:

The information about the problems on HPC nx6325 is in this message:

http://marc.theaimsgroup.com/?l=linux-acpi&m=116068742123641&w=2

and the thread starts at:

http://marc.theaimsgroup.com/?l=linux-acpi&m=116060772825114&w=2
Comment 24 Dmitry Torokhov 2006-11-15 19:39:53 UTC
Rafael,

Does the nx6325 resume if you limit protocol to exps via "proto=exps" module 
parameter?
Comment 25 Rafael J. Wysocki 2006-11-16 07:09:55 UTC
It resumes but the temperature value goes mad in one of the ACPI thermal zones
and the box shuts down (due to detected "overheating").

Anyway, it doesn't help and I think we can't do a lot here without the exact
information on how the box is (mis)designed.
Comment 26 Dmitry Torokhov 2006-11-16 07:53:09 UTC
Created attachment 9531 [details]
Fiddle with reset logic

Actually I think we could - apparently there is a difference between
psmouse_disconnect() and psmouse_cleanup() that is important to BIOS for some
reason. One thing I see is that psmouse_cleanup() does reset mouse but that
disables data reporting while psmouse_disconnect() leaves mouse with data
reporting enabled.

Could you please try the attached patch - I am interested in both synaptics and
expr protocols.

Thanks!
Comment 27 Rafael J. Wysocki 2006-11-18 14:21:45 UTC
It changes the behavior, but the new one is not desirable too.  Namely, the
resuming of power resources used to control fans apparently fails and after the
resume the fans seem to spin as the BIOS tells them (the thermal zones seem to
show correct temperatures, but this has no effect on the fans just as though
they were totally out of control).

When the psmouse module is unloaded before the suspend, the resuming of the
power resources apparently succeeds and the fans react properly on what happens
in the thermal zones.

It doesn't seem to matter if proto=exps is used.
Comment 28 Martin Kouřim 2007-02-03 08:12:51 UTC
I've got similar problem on my HP nx6310. After resume from S3, touchpad does 
not work (doesn't generate any interrupts). If I reload psmouse during 
suspend/resume, touchpad doesn't work and keyboard doesn't work either. The 
same if I reload psmouse after resume (if it is loaded during suspend).

BUT suspend work perfectly ok (both with loaded psmouse during suspend or 
with reloading psmouse during suspend/resume) when network cable is attached to 
ethernet interface...

kernel 2.6.19.2
Comment 29 Dmitry Torokhov 2007-02-18 09:57:51 UTC
Please apply all 3 patches from bug 7977 and let me know if it fixes your
touchpad. Thanks!

*** This bug has been marked as a duplicate of 7977 ***

Note You need to log in before you can comment on or make changes to this bug.