You are not logged in.
TL;DR regarding SOLVED-status: We have a working patch for the ACPI DSDT tables, which brings S3 back to the X1. Making that work is a manual process, but not too sticky after all. Here is a short step-by-step write-up to do it yourself, which is probably the safest method. That method brings energy consumption during sleep down from 3-4 watts to sane <0.2 watts. We are still hoping for an official BIOS update since it would be cleanest fix; the issue has been forwarded to Lenovo on different channels. Many thanks especially to fiji-flo and Ranguvar for the great support, you deserve the main credits for making it work.
Update: As confirmed by Ran, the patching procedure also works with the X1 Yoga 3rd gen.
---------------------------------
Hey guys
I just got my new Lenovo X1 Carbon, with an Intel i7-8550U. The system performs exceptionelly well, and it looks like the entire set of hardware devices are seamlessly supported with Arch (except maybe for the fingerprint reader - didn't look into this). However, it seems to drain a lot of battery when suspended.
Update regarding drain: I spent the days with several measurements in various circumstances. Fully booted, 50% brightness, no actual load, active wifi, but without X started, the laptop drains approx. 6.3% of battery per hour, while in s2idle it drains about 4.1% per hour (both include all Powertop tweaks enabled, and all devices in /proc/acpi/wakeup disabled except lid/slpb). For a laptop with potentially very long runtime, this is insane.
From a superficial point of view, on suspend, the system seems to behave exactly as it should: Immediately shuts down everything noticable, including display and fan. Lenovo LED on display front starts blinking, as usual. When its in a soft-case, I can feel a slight warming effect on the inside after some 15-30 minutes (which shouldn't be the case obviously). After ruling the obvious things out (WOL, wakeup-enabled devices, etc), I'm afraid deep sleep is not supported:
$ dmesg | grep -i acpi | grep supports
[ 0.216048] ACPI: (supports S0 S4 S5)
Seems like S3 is missing.
$ cat /sys/power/state
freeze mem disk
$ cat /sys/power/mem_sleep
[s2idle]
According to kernel documentation on sleep states, the latter should actually contain "deep", not only s2idle - so my educated guess would be, that's the problem.
For reference:
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers (rev 08)
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (rev 07)
00:04.0 Signal processing controller: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem (rev 08)
00:08.0 System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen Core Processor Gaussian Mixture Model
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21)
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 (rev 21)
00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21)
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #1 (rev f1)
00:1c.4 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 (rev f1)
00:1d.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #9 (rev f1)
00:1f.0 ISA bridge: Intel Corporation Device 9d4e (rev 21)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (4) I219-V (rev 21)
02:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev 78)
04:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd Device a808
These Xeon-E3 lines look suspicious to me on first sight. Also, grepping dmesg for ACPI gives a few questionable hints, but they don't seem too relevant to me:
[ 221.191391] acpi INT3400:00: Unsupported event [0x86]
[ 221.206349] thinkpad_acpi: unknown possible thermal alarm or keyboard event received
[ 221.206353] thinkpad_acpi: unhandled HKEY event 0x6032
[ 221.206355] thinkpad_acpi: please report the conditions when this event happened to ibm-acpi-devel@lists.sourceforge.net
[ 661.150243] acpi INT3400:00: Unsupported event [0x86]
[ 661.157331] ACPI: button: The lid device is not compliant to SW_LID.
Edit: As another note, I thoroughly looked through all available BIOS/UEFI settings, whether there is any kind of suspend/S3 setting available like on other laptops, but no luck either. The same goes for different kernel options, especially all variants of acpi_sleep and mem_sleep_default - nothing changes.
A laptop without S3 is not applicable for me in any way. Can anyone help me out here, please?
Last edited by esonn (2018-03-05 07:51:05)
Anyone who quotes me in their sig is an idiot. -- Rusty Russell
Offline
Yep, same deal here.
If you check this XPS 9370 guide, the user notes he had to manually set mem_sleep to deep.
There doesn't appear to be such an option for the X1C6 yet, though.
https://gist.github.com/greigdp/bb70fbc … 8eacb85b8f
As for the rest, the cores are entering C7, but the package won't go lower than C3.
I already tried bumping nvme_core.default_ps_max_latency_us, but that doesn't appear to be the issue.
...
Looking through the code, this seems the relevant file: https://git.kernel.org/pub/scm/linux/ke … /suspend.c
'valid_state' is the function that checks if a state is valid for the hardware.
static bool valid_state(suspend_state_t state)
{
/*
* PM_SUSPEND_STANDBY and PM_SUSPEND_MEM states need low level
* support and need to be valid to the low level
* implementation, no valid callback implies that none are valid.
*/
return suspend_ops && suspend_ops->valid && suspend_ops->valid(state);
}
Just below, we can see suspend_set_ops runs that function on PM_SUSPEND_MEM (aka "deep").
void suspend_set_ops(const struct platform_suspend_ops *ops)
{
lock_system_sleep();
suspend_ops = ops;
if (valid_state(PM_SUSPEND_STANDBY)) {
mem_sleep_states[PM_SUSPEND_STANDBY] = mem_sleep_labels[PM_SUSPEND_STANDBY];
pm_states[PM_SUSPEND_STANDBY] = pm_labels[PM_SUSPEND_STANDBY];
if (mem_sleep_default == PM_SUSPEND_STANDBY)
mem_sleep_current = PM_SUSPEND_STANDBY;
}
if (valid_state(PM_SUSPEND_MEM)) {
mem_sleep_states[PM_SUSPEND_MEM] = mem_sleep_labels[PM_SUSPEND_MEM];
if (mem_sleep_default >= PM_SUSPEND_MEM)
mem_sleep_current = PM_SUSPEND_MEM;
}
unlock_system_sleep();
}
Last edited by Ranguvar (2018-03-01 03:07:41)
Offline
Maybe try some new acpi_osi settings, something like this: (disable windows 2000, enable new versions of windows 10)
acpi_osi="!Windows 2000" acpi_osi="Windows 2016" acpi_osi="Windows 2017"
https://github.com/torvalds/linux/blob/ … meters.txt
acpi osi strings v4.15.7
The 2016 and 2017 strings are included in the 4.16 kernel. v4.16-rc3
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
Thanks, good thinking. I just tried various acpi_osi settings with 4.15.5-1-ARCH to no avail. Currently compiling 4.16-rc3, let's see if that makes any difference.
Update: New kernel installed, unfortunately playing around with acpi_osi strings regarding newer Windows versions didn't change anything in 4.16-rc3, as far as I can see. dmesg still only reports ACPI S0/S4/S5, while /sys/power/mem restricts to s2idle.
A few combinations I tried regarding kernel options (with both, 4.15.5 + 4.15.6 where applicable):
acpi_osi=Linux
acpi_osi="Windows 2015"
acpi_osi="Windows 2016"
acpi_osi="!Windows 2012"
acpi_osi=!
acpi_osi=!!
acpi_osi=! acpi_osi="Windows 2017"
acpi_osi=! acpi_osi="Windows 2015"
Moreover, I tried a few things from Intel's best-practices regarding Linux suspend debugging, especially investigating more verbose logstates, i.e.
initcall_debug ignore_loglevel
Nothing of interest caught my eye, however.
Last edited by esonn (2018-03-01 12:15:01)
Anyone who quotes me in their sig is an idiot. -- Rusty Russell
Offline
Thanks esonn. Please update us if you find anything interesting.
Can you post your dmesg with initcall_debug ignore_loglevel?
I found a related thread: https://www.centos.org/forums/viewtopic.php?t=57544
Offline
Sure thing - since the output is of considerable length, grab it from here. The output is from the 4.16-rc3 kernel with the /proc/config.gz from the regular 4.15.5-1-ARCH kernel.
In the meanwhile, I actually suspect it's a BIOS problem and maybe can't be fixed without an update from Lenovo.
Anyone who quotes me in their sig is an idiot. -- Rusty Russell
Offline
Alright, yeah that's only part of the dmesg so I'll try to pull mine, just looking to compare to the X1C5.
Offline
Now as you mention it, all those debugging options probably maxed out the kernel ring buffer. Here is a full version, with only "ignore_loglevel" set.
Moreover, I found a tool called fwts, a firmware tester for a significant range of devices (AUR link). Running it with --power-states parameter gives me the following output:
Results generated by fwts: Version V18.02.00 (2018-02-27 03:05:28).
Some of this work - Copyright (c) 1999 - 2018, Intel Corp. All rights reserved.
Some of this work - Copyright (c) 2010 - 2018, Canonical.
Some of this work - Copyright (c) 2016 - 2018, IBM.
Some of this work - Copyright (c) 2017 - 2018, ARM Ltd.
This test run on 01/03/18 at 17:02:22 on host Linux x1 4.15.6-1-ARCH #1 SMP
PREEMPT Sun Feb 25 12:53:23 UTC 2018 x86_64.
Command: "fwts --power-state".
Running tests: s3power s3 s4.
s3power: S3 power loss during suspend test (takes minimum of 10 minutes to run).
--------------------------------------------------------------------------------
Test 1 of 1: S3 power loss during suspend test.
Detecting the power method.
Response to CanSuspend is yes
User allowed to execute the CanSuspend action
Using logind as the default power method.
Requesting Suspend action
Skipping the minimum delay (0) and using a 3 seconds delay instead
S3 duration = 601.
Change in capacity: 570 mWh
Loss of 3420.0000 mWh per hour.
The 57020 mWh battery will provide 16.67 hours of suspend time.
FAILED [CRITICAL] ShortSuspendLife24hrs: Test 1, Machine cannot remain suspended
for 1 day.
Note: Accuracy of results are increased with longer sleep delay durations.
pm-suspend returned 0 after 601 seconds.
================================================================================
0 passed, 1 failed, 0 warning, 0 aborted, 0 skipped, 0 info only.
================================================================================
s3: S3 suspend/resume test.
--------------------------------------------------------------------------------
Test 1 of 1: S3 suspend/resume test.
Defaulted to 1 test, use --s3-multiple=N to run more S3 cycles
S3 cycle 1 of 1
Using logind as the default power method.
Requesting Suspend action
Skipping the minimum delay (0) and using a 3 seconds delay instead
S3 duration = 31.
pm-action returned 0 after 31 seconds.
Suspend/Resume Timings:
Could not determine time to suspend.
Could not determine time to resume.
Completed S3 cycle(s)
PASSED: Test 1, No kernel log errors detected.
PASSED: Test 1, No PM related suspend issues detected.
PASSED: Test 1, No device errors detected.
PASSED: Test 1, No kernel oopses detected.
PASSED: Test 1, No kernel WARN_ON warnings detected.
PASSED: Test 1, Found no errors doing 1 suspend/resume cycle(s).
PASSED: Test 1, All suspends took less than 15.00 seconds.
PASSED: Test 1, All resumes took less than 15.00 seconds.
================================================================================
8 passed, 0 failed, 0 warning, 0 aborted, 0 skipped, 0 info only.
================================================================================
s4: S4 hibernate/resume test.
--------------------------------------------------------------------------------
FAILED [MEDIUM] NoSwap: Test 1, Cannot run hibernate test - machine appears to
have NO swap.
Aborted test, initialisation failed.
================================================================================
0 passed, 0 failed, 0 warning, 1 aborted, 0 skipped, 0 info only.
================================================================================
8 passed, 1 failed, 0 warning, 1 aborted, 0 skipped, 0 info only.
Test Failure Summary
================================================================================
Critical failures: 1
s3power: Machine cannot remain suspended for 1 day.
High failures: NONE
Medium failures: 1
s4: Cannot run hibernate test - machine appears to have NO swap.
Low failures: NONE
Other failures: NONE
Test |Pass |Fail |Abort|Warn |Skip |Info |
---------------+-----+-----+-----+-----+-----+-----+
s3 | 8| | | | | |
s3power | | 1| | | | |
s4 | | | 1| | | |
---------------+-----+-----+-----+-----+-----+-----+
Total: | 8| 1| 1| 0| 0| 0|
---------------+-----+-----+-----+-----+-----+-----+
I have no idea why it complains about "power loss" during s3power test. However, the calculated maximum time the notebook can remain in suspend mode is quite accurately given and more or less matches my measurements:
The 57020 mWh battery will provide 16.67 hours of suspend time.
The regular s3 test seems to work, but I suspend s3power matches "deep", while regular s3 is the "s2idle" state. I don't care too much about hibernate/s4 (that may change if I can't fix the s3 problem...).
Anyone who quotes me in their sig is an idiot. -- Rusty Russell
Offline
I also have an X1C6, and I ran fwts. Here are my results:
Results generated by fwts: Version V18.02.00 (2018-02-27 03:05:28).
Some of this work - Copyright (c) 1999 - 2018, Intel Corp. All rights reserved.
Some of this work - Copyright (c) 2010 - 2018, Canonical.
Some of this work - Copyright (c) 2016 - 2018, IBM.
Some of this work - Copyright (c) 2017 - 2018, ARM Ltd.
This test run on 01/03/18 at 13:45:23 on host Linux jeremy-arch 4.15.6-1-ARCH #1
SMP PREEMPT Sun Feb 25 12:53:23 UTC 2018 x86_64.
Command: "fwts --power-states -".
Running tests: s3power s3 s4.
s3power: S3 power loss during suspend test (takes minimum of 10 minutes to run).
--------------------------------------------------------------------------------
Test 1 of 1: S3 power loss during suspend test.
Detecting the power method.
Response to CanSuspend is yes
User allowed to execute the CanSuspend action
Using logind as the default power method.
Requesting Suspend action
Skipping the minimum delay (0) and using a 3 seconds delay instead
S3 duration = 600.
Change in capacity: 1070 mWh
Loss of 6420.0000 mWh per hour.
The 57020 mWh battery will provide 8.88 hours of suspend time.
FAILED [CRITICAL] ShortSuspendLife24hrs: Test 1, Machine cannot remain suspended
for 1 day.
Note: Accuracy of results are increased with longer sleep delay durations.
pm-suspend returned 0 after 600 seconds.
================================================================================
0 passed, 1 failed, 0 warning, 0 aborted, 0 skipped, 0 info only.
================================================================================
s3: S3 suspend/resume test.
--------------------------------------------------------------------------------
Test 1 of 1: S3 suspend/resume test.
Defaulted to 1 test, use --s3-multiple=N to run more S3 cycles
S3 cycle 1 of 1
Using logind as the default power method.
Requesting Suspend action
Skipping the minimum delay (0) and using a 3 seconds delay instead
S3 duration = 31.
pm-action returned 0 after 31 seconds.
Suspend/Resume Timings:
Could not determine time to suspend.
Could not determine time to resume.
Completed S3 cycle(s)
PASSED: Test 1, No kernel log errors detected.
PASSED: Test 1, No PM related suspend issues detected.
PASSED: Test 1, No device errors detected.
PASSED: Test 1, No kernel oopses detected.
PASSED: Test 1, No kernel WARN_ON warnings detected.
PASSED: Test 1, Found no errors doing 1 suspend/resume cycle(s).
PASSED: Test 1, All suspends took less than 15.00 seconds.
PASSED: Test 1, All resumes took less than 15.00 seconds.
================================================================================
8 passed, 0 failed, 0 warning, 0 aborted, 0 skipped, 0 info only.
================================================================================
s4: S4 hibernate/resume test.
--------------------------------------------------------------------------------
Test 1 of 1: S4 hibernate/resume test.
Defaulted to run 1 test, run --s4-multiple=N to run more S4 cycles
S4 cycle 1 of 1
Using logind as the default power method.
Requesting Hibernate action
Skipping the minimum delay (0) and using a 3 seconds delay instead
S4 duration = 112.
FAILED [HIGH] DeviceFreeze: Test 1, Failed to freeze devices.
FAILED [HIGH] HibernateImageRestore: Test 1, Failed to restore hibernate image.
PASSED: Test 1, No kernel log errors detected.
Found 2 PM related hibernate issues.
PASSED: Test 1, No device errors detected.
PASSED: Test 1, No kernel oopses detected.
PASSED: Test 1, No kernel WARN_ON warnings detected.
Found 2 errors and 0 oopses doing 1 hibernate/resume cycle(s).
================================================================================
4 passed, 2 failed, 0 warning, 0 aborted, 0 skipped, 0 info only.
================================================================================
12 passed, 3 failed, 0 warning, 0 aborted, 0 skipped, 0 info only.
Test Failure Summary
================================================================================
Critical failures: 1
s3power: Machine cannot remain suspended for 1 day.
High failures: 2
s4: Failed to freeze devices.
s4: Failed to restore hibernate image.
Medium failures: NONE
Low failures: NONE
Other failures: NONE
Test |Pass |Fail |Abort|Warn |Skip |Info |
---------------+-----+-----+-----+-----+-----+-----+
s3 | 8| | | | | |
s3power | | 1| | | | |
s4 | 4| 2| | | | |
---------------+-----+-----+-----+-----+-----+-----+
Total: | 12| 3| 0| 0| 0| 0|
---------------+-----+-----+-----+-----+-----+-----+
Offline
Lenovo forum post, please add "Kudos" and post for visibility.
https://forums.lenovo.com/t5/Linux-Disc … -p/3998182
EDIT: Esonn posted another thread: https://forums.lenovo.com/t5/Linux-Disc … -p/3997789
Last edited by Ranguvar (2018-03-02 02:37:47)
Offline
If you are so inclined, you could try to analyze the acpi tables with the tools from the iasl package or create a kernel bug report, probably in the product category ACPI or Power Management. A firmware update from Lenovo would probably be the cleanest solution, though.
http://bugzilla.kernel.org/
https://01.org/blogs/rzhang/2015/best-p … ate-issues
https://01.org/linux-acpi/utilities
Last edited by progandy (2018-03-01 21:06:00)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
Ranguvar: Sorry about that, should have stated here that I already opened a thread (may boost visibility anyway).
progandy: Thanks for that input. I actually began trying to rebuild the DSDT tables, but I'm currently stuck when trying to recompile the decompiled firmware image due to compiler errors (which is, according to the wiki, a quite usual thing which has to be fixed manually).
Anyone who quotes me in their sig is an idiot. -- Rusty Russell
Offline
In Reply to Ranguvar's thread in the Lenovo forums an employee wrote:
Dear customers,
ThinkPad X1 Carbon Gen 6 supports Windows Modern Standby (aka S0i3) so that ACPI table doesn't specify the support of S3.
So S0i3 is the new thing, I wasn't aware of that. I found a series of blogposts from a girl who had the same issue with a Lenovo tablet running Linux which seem interesting regarding this topic, especially S3 vs. S0i3 and how she got it working. However, the did that on an Intel Atom CPU, which is a different story. The basic idea Microsoft promotes, is that Laptops should not sleep in a traditional way, but more like Smartphones and Tablets currently do (e.g. some devices may quickly wake up the machine for doing stuff, e.g. Wifi). While this idea is not completely stupid imho, I wouldn't need or want that for a laptop.
Unfortunately, that particular tablet has an Intel Atom CPU for which, as it apprears, Linux support for S0i3 exists as of kernel 4.15. I did a quick grep across the sources of 4.16, and to me - as non-kernel-programmer - it doesn't look too promising regarding current S0i3 support for Intel Core CPUs. I hope I'm wrong.
What I think I found out, is that Linux bascially understands S0i3, as it actually is a kind of very low-power s2idle state. The kernel will automatically enter S0i3, if certain preconditions are met, i.e. all devices are ready for it. This means display is turned off and other things. I found a very interesting thread on the pm-linux mailing list, which basically points this out (I know it seems old, but it depicts our problem).
So as far as I understand the current situation, there are three options we may have:
Investigate the pm-linux mailing list advice, assure all devices support ASPM (->lspci -vv) and are in L1 or D3; if everything works, power consumption should go down to <=0.5 watts by itself. A quick check revealed that most devices are ASPM aware (they were not on my x250 btw), but I don't yet fully understand which device states are necessary.
Hack the DSDT table, basically hacking the firmware responsible for announced ACPI power states (among other things). People have successfully done that, but obviously not for the X1C6. I continue to look into that, but oh boy, ACPI machine language looks like way out of my comfort zone.
Continue to tackle Lenovo to provide an alternative BIOS image which brings S3 back. On the forum an Lenovo employee, by now, pointed out that rolling out a new mainline image supporting S3 is out of the question, since it would break Windows power management. So I asked for an alternative image for us poor Linux users - honestly, I don't think chances are too great they're actually falling for that.
Last edited by esonn (2018-03-02 10:40:15)
Anyone who quotes me in their sig is an idiot. -- Rusty Russell
Offline
Hacking the DSDT table is probably our best bet.
I have some experience with DSDT editing from Hackintosh projects, but not a great deal.
Having an S3 BIOS from Lenovo would **greatly** assist, as I could simply diff the DSDT/SSDT files.
Indeed, we could use the normal BIOS, hack a DSDT patch, and have the patch or the full new DSDT load just for Linux, while Windows takes the original.
Offline
As a short-term workaround (but not ideal), I configured the HandleLidSwitch event to hibernate instead of suspend, and changed the behavior of the power button to hibernate instead of suspend. Waking from hibernate on X1C6 is reasonably fast enough for now (though it's much longer than actual S3 or S0i3)
Offline
Ranguvar: I have no experience here (just managed iasl to at least recompile the entire file, but still with dozens of errors). I don't know if that helps you, but I also have access to an X1C5 running arch, which still supports S3 - would it help to give you /sys/firmware/acpi/tables/* dumps from that one?
On a minor note, I had a quick discussion with @Lenovo on Twitter, and they assured me to forward the issue to the developers. However, they also talked about resources and time and testing, which I read as "too less of a priority, go away".
PastExcitement: I haven't yet tried suspend, does it it work out of the box? May be the temporary solution.
Anyone who quotes me in their sig is an idiot. -- Rusty Russell
Offline
Yes! Please do provide your DSDT/SSDT dumps from your X1C5. I was just about to note that would help.
Don't worry about the errors, nearly all non-Apple ACPI tables require some basic patching before they will recompile.
Please copy the entire contents of /sys/firmware/acpi/tables and upload.
If we could have someone with a T480s upload their tables also, that could help to compare across.
Last edited by Ranguvar (2018-03-02 17:25:15)
Offline
X1 Gen5 ACPI tables (and some system info), here you go, Ranguvar! I'll try to find a T480s user. Tell me if I can assist you in any way.
Anyone who quotes me in their sig is an idiot. -- Rusty Russell
Offline
esonn: With a swap partition larger than 16 GB (I used 20 GB = 16 + sqrt(16)), hibernate works successfully in Arch on the X1C6. I followed the docs at https://wiki.archlinux.org/index.php/Po … ibernation which worked well.
Offline
This is ridiculous. You get a totally bloated sleep state, but it is implemented in a way that it is incompatible with a proper deep sleep.
I want my wifi OFF when I suspend and please don't notify me about mails either
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
Linking specifically this blog post, where Nicole Faerber got S0i3 working on a ThinkPad Tablet 10: https://www.dpin.de/nf/finally-s0i3-is- … el-4-15rc/
I'll poke at the ACPI tables after work tonight.
Last edited by Ranguvar (2018-03-02 20:05:36)
Offline
Maybe this is also interesting: https://certification.ubuntu.com/hardware/201712-26045/
It seems like there is a special Ubuntu image for the X1C6... The certification page says there are no issues except this one:
Slow Resume from Suspend
This system does not not meet our performance criteria for resuming from suspend, but suspend/resume is functional and other functionality is not affected.
edit: could someone check if the BIOS version N23ET32W (1.07) is the installed version? And maybe it would help to post the Ubuntu certification link at the Lenovo forum and ask how the laptop got certified...
Last edited by johannesg00 (2018-03-02 21:26:37)
Offline
johannesg00: I think some X1C6 machines might come with N23ET32W (1.07), but mine came with N23ET33W (1.08)
Offline
johannesg00, suspend works, but you get only suspend to idle (That LTS ubuntu has probably an old kernel without any S0ix support) . There is nothing said about a working S3 state...
Last edited by progandy (2018-03-02 21:40:11)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
/r/Sassywhat sent me his T480s dump, but I'm afraid they're corrupted... trying to get a legit one.
Here are the correct T480s ACPI tables.
Last edited by esonn (2018-03-02 23:25:13)
Anyone who quotes me in their sig is an idiot. -- Rusty Russell
Offline