[ +cc Dmitry Torokhov, Greg Kroah-Hartman, linux-input, linux-serial ] On 11/26/2013 05:19 PM, Manuel Krause wrote:
Since kernel 3.12.0 I have a problem with hibernate+resume not reactivating my serial mouse (trackball) with my HP notebook. Kernels 3.11.0 til 9 don't show this behaviour. Machine: HP Notebook with Core2Duo CPU (Penryn) Distro: openSUSE 12.3, 64bit, continuously updated Desktop: KDE 4.11.3 MESA & drm & Xorg: most recent ones from: http://download.opensuse.org/repositories/home:/pontostroy:/X11/openSUSE_12.3/x86_64/ Current kernel: 3.12.1 vanilla from openSUSE repos, with -ck1 and BFQ patches The Logitech Trackman Marble FX is a PS/2 device and connected via an original Logitech PS/2-COM-port adapter and manually configured via my xorg.conf. At first, I blamed the -ck1 patches from Con Kolivas for this behaviour that I use in addition to the BFQ patches, what has showed up as not right: This happens with the normal vanilla kernel schedulers for CPU and disk I/O, too. By coincidence I found a weird(!) way to reactivate the serial mouse: (1) call Hibernate (suspend-to-disk) from KDE desktop as normal (2) resume --> the PS/2 touchpad is working, the serial trackball NOT (3) call suspend-to-RAM (Sleep) from KDE, serial trackball still dead (4) execute `setserial -a /dev/ttyS0` in a konsole window or a tty* console (5) ==> serial trackball is back with all configuration from xorg.conf It's fully reproducible over multiple hibernations. This also happens when calling `pm-hibernate` (to-disk) and `pm-suspend` (to-RAM) and the setserial from a root shell in KDE or any tty*. Please, _always_CC_me_ -- as I'm not on the kernel mailing list.
Manuel, Please attach complete dmesgs (zipped, if necessary) of a suspend/resume cycle on a vanilla 3.12.x (where resume fails) _and_ a vanilla 3.11.x (where resume succeeds). For the test configurations, please do not apply patches. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html