| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20131202190824.GB5245@core.coreip.homeip.net>
Date: Mon, 2 Dec 2013 11:08:24 -0800
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Shuah Khan <shuah.kh@...sung.com>
Cc: Manuel Krause <manuelkrause@...scape.net>,
Peter Hurley <peter@...leysoftware.com>,
linux-kernel@...r.kernel.org, Greg KH <gregkh@...uxfoundation.org>,
linux-input@...r.kernel.org,
linux-serial <linux-serial@...r.kernel.org>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
"shuahkhan@...il.com" <shuahkhan@...il.com>
Subject: Re: 3.12.x looses serial mouse over hibernate + resume
On Mon, Dec 02, 2013 at 11:44:56AM -0700, Shuah Khan wrote:
> On 12/02/2013 11:35 AM, Manuel Krause wrote:
> >On 2013-12-02 17:45, Dmitry Torokhov wrote:
> >>On Mon, Dec 02, 2013 at 08:38:16AM -0800, Dmitry Torokhov wrote:
> >>>On Monday, December 02, 2013 05:08:28 PM Manuel Krause wrote:
> >>>>On 2013-12-01 16:43, Peter Hurley wrote:
> >>>>>[ +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
> >>>>
> >>>>Thank you very much for your reply!
> >>>>Attached you'll find a zip file with the two edited dmesg logs of
> >>>>plain vanilla kernel runs.
> >>>>
> >>>>I have to add, that the resumes _do_ succeed in both cases, only
> >>>>the serial mouse doesn't get activated after hibernate in 3.12.x
> >>>>automatically. Just scan for and compare the lines indicating
> >>>>"serial 00:08: disabled" or "serial 00:08: activated". In 3.12.x
> >>>>the activation doesn't happen after hibernate, but after
> >>>>suspend-to-ram (sleep). That only after STR and not before a
> >>>>setserial gets my mouse back... a miracle. ;-)
> >>>
> >>>I do not see
> >>>
> >>>>[ 206.577370] serial 00:08: activated
> >>>
> >>>in the restore from hibernation log of 3.12 which shoudl come from PNP
> >>>layer.
> >>>
> >>>[dtor@...r-d630 work]$ git log --oneline v3.11..v3.12 -- drivers/pnp/
> >>>729377d pnp: change pnp bus pm_ops to invoke pnp driver dev_pm_ops if
> >>>specified
> >>>ce63e18 Merge branch 'pnp'
> >>>8ad928d ACPI / PM: Use ACPI_STATE_D3_COLD instead of ACPI_STATE_D3
> >>>everywhere
> >>>eaf140b PNP: convert PNP driver bus legacy pm_ops to dev_pm_ops
> >>>
> >>>I'd start looking into these commits.
> >>>
> >>
> >>Does the following patch fixes the issue?
> >>
> >
> >PNP: fix restoring devices after hibernation
> >
> >From: Dmitry Torokhov <dmitry.torokhov@...il.com>
> >
> >On returning from hibernation 'restore; callback is called, not 'resume'.
> >This fixes breakage introduced by commit
> >eaf140b60ec961252083ab8adaf67aef29a362dd
> >
> >Signed-off-by: Dmitry Torokhov <dmitry.torokhov@...il.com>
> >---
> > drivers/pnp/driver.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/pnp/driver.c b/drivers/pnp/driver.c
> >index a39ee38..185a24a 100644
> >--- a/drivers/pnp/driver.c
> >+++ b/drivers/pnp/driver.c
> >@@ -235,8 +235,9 @@ static int pnp_bus_resume(struct device *dev)
> >
> > static const struct dev_pm_ops pnp_bus_dev_pm_ops = {
> > .suspend = pnp_bus_suspend,
> >- .freeze = pnp_bus_freeze,
> > .resume = pnp_bus_resume,
> >+ .freeze = pnp_bus_freeze,
> >+ .restore = pnp_bus_resume,
> > };
> >
> > struct bus_type pnp_bus_type = {
> >
> >
> >YES! This patch fixes the issue!!! (Even if compiled with a patched
> >kernel.) ;-)
> >
> >Many thanks for your work!
> >
> >Manuel Krause
> >
>
> I am glad the problem is fixed. But I am puzzled. pnp_bus_resume()
> didn't handle restore prior to this change. state doesn't get passed
> in to legacy resume routines. I had to add freeze to handle
> PMSG_FREEZE case, sounds like restore is needed as well, however I
> don't see where how restore is handled prior to this change.
Take a look at drivers/base/platform.c::platform_pm_restore()
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists