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