[BUG] s2idle: Surface Pro 3 suspend/resume issues

[BUG] s2idle: Surface Pro 3 suspend/resume issues

[Valentin Manea]

Again with correct linux-pm

Hi,

   Somewhere between 4.12 and 4.13 the s2idle doesn't work anymore on the
Surface Pro 3.
   After some bisecting I found 3 patches that seem to be at fault
ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems ->
0f1a83833a0ba93d6986d9e30c8fe35d7d45c17c

ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle ->
33e4f80ee69b5168badf37edbfed796eb48434b9

ACPI / PM: Clean up device wakeup enable/disable code ->
235d81a630ca2d39818da96f0c14bc960ffbaeb5

   It doesn't seem to be just one patch, I've tried combinations of the
3, but only with all three reverted s2idle suspend and resume starts
working again.
   I'm not versed in x86 and ACPI so my testing is very coarse because
there is some re-factoring included there. Do you have any idea which
parts could be casing the problem? Or at least how to debug further?

Thanks,
Valentin

Re: [BUG] s2idle: Surface Pro 3 suspend/resume issues

[Zhang Rui]

On Mon, 2018-01-08 at 07:55 +0000, Valentin Manea wrote:
> Again with correct linux-pm
> 
> Hi,
> 
>    Somewhere between 4.12 and 4.13 the s2idle doesn't work anymore on
> the
> Surface Pro 3.

will you please be more specific about the symptom?
what command do you use to do s2idle, and how do you wake it up?


BTW, does the problem still exists in the latest upstream kernel?

thanks,
rui
>    After some bisecting I found 3 patches that seem to be at fault
> ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems
> ->
> 0f1a83833a0ba93d6986d9e30c8fe35d7d45c17c
> 
> ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle ->
> 33e4f80ee69b5168badf37edbfed796eb48434b9
> 
> ACPI / PM: Clean up device wakeup enable/disable code ->
> 235d81a630ca2d39818da96f0c14bc960ffbaeb5
> 
>    It doesn't seem to be just one patch, I've tried combinations of
> the
> 3, but only with all three reverted s2idle suspend and resume starts
> working again.
>    I'm not versed in x86 and ACPI so my testing is very coarse
> because
> there is some re-factoring included there. Do you have any idea which
> parts could be casing the problem? Or at least how to debug further?
> 
> Thanks,
> Valentin

Re: [BUG] s2idle: Surface Pro 3 suspend/resume issues

[Valentin Manea]

On 2018-01-08 08:13, Zhang Rui wrote:
> On Mon, 2018-01-08 at 07:55 +0000, Valentin Manea wrote:
>> Again with correct linux-pm
>> 
>> Hi,
>> 
>>    Somewhere between 4.12 and 4.13 the s2idle doesn't work anymore on
>> the
>> Surface Pro 3.
> 
> will you please be more specific about the symptom?
> what command do you use to do s2idle, and how do you wake it up?

Sure, sorry for not being more specific. I tried both the DE(KDE) 
suspend functionality but also:
echo memory  > /sys/power/state
and the behaviour is the same: display goes dark, system is not 
responding - the power button which previously wakes up the system 
doesn't work anymore. It needs a hard reset from this point

The home button has a slight vibration when device is fully running, in 
this state the vibration doesn't happen at all so I suppose it went 
through some sleep stages.

For reference I tried with iommu=off booting because of another bug that 
made the rounds but that never helped. The problem seems to be in the 3 
patches I mentioned in my top email

> 
> 
> BTW, does the problem still exists in the latest upstream kernel?

Yep, no changes. System still needs a hard reset after suspending to 
idle.
> 
> thanks,
> rui

Thanks,
Valentin

Re: [BUG] s2idle: Surface Pro 3 suspend/resume issues

[Zhang Rui]

On Mon, 2018-01-08 at 08:21 +0000, Valentin Manea wrote:
> On 2018-01-08 08:13, Zhang Rui wrote:
> > 
> > On Mon, 2018-01-08 at 07:55 +0000, Valentin Manea wrote:
> > > 
> > > Again with correct linux-pm
> > > 
> > > Hi,
> > > 
> > >    Somewhere between 4.12 and 4.13 the s2idle doesn't work
> > > anymore on
> > > the
> > > Surface Pro 3.
> > will you please be more specific about the symptom?
> > what command do you use to do s2idle, and how do you wake it up?
> Sure, sorry for not being more specific. I tried both the DE(KDE) 
> suspend functionality but also:
> echo memory  > /sys/power/state
> and the behaviour is the same: display goes dark, system is not 
> responding - the power button which previously wakes up the system 
> doesn't work anymore. It needs a hard reset from this point
> 
> The home button has a slight vibration when device is fully running,
> in 
> this state the vibration doesn't happen at all so I suppose it went 
> through some sleep stages.
> 
> For reference I tried with iommu=off booting because of another bug
> that 
> made the rounds but that never helped. The problem seems to be in the
> 3 
> patches I mentioned in my top email
> 
> > 
> > 
> > 
> > BTW, does the problem still exists in the latest upstream kernel?
> Yep, no changes. System still needs a hard reset after suspending to 
> idle.

in latest upstream kernel, does it work if you use rtcwake instead?
say, "rtcwake -m freeze -s 20"

thanks,
rui
> > 
> > 
> > thanks,
> > rui
> Thanks,
> Valentin
> 

Re: [BUG] s2idle: Surface Pro 3 suspend/resume issues

[Valentin Manea]

On 2018-01-08 08:37, Zhang Rui wrote:
> On Mon, 2018-01-08 at 08:21 +0000, Valentin Manea wrote:
>> On 2018-01-08 08:13, Zhang Rui wrote:
> 
> in latest upstream kernel, does it work if you use rtcwake instead?
> say, "rtcwake -m freeze -s 20"
Sorry didn't try rtcwake but when I try 
pm_test(platform,devices,freezer) with almost any value the system goes 
to sleep/resumes fine. I will give rtcwake a try later today and let you 
know of the results.

Thanks,
Valentin

Re: [BUG] s2idle: Surface Pro 3 suspend/resume issues

[Rafael J. Wysocki]

On Mon, Jan 8, 2018 at 9:21 AM, Valentin Manea <linux-pm@mrs.ro> wrote:
>
> On 2018-01-08 08:13, Zhang Rui wrote:
>>
>> On Mon, 2018-01-08 at 07:55 +0000, Valentin Manea wrote:
>>>
>>> Again with correct linux-pm
>>>
>>> Hi,
>>>
>>>    Somewhere between 4.12 and 4.13 the s2idle doesn't work anymore on
>>> the
>>> Surface Pro 3.
>>
>>
>> will you please be more specific about the symptom?
>> what command do you use to do s2idle, and how do you wake it up?
>
>
> Sure, sorry for not being more specific. I tried both the DE(KDE) suspend
> functionality but also:
> echo memory  > /sys/power/state
> and the behaviour is the same: display goes dark, system is not responding -
> the power button which previously wakes up the system doesn't work anymore.
> It needs a hard reset from this point
>
> The home button has a slight vibration when device is fully running, in this
> state the vibration doesn't happen at all so I suppose it went through some
> sleep stages.
>
> For reference I tried with iommu=off booting because of another bug that
> made the rounds but that never helped. The problem seems to be in the 3
> patches I mentioned in my top email

I think what happens is that the events from the power button are
treated as spurious now.

The easiest way to debug this would be to find an alternative wakeup
device and then see what happens with the button wakeup.

Please open a BZ entry for this at bugzilla.kernel.org (in the
suspend/hibernation category) and add rjw@rjwysocki.net to the CC list
in it.  I'll get back to you then.

Thanks,
Rafael

Re: [BUG] s2idle: Surface Pro 3 suspend/resume issues

[Nick Singer]

On 01/08/18 12:03, Rafael J. Wysocki wrote:
> On Mon, Jan 8, 2018 at 9:21 AM, Valentin Manea <linux-pm@mrs.ro> wrote:
>>
>> On 2018-01-08 08:13, Zhang Rui wrote:
>>>
>>> On Mon, 2018-01-08 at 07:55 +0000, Valentin Manea wrote:
>>>>
>>>> Again with correct linux-pm
>>>>
>>>> Hi,
>>>>
>>>>    Somewhere between 4.12 and 4.13 the s2idle doesn't work anymore on
>>>> the
>>>> Surface Pro 3.
>>>
>>>
>>> will you please be more specific about the symptom?
>>> what command do you use to do s2idle, and how do you wake it up?
>>
>>
>> Sure, sorry for not being more specific. I tried both the DE(KDE) suspend
>> functionality but also:
>> echo memory  > /sys/power/state
>> and the behaviour is the same: display goes dark, system is not responding -
>> the power button which previously wakes up the system doesn't work anymore.
>> It needs a hard reset from this point
I've a pretty similar behavior since kernel >4.7 on my ThinkPad t450s.

>> The home button has a slight vibration when device is fully running, in this
>> state the vibration doesn't happen at all so I suppose it went through some
>> sleep stages.
On my machine, the lights and the fan turn back on, power-button still
indicates a sleep by a build-in, blinking led.

>> For reference I tried with iommu=off booting because of another bug that
>> made the rounds but that never helped. The problem seems to be in the 3
>> patches I mentioned in my top email
I haven't been able to pin-point any patch down so haven't tested the 3
mentioned patches.

> I think what happens is that the events from the power button are
> treated as spurious now.
> 
> The easiest way to debug this would be to find an alternative wakeup
> device and then see what happens with the button wakeup.
> 
> Please open a BZ entry for this at bugzilla.kernel.org (in the
> suspend/hibernation category) and add rjw@rjwysocki.net to the CC list
> in it.  I'll get back to you then.
Could you please reference the bug here if you intend to create one? I'd
like to check the suggested debugging mechanisms suggested to you also
on my machine. I'm assuming it could be a related issue (since the
symptoms are so similar).

Re: [BUG] s2idle: Surface Pro 3 suspend/resume issues

[Rafael J. Wysocki]

On Wed, Jan 10, 2018 at 6:03 PM, Nick Singer <nick.singer@geekify.de> wrote:
> On 01/08/18 12:03, Rafael J. Wysocki wrote:
>> On Mon, Jan 8, 2018 at 9:21 AM, Valentin Manea <linux-pm@mrs.ro> wrote:
>>>
>>> On 2018-01-08 08:13, Zhang Rui wrote:
>>>>
>>>> On Mon, 2018-01-08 at 07:55 +0000, Valentin Manea wrote:
>>>>>
>>>>> Again with correct linux-pm
>>>>>
>>>>> Hi,
>>>>>
>>>>>    Somewhere between 4.12 and 4.13 the s2idle doesn't work anymore on
>>>>> the
>>>>> Surface Pro 3.
>>>>
>>>>
>>>> will you please be more specific about the symptom?
>>>> what command do you use to do s2idle, and how do you wake it up?
>>>
>>>
>>> Sure, sorry for not being more specific. I tried both the DE(KDE) suspend
>>> functionality but also:
>>> echo memory  > /sys/power/state
>>> and the behaviour is the same: display goes dark, system is not responding -
>>> the power button which previously wakes up the system doesn't work anymore.
>>> It needs a hard reset from this point

> I've a pretty similar behavior since kernel >4.7 on my ThinkPad t450s.

This is a different bug and you are probably not talking about suspend-to-idle.

>>> The home button has a slight vibration when device is fully running, in this
>>> state the vibration doesn't happen at all so I suppose it went through some
>>> sleep stages.

> On my machine, the lights and the fan turn back on, power-button still
> indicates a sleep by a build-in, blinking led.

But is this suspend-to-idle or suspend-to-RAM?

>>> For reference I tried with iommu=off booting because of another bug that
>>> made the rounds but that never helped. The problem seems to be in the 3
>>> patches I mentioned in my top email

> I haven't been able to pin-point any patch down so haven't tested the 3
> mentioned patches.

They probably won't help.

Anyway, please open a new BZ entry for this at bugzilla.kernel.org in
the suspend/hibernation category (you can assign it to
rjw@rjwysocki.net).  We'll track it in there.

>
>> I think what happens is that the events from the power button are
>> treated as spurious now.
>>
>> The easiest way to debug this would be to find an alternative wakeup
>> device and then see what happens with the button wakeup.
>>
>> Please open a BZ entry for this at bugzilla.kernel.org (in the
>> suspend/hibernation category) and add rjw@rjwysocki.net to the CC list
>> in it.  I'll get back to you then.

> Could you please reference the bug here if you intend to create one? I'd
> like to check the suggested debugging mechanisms suggested to you also
> on my machine. I'm assuming it could be a related issue (since the
> symptoms are so similar).

That's kernel BZ #198389, but honestly I don't think it's the same
issue.  The symptoms may be similar, but the underlying issue is
likely different.

Thanks,
Rafael