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? Thanks! -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
