Re: suspend-to-mem broken by eed4d47efe95 (ACPI / sleep: Ignore spurious SCI wakeups from suspend-to-idle)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 5, 2017 at 11:14 PM, Dominik Brodowski
<linux@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Mon, Jun 05, 2017 at 10:32:15PM +0200, Rafael J. Wysocki wrote:
>> On Mon, Jun 5, 2017 at 5:09 PM, Dominik Brodowski
>> <linux@xxxxxxxxxxxxxxxxxxxx> wrote:
>> > On Mon, Jun 05, 2017 at 03:08:57PM +0200, Rafael J. Wysocki wrote:
>> >> On Monday, June 05, 2017 11:05:21 AM Dominik Brodowski wrote:
>> >> > unfortunately, commit eed4d47efe95 (ACPI / sleep: Ignore spurious SCI
>> >> > wakeups from suspend-to-idle) breaks suspend-to-mem on my Dell XPS 13
>> >> > (9343) up to v4.12-rc4: Issuing
>> >> >
>> >> >     $ echo "mem" > /sys/power/state
>> >> >
>> >> > in the initramfs returns, after a while, with "write error: Resource
>> >> > busy", and the system *not* having entered the sleep state in between.
>> >>
>> >> Why initramfs?
>> >
>> > Easiest and quickest to test, with no userspace in between to interfere.
>> > During normal operations, I see suspend-to-mem fail, then a fall-back to
>> > s2idle...
>>
>> I see, OK.
>>
>> >> > In contrast thereto, 8a537ece3d94 (PM / wakeup: Integrate mechanism to abort
>> >> > transitions in progress) still works fine, and allows to enter
>> >> > suspend-to-mem. No real difference is to be seen in dmesg, with the notable
>> >> > exception of
>> >> >
>> >> >     ACPI: Low-level resume complete
>> >> >     ACPI : EC: EC started
>> >> >     PM: Restoring platform NVS memory
>> >> >     Suspended for N.NNNN seconds
>> >> >
>> >> > only showing up on working kernels. Reverting eed4d47efe95 on top of
>> >> > v4.12-rc4 restores suspend-to-mem to work as expected.
>> >>
>> >> I'm sure it is not necessary to revert all of it.
>> >
>> > Thought so, just wanted to confirm that eed4d47efe95 is indeed the culprit.
>> >
>> >> I guess what happens is that you get a wakeup event during suspend which is
>> >> aborted as a result.
>> >>
>> >> Please apply the partial revert below and see if it makes the issue go away.
>> >
>> > Yes it does -- with this patch applied on top of v4.12-rc4, everything works
>> > as expected. Both in initramfs and during normal runtime operations. Only an
>> > (probably unrelated) issue still appears during resume, namely "cache"
>> > complaining that the non-boot CPUs should not be sleeping:
>>
>> That's unrelated.
>>
>> OK, this still leaves us with three possibilities.
>>
>> Can you please try to apply the device_pm.c part of the partial revert
>> alone and see if that helps (and if not, same for the button.c and
>> battery.c changes)?
>
> Indeed, the device_pm.c part of the partial revert helps on its own.
> For completeness, applying only the chunks for button.c or battery.c
> does not help;

That's kind of expected. :-)

Anyway, I decided to revert commit eed4d47efe95 entirely as it turns
out to be premature and causes too many problems to happen all over.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux