Re: Bug: touchpad unresponsive after resume from S3 (psmouse driver)

[Daniel Manrique <daniel.manrique@canonical.com>]

On 11-12-01 12:15 AM, Dmitry Torokhov wrote:
> On Wed, Nov 30, 2011 at 10:18:10AM -0500, Daniel Manrique wrote:
>> On 11-11-29 07:17 PM, Dmitry Torokhov wrote:
>>> On Tue, Nov 29, 2011 at 02:43:35PM -0500, Daniel Manrique wrote:
>>>> On 11-11-29 12:53 PM, Dmitry Torokhov wrote:
>>>>> Hi Daniel,
>>>>>
>>>>> On Tue, Nov 29, 2011 at 11:26:19AM -0500, Daniel Manrique wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I apologize for sending this bug report directly; with the kernel.org bugtracker
>>>>>> down I was told this was the best option for the time being. If this is not
>>>>>> correct, could you please let me know of a good place to submit this bug report?
>>>>>>
>>>>>> I have several Dell laptops with Synaptics touchpads, particularly a group of
>>>>>> Vostro V13 systems. On these, after a suspend/resume cycle, the touchpad
>>>>>> (Synaptics) is unresponsive; a workaround is to rmmod psmouse; modprobe psmouse.
>>>>>>
>>>>>> This was first reported on kernel 2.6.38, although I think the issue has been
>>>>>> present from as early as 2.6.32. I verified it for sure with Ubuntu 2.6.38
>>>>>> kernels, 3.0.0 kernels, and a 3.2.0 kernel from the development release, as well
>>>>>> as a "mainline" 3.1.0-rc10 kernel.
>>>>>>
>>>>>> Since this problem was seen on Ubuntu, it's filed on the Launchpad bug tracker.
>>>>>> The first report I can find is this one:
>>>>>>
>>>>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/715267
>>>>>>
>>>>>> This includes a series of log messages I don't see on my systems. I then filed
>>>>>> this other bug:
>>>>>>
>>>>>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/879650
>>>>>>
>>>>>> The last one contains specific information from one of my systems (a Vostro V13).
>>>>>>
>>>>>> I'd really appreciate any help or guidance on how to solve this problem. If you
>>>>>> need me to collect any information or run any tests on these machines, please
>>>>>> don't hesitate to ask, these systems are primarily used for testing.
>>>>>>
>>>>>
>>>>> Please do:
>>>>>
>>>>>  - enable i8042 debug (echo 1 > /sys/module/i8042/parameters/debug)
>>>>>  - rmmod psmouse;
>>>>>  - suspend/resume;
>>>>>  - collect dmesg;
>>>>>  - suspend/resume;
>>>>>  - collect dmesg again
>>>>>
>>>>> and we'll have to try and find what we do differently.
>>>>>
>>>>> Thanks.
>>>>>
>>>>
>>>> Hi Dmitry,
>>>>
>>>> Thanks so much for the quick reply!
>>>>
>>>> I just ran the tests you requested with some extra steps which I hope won't
>>>> confuse things. Here's the sequence I followed:
>>>>
>>>> - Enabled i8042 debug
>>>> - sudo rmmod psmouse. Touchpad of course becomes unresponsive.
>>>> - sudo pm-suspend
>>>> - Wake the machine by pressing power
>>>> - At this point touchpad is unresponsive.
>>>> - Collected dmesg-1.txt
>>>> - sudo pm-suspend
>>>> - wake the machine by pressing power
>>>> - At this point touchpad is still unresponsive.
>>>> - Collected dmesg-2.txt
>>>> - sudo modprobe psmouse. Touchpad begins responding.
>>>> - Collected dmesg-3.txt
>>>> - sudo pm-suspend
>>>> - wake the machine by pressing power
>>>> - At this point touchpad is again unresponsive.
>>>> - Collected dmesg-4.txt
>>>>
>>>> To avoid attaching largish files to this email, I put the logs on a
>>>> publically-accessible http server at:
>>>> http://people.canonical.com/~roadmr/lp715267/. Please let me know if you prefer
>>>> something else.
>>>>
>>>
>>> Hmm, it just does not want to admit that it is synaptics after reset.
>>> Does the patch below help any?
>>
>> Hi Dmitry,
>>
>> I applied the patch to a 3.2-series kernel (based off 3.2-rc3 I think). It
>> applied cleanly to psmouse.c, and after compiling the driver and putting it in
>> place of the old psmouse.ko, the touchpad works after resuming from suspend!
>>
>> I did a comparison test by swapping drivers (old vs. new) without rebooting, by
>> rmmodding the existing psmouse driver, putting the old/new file in place,
>> reloading the driver and doing a suspend/resume cycle. Consistently, with the
>> old/original driver I still see the problem, but with the new/patched driver the
>> touchpad is always enabled after resume.
>>
>> i only tested this on one of the failing Vostro V13, please let me know if I
>> should test for anything like possible misbehaviors on other previously-working
>> systems or some other kind of regression.
>>
>> But still, this patch seems to work fine, thanks for this! What's the next step
>> for getting this fix into the official kernel? Anything I can do to help?
>>
> 
> Could you please try removing either ssleep(1) or querying of device ID
> from the patch and see which one of them actually fixes the issue?

Hi Dmitry,

Certainly! I compiled and tested two new versions of the module, one with the
"delaying after reset" code commented out, the other with the "querying ID"
block commented out.

The ssleep(1); line is what appears to do the trick; the version that just
queries the ID exhibits the same problem I reported initially, while the one
that just ssleeps works fine, with the touchpad working OK after resuming.

I'll await further instructions on this, thanks so much for your help!

- Daniel

> Thanks!
>