Bug 9226

Summary: Touchpad not recognized on resume (suspend-to-ram)
Product: Drivers Reporter: Mikhail Malygin (mmalygin)
Component: Input DevicesAssignee: drivers_input-devices
Status: RESOLVED DOCUMENTED    
Severity: normal CC: acpi-bugzilla, alan, anders, astarikovskiy, bluefuture, ciprian.craciun, dmitry.torokhov, drivers_input-devices, ondra.herman, plastikman, rforssen, rjw, wturkal
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.22 Subsystem:
Regression: Yes Bisected commit-id:
Bug Depends on:    
Bug Blocks: 7216    
Attachments: Suspend debug patch
dmesg - pm tests (echo 5..1, then echo 0 > /sys/power/pm_test_level)
Test suspend - echo 0, echo 2
Suspen/Resume with i8042 debug=1
Reset mouse at resume
dmesg / patched ps_mouse + i8042 debug enabled
dmesg - kernel 2.6.23 patched with psmouse-base.c + i8042 debug enabled
Reset mouse at resume
dmesg - kernel 2.6.23 patch2 - psmouse-base.c + i8042 debug
Allow invoking i8042 resume manually
Trace: suspend/resume; echo 2 > pm_test_level; suspend/resume
dmesg - i8042 force_resume patch + debug enabled
dmesg - force_resume=1, force_resume=2
Debug patch to try
Patch to debug suspending of devices
Patch history
TP works !!! - "echo 235 > /sys/power/pm_drivers; echo mem > /sys/power/state"
TP does not work - "echo 236 > /sys/power/pm_drivers; echo mem > /sys/power/state"

Description Mikhail Malygin 2007-10-25 10:54:02 UTC
Most recent kernel where this bug did not occur:
Distribution:Ubuntu 7.04 - 7.10, Fedora 7-8, SuSE 10.2, Slackware 12.
Hardware Environment:FSC Amilo pro v3205 BIOS v.1.20 1.66 C2D
Software Environment:
Problem Description: 
It looks like because of the BIOS (1.20) version kernel does not recongnize a touchpad after suspending the ram and does not create a corresponding input class (people say on laptops with BIOS less then 1.17 everything works fine, so it is most probably happens because of BIOS changes. XP suspends/resumes 100% ok so that can not be a BIOS bug. Tried different distro - everywhere is the same.

Steps to reproduce: 100% reproducable on any Amilo v3205/Si1520 with BIOS 1.29/1.20
Comment 1 Rafael J. Wysocki 2007-10-25 14:03:04 UTC
[The fact that XP resumes correctly doesn't imply that the BIOS is not buggy.]

Can you please try the 2.6.23 kernel (that contains many suspend-related fixes)?
Comment 2 Mikhail Malygin 2007-10-25 16:22:41 UTC
Just tried the 2.6.23.1 - unfortunately has the same effect - simply does not find this device on resume, even does not tell anything about synaptics in the log...

(In reply to comment #1)
> [The fact that XP resumes correctly doesn't imply that the BIOS is not
> buggy.]
> 
> Can you please try the 2.6.23 kernel (that contains many suspend-related
> fixes)?
> 
Comment 3 Rafael J. Wysocki 2007-10-25 16:34:14 UTC
Please apply the patch from:

http://bugzilla.kernel.org/attachment.cgi?id=12991&action=view

on top of 2.6.23.1.  Then, please follow the instructions at:

http://bugzilla.kernel.org/show_bug.cgi?id=7499#c44

and see if you are able to reproduce the problem and in which step.
Comment 4 Mikhail Malygin 2007-10-26 00:11:56 UTC
Unfortunately it does not apply:

patch -p1 < suspend-debug-facility.patch 
patching file kernel/power/main.c
Hunk #1 succeeded at 27 with fuzz 2 (offset -4 lines).
Hunk #2 FAILED at 172.
Hunk #3 FAILED at 206.
Hunk #4 succeeded at 292 with fuzz 1 (offset -3 lines).
Hunk #5 succeeded at 420 (offset -3 lines).
2 out of 5 hunks FAILED -- saving rejects to file kernel/power/main.c.rej
patching file kernel/power/power.h
Hunk #1 succeeded at 194 (offset 12 lines).


(In reply to comment #3)
> Please apply the patch from:
Comment 5 Rafael J. Wysocki 2007-10-26 15:22:00 UTC
I'm sorry, some additional patches are necessary for that to work against 2.3.23.

I'll attach a version that applies on top of 2.6.24-rc1.
Comment 6 Rafael J. Wysocki 2007-10-26 15:24:36 UTC
Created attachment 13284 [details]
Suspend debug patch

This is the version of the patch from
http://bugzilla.kernel.org/attachment.cgi?id=12991&action=view
that applies on top of 2.6.24-rc1 .

Please apply it on top of 2.6.24-rc1 and follow the instructions given at:
http://bugzilla.kernel.org/show_bug.cgi?id=7499#c44
Comment 7 Mikhail Malygin 2007-10-27 03:03:18 UTC
Unfortunatelly it doe snot compile for whatever reason:

  LD      .tmp_vmlinux1
arch/x86/kernel/built-in.o: In function `smp_send_nmi_allbutself':
/usr/src/linux-2.6.23/arch/x86/kernel/crash.c:85: undefined reference to `genapic'
make[1]: *** [.tmp_vmlinux1] Error 1



(In reply to comment #6)
> Created an attachment (id=13284) [details]
> Suspend debug patch
> 
> This is the version of the patch from
> http://bugzilla.kernel.org/attachment.cgi?id=12991&action=view
> that applies on top of 2.6.24-rc1 .
> 
> Please apply it on top of 2.6.24-rc1 and follow the instructions given at:
> http://bugzilla.kernel.org/show_bug.cgi?id=7499#c44
> 
Comment 8 Mikhail Malygin 2007-10-27 09:53:11 UTC
Created attachment 13286 [details]
dmesg - pm tests (echo 5..1, then echo 0 > /sys/power/pm_test_level)
Comment 9 Mikhail Malygin 2007-10-27 09:55:10 UTC
Finally I fixed it and compiled it successfully...looks like a bit buggy 2.6.24.rc1 patch...

After echoing 1-5 to pm_test_level touchpad does work perfectly!!!  Even works after i put 0 then next cycle 1 to pm_test_level. 

After echoing 0 to pm_test_level touchpad does not work. But i i suspend the box which "echo 1" afterwards my touchpad comes back perfectly.

I have attached dmesg dump for echo 1-5 and echo 0 cycles: http://bugzilla.kernel.org/attachment.cgi?id=13286



(In reply to comment #6)
> Created an attachment (id=13284) [details]
> Suspend debug patch
Comment 10 Mikhail Malygin 2007-10-28 08:56:50 UTC
Anything I could do in order to help in futher investigation?
Comment 11 Rafael J. Wysocki 2007-10-28 11:47:14 UTC
What happens if you normally suspend to RAM and then test with pm_test_level=2?
Comment 12 Mikhail Malygin 2007-10-28 12:24:00 UTC
Created attachment 13304 [details]
Test suspend - echo 0, echo 2
Comment 13 Mikhail Malygin 2007-10-28 12:26:21 UTC
Normal suspend kills the touchpad. 
Suspend with pm_test_level=2 BRINGS IT BACK TO LIFE :) !

I have attached the corresponding dmesg: 
http://bugzilla.kernel.org/attachment.cgi?id=13304&action=view

(In reply to comment #11)
> What happens if you normally suspend to RAM and then test with
> pm_test_level=2?
> 
Comment 14 Rafael J. Wysocki 2007-10-28 12:36:59 UTC
Well, it looks like the touchpad is not reinitialized appropriately during resume.

I'll try to reassign the bug to Drivers->Input.
Comment 15 Rafael J. Wysocki 2007-10-28 12:44:26 UTC
(In reply to comment #14)
> Well, it looks like the touchpad is not reinitialized appropriately during
> resume.
> 
> I'll try to reassign the bug to Drivers->Input.

Done.

The touchpad doesn't work after a resume from RAM, but it's sufficient to suspend and resume devices once again to make it work (that's what pm_test_level=2 does).
Comment 16 Dmitry Torokhov 2007-10-28 19:33:57 UTC
Could you please try doing "echo 1 > /sys/module/i8042/parameters/debug" before suspending/resuming and send me full dmesg. Please boot with log_buf_len=262144 to make sure we won't loose any messages.
Comment 17 Mikhail Malygin 2007-10-29 02:15:01 UTC
Created attachment 13308 [details]
Suspen/Resume with i8042 debug=1
Comment 18 Dmitry Torokhov 2007-10-29 08:17:06 UTC
Created attachment 13311 [details]
Reset mouse at resume

Could you please try this patch? Thanks!
Comment 19 Mikhail Malygin 2007-10-29 10:34:42 UTC
Tried to patch ps_mouse in 2.6.24rc1 - the same result: normal suspend/resume kills the touchpad, suspending with pm_test_level=2 brings it back.
Comment 20 Dmitry Torokhov 2007-10-29 10:59:48 UTC
Can I get another i8042 debug dmesg with the patch applied, please?
Comment 21 Mikhail Malygin 2007-10-29 11:23:37 UTC
Created attachment 13318 [details]
dmesg / patched ps_mouse + i8042 debug enabled
Comment 22 Dmitry Torokhov 2007-10-29 11:59:00 UTC
Hmm, the log is from teh same kernel as before. Are you sure you a running with new kernel?
Comment 23 Mikhail Malygin 2007-10-29 13:12:38 UTC
maybe i did something wrong, but i didn't recompile the whole kernel - just the ps_mouse module. Should I do make clean?

(In reply to comment #22)
> Hmm, the log is from teh same kernel as before. Are you sure you a running
> with
> new kernel?
> 
Comment 24 Dmitry Torokhov 2007-10-29 13:20:34 UTC
Just make sure that you are loading the updated module - I do not see the new  commands I expected to be sent to i8042 in the 2nd log, that's why I am asking. 
Comment 25 Mikhail Malygin 2007-10-29 13:31:09 UTC
ok, I'll better recompile it from scratch... 
BTW, should I use this "2.6.24rc1" patched version or can I apply your patch tp 2.6.23 tree?

(In reply to comment #24)
> Just make sure that you are loading the updated module - I do not see the new 
> commands I expected to be sent to i8042 in the 2nd log, that's why I am
> asking. 
> 
Comment 26 Dmitry Torokhov 2007-10-29 13:35:13 UTC
I think it can be applied to 2.6.23...
Comment 27 Mikhail Malygin 2007-10-29 15:14:59 UTC
Created attachment 13327 [details]
dmesg - kernel 2.6.23 patched with psmouse-base.c + i8042 debug enabled

Did complete recompile - behavior has not been changed.
Comment 28 Dmitry Torokhov 2007-10-30 10:05:54 UTC
Created attachment 13346 [details]
Reset mouse at resume

Ok, the mouse still does not want to talk to us after resume... Let's try resetting a little harder... Could you please try this patch instead?
Comment 29 Mikhail Malygin 2007-10-30 12:13:23 UTC
Created attachment 13353 [details]
dmesg - kernel 2.6.23 patch2 - psmouse-base.c + i8042 debug

Tested - still the same
Comment 30 Mikhail Malygin 2007-10-31 12:40:18 UTC
Anything else i can have with?

(In reply to comment #28)
> Ok, the mouse still does not want to talk to us after resume... Let's try
> resetting a little harder... Could you please try this patch instead?
Comment 31 Mikhail Malygin 2007-11-01 13:16:34 UTC
It is any way to go further or should I consider the problem to be unresolvable? If that is so, could you give me a hint how to hack the whole suspend/resume process in order to reinitialize it twice - workaround but still something i can use in my dayly work?
Comment 32 Rafael J. Wysocki 2007-11-02 04:24:16 UTC
(In reply to comment #31)
> It is any way to go further or should I consider the problem to be
> unresolvable?

Well, it looks resolvable, but we need to know what to fix.  For now, we only know that suspending and resuming _all_ devices brings your touchpad back to life, which doesn't necessarily mean that the touchpad itself needs that (it may be a device the touchpad depends on somehow).

Please compile the kernel with CONFIG_PM_VERBOSE set, suspend to RAM, then run the level 2 test (ie. "suspend" with pm_test_level=2) and attach the dmesg output from after that (you may need to increase the dmesg buffer size to get the entire log).

> If that is so, could you give me a hint how to hack the whole
> suspend/resume process in order to reinitialize it twice -
> workaround but still something i can use in my dayly work?

On openSUSE 10.2 you can modify /etc/pm/functions by adding your workaround commands to do_suspend() .
Comment 33 Dmitry Torokhov 2007-11-02 08:55:34 UTC
Created attachment 13378 [details]
Allow invoking i8042 resume manually

OK, let's try to get some more data. Please apply the patch below. You should see a new attribute - /sys/bus/platform/devices/i8042/force_resume. Writing 1 there forces i8042's resume method to be called, writing 2 causes it go through suspend first, then resume. Again, I'd like to see debug dmesgs. Thanks!
Comment 34 Mikhail Malygin 2007-11-02 11:06:20 UTC
Created attachment 13382 [details]
Trace: suspend/resume; echo 2 > pm_test_level; suspend/resume
Comment 35 Rafael J. Wysocki 2007-11-02 11:32:26 UTC
(In reply to comment #33)

Do I understand correctly that you want Mikhail to suspend to RAM with the patch applied, then try to invoke the i8042's .resume() manually (or .suspend()/.resume(), depending on what's written into /sys/bus/platform/devices/i8042/force_resume) and see if that revives the touchpad?
Comment 36 Dmitry Torokhov 2007-11-02 12:24:16 UTC
Right. This way we either isolate breakage to input layer or see that we need to look elsewhere, probly into ACPI/PNP code...
Comment 37 Mikhail Malygin 2007-11-02 12:50:08 UTC
Created attachment 13384 [details]
dmesg - i8042 force_resume patch + debug enabled

Sequence:
echo 1 > force_resume;
echo mem > power state;
resume
echo 2 > force_resume;
echo mem > power state;
resume
Comment 38 Mikhail Malygin 2007-11-03 11:36:51 UTC
Created attachment 13389 [details]
dmesg - force_resume=1, force_resume=2

Sorry, apparently i did not get right what to do - now i did the following:
1. suspend/resume - touchpad dead;
2. echo 1 > /sys/bus/platform/devices/i8042/force_resume - still dead;
3. echo 2 > /sys/bus/platform/devices/i8042/force_resume - still dead...

I have attached the dmsg extraction with i8042 debug enabled - macbe it can say something for you...
Comment 39 Dmitry Torokhov 2007-11-05 13:40:38 UTC
Hmm, that means that the problem is wider than input core alone, somethign else is not resumed properly.. PNP? ACPI? 
Comment 40 Rafael J. Wysocki 2007-11-05 13:46:41 UTC
Well, both seem to be good candidates ...
Comment 41 Mikhail Malygin 2007-11-06 10:06:31 UTC
But how did the suspend/resume without actual S3 call work? Why there we get the touchpad properly resumed? (In reply to comment #40)
> Well, both seem to be good candidates ...
> 
Comment 42 Rafael J. Wysocki 2007-11-06 15:02:05 UTC
If we actaully go to S3, the platform firmware takes over control and it may do some things that will have to be undone after the resume.

The problem is we don't know what it does and therefore we don't know how to undo that.
Comment 43 Mikhail Malygin 2007-11-09 05:25:07 UTC
That is really sad. All that means it is not resolvable with remote reproduction?

(In reply to comment #42)
> The problem is we don't know what it does and therefore we don't know how to
> undo that.
> 
Comment 44 Rafael J. Wysocki 2007-11-09 14:43:49 UTC
(In reply to comment #43)
> That is really sad. All that means it is not resolvable with remote
> reproduction?

We need to find a way to narrow it somehow.
Comment 45 Mikhail Malygin 2007-11-10 12:04:24 UTC
Should I do any other tests to find a problematic  place?
Comment 46 Rafael J. Wysocki 2007-12-12 16:27:43 UTC
Please install the current mainline kernel on this box and check if the issue is present in it.  In case it is, please report back and I'll tell you what to do next.
Comment 47 Mikhail Malygin 2007-12-13 02:36:14 UTC
i have checked it with (2.6.23 + 2.6.24.rc5 patch) - still the same. What should I try next?
Comment 48 Rafael J. Wysocki 2007-12-13 07:57:38 UTC
Please apply patches 01-09 from
http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.24-rc4-git6/patches/
on top of 2.6.24-rc5.

If you boot the kernel with these patches applied, there should be /sys/power/pm_test file .  If it's present, please do:

# echo 8 > /proc/sys/kernel/printk
# echo core > /sys/power/pm_test
# echo mem > /sys/power/state

and see if your touchpad works after that.
Comment 49 Mikhail Malygin 2007-12-13 10:33:43 UTC
I have applied the patches to 2.6.24-rc4 (some patches were rejected on 2.6.24-rc5) . After doing the given command sequence the box did not completely suspend - it stayed for 5 seconds with some console messages (freezing consoles ...) and then came back to life TOGETHER WITH TOUCHPAD! Do you need a dmesg? 
Comment 50 Rafael J. Wysocki 2007-12-13 13:05:10 UTC
(In reply to comment #49)
> I have applied the patches to 2.6.24-rc4 (some patches were rejected on
> 2.6.24-rc5) . After doing the given command sequence the box did not
> completely suspend - it stayed for 5 seconds with some console messages
> (freezing consoles ...)

It's supposed to do that.  It just didn't go to the BIOS.

> and then came back to life TOGETHER WITH TOUCHPAD!

Well, this means exactly that the BIOS does something we're not expecting.  This may be related to the embedded controller or something like this.

> Do you need a dmesg?

No, thanks.

 
Comment 51 Rafael J. Wysocki 2007-12-13 13:15:36 UTC
[I guess it's time to get some ACPI people on board.]

Can you check if doing:

#echo devices > /sys/power/pm_test
#echo mem > /sys/power/state

after a "regular" resume from RAM (ie. when the touchpad is dead) brings the touchpad back to life?
Comment 52 Mikhail Malygin 2007-12-13 13:26:06 UTC
boot 2.6.24.rc4
echo mem > /sys/power/state
echo devices > /sys/power/pm_test
echo mem > /sys/power/state

That sequence brings the Touchpad back to live!
Comment 53 Rafael J. Wysocki 2007-12-13 13:42:22 UTC
Well, clearly, we have to reset something during a resume so that things work again, but it's not i8042.  The question is what.

I'll try to write a piece of debug code for you, but that'll take some time (please "ping" me in a couple of days).
Comment 54 Mikhail Malygin 2007-12-17 03:03:43 UTC
Is it too early "ping" :) ? Can I make a new tests?
Comment 55 Rafael J. Wysocki 2007-12-17 09:40:02 UTC
Created attachment 14085 [details]
Debug patch to try

For starters, can you check if this patch has any effect on the regular suspend?
Comment 56 Mikhail Malygin 2007-12-17 15:06:12 UTC
have tested - does not have any effect (echo mem > /sys/power/state)
Comment 57 Mikhail Malygin 2007-12-22 10:01:58 UTC
another "ping" message :) ... Would it be possible to make any new tests?
Comment 58 Rafael J. Wysocki 2007-12-23 16:16:07 UTC
Created attachment 14164 [details]
Patch to debug suspending of devices

Yes, sorry for the delay.

Please revert the patch from Comment #55 and apply the appended patch (please let me know in case it doesn't apply).

Next, please compile the kernel with CONFIG_PM_VERBOSE set.  Then, if everything goes well, there should be /sys/power/pm_drivers attribute available.  There should be two numbers in it, 0 and the number of devices registered in your systems.  If you echo a number (say N) between these two into /sys/power/pm_drivers, the suspend will be artificially failed after suspending N devices (ie. the suspend of device (N+1) will fail with ECANCELED).  By echoing 0 to /sys/power/pm_drivers you go back to the normal behavior.

Now, you can do the following:
(1) suspend normally
(2) after the resume, echo n/2 to /sys/power/pm_drivers, where n is the second number printed by "cat /sys/power/pm_drivers" and try to suspend (the suspend will fail)
(3) see if your touchpad works
(4) if it does, echo 0 to /sys/power/pm_drivers and repeat from (1), but take n/4 instead of n/2 in (2)
(5) otherwise, echo 0 to /sys/power/pm_drivers and repeat from (1), but take 3n/4 instead of n/2 in (2)
Repeat the procedure in the binary search fashion until you find the exact number that has to be echoed into /sys/power/pm_drivers before the second fake suspend so that the touchpad works.  Next, attach the output of dmesg taken exactly at this point.
Comment 59 Mikhail Malygin 2007-12-24 01:19:49 UTC
Unfortunately it does not apply on 2.6.23 - 24.rc4,5,6 - here is the output for 2.6.24.rc6:

patch -p1 < suspend-drivers-debug.patch 
patching file drivers/base/power/main.c
patching file kernel/power/main.c
Hunk #1 FAILED at 126.
Hunk #2 FAILED at 508.
2 out of 2 hunks FAILED -- saving rejects to file kernel/power/main.c.rej
Comment 60 Rafael J. Wysocki 2007-12-24 05:02:18 UTC
Well, sorry.

Please apply the series of patches from:
http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.24-rc6/patches/
on top of 2.6.24-rc6 (should apply to the current -git too) and follow the instructions in Comment #58.
Comment 61 Mikhail Malygin 2007-12-24 14:50:22 UTC
Sorry , maybe i am doing something wrong but that series does not apply as well. Here what i did - patch output i have attached as well:

root@amilo:/usr/src $ rm -rf linux-2.6.23 
root@amilo:/usr/src $ tar jxf ../patches/linux-2.6.23.tar.bz2 
root@amilo:/usr/src $ cd linux
root@amilo:/usr/src/linux $ bzcat -dc ../patches/patch-2.6.24-rc6.bz2 | patch -p1 > history

patching file .gitignore
....
patching file sound/usb/usbquirks.h

root@amilo:/usr/src/linux $ for i in `cat ../patches/p/series`; do echo "<<<<<<<<<<<<<<< --- APPLYING $i ---"; patch --dry-run -p1 < ../patches/p/$i; done > hist
Comment 62 Mikhail Malygin 2007-12-24 14:51:35 UTC
Created attachment 14173 [details]
Patch history
Comment 63 Rafael J. Wysocki 2007-12-24 15:09:58 UTC
Well, please download http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.24-rc6/snapshot-071224.tgz, unpack it in the unmodified 2.6.24-rc6 source directory, rename "hibernation_and_suspend" to  "patches" and run "quilt push -a".  Works for me.
Comment 64 Mikhail Malygin 2007-12-25 03:03:02 UTC
Thanks, now it works. I have made some tests and found after first suspend/resume cycle one interesting thing - the number of the registered devices has been lowered from 352 to 349 (see below):

$ cat /sys/power/pm_drivers 
0 352
$ echo mem > /sys/power/state
-------------------------------------> first suspend/resume
$ echo 176 > /sys/power/pm_drivers
$ cat /sys/power/pm_drivers
176 349
$ echo 0 > /sys/power/pm_drivers
$ cat /sys/power/pm_drivers
0 349

I have used the first number (352) and tried to echo n/2=176 (TP works), n/4=88 (TP works) and (3*n)/4=264 (TP does not work) but then stopped - could you please write the algorithm i should use there?

 
Comment 65 Mikhail Malygin 2007-12-25 03:20:54 UTC
Sorry, was a stupid question - looks like i found that "magic" number - it is 235: after echoing 235 - TP works, increasing number to 236 stops it. attached you can find dmesg for both fake suspend cycles 
Comment 66 Mikhail Malygin 2007-12-25 03:23:26 UTC
Created attachment 14179 [details]
TP works !!! - "echo 235 > /sys/power/pm_drivers;  echo mem > /sys/power/state"
Comment 67 Mikhail Malygin 2007-12-25 03:24:09 UTC
Created attachment 14180 [details]
TP does not work - "echo 236 > /sys/power/pm_drivers;  echo mem > /sys/power/state"
Comment 68 Rafael J. Wysocki 2007-12-25 10:30:35 UTC
It looks like the second suspend of serio:serio0 makes your touchpad work after resuming.  I'll try to prepare another debug patch, but that'll take some time again.
Comment 69 Rafael J. Wysocki 2008-01-02 08:11:42 UTC
In the meantime, there's an important ACPI fix in the new patch series at:
http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.24-rc6/patches/
(the latest snapshot at: http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.24-rc6/snapshot-080101.tgz).

Can you test it on top of 2.6.24-rc6, please?
Comment 70 Mikhail Malygin 2008-01-10 09:11:18 UTC
Sorry, I was on vacation... 
I have tried the snapshot-080101.tgz today . does not bring the touchpad back.
Comment 71 Mikhail Malygin 2008-01-12 12:15:46 UTC
Anything else i could do to help in investigating the problem?
Comment 72 Rafael J. Wysocki 2008-01-12 13:34:50 UTC
I'll let you know when I have the next debug patch ready.
Comment 73 Zak Peirce 2008-03-05 13:52:09 UTC
Just wanted to add a me too here on this.  I have a gateway 8510GZ Centrino 1.7 GHZ machine that the touchpad does not wake up after sleep.  I have tested some of the debug patches that you posted and they also provide the same results as Mikhail reported.  

If there is any testing that you need done I can also help.

Thanks,

Zak
Comment 74 Ondra Herman 2008-07-29 17:35:54 UTC
Hi,

is something happening? This is really annoying bug. Is there anything I can do to help? Thanks,

   Ondra
Comment 75 ste 2009-01-03 17:00:28 UTC
Please can Rafael teel us if this bug must be reassigned or put as NEW?
Comment 76 Rafael J. Wysocki 2009-01-04 11:36:30 UTC
Sorry, I lost this report from my radar.

I understand that this issue is still present in 2.6.28.  Is that correct?
Comment 77 ste 2009-01-04 14:22:23 UTC
I can confirm that this bug is still present in 2.6.27 and also other people could confirm this[ยน]
I have not already tested on the new released server 2.6.28. Is there anybody in cc that have already tested on 2.6.28?

[1] https://bugs.launchpad.net/linux/+bug/52967
Comment 78 ste 2009-01-11 05:44:57 UTC
Rafael i have tested this issue with 2.6.28 and is still present.
Comment 79 Rafael J. Wysocki 2009-01-11 05:55:50 UTC
Unfortunately, I'm not aware of any patches that can help fix this problem and I'm not an input devices expert myself.
Comment 80 Zak Peirce 2009-01-11 11:44:52 UTC
Rafael,

Is there some one else that this can be assigned to?  I would love to have STR working.

-Zak
Comment 81 Rafael J. Wysocki 2009-01-11 15:26:47 UTC
No idea.  Everyone relevant seems to be in the CC list ...
Comment 82 ste 2009-01-11 15:47:06 UTC
Rafael Zak and other in cc what do u think about add in cc or assign this bug to drivers_input-devices@kernel-bugs.osdl.org ?
Comment 83 Rafael J. Wysocki 2009-01-11 15:56:11 UTC
Well, you can try, but that need not have any effect.
Comment 84 ste 2009-01-12 01:54:13 UTC
Ok now drivers_input-devices@kernel-bugs.osdl.org  is in cc. I think that only you could assign this bug to this address.
Comment 85 Zak Peirce 2009-01-29 15:47:28 UTC
With the release of 2.6.29-rc3 http://lkml.org/lkml/2009/1/28/277 there are fixes for PCI suspend/resume handling.  I will try to give the 2.6.29-rc3 a shot some time next week.

-Zak
Comment 86 Zak Peirce 2009-01-29 17:47:22 UTC
looks like 2.6.29-rc3 does not help. 
Comment 87 Ciprian Dorin Craciun 2009-03-22 05:00:17 UTC
I have a similar problem: after a suspend-to-ram, the Synaptics touch pad driver stops working correctly (the scroll features do not work, but I can move and click the mouse).

There is nothing suspicious in either kernel and X logs. This problem appeared only when I've installed 2.6.28 (any minor version, currently I have .8). This problem was not seen in either 2.6.25 or .27. My laptop is a Benq Joybook S32B.

Now I've skimmed through the replies, and tried the thing with echo ... > /sys/bus/..., and didn't worked. (I must mention that if I restart X server the problem is fixed until the next susspend. This is not an X problem, as with another kernel, the same "experiment" works.)

If anyone wants me to try some patch, I'm up for it!

Thanks,
Ciprian Craciun.
Comment 88 Rafael J. Wysocki 2011-01-16 21:45:29 UTC
Can you test the 2.6.37 kernel and see if the issue is still present in it,
please?
Comment 89 Zak Peirce 2011-01-19 00:51:12 UTC
(In reply to comment #88)
> Can you test the 2.6.37 kernel and see if the issue is still present in it,
> please?

Compiled up 2.6.37 on Fedora 14 still have the same issues.  the trackpad does not wake up after resuming from STR.
Comment 90 Dmitry Torokhov 2011-01-19 01:00:30 UTC
Hmm, btw, does it help if you boot with i8042.reset on the kernel command line?
Comment 91 ste 2011-01-30 23:24:15 UTC
Adding atkbd.reset option finally works fine and seems from 2.6.35. Is there something that could be done inside kernel directly?
Comment 92 Zak Peirce 2011-02-04 04:04:38 UTC
(In reply to comment #90)
> Hmm, btw, does it help if you boot with i8042.reset on the kernel command
> line?

Like ste said adding atkbd.reset works on 2.6.35 and on 2.6.37.  At this point the laptop that has this issue is no longer my daily driver so this "hack" is good enough.
Comment 93 Alan 2012-05-17 14:52:24 UTC
Dmitry: only question on this is should be quirk the i8042_reset for this system ?
Comment 94 Dmitry Torokhov 2012-05-18 06:41:55 UTC
We now trying to automatically reset i8042 suding suspend/resume on all systems without quirks. In this bug Zak and Ste mention that they need atkbd.reset, not i8042.reset and we currently do not have automatic reset quirks in atkbd driver.

It would be nice to see if they really need atkbd.reset with 3.x kernels.
Comment 95 Alan 2012-05-22 14:38:23 UTC
*** Bug 11656 has been marked as a duplicate of this bug. ***