X1 Carbon again; Qubes DSDT override?
D. J. Bernstein
ThinkPad X1 Carbon 6th generation (Kaby Lake), 20KGS1QM00, flashed to
BIOS N23ET48W (1.23) 06/01/2018. Happy to do experiments. Previous
threads on this:
https://groups.google.com/forum/#!msg/qubes-users/QrG7uUZsSZY/8qWAdfr1DgAJ
https://groups.google.com/forum/#!msg/qubes-users/c_plaiZZ5pw/jWJuO1gDCAAJ
There seems to be a cross-platform problem and a Qubes-specific problem,
and beyond this I have a general Qubes configuration question. I see how
to handle various specific issues below by compiling my own kernel, but
I'd rather stick to the supported kernels if possible (and, similarly, I
presume that Qubes tries to limit the number of kernel patches).
1. Cross-platform problem: The BIOS on this machine 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
Presumably the kernel will handle this at some point. For the moment,
I've tried kernels 4.14.18 (Qubes R4.0 ISO, under EFI and legacy),
4.14.41 (qubes-dom0-update, under EFI and legacy), and some 4.16.*
(sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable kernel
kernel-qubes-vm, under EFI), without noticing any differences in what
I'll describe. I've also tried kernel parameter "acpi.ec_no_wakeup=1",
which various sources say makes suspend work on this machine, and again
haven't noticed any differences.
I'm currently looking at 4.14.41 (legacy) with acpi.ec_no_wakeup=1;
dmesg says "ACPI: (supports S0 S5)" (I'd like "S3") and
/sys/power/mem_sleep says "[s2idle]" (I'd like "mem").
2. In principle s2idle should be an adequate replacement for S3. This
brings me to the second problem: if I simply try closing the lid, the
machine seems to suspend properly, but then opening the lid doesn't wake
it up, pushing the power button (for less than a second or more than a
second) doesn't wake it up, and pushing other keys doesn't wake it up.
This seems to be Qubes-specific, or maybe Xen-specific. I haven't seen
the same report from people using Arch etc. There are reports of s2idle
consuming too much power, fixed by changing two BIOS options (enable
BIOS assist for Thunderbolt; disable card reader); that isn't the issue
here.
I've tried the usual sequence of /sys/power/pm_test experiments, with no
obvious failures, so the issue could simply be that s2idle is somehow
losing the wakeup events. I don't have experience debugging this. I
tried enabling /sys/.../wakeup for the keyboard and that didn't help,
but I didn't try anything systematic.
I've tried doing a series of 5-second sleeps via pm_test, automatically
stopping when the lid is opened again, but this consumes more power
overall than avoiding sleeps. I haven't tried a power meter; if the
power is consumed primarily during wakeups then 60-second sleeps would
work acceptably.
3. I've instead been trying an alternate approach, namely
* convincing the kernel to enter S3 and
* hoping that the s2idle wakeup issue doesn't apply to S3.
Apparently Lenovo claims that having the BIOS announce S3 support along
with S0i3 support would make Windows fail, and Lenovo won't maintain a
BIOS fork specifically for Linux, but
https://delta-xi.net/#056
explains how to patch the DSDT to announce S3 support, and
http://kernel.dk/acpi.patch
is a streamlined patch that does exactly this. Maybe the easiest way
forward is to apply an analogous ad-hoc patch to the kernel, but, as
mentioned above, I'd rather stick to the supported kernels if possible.
I've disassembled the original DSDT with acpica-unix-20180629, applied
the streamlined patch, reassembled the DSDT into dsdt.aml, and used cpio
to package dsdt.aml into an acpi_override file, as per the delta-xi.net
instructions mentioned above. The next step in the instructions is to
change
initrd /initramfs...
in grub.cfg to
initrd /acpi_override /initramfs...
although my understanding of GRUB configuration says that
acpi /dsdt.aml
initrd /initramfs...
does the same thing more directly. There are success reports for various
operating systems at this point.
This brings me to my general configuration question: Is there a way to
override ACPI data, such as the DSDT, under Qubes?
I started with an EFI installation of Qubes. This boots Xen, which in
turn reads /boot/efi/EFI/qubes/xen.cfg to see that it's supposed to boot
the dom0 kernel. There's a "ramdisk" command in xen.cfg that sounds
similar to GRUB's "initrd", but the documentation
https://wiki.xen.org/wiki/Xen_EFI
sounds like only one "ramdisk" is allowed, and doesn't mention ACPI or
DSDT. Rather than trying to get Xen to run GRUB or another shim, I
switched over to a legacy installation of Qubes, since I knew this would
use GRUB. Qubes, like other Xen systems, sets up grub.cfg as follows:
multiboot /xen...
module /vmlinuz...
module --nounzip /initramfs...
I've tried putting
module /acpi_override
at various locations in grub.cfg, and in particular putting this after
vmlinuz does produce an effect, namely
"kernel panic - not syncing: VFS: Unable to mount root to an unknown-block(0,0)"
which might suggest that I screwed something up with the dsdt.aml or the
acpi_override, but I don't know why patching power-management tables
would affect filesystem mounting. I've also tried putting
acpi /dsdt.aml
at various locations, with no obvious effect---I'm not sure Xen pays
attention to the data that's written by the acpi command.
---Dan
thum...@gmail.com
I basically followed a similar path to you with the same results.
For where to put acpi, I found this page: http://developers-club.com/posts/165897/
I was also concerned that I screwed up the AML file, so I edited my grub to launch a normal kernel instead of the Xen kernel and was able to see the S3 state then.
That does point to Xen doing something differently. I couldn't find any resources directly relating to Xen, but I did find this thread that sounds like it could be related: https://lists.gnu.org/archive/html/grub-devel/2017-03/msg00088.html
I haven't made any progress past that. :(
Best wishes,
--Bo
jdow...@gmail.com
im also very disappointed and sad... i had high hopes for my first laptop upgrade after a long time and the x1c6 is not living up to it.
Basically all fine with linux, changing the kernel parameter to enable s2idle etc solves the suspend issue (i followed the arch linux wiki).
But then with qubes its a nightmare, it gets unbearably hot all the time (5 VMs running just a browser normal office workload) and of course no progress with suspend. Just to let you know the laptop gets so constantly hot all the time ( this is with the latest bios mind you!) that the adhesive on the bottom screen bezel has come off.
So sad.. :(
jdow...@gmail.com
D. J. Bernstein
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
jdow...@gmail.com
I get inspired by people like you to contribute to open source projects.
I followed your guide to the letter and got the results you were describing exactly.
I believe your efforts should be documented in the qubes wiki.
Let me know how you are getting along with the set up, did you try any under volting?
eriked...@gmail.com
I can also confirm initial success with these instructions.
Should we be on the lookout for any other issues with suspend, now that waking up works?
rich...@gmail.com
From a fresh Qubes install, I have compiled the patched kernel and specified the following kernel command options in my /boot/efi/EFI/qubes/xen.cfg file:
acpi_force_s3=5
mem_sleep_default=deep
The system now responds to the power button being pushed or the lid being opened in a sleep state. The pulsing power button light turns to a steady light. So that's nice.
Unfortunately, the system freezes within seconds. Sometimes at the X lock screen. Sometimes it just remains blank.
(Given that this is a UEFI install using the Lenovo Red Hat LiveCD usb disk creation trick, I do not know how to otherwise specify kernel command options at boot. Should I get a menu similar to the GRUB menu I see on a legacy install? Because I don't. I see a row of penguins and then the typical scrolling wall of linux boot text)
Any thoughts?
rich...@gmail.com
By process of elimination, I was able to pinpoint the wakeup issue to sys-usb.
With further testing, I found that removing the USB-C Thunderbolt 3 Controller from sys-usb's device list resolved the issue.
Will test further to see if fiddling with Thunderbolt BIOS assist mode will help. Might a BIOS update might fix this? (The BIOS is on N23ET40W v1.15 from 2018-04-13). Is there a way to update the BIOS without a Windows 10 utility?
Side notes:
1. Despite dmidecode reporting back the proper magic LENOVO and X1 Carbon magic strings, I still need to manually specify acpi_force_s3=5 into my xen.cfg, otherwise the kernel patch does not appear to work.
2. My aside about needing the LiveCD Lenovo trick was irrelevant. I can install from an install disk created with dd, so I don't know what I was doing wrong the first time.
fabio....@gmail.com
http://thinkwiki.de/BIOS-Update_ohne_optisches_Laufwerk_unter_Linux
You basically need to download the BIOS update as ISO image, then use 'geteltorito' to convert it to an image. Then 'dd' it to a USB stick.
rangu...@gmail.com
Turning Thunderbolt BIOS assist on should be the solution.
I had the same issue in Linux and fixed it by turning that on.
aqeel...@gmail.com
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
fiasc...@gmail.com
Dan's notes worked perfectly for me once I remembered to enable thunderbolt assist. Thanks djb!
pkra...@gmail.com
Thank you for the instructions! I would like to confirm the patch still works against 4.14.72.1
The only problem I had with original instruction is that yum didn't want to install another kernel (compiled one) with identical version (one was already installed since I did upgrade first) - I had to increment value in qubes-linux-kernel/rel file and recompile again so my version named as 4.14.72.2.
mark...@gmail.com
hi friends just update the bios and choose the linux sleep option in the bios, the issue has been fixed
richard...@gmail.com
Can confirm. Perform the BIOS update, and enter BIOS configuration at boot:
Config -> Power -> Sleep State -> Linux
I switched xen.cfg default kernel to 4.14.18-1.pvops.qubes.x86_64.
Sleep now works great! Laptop even wakes to XScreenSaver when lid is opened.
Arthur B.
Just updated the bios to 1.34 (N23ET59W) on a 6th gen X1. Set Sleep State to "Linux" and the laptop still does not wake up when the lid is closed and re-opened. Running 4.14.74-1.
Do I still need to downgrade the kernel and patch? It sounded like the bios update would be enough.
arthur....@gmail.com
Ah, still needs to turn on the Thunderbolt assist on as well.