Would you be willing to post the relevant section of your configuration.nix?
I ask because when I look at my nixpkgs I’m only seeing sections like pkgs.linuxPackages_4_14 and pkgs.linuxPackages_4_9. A few others, too, but nothing even close to the 4.19 series.
I don’t think we ever did.
What I think we accepted as normal is that we have very little power to change things like this, and that consumer hardware vendors don’t really much care about Linux users.
I don’t think there is anything specific in my configuration that sets that. I’m using the default linux kernel via nixpkgs commit 19b9dd603a2. (I build my systems based on whatever nixpkgs master I pull when I want to update something.)
Unfortunately, no good. Not only will X not start, but the system froze the first time it went to sleep.
Fingers crossed for the new 5.4 kernels…
Unfortunately, no good. Not only will X not start, but the system froze the first time it went to sleep.
Fingers crossed for the new 5.4 kernels…
No idea how similar are BIOS/ACPI problems for various Thinkpads…
Observations on W530:
I have a Lenovo T495, and it’s the exact same CPU. I had the same issue (even with the latest 5.4 kernel built manually).
Do you use a WM/DE built upon Xorg or Wayland ? When I switched from Xorg to Wayland (i3 to sway) it started to work smoothly : no more issue with sleep.
Today, if I put to sleep while being on a Xorg dummy session (with xterm only to type systemctl suspend) I reproduce the issue most of the time. On Wayland I cannot reproduce the issue, and it works pretty well.
Do you use a WM/DE built upon Xorg or Wayland ? When I switched from Xorg to Wayland (i3 to sway) it started to work smoothly : no more issue with sleep.
Today, if I put to sleep while being on a Xorg dummy session (with xterm only to type
systemctl suspend) I reproduce the issue most of the time. On Wayland I cannot reproduce the issue, and it works pretty well.
Hm, good question; I alternate between running Xorg and just an fbterm, the last hang was with a text VT in the foreground and VT7 with Xorg in the background, and I don’t remember whether the previous one was with Xorg in foreground or from fbterm with no Xorg. Will try to experiment with that, thanks.
Are you guys using kde plasma by any chance or possibly something with heavy desktop effects ?
I had the similar issue on a ryzen 7 3700u laptop, where sleep would hard fail and temp bricked the laptop requiring a hard power cycle but after doing a bit of debugging I ended up disabling the plasma compositor (and now have no fancy desktop effects) but sleep works fine. Good luck !
I was not using Plasma back then, I was using i3 without any compositor main of the time (and for my reproduction setup I’m literally using a barebones X with only xterm). So I do not think this is related to heavy compositors. (When I needed composition on xorg, I was using compton, and I was still experiencing this issue). If this is indeed related to xorg, I believe a compositor can make the effect worse. (If you are experiencing a 50/50 chance to recover from sleep, you could be at 80/20 for instance).
Another thing to check : are you using the “full” amdgpu driver for Xorg or are you using Xorg with KMS ? (One way to know is to check if vaapi is enabled correctly using vainfo command : if you do not have vaapi, you might be using KMS).
I’m pretty sure i’m using the open source drivers, unless official drivers are now shipped and used by default. I’m also not forcing nomodeset so i reckon kms is used by default.
amdgpu is the open-source driver 
it has to be manually installed on nix when using Xorg though.
Do any of you know anything about the C6 sleep state?
On transit away from my machine at the moment, so no links, but I did a lot of reading last night about how a bunch of amd processors shipped with bugs that were alleviated by not allowing the machine to go all the way to C6. AMD supposedly solved this on sone processors, but I didn’t see many satisfied folks…
Unfortunately, not that many answers on the solution in terms of kernel parameters. There is apparently a python app called ZenStates that will disable it. But I read some of the code and it seems to involve writing special opcodes to /dev/cpu*. Unfortunately, no such devices on my machine, and I’ve not investigated deeper yet.
I also saw stuff about buggy “iommu”. And another rather esoteric. (and so not memorable to be right now) set of parameters that might disable C6.
I’ll dig into all of these more on my own, but I would definitely welcome advice if y’all know more.
I do not know about C6 sleep state, I’ll do some research.
If it is CPU related : Maybe using microcode update can help ? I use the latest AMD microcode updates (hardware.cpu.amd.updateMicrocode = true;).
I use ZenStates with my Zen 1 CPU. Before incorporating it via systemd, I would get system hangs quite regularly. That said, I do have /dev/cpu/* so it may well not apply for your newer CPU.
I think I finally fixed it. I tweaked more kernel parameters and now haven’t had the system crash in five or six days.
C6 wasn’t the answer in my case. The msr kernel module gave me /dev/cpu/*, so I was able to play with ZenStates… however even that did not completely fix the problem. Plus, every time my system woke back up, C6 got re-enabled.
iommu=soft fixed one warning I was seeing during bootup, and may have been related.
But the parameter that magically fixed everything was idle=nomwait. I don’t understand why, but after adding that parameter I haven’t had any glitches at all.
It’s been a few months since my last update. The last change, iommu=soft made things better, but I still usually get a crash once every other day.
But two weeks ago, I spent time at a retreat and despite waking my machine many times, I had not one crash or network drop in four days.
Correlation != causation, but it makes me really wonder if something is broken in the iwlwifi driver.
For the last few days, I’ve been running with a script that theoretically unloads the wifi driver and terminates wpa_supplicant before sleep, but that doesn’t seem to help, either. Kinda at my wits end on this. 
At this point, I’ve exhausted all ideas. I have not one single lead to go on.
Thinkpad x395 HIGHLY DISRECOMMENDED. I don’t know if it’s janky hardware with the AMD chipset, or bad Linux support, or whatever, but this machine can’t hold an internet connection and can’t reliably wake back up from sleep, so… it’s a very expensive failure as a Linux machine.
Maybe test another distribution like Arch Linux or even Windows? ( Arch: Up-to-date kernel and driver (amdgpu))
Arch Wiki:
Lenovo ThinkPad X395
[1] Laptop/Lenovo - ArchWiki
[2] https://support.lenovo.com/us/en/downloads/ds540046
For the unstable hardware connection, is your WiFi card an Intel one ? If it is an Intel Corporation Wireless-AC 9260 you must use a kernel that is at least 5.5. An issue (that made the hardware crash completely) happened on high wireless traffic before this version.
For the AMD part on my T495, the sleep issue was directly related to the compositor (for me). Plasma fails completly (black screen when waking up), all wayland compositors didn’t show any problems (always recovering from sleep flawlessly).
(I’ve noticed that randomly I loose the webcam when raking up, but that’s not a blocker for me.)
(I’ve always been on fwupdmgr testing since I need it for the fingerprint reader).
WIFI is exactly that model. At least I know now that a future OS version will have a kernel that supports this thing correctly.
However, I disabled the compositor, rebooted the machine, saw the degraded visual performance… and almost immediately got a wake-from-sleep crash, so I think I can rule that out, too.
The thing is, when my machine fails to wake-from-sleep, it is a thorough crash. The screen is blank, sure, but the power button doesn’t restart the machine, and the mute and microphone mute buttons, which have lights on them, don’t respond.