Re: Regression on Dell XPS13

[Rafael J. Wysocki]

On Wed, Jan 18, 2017 at 12:11 PM, Paul Menzel <pmenzel@xxxxxxxxxxxxx> wrote:
> Dear Rafael, dear Mario,
>
>
> On 01/18/17 03:18, Rafael J. Wysocki wrote:
>>
>> Mario, thanks for CCing this to linux-pm.
>
>
> Rafael, you should have also received the message, Mario answered to.
>
>> On Tue, Jan 17, 2017 at 5:57 PM,  <Mario.Limonciello@xxxxxxxx> wrote:
>
>
>>> Thanks for raising this topic and including me.
>>> Suspend to Idle support in Linux as an alternative S3 on x86 is a new
>>> topic.  In all, I expected that some problems would arise as a result
>>> of this patch, and I hope they will spur interesting discussions and
>>> solutions.
>>>
>>> Something that might not be immediately obvious is that by supporting
>>> suspend to idle, new driver bugs are going to be identified for drivers
>>> that don't properly put hardware into low enough power modes for the CPU
>>> to go into the proper state.  Traditionally with S3 the BIOS would be
>>> responsible
>>> for powering devices down before S3 and back up when exiting S3.
>>> This onus is now on the OS.
>
>
> That is fine, but then it shouldnât be the default, until most of these bugs
> are identified and fixed.

Right.

> Also, the commit message should make that more clear, and in my opinion the
> tested devices be listed.
>
>>>> -----Original Message-----
>>>> From: Paul Menzel [mailto:pmenzel@xxxxxxxxxxxxx]
>>>> Sent: Tuesday, January 17, 2017 8:34 AM
>>>> To: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>; Limonciello, Mario
>>>> <Mario_Limonciello@xxxxxxxx>
>>>> Cc: Thorsten Leemhuis <linux@xxxxxxxxxxxxx>; Greg Kroah-Hartman
>>>> <gregkh@xxxxxxxxxxxxxxxxxxx>; Tomas Winkler <tomas.winkler@xxxxxxxxx>;
>>>> Jan Niehusmann <jan@xxxxxxxxxx>; Usyskin, Alexander
>>>> <alexander.usyskin@xxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx; Chen, Yu C
>>>> <yu.c.chen@xxxxxxxxx>; Sarvela, Tomi P <tomi.p.sarvela@xxxxxxxxx>;
>>>> Daniel
>>>> Blueman <daniel@xxxxxxxxx>; Len Brown <len.brown@xxxxxxxxx>; linux-
>>>> pm@xxxxxxxxxxxxxxx
>>>> Subject: Regression on Dell XPS13 (was: [char-misc for 4.10-rc4 V2] mei:
>>>> bus:
>>>> enable OS version only for SPT and newer)
>>>>
>>>> On 01/17/17 09:14, Thorsten Leemhuis wrote:
>>>>>
>>>>> Greg Kroah-Hartman wrote on 16.01.2017 12:05:
>>>>>>
>>>>>> On Sun, Jan 15, 2017 at 11:58:30AM +0100, Greg Kroah-Hartman wrote:
>>>>>>>
>>>>>>> On Sun, Jan 15, 2017 at 07:19:03AM +0000, Winkler, Tomas wrote:
>>>>>>>>>
>>>>>>>>> Subject: Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS
>>>>>>>>> version only for SPT and newer On Sat, Jan 14, 2017 at 08:27:31PM
>>>>>>>>> +0100, Paul Menzel wrote:
>>>>>>>>>>
>>>>>>>>>> On 2017-01-13 14:00, Greg Kroah-Hartman wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Jan 11, 2017 at 03:26:06PM +0100, Paul Menzel wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 01/11/17 15:12, Winkler, Tomas wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 01/11/17 10:24, Winkler, Tomas wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Wed, Jan 11, 2017 at 01:27:21AM +0200, Tomas Winkler
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On older platforms the command should be just ignored by
>>>>>>>>>>>>>>>>>> the firmware but some older platforms misbehave so it's
>>>>>>>>>>>>>>>>>> safer to send the command only if required.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks! This fixes suspend-to-ram for me (on a Thinkpad
>>>>>>>>>>>>>>>>> x201s).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What about Dell XPS13?
>>>>
>>>>
>>>> There is a regression with Linux 4.10-rc{1,2,3} on the Intel Kaby Lake
>>>> device
>>>> Dell XPS13 (9360). Hitting the power button, the light of the power
>>>> button
>>>> never goes off. Pressing it again, nothing happen. Only pressing it like
>>>> ten
>>>> seconds the screen comes back for five seconds, and then it seems to try
>>>> to
>>>> suspend again.
>
>
>> Can you please check if reverting commit 08b98d329165 (PM / sleep /
>> ACPI: Use the ACPI_FADT_LOW_POWER_S0 flag) helps?
>
>
> Didnât the `git bisect` run already take care of that? Anyway, I built
> Linusâ master with the commit reverted, and `deep` is now indeed selected.
> No idea, if something else changed, or I messed up during bisection.

The bisection could turn up the other commit depending on how it converged.

Anyway, I'm going to queue up a revert of 08b98d329165 (I may not be
able to push it before the end of the next week, though) and in the
meantime you should be able to work around the issue by adding
mem_sleep_default=deep to the kernel command line.

We can go back to asking the ACPI tables about what the default should
be when the driver issue exposed by that commit is fixed.

Thanks,
Rafael