Re: 3.12.x looses serial mouse over hibernate + resume

Re: 3.12.x looses serial mouse over hibernate + resume

[Peter Hurley]

[ +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

Re: 3.12.x looses serial mouse over hibernate + resume

[Manuel Krause]

[-- Attachment #1: Type: text/plain, Size: 2832 bytes --]

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. ;-)

Best regards, and, please, tell me if you need more information,

Manuel Krause


[-- Attachment #2: 3.12.x-looses-serial-mouse-over-hibernate.zip --]
[-- Type: application/zip, Size: 34983 bytes --]

Re: 3.12.x looses serial mouse over hibernate + resume

[Dmitry Torokhov]

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@dtor-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.

Thanks.

-- 
Dmitry

Re: 3.12.x looses serial mouse over hibernate + resume

[Dmitry Torokhov]

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@dtor-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?

-- 
Dmitry

PNP: fix restoring devices after hibernation

From: Dmitry Torokhov <dmitry.torokhov@gmail.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@gmail.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 = {

Re: 3.12.x looses serial mouse over hibernate + resume

[Manuel Krause]

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@dtor-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@gmail.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@gmail.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

Re: 3.12.x looses serial mouse over hibernate + resume

[Shuah Khan]

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@dtor-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@gmail.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@gmail.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.

-- Shuah

-- 
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah.kh@samsung.com | (970) 672-0658

Re: 3.12.x looses serial mouse over hibernate + resume

[Dmitry Torokhov]

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@dtor-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@gmail.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@gmail.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

Re: 3.12.x looses serial mouse over hibernate + resume

[Shuah Khan]

On 12/02/2013 12:08 PM, Dmitry Torokhov wrote:
> On Mon, Dec 02, 2013 at 11:44:56AM -0700, Shuah Khan wrote:

>>>
>>
>> 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.
>

Yes I see it now. Before the conversion, platform_legacy_resume() path 
is taken since pnp didn't have pm.

        if (drv->pm) {
                 if (drv->pm->restore)
                         ret = drv->pm->restore(dev);
        } else {
                 ret = platform_legacy_resume(dev);
         }

Thanks for fixing the problem.

-- Shuah

-- 
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah.kh@samsung.com | (970) 672-0658

Re: 3.12.x looses serial mouse over hibernate + resume

[Dmitry Torokhov]

On Mon, Dec 02, 2013 at 07:35:47PM +0100, 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@dtor-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@gmail.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@gmail.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!
> 

Thank you Manuel, but IO think the patch is not complete as we need to
re-enable PNP devices after we make a snapshot to make sure they are
working and can handle saving the data. Coudl you please try the patch
below?

-- 
Dmitry


PNP: fix restoring devices after hibernation

From: Dmitry Torokhov <dmitry.torokhov@gmail.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@gmail.com>
---
 drivers/pnp/driver.c |   12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/pnp/driver.c b/drivers/pnp/driver.c
index a39ee38..2bd5c5f 100644
--- a/drivers/pnp/driver.c
+++ b/drivers/pnp/driver.c
@@ -197,6 +197,11 @@ static int pnp_bus_freeze(struct device *dev)
 	return __pnp_bus_suspend(dev, PMSG_FREEZE);
 }
 
+static int pnp_bus_poweroff(struct device *dev)
+{
+	return __pnp_bus_suspend(dev, PMSG_HIBERNATE);
+}
+
 static int pnp_bus_resume(struct device *dev)
 {
 	struct pnp_dev *pnp_dev = to_pnp_dev(dev);
@@ -234,9 +239,14 @@ static int pnp_bus_resume(struct device *dev)
 }
 
 static const struct dev_pm_ops pnp_bus_dev_pm_ops = {
+	/* Suspend callbacks */
 	.suspend = pnp_bus_suspend,
-	.freeze = pnp_bus_freeze,
 	.resume = pnp_bus_resume,
+	/* Hibernate callbacks */
+	.freeze = pnp_bus_freeze,
+	.thaw = pnp_bus_resume,
+	.poweroff = pnp_bus_poweroff,
+	.restore = pnp_bus_resume,
 };
 
 struct bus_type pnp_bus_type = {

Re: 3.12.x looses serial mouse over hibernate + resume

[Manuel Krause]

On 2013-12-02 20:07, Dmitry Torokhov wrote:
> On Mon, Dec 02, 2013 at 07:35:47PM +0100, 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@dtor-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@gmail.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@gmail.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!
>>
>
> Thank you Manuel, but IO think the patch is not complete as we need to
> re-enable PNP devices after we make a snapshot to make sure they are
> working and can handle saving the data. Coudl you please try the patch
> below?
>

PNP: fix restoring devices after hibernation

From: Dmitry Torokhov <dmitry.torokhov@gmail.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@gmail.com>
---
  drivers/pnp/driver.c |   12 +++++++++++-
  1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/pnp/driver.c b/drivers/pnp/driver.c
index a39ee38..2bd5c5f 100644
--- a/drivers/pnp/driver.c
+++ b/drivers/pnp/driver.c
@@ -197,6 +197,11 @@ static int pnp_bus_freeze(struct device *dev)
  	return __pnp_bus_suspend(dev, PMSG_FREEZE);
  }

+static int pnp_bus_poweroff(struct device *dev)
+{
+	return __pnp_bus_suspend(dev, PMSG_HIBERNATE);
+}
+
  static int pnp_bus_resume(struct device *dev)
  {
  	struct pnp_dev *pnp_dev = to_pnp_dev(dev);
@@ -234,9 +239,14 @@ static int pnp_bus_resume(struct device *dev)
  }

  static const struct dev_pm_ops pnp_bus_dev_pm_ops = {
+	/* Suspend callbacks */
  	.suspend = pnp_bus_suspend,
-	.freeze = pnp_bus_freeze,
  	.resume = pnp_bus_resume,
+	/* Hibernate callbacks */
+	.freeze = pnp_bus_freeze,
+	.thaw = pnp_bus_resume,
+	.poweroff = pnp_bus_poweroff,
+	.restore = pnp_bus_resume,
  };

  struct bus_type pnp_bus_type = {

ALSO, YES, this second patch version does cure the issue, on 
here, too.

Best regards, Manuel Krause

Re: 3.12.x looses serial mouse over hibernate + resume

[Dmitry Torokhov]

On Mon, Dec 02, 2013 at 09:40:20PM +0100, Manuel Krause wrote:
> On 2013-12-02 20:07, Dmitry Torokhov wrote:
> >
> >Thank you Manuel, but IO think the patch is not complete as we need to
> >re-enable PNP devices after we make a snapshot to make sure they are
> >working and can handle saving the data. Coudl you please try the patch
> >below?
> >
> 
> PNP: fix restoring devices after hibernation
> 
> From: Dmitry Torokhov <dmitry.torokhov@gmail.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@gmail.com>
> ---
>  drivers/pnp/driver.c |   12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pnp/driver.c b/drivers/pnp/driver.c
> index a39ee38..2bd5c5f 100644
> --- a/drivers/pnp/driver.c
> +++ b/drivers/pnp/driver.c
> @@ -197,6 +197,11 @@ static int pnp_bus_freeze(struct device *dev)
>  	return __pnp_bus_suspend(dev, PMSG_FREEZE);
>  }
> 
> +static int pnp_bus_poweroff(struct device *dev)
> +{
> +	return __pnp_bus_suspend(dev, PMSG_HIBERNATE);
> +}
> +
>  static int pnp_bus_resume(struct device *dev)
>  {
>  	struct pnp_dev *pnp_dev = to_pnp_dev(dev);
> @@ -234,9 +239,14 @@ static int pnp_bus_resume(struct device *dev)
>  }
> 
>  static const struct dev_pm_ops pnp_bus_dev_pm_ops = {
> +	/* Suspend callbacks */
>  	.suspend = pnp_bus_suspend,
> -	.freeze = pnp_bus_freeze,
>  	.resume = pnp_bus_resume,
> +	/* Hibernate callbacks */
> +	.freeze = pnp_bus_freeze,
> +	.thaw = pnp_bus_resume,
> +	.poweroff = pnp_bus_poweroff,
> +	.restore = pnp_bus_resume,
>  };
> 
>  struct bus_type pnp_bus_type = {
> 
> ALSO, YES, this second patch version does cure the issue, on here,
> too.

Rafael,

Will you please take this patch in? It would also make sense to add it
to stable I think.

Thanks.

-- 
Dmitry

Re: 3.12.x looses serial mouse over hibernate + resume

[Manuel Krause]

On 2013-12-04 18:16, Dmitry Torokhov wrote:
> On Mon, Dec 02, 2013 at 09:40:20PM +0100, Manuel Krause wrote:
>> On 2013-12-02 20:07, Dmitry Torokhov wrote:
>>>
>>> Thank you Manuel, but IO think the patch is not complete as we need to
>>> re-enable PNP devices after we make a snapshot to make sure they are
>>> working and can handle saving the data. Coudl you please try the patch
>>> below?
>>>
>>
>> PNP: fix restoring devices after hibernation
>>
>> From: Dmitry Torokhov <dmitry.torokhov@gmail.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@gmail.com>
>> ---
>>   drivers/pnp/driver.c |   12 +++++++++++-
>>   1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/pnp/driver.c b/drivers/pnp/driver.c
>> index a39ee38..2bd5c5f 100644
>> --- a/drivers/pnp/driver.c
>> +++ b/drivers/pnp/driver.c
>> @@ -197,6 +197,11 @@ static int pnp_bus_freeze(struct device *dev)
>>   	return __pnp_bus_suspend(dev, PMSG_FREEZE);
>>   }
>>
>> +static int pnp_bus_poweroff(struct device *dev)
>> +{
>> +	return __pnp_bus_suspend(dev, PMSG_HIBERNATE);
>> +}
>> +
>>   static int pnp_bus_resume(struct device *dev)
>>   {
>>   	struct pnp_dev *pnp_dev = to_pnp_dev(dev);
>> @@ -234,9 +239,14 @@ static int pnp_bus_resume(struct device *dev)
>>   }
>>
>>   static const struct dev_pm_ops pnp_bus_dev_pm_ops = {
>> +	/* Suspend callbacks */
>>   	.suspend = pnp_bus_suspend,
>> -	.freeze = pnp_bus_freeze,
>>   	.resume = pnp_bus_resume,
>> +	/* Hibernate callbacks */
>> +	.freeze = pnp_bus_freeze,
>> +	.thaw = pnp_bus_resume,
>> +	.poweroff = pnp_bus_poweroff,
>> +	.restore = pnp_bus_resume,
>>   };
>>
>>   struct bus_type pnp_bus_type = {
>>
>> ALSO, YES, this second patch version does cure the issue, on here,
>> too.
>
> Rafael,
>
> Will you please take this patch in? It would also make sense to add it
> to stable I think.
>
> Thanks.
>

This patch works very well for many following hibernate/resume 
cyles, now, since the patch is applied. And it doesn't show any 
side-effects for me.
Thank you for "taking it in".

Best regards, Manuel Krause

Re: 3.12.x looses serial mouse over hibernate + resume

[Rafael J. Wysocki]

On 12/4/2013 6:16 PM, Dmitry Torokhov wrote:
> On Mon, Dec 02, 2013 at 09:40:20PM +0100, Manuel Krause wrote:
>> On 2013-12-02 20:07, Dmitry Torokhov wrote:
>>> Thank you Manuel, but IO think the patch is not complete as we need to
>>> re-enable PNP devices after we make a snapshot to make sure they are
>>> working and can handle saving the data. Coudl you please try the patch
>>> below?
>>>
>> PNP: fix restoring devices after hibernation
>>
>> From: Dmitry Torokhov <dmitry.torokhov@gmail.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@gmail.com>
>> ---
>>   drivers/pnp/driver.c |   12 +++++++++++-
>>   1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/pnp/driver.c b/drivers/pnp/driver.c
>> index a39ee38..2bd5c5f 100644
>> --- a/drivers/pnp/driver.c
>> +++ b/drivers/pnp/driver.c
>> @@ -197,6 +197,11 @@ static int pnp_bus_freeze(struct device *dev)
>>   	return __pnp_bus_suspend(dev, PMSG_FREEZE);
>>   }
>>
>> +static int pnp_bus_poweroff(struct device *dev)
>> +{
>> +	return __pnp_bus_suspend(dev, PMSG_HIBERNATE);
>> +}
>> +
>>   static int pnp_bus_resume(struct device *dev)
>>   {
>>   	struct pnp_dev *pnp_dev = to_pnp_dev(dev);
>> @@ -234,9 +239,14 @@ static int pnp_bus_resume(struct device *dev)
>>   }
>>
>>   static const struct dev_pm_ops pnp_bus_dev_pm_ops = {
>> +	/* Suspend callbacks */
>>   	.suspend = pnp_bus_suspend,
>> -	.freeze = pnp_bus_freeze,
>>   	.resume = pnp_bus_resume,
>> +	/* Hibernate callbacks */
>> +	.freeze = pnp_bus_freeze,
>> +	.thaw = pnp_bus_resume,
>> +	.poweroff = pnp_bus_poweroff,
>> +	.restore = pnp_bus_resume,
>>   };
>>
>>   struct bus_type pnp_bus_type = {
>>
>> ALSO, YES, this second patch version does cure the issue, on here,
>> too.
> Rafael,
>
> Will you please take this patch in? It would also make sense to add it
> to stable I think.

Well, it conveniently hasn't been sent to linux-pm.

OK, I'll try to find it in the linux-kernel archives.

Thanks,
Rafael