On Thu, Sep 06, 2018 at 11:27:26AM -0000, D. J. Bernstein wrote:
> [Sent mid-August to the devel@xxxxxxxxxx mailing list and to the three
> listed ACPICA maintainers. Didn't see it on the mailing list, and didn't
> hear back when I asked mailman@xxxxxxxxxx. Now trying linux-acpi. I'm
> watching the list so please don't cc me on replies.]
>
> On a current Lenovo ThinkPad X1 Carbon 6th generation (Kaby Lake), the
> BIOS announces only "S0i3" ("Windows Modern Standby") support and not S3
> (normal suspend) support:
>
> https://wiki.archlinux.org/index.php/Lenovo_ThinkPad_X1_Carbon_(Gen_6)
> https://bbs.archlinux.org/viewtopic.php?id=234913
> https://forums.lenovo.com/t5/Linux-Discussion/X1-Carbon-Gen-6-cannot-enter-deep-sleep-S3-state-aka-Suspend-to/td-p/3998182
> https://delta-xi.net/#056
>
> The information from the BIOS is inaccurate: the hardware does in fact
> support S3 as hardware sleep state 5. The primary purpose of this patch
> is to correct the wrong information from the BIOS on this laptop (as
> identified by DMI). The secondary purpose of this patch is to add an
> "acpi_force_s3=5" command-line option that lets users manually specify
> the same thing on other machines.
>
> Why is this important? Answer: When the kernel doesn't know that the
> laptop supports S3, it falls back to using s2idle for suspend. However,
> as the above links show, Linux users see much higher power use on this
> laptop with s2idle than with S3. Also, for those of us running Linux
> inside a VM in Qubes, wakeup from s2idle seems to fail on this laptop.
> Presumably the wakeup bug will be found and fixed at some point, and
> perhaps s2idle (and/or S0i3) will someday use as little power as S3, but
> at least for the moment it's much better to have traditional S3 support.
>
> Why doesn't the BIOS accurately report S3? The Lenovo answer is simply
> that this breaks Windows:
>
> https://forums.lenovo.com/t5/Linux-Discussion/X1-Carbon-Gen-6-cannot-enter-deep-sleep-S3-state-aka-Suspend-to/m-p/3998636/highlight/true#M10573
>
> As the above links also show, Linux users have converged on overriding
> the ACPI DSDT for this laptop to enable S3. However, my understanding is
> that there's a preference to eliminate ACPI overrides in favor of kernel
> patches (for fairly obvious reasons), and that this preference is strong
> enough that it doesn't need justification.
>
> I haven't done much Linux kernel programming, so please check carefully
> for any coding issues, and please feel free to fix anything that's
> wrong. For example, should the DMI information be prioritized over the
> command-line option? I don't see a serious argument one way or the
> other, and I didn't find any documentation of Linux conventions on this
> topic. For the patch the answer is yes, but feel free to fix if it
> should be the other way.
>
> What bothers me more is that I haven't found documentation of how this
> sort of thing is supposed to be tested. It seems to work on the laptop
> where I'm typing this, and some other people have reported success:
>
> https://marc.info/?l=qubes-users&m=153311827308201
> https://marc.info/?l=qubes-users&m=153356792316425
> https://marc.info/?l=qubes-users&m=153402652424867
The problem here is that the S3 path which may accidentally work may
break something else because it was never tested by Lenovo. So we
suddenly start getting bug reports of issues that are caused by forcing
S3.
I would rather try to get Linux s2idle to work as well (and better) than
Windows :-)
One thing that consumes quite lot power are the two Thunderbolt ports on
that system. They are always present (unless you go and switch to legacy
Thunderbolt mode from the BIOS) so they need to be powered off when
idle.
If it helps, I'm working on that currently and planning to send out a
patch series later today that allows the Thunderbolt ports to power off
during s2idle and runtime.
