Created attachment 241691 [details] analyze_suspend -dev -x2 output On a Dell XPS11 laptop... When suspending to memory shortly after a resume, serio1 takes 14 seconds to suspend.
Created attachment 241701 [details] config file to reproduce this issue with analyze_suspend reproduce this failure by using the attached config file: ./analyze_suspend.py -config suspend-x2.cfg
I suspect that is because we cheat and do not actually resume the touchpad when we say we did, but rather mark the device as resumed and fire off work item to really reinitialize it. If you try to suspend right away, you need to wait until the device actually resumes before it can be suspended again.
when i manually suspend the system and resume, i am able to use the touchpad _well_ before 14 seconds, usually at about 2 seconds... perhaps analyze_suspend should use kprobes to monitor this work item to see when it actually runs?
Could I see full dmesg of the 2 attempts?
Created attachment 245491 [details] dmesg Attached is the dmesg associated with the initial comment #0 and comment #1. Here is the fun part: [ 2742.182392] PM: Suspending system (mem) [ 2742.182457] Suspending console(s) (use no_console_suspend to debug) [ 2742.205841] sd 0:0:0:0: [sda] Synchronizing SCSI cache [ 2742.207324] sd 0:0:0:0: [sda] Stopping disk [ 2753.749248] psmouse serio1: Failed to deactivate mouse on isa0060/serio1 [ 2754.002838] psmouse serio1: Failed to enable mouse on isa0060/serio1 [ 2756.276056] psmouse serio1: Failed to enable mouse on isa0060/serio1 [ 2756.402760] psmouse serio1: Failed to disable mouse on isa0060/serio1 [ 2756.719189] Removing pn544 [ 2756.833784] PM: suspend of devices complete after 14649.888 msecs
Len, can you still reproduce this with the latest Linux kernel?