Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I helped fix sleep-wake hangs on Linux with AMD GPUs

nyanpasu64.gitlab.io

Post reply on HN
Print view View original

71–80 of 218 posts

Re: I helped fix sleep-wake hangs on Linux with AMD GPUs

#71

Post by tostiheld »

tgsovlerkhgsel wrote: post #48

AMD GPU linux drivers are (were?) a nightmare in general, and this includes iGPUs in their processors. Sadly, I don't have the impression that AMD is actively working on fixing this. Just to make sure I'm not griping over something long fixed, I took a quick look and instantly found someone with a very similar issue to the one I ran into happening on a semi-recent kernel: https://community.amd.com/t5/pc-drivers-softw…

> It looks to me that if you want to have a working computer under Linux, it's worth the extra cost to avoid AMD.

I think this is a rather hasty conclusion. The popular opinion is the opposite. If you want a working computer under Linux, it's worth it to avoid NVIDIA, especially for laptops. Sure, AMD are not perfect contributors to the kernel, but they are contributing more than NVIDIA[0]. NVIDIA has made some moves recently[1], but the AMD GPUs are still better integrated. Notably since the Steam Deck had been released, the situation has been excellent.

Anecdotally, my laptop with an NVIDIA GPU has many issues that have persisted over the years with things like high idle power draw or frequent straight up crashes, or incomplete Wayland support. My 3 devices that have an AMD GPU (1 desktop, 2 laptops) however, have been working flawlessly from day 1.

[0] https://www.phoronix.com/news/NVIDIA-Contributions-2010s-Ker...

[1] https://github.com/NVIDIA/open-gpu-kernel-modules

Re: I helped fix sleep-wake hangs on Linux with AMD GPUs

#72

Post by nyanpasu64 »

jchw wrote: post #56

Memory management and specifically OOM conditions remain an unbelievably painful nightmare on Linux. It's not like I run into these issues constantly, but I've definitely tried to debug issues like these (unsuccessfully). Ultimately if I OOM a machine I usually wind up installing more RAM, which is wasteful/expensive, but it's pretty clear that handling OOM conditions gracefully is going to be a hard problem for Linu…

Windows says that my motherboard serial port is connected to the Pci Bus → PCI standard ISA bridge. Long live DOS!

Thanks for the video about TTM, I'll watch it when I have a chance.

Re: I helped fix sleep-wake hangs on Linux with AMD GPUs

#73

Post by talldayo »

whatever1 wrote: post #28

Apple became a trillion dollar company by mastering sleeping / waking up of electronic devices. why nobody else sees this?

I think it could be argued that the Mac contributes nearly nothing to Apple's current trillion-dollar valuation. If the Mac was spun out into it's own business it would be lucky to crest a $100B market cap.

Re: I helped fix sleep-wake hangs on Linux with AMD GPUs

#74

Post by nyanpasu64 »

jorvi wrote: post #3

> Through some digging, I found that when a desktop enters S3 sleep, the system cuts power to PCIe GPUs I am not sure how correct this assumption is. S3 is supposed to cut power to everything but RAM, but for example Gigabyte Aorus motherboards are notorious for an NVMe SSD sleep bug that randomly prevents the system from properly sleeping or waking. This is fixed by adding the following udev rule: # Generic PCIe fix…

Hmm, on my motherboard I had to disable spontaneous wake by adding to /etc/udev/rules.d/:

  ACTION=="add", KERNELS=="0000:00:01.1", ATTR{power/wakeup}="disabled"
And my Logitech Bolt receiver wakes multiple of my Linux computers instantly, I don't know why it doesn't do that on Windows and haven't tried doing a USB capture (and don't know what equipment I'd need to try it out, logic analyzer? Glasgow?). In the meantime I've added a rule to block that:

  ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c548", ATTR{power/wakeup}="disabled"

Re: I helped fix sleep-wake hangs on Linux with AMD GPUs

#75

Post by lillecarl »

_cenw wrote: post #57
bachmeier wrote: post #51

Earlier quoted context omitted.

> Sleep & suspend doesn’t work on Windows either. What's strange is that it never used to be a problem. There are five Windows laptops floating around our house at various times (mixture of work and personal) and suspend works properly on none of them. Oddly, it works on my personal laptop with Debian Stable almost every time, failing maybe 1/25 times. Other distros are about the same as Windows.

Modern Standby. Windows wanted to do the Apple "power nap" stuff, but never realized how painful it'd be if you don't control all the hardware and have millions of different hardware permutations (with a lot of terrible drivers) instead of just a few. Not that it would've helped, half the time my machine is either overheating or off it seems to be wake timers doing windows updates (which yes, you can disable, but mos…

I'm super happy with S0 on Linux. The implementation is all about doing as little as possible but effectively remain "on".

Re: I helped fix sleep-wake hangs on Linux with AMD GPUs

#76

Post by itsn0tm3 »

nikanj wrote: post #70
dekhn wrote: post #66

I used to think that naming things, cache invalidation, and off-by-one errors were the 2 biggest problems in CS, but then I learned about the "sleep/wake" problem and realized it's NP-complete.

Only on Linux though, on Windows it’s O(n2) and on Macos it’s O(log n)

Well only as long as you don‘t hackintosh. That stuff used to be a horror sometimes!

Re: I helped fix sleep-wake hangs on Linux with AMD GPUs

#77

Post by jchw »

Skunkleton wrote: post #60
jchw wrote: post #56

Memory management and specifically OOM conditions remain an unbelievably painful nightmare on Linux. It's not like I run into these issues constantly, but I've definitely tried to debug issues like these (unsuccessfully). Ultimately if I OOM a machine I usually wind up installing more RAM, which is wasteful/expensive, but it's pretty clear that handling OOM conditions gracefully is going to be a hard problem for Linu…

I’ve had good luck containing ooms with cgroups. I’m not sure if there is a state of the art for handling oom conditions beyond what Linux does. If anyone knows and can recommend some reading I would appreciate it.

There's really two problems as I understand it:

- Overcommit. Linux will "overcommit" memory: allocations will succeed when there's no memory, and then hang when the page is actually mapped if no physical pages are available (to my understanding.) Windows NT doesn't do this. Not sure exactly how macOS/XNU handles it.

- The OOM killer. Because allocations don't fail, to actually recover from an OOM situation the kernel will enumerate processes and try to kill ones that are using a lot of memory, by scoring them using heuristics. The big problem? If there isn't a single process hogging the memory, this approach is likely to work very poorly. As an example, consider a highly parallel task like make -j32. An individual C++ compiler invocation is unlikely to use more than a gigabyte or two of memory, so it's more likely that things like Electron apps will get caught first. The thrashing of memory combined with the high CPU consumption of compilers that are not getting killed will grind the machine to a near-complete halt. If you are lucky, then it will finally pick a compiler to kill, and set off a chain reaction that ends your make invocation.

There are solutions... Indeed, you can use quotas with cgroups. There's tools like systemd-oomd that try to provide better userspace OOM killing using cgroups. You can disable overcommit, but some software will not function very well like this as they like to allocate a ton of pages ahead of time and potentially use them later. Overcommit fundamentally improves the ability to efficiently utilize all available memory. Ultimately I think overcommit is probably a bad idea... but it is hard to come up with a zero-compromises solution that keeps optimal memory/CPU utilization but avoids pathological OOM conditions by design.

Re: I helped fix sleep-wake hangs on Linux with AMD GPUs

#78

Post by kiwijamo »

xondono wrote: post #36
Apofis wrote: post #23

Earlier quoted context omitted.

Remarkable that it's 2025 and laptop sleep/suspend still doesn't work right on linux. I think the first time I encountered this was probably 15 years ago now?

Sleep & suspend doesn’t work on Windows either. Power control is the kind of stuff that benefits from very tight integration, and PCs just don’t have that. Firmware is seen by most vendors as a pure cost to minimize, so you get a fragmented market full of subcontractors delivering the bare minimum that is considered “working”. Manufacturers also know most people aren’t going to use a big part of the functions they’re…

Even Apple struggled to get it working perfectly in my experience across several models in the PPC/x86 era. Yes they are better(-ish) but when I had Apple laptops I'd still see weird sleep/wake issues in around 1 in every ~50 sleep/wake cycles. I also had one Apple laptop which had its battery going from 100% to 0% overnight during sleep requiring a cold start in the morning on a regular basis despite it being put to sleep the evening before and seemingly going to sleep without issues. Lenovo manages to do sleep/wake fine in Linux almost as well as Apple in my experience and I sleep/wake my Lenovo laptop regularly -- this is across two different models I have used so far (X1 and X390). Hopefully Apple has improved this in their ARM laptops but haven't used them much so can't really comment on ARM.

Re: I helped fix sleep-wake hangs on Linux with AMD GPUs

#80

Post by grayhatter »

lillecarl wrote: post #67
Apofis wrote: post #23

Earlier quoted context omitted.

Remarkable that it's 2025 and laptop sleep/suspend still doesn't work right on linux. I think the first time I encountered this was probably 15 years ago now?

If you have a modern machine with S0 sleep, which is "modern standby" it's very much solved. What it does is it pauses all userspace processes, disables all cores but one and keeps it running on the lowest frequency. The system stays "on" but all devices go in power-saving state which is good enough for days. So it's not really a problem unless you really wanna do deeper sleeps.

> so it's not really a problem unless you really wanna do deeper sleeps.

the way I parsed this was; so it's not really a problem unless you want to use your computer the way you want to use it.

I get things are complicated, and hardware support is a mixed bag. But it doesn't have to be this way.

Post reply on HN