On Wednesday, 1 August 2018 12:04:13 UTC+10, D. J. Bernstein wrote:
> I finally decided to resort to patching the kernel. Suspend now seems to
> work normally in several tests on a Lenovo X1 ThinkPad Carbon 6th
> generation under Qubes R4.0. The idea of the patch is to do
>
> if (sleep_state == ACPI_STATE_S3) {
> *sleep_type_a = 5;
> *sleep_type_b = 5;
> return_ACPI_STATUS(AE_OK);
> }
>
> near the top of acpi_get_sleep_type_data() (right after the "Validate
> parameters" part) in linux/drivers/acpi/acpica/hwxface.c. This has the
> same effect as the DSDT patches running around for this laptop: telling
> the kernel that the laptop supports S3 state (which the hardware _does_
> support---the starting problem is that the BIOS fails to announce this),
> and more specifically that S3 is hardware sleep type 5.
>
> Of course, simply adding the lines above wouldn't be appropriate for
> non-laptops, or laptops where S3 is another hardware sleep type. The
> actual patch is instead triggered by
>
> * DMI reporting this laptop, or
> * "acpi_force_s3=5" on the kernel command line (so users have a
> relatively easy way to handle newer laptops with the same problem).
>
> If this patch survives more tests and review (I'm not a Linux kernel
> expert) then it should be suitable for upstream adoption. I've attached
> the patch, and some notes on how I compiled a patched kernel for Qubes
> R4.0.
>
> Beyond the patch, I've put
>
> mem_sleep_default=deep
>
> into my /boot/efi/EFI/qubes/xen.cfg on the kernel= line for the patched
> kernel, to tell the kernel to use S3 for suspend---otherwise it uses
> s2idle. The importance of S3 vs. s2idle for this laptop is different on
> Qubes from vanilla Linux: there are many reports of s2idle consuming
> more power than S3 on vanilla Linux, but Qubes seems unique in s2idle
> not waking up at all. I don't see a serious argument for s2idle when S3
> is supported, so I'm not sure why mem_sleep_default prefers s2idle over
> S3; even if there's a reason for this, maybe there would be general
> interest in a second patch that disables s2idle on this laptop.
>
> ---Dan
Hi Dan,
I followed kernel-compile-notes.txt twice. The first time failed, the second
time worked a charm with minor changes to the method. These are my notes on the
experience.
Before I proceed, I note that the current version of the qubes-linux-kernel git
on stable-4.14 is 4.14.67-1. This is the version of the kernel that I have
compiled and applied your patch to.
The first (failed) attempted, I was on a fresh install of Qubes R4.0, kernel
4.14.18-1. Compiling the kernel seemed to work, as did installing. Upon boot
and unlocking my hard-drive the system never seemed to get anywhere on the
loading. Upon pressing escape I noticed I was being spammed with a `dracut`
error before eventually it dropped to an emergency shell. A more forward
thinking me would have written down the error message. I simply reinstalled
Qubes R4.0 fresh to start over.
The second (successful) attempt was after I had updated dom0. I was running
kernel 4.14.57-2. I knew that this was an earlier version than the one I was
going to compile so it wasn't going to be an issue (as you've described in your
excellent notes). I doubt updating dom0 had anything to do with the success of
this attempt, instead I did two things differently to your notes:
1. I ran the following command twice, superfluous I presume:
make verify-sources
2. I ran the following command in dom0 after installing:
dom0 $ sudo dracut -f "/boot/efi/EFI/qubes/initramfs-$version.img" "$version"
Paying special attention that the variable $version was expanded correctly.
After adding the kernel parameter:
mem_sleep_default=deep
to the appropriate line in /boot/efi/EFI/qubes/xen.cfg - again as you've
described.
To conclude, I can confirm that your patch works for version 4.14.67-1 of the
qubes-linux-kernel too. That is, standby and wake from standby work as intended
and the command:
dmesg | grep ACPI | grep supports
yields:
ACPI: (supports S0 S3 S5)
on my Carbon X1 Gen 6, i7 8550U.
However, perhaps unrelated, I have noticed the CPU doesn't turbo boost. Running
the following command in dom0:
xenpm get-cpufreq-states
shows that only 13 / 16 P-States are usable with P0, P1, P3 (the turbo states)
clearly as the ones that aren't available.
Regards,
Aqeel
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/473a1a33-a7cb-45e3-8d2b-38fb7802bda0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
