Bug 7277

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?

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.

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.

Created attachment 9195 [details]
dmesg after applying the patch

Can you give me the acpidump output? I'd like check it.

Created attachment 9196 [details]
acpidump output

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.

Created attachment 9197 [details]
my small dsdt changes to silence iasl compiler warnings

>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?

hibernation == s3 (suspend-to-ram), yes.

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.

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.

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).

Created attachment 9198 [details]
dmesg showing a session without psmouse module

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.

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.

Ok, this suggests it's not an issue in pnpacpi, proberly you report this to 
input driver maintainer.

Couldn't you reassign this bug?

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).

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?

Dmitry, did you read David's last comments? he seems to think just the opposite,
that the problem is not pnpacpi.

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.

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

Rafael,

Does the nx6325 resume if you limit protocol to exps via "proto=exps" module 
parameter?

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.

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!

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.

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

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 ***