Get the top HN stories in your inbox every day.
jorvi
nyanpasu64
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"
ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c548", ATTR{power/wakeup}="disabled"jorvi
Good tip!
KERNELS=="0000:00:01.1" sounds like an interesting way to do it, since you can target separate functions of the PCI device (in this case: domain 0, bus 0, slot 1, function 1).
VMG
As somebody with an Aorus motherboard who has probably burned a few kWh on this issue, I was really excited to try these solutions - no luck. Thank you anyway!
jorvi
Did you try the general fix? And reload udev rules?
You also have to make sure it applies after the default rules.
You can check if the rule applies once you have everything set up by doing an `udevadm` attribute walk of your SSD device (not partition), and then following it up all the way up the device tree until you see your specific device port (target fix) or PCIe driver subsystem (general fix). Then check if "power/wakeup" is set to "disabled". If it is set to disabled, something else is keeping your device awake on sleep.
For that you can check /proc/acpi/wakeup, and there's also a specific systemd invocation (that I forgot) you can do that shows if your device slept, how long it slept, how much battery was drained, and if your device woke-up, slept or failed to resume, it'll give you a reason.. to the best of its ability.
VMG
Maybe I should have clarified more - I'm using a desktop PC, not a laptop
The system seems to go into sleep state just fine, it just freezes when waking up again
mafuyu
Wow, thanks for this tip! I've been dealing with suspend issues with an X570 Aorus Master as well.
Running `echo GPP0 >> /proc/acpi/wakeup` into a systemd unit at boot solved the issue for me... except the first sleep after a boot would always wake back up immediately.
I applied your udev rule and that issue seems to be resolved as well!
jorvi
This is more so for your future unit file use: did you use `Type=oneshot` and `RemainAfterExit=yes`?
I remember there being some strange interaction with the wakeup behaviour being toggled otherwise. But this could be due to me being on NixOS.
mafuyu
I just did `ExecStart` with `multi-user.target`. That implies the unit is `simple`, so it very well could be sequencing incorrectly at boot and failing. That's a good point; I'll have to keep that in mind!
bArray
> 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.
You would hope that you could probe the hardware to see if it really is in sleep or not, or that re-waking the hardware would not cause issue if it never went to sleep.
Also I would expect that you could send a sleep command to the PCIe device, then try to sleep the bus itself. The to wake you would bring back the bus and then wake the device.
krastanov
sigh, I have been struggling with this issue for a while, but this did not seem to work either. I have documented it here: https://bbs.archlinux.org/viewtopic.php?id=302440
Any further insight you might have on these Aorus wakeup issues? In particular, it seems the wakeup in my case is coming from `.../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:45/wakeup/wakeup6` which does not really mean anything to me.
jorvi
It doesn't to me either, but following a tip from someone higher up the comments you could try
ACTION=="offline", KERNELS=="0000:00:45.6", ATTR{power/wakeup}="disabled"
faraggi
I had this issue and this MB for years I eventually solved it by physically removing a crappy USB C PCIE card I'd bought because my case didn't have any USBC ports.
(Additionally I also previously disabled PCI wakeup buses and haven't touched it again since it's working)
hope that info helps.
gU9x3u8XmQNG
Are these fixes, or workarounds?
lorenzbrun
Author of memreserver (one of the mentioned userspace workarounds) here. I've debugged this a few years back, only public comment I can quickly find is [1]. I also remember some mailing list discussions, but it basically came down to the isuse that Linux didn't have staggered suspend hooks that reliably ran before disks and parts of the memory subsystem were frozen. Apparently this is now possible. Sadly the Freedesktop Gitlab doesn't seem indexable so this knowledge seems to have gotten lost.
[1] https://gitlab.freedesktop.org/drm/amd/-/issues/2125#note_17...
sabujp
This is amazing work! If folks have ever wondered why suspend is so difficult to get working on linux and why debugging it is equally difficult, this is a single datapoint with lots of information about all the things that can go wrong. Even now I have a thinkpad P1G4 where the fans won't turn off automatically unless I turn them off before going into suspend. Recently I also started having crackling issues with my bluetooth headphones after resuming from suspend and had to disable node suspension there also (https://wiki.archlinux.org/title/PipeWire#Noticeable_audio_d...).
Apofis
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?
xondono
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 supposed to provide to OSes, and no one is really checking them, so it’s very common for devices to have only partial support for things they supposedly do.
kiwijamo
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.
stephen_g
I was amazed when I got an 11th-generation Intel NUC and it didn't sleep/wake properly.
I would have expected it with a cheap clone, but this was a fully integrated computer made by the same people who designed and manufactured the processor itself!
I can't remember if it ever fixed it - maybe after a year or two there were finally newer EFI and graphics drivers that fixed the issue, but maybe it never did? In the end I ended up getting a newer machine to replace it anyway and it became my home server so just runs Proxmox now and doesn't need to ever sleep...
mindcrime
> Sleep & suspend doesn’t work on Windows either.
Or Macintosh. My $DAYJOB Macbook sleeps properly about about 2 out of 10 times, at best. Most of the time it fails to sleep and by the next morning when I open it up, the battery is dead. :-(
For comparison, my System76 laptop running PopOS! sleeps perfectly, every time with no issues. shrug
bachmeier
> 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.
jml78
Are there issues in Windows? Sure but if you give me 100 laptops, 80% will do this right without any issue. Maybe 30% of those laptops will work right on any Linux distro without major fucking around with bullshit trying to make it work. Yes those numbers are made up but I have been running versions of Linux since Slackware in the 90s. I still have a desktop with an amd cpu and nvidia gpu that I can’t get to sleep/suspend right. Works fine when dual boated in windows. I just gave up and manually do shit now when using Linux
washadjeffmad
This space is problematic enough that you could reliably segfault 2017-2019 Intel MacBooks by closing the lid before unplugging HID peripherals, preventing suspend (and cooking it in your bag on the commute home).
It also plagues Windows on custom PC builds, even when there are vendor drivers. Not every component plays nicely with suspend states, ASPM, C-sates, load line calibration, etc. And while often the capability exists natively to address issues (in BIOS, Linux, etc), how many people know how to start looking?
janderson215
Hmm I thought that was a feature, not a bug. I used to leave everything plugged and close the lid if I wanted big downloads to keep going or wanted an even quicker start up.
burnte
My custom-build desktop had an issue with the previous AM4 motherboard I had where if you told Windows to hibernate, the entire machine would shut down as normal, but then a few seconds later it'd wake back up by itself and unhibernate. I had to turn off the PSU power switch during those few moments to keep it in hibernate mode. New mobo and that's gone now. BIOS updates never helped. Really odd.
rikthevik
After my (closed) gaming laptop started making annoying Windows noises earlier today, I'm led to believe that it doesn't work properly on Windows either.
It seems like it's basically hardware whack-a-mole at this point. The only reason Apple does it reasonably well is they control more of the stack and they support less hardware. The only reason Windows does it better than Linux is they have more eyes on it.
sour-taste
The reason it works better on Mac and windows is because they're designed to be desktop OSs. On Linux the funding goes to things cloud services and Android use, which decidedly does not include suspension or other desktop features
bongodongobob
It doesn't work right on Windows either to be fair. With a mixed laptop fleet at work, we've just disabled sleep/hibernate company wide because it causes way too many problems.
larrik
That seems like a good way to cook your laptop when you throw it into a bag with the CPU pegged.
lillecarl
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.
grayhatter
> 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.
makeitdouble
Another way to put it: nobody solved this problem, so the next move was to embrace never sleeping and market it as a feature.
Microsoft also went that route with the Surface line, it just never sleeps.
dismalaf
Recent Windows laptops have even more issues. My wife literally never suspends her Windows laptop for this reason. Meanwhile my Intel/Nvidia laptop running Debian works flawlessly (albeit with Nouveau drivers, gave up on the proprietary ones for reasons unrelated to suspend).
caycep
it's arguably not great on windows either... (see Gigabyte Aorus comment above)
trelane
This is highly hardware dependent. Modern hardware is complex enough that it pretty much has to explicitly support Linux or it won't work well.
I have been buying System76 for about twenty years now, and this is has not been an issue for me either.
jamesdutc
It can be really hit-or-miss, and it can be really hard to debug errors like in the post.
A lot of workarounds that are suggested for various issues are also not really viable. Some of the workarounds involve turning off different power-saving modes; however, the point of enabling sleep is often to increase the amount of usable time between charges, and turning off these power-saving modes can often dramatically shorten battery life.
But getting sleep to work (even S0ix!) is not impossible.
I have a bunch of handheld AMD 7840U and AMD 8840U devices that I have installed Arch Linux on: GPD Win Max 2, GPD Win Mini, GPD Win 4, Minisforum V3, OneXPlayer X1 Ryzen. These devices were not designed with Linux support in mind. I would be very surprised if the companies that made them ever tested them with Linux. Yet with just a small amount of work (generally fiddling with `/proc/acpi/wakeup` and `/sys/devices/*/*/*/power/wakeup` to disable sources of spurious wakeups,) I have gotten essentially flawless S0ix support (… on all but the newest OneXPlayer X1 Ryzen.)
(In general, out-of-the-box stock Linux kernel support on these devices is fantastic. Touchscreens work, pen input works, wifi and Bluetooth work well. The only gap I've seen is fingerprint reader support.)
I suspect that given how small these manufacturers are (and how small their production batches must be,) there's much less extreme-customization and tight-integration of components. This is visibly evident in the form-factors of these devices, which many millimeters thicker than they might otherwise be. (Of course, these devices are primarily advertised to a gaming audience who are eager to avoid the thermal-throttling that happens with ultra-thin devices like Surface Pro…) I partially suspect that the lack of extreme-customization, the lack of tight-integration, and the smaller production batches means that the manufacturers make much more conservative choices in components. Maybe this explains the exceptional Linux support?
hasperdi
Hi, do you have these tweaks published somewhere? I'm particularly interested in knowing your GPD Win Mini tweaks.
Thanks
fulafel
To add: for the end user, the way to easily get working suspend is to buy known-good compatible hardware.
It's been solid on every business Thinkpad for a long long time for me and consistently seems people on Windows with the same models have more sleep problems.
Gormo
My sincere personal thanks for this. My main laptop is a Ryzen-based ThinkPad running Linux that I suspend and hibernate regularly, and I sporadically encounter this issue. Looking forward to 6.14!
imp0cat
This. Thanks a lot!
mkesper
Why was dm->cached_state storing -12 instead of a pointer? Most likely this happened because earlier during suspend, dm_suspend() assigned dm.cached_state = drm_atomic_helper_suspend(adev_to_drm(adev)). The callee drm_atomic_helper_suspend() could return either a valid pointer, or ERR_PTR(err) which encoded errors as negative pointers. But the caller function assigned the return value directly to a pointer which gets dereferenced upon resume, instead of testing the return value for an error.
One more point for rust in the kernel. Just can't happen if you're required to handle a Result type.
vlovich123
You can also get algebraic sum types in C with the C preprocessor: https://github.com/Hirrolot/datatype99
But of course defaults matter and the kernel’s rich history of not modernizing coding practices is going to work against improvements in C land. Ironically, it’s that same resistance that frustrates the Rust devs so much because their resistant to even cleaning up their own subsystems or putting down markers documenting how the subsystems are supposed to work.
Maybe https://github.com/llvm/llvm-project/issues/74205 would help once it trickles down into the kernel, but I suspect that people are still going to choose to do this manual overloading of the pointer instead of using types for safety.
jph
Your work will help me on a Framework AMD laptop with the GPU extension and dual boot Linux/Windows. May I donate to you or to your favorite charity? My contact info is in my profile.
lelandfe
Love this!
dekhn
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.
verall
I think sleep/wake is a subset of cache invalidation - if all peripherals were stateless, probably it wouldn't be an issue.
nikanj
Only on Linux though, on Windows it’s O(n2) and on Macos it’s O(log n)
ncann
With how much trouble I had with trying (and failing) to make my brand new Dell laptop sleep properly and not the "Modern Standby" crap, plus my desktop randomly breaking GPU hardware acceleration in browser after waking up, I would say it's around O(n4) now. Or maybe even O(n!).
itsn0tm3
Well only as long as you don‘t hackintosh. That stuff used to be a horror sometimes!
0x38B
Remembering the hours I spent going through KEXTs and bootloader config in ill-fated attempts to set up a Hackintosh fills me now with a kind of horror. Worst of all were the ACPI tables - SSDT and the like.
In contrast to that, running MacOS in a VM is heaven. Figuring out how to pass my iPhone through to Xcode took as long as the initial setup.
jchw
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 Linux to solve into the future.
This is really great work and will serve as a reference point for debugging similar issues in the future. Pretty happy about systemd's debug-shell feature, I had no idea that existed. I don't think my X670E Steel Legend board has a serial header anywhere on it, though. How do modern built-in serial ports work, anyway? Are they attached off of the chipset PCIe lanes?
Something that's also very useful when trying to dive into the Linux kernel is that there's a bunch of great talks discussing Linux kernel subsystems from conferences like FOSDEM and Linux Plumber's Conference which you can usually find recordings of online. For example, there's this one for TTM, the memory subsystem that most of the desktop GPU DRM drivers use:
nyanpasu64
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.
Skunkleton
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.
jchw
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.
fc417fc802
> two problems ... overcommit
Is there any other sensible way to do this though? It would be quite inefficient to constantly call mmap for additional small(ish) pieces of memory. In effect overcommit just means that until the page is actually written to it hasn't really been allocated. (Aside: I believe a malloc implementation that zero'd out blocks on allocation would fail abruptly rather than later in case that happens to be what bugs you about it.)
Additionally how do you suppose fork should be implemented efficiently? Currently it performs copy-on-write. At minimum you'd need a way to mark pages as "never going to write to these, don't reserve space for a copy". Except such an API is either very awkward to use in practice or else leaves you with some very awkward edge cases to deal with in your program logic.
> You can disable overcommit, but some software will not function very well
Yeah about that.
Chromium runs (AFAIK) 1 PID namespace per tab. On my machine right now it reports 1.1 TiB virtual memory with a little over 100 MiB resident per tab. 1.1 TiB mapped PER TAB. Of the resident I have no idea how much is actually unique (ie written to following the initial fork).
Firefox is much more reasonable at a mere 18 GiB mapped per PID.
Avamander
> Memory management and specifically OOM conditions remain an unbelievably painful nightmare on Linux.
Yes. It's horrendous to put it mildly. Linux does not handle OOM conditions properly.
I know I can set up a few guardrails with cgroups. I know I can also install earlyoom. I know I can increase swap or use zram. In the end these are all fundamentally just nasty hacks that might spare one once in a while. They do not fix how these conditions are handled. Please do not offer these as solutions.
I've seen LUKS volumes mount themselves read-only because the kernel couldn't allocate memory in dm_crypt, for the love of god just kill something in userspace. The current state is utterly unacceptable and I'm tired of all the excuses.
jorvi
Have you been running zswap / zram?
With zstd you can turn 8GB of RAM into 20GB of 'RAM' without much issue. or 16GB into 40GB. Hell, if you're feeling adventurous (and Android does this, so its very stable) you can overcommit your memory past 100%.
dralley
Fantastic news. AMD's linux graphics drivers have mostly worked great for me but this has been the one exception that I've hit multiple times.
MegaDeKay
My luck has been a little less good. Latest problem I'm having is the driver spamming my logs after waking from sleep with "[drm] scheduler comp_1.0.n is not ready, skipping" after "WARNING: CPU: 12 PID: 11871 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:100 generic_reg_update_ex+0x1d2/0x290 [amdgpu]"
juujian
Same great experience, but I experience similar issues when I disconnect thunderbolt with monitors when my machine is asleep. Laptop though, so very different driver set, no GPU via pci
jorvi
You can probably write a udev rule for the Thunderbolt / USB-C port with either ACTION=="offline", "remove" or "online".
"offline" is for when your system turns off or suspends, "online" vice versa, and "remove" is self-explanatory.
If you go with "offline", I'd look into hard disconnecting the monitors. This might cause monitor rearrangement (= you'll need to manually assign) or blinking on laptop bootup. Might also stop any charging. But that could be mitigated by checking the "subsystems" attribute.
If you go with "online", you probably need run some sort of clean-up / refresh script or rule
If you go with "remove", you'll need the same clean-up / refresh script.
It'll take some trial-and-error, but it'll be satisfying once it works. Also highly recommended to check the NixOS repositories and official wiki and Arch wiki to see if your laptop or monitors have workarounds for their quirks.
dado3212
> So I did the natural thing: I saved and extracted the amdgpu.ko kernel module, decompiled it in Ghidra, and mapped the location of the crash in dm_resume to the corresponding lines in the kernel source.
This is always my favorite part of debugging.
Daunk
For all the years I've been using Linux, I've always had some kind of sleep issues. I've used Intel, AMD, ATI, and NVIDIA hardware across countless distros and setups, yet nothing seems to make a difference, there's always something that doesn’t work properly with sleep or hibernation.
Honestly, it's one of the main issues I wish the Linux community would take a closer look at and finally fix!
kiwijamo
Interestingly sleep/wake is something I've found to work almost always just fine out of the box in Linux, including on machines Windows has sleeping issues! It used to be quite bad but things has improved heaps over the last 10 or so years -- however I've also stuck with Lenovo laptops which does generally seem to have better support in Linux.
kristianp
I agree, I have a Thinkpad with Intel processor + nvidia GPU purchased in 2023 and I have not had sleep issues. Ubuntu 22.04.
The nearest thing to a sleep issue is that the screen is visible for a fraction of a second on some wakeups before the lock screen covers it. A bit of a privacy issue.
Good to see that AMD might be getting better support, in part because of its growing popularity.
freedomben
Indeed, whatever Lenovo has seems mostly good. Not perfect, but does the right thing 19 out of 20 times, maybe more. Unfortunately that one time it doesn't work and roasts in my backpack it's a catastrophe :-(
Narishma
I think it it's because there are too many subsystems involved in sleep/resume all being worked on as independent projects (kernel, drivers which sometimes have both kernel and user space components, init system, display server, desktop environment, probably others I'm not aware of). That said, I've had my share of sleep issues on Windows as well over the years, I suspect for the same reasons.
cutty_wise
[dead]
1970-01-01
This. Linux users must resort to bronze-age tooling in 2025; Crafting and launching handmade scripts by candlelight to diagnose their plethora of sleep issues. But the community likes it this way. Meanwhile, Mac users continue to have sleep that 'just works' and Windows users have an entire sleep troubleshooting toolkit:
https://learn.microsoft.com/en-us/windows-hardware/design/de...
nyanpasu64
I once ran into a corporate laptop that had been downgraded from Windows 11 to 10, that would burn up its CPU during Modern Standby and eventually enter hibernate after burning a good fraction of its battery. The sleep study identified various PCIe devices and I tried installing drivers but they did not help. I wonder if it would've worked better on Windows 11 with stock drivers.
nyanpasu64
Update: I upgraded to an Intel Arc B570 GPU... and ran into the exact same problem on an independent driver: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/4288
KronisLV
Oh hey, another Intel Arc user! I got the LE B580 and so far it's been a pretty good experience for me, though I don't really use suspend.
Also I got curious about your blog (haven't heard about Zola, recently migrated my own blog over to a newer version of Grav, which is a flat file CMS with no DB) and saw your post about looking for a new job. Hope things work out for you, stay safe!
nyanpasu64
All the non-scalped B580s were out of stock by the time I decided to buy a GPU :( Thanks for the moral support!
Get the top HN stories in your inbox every day.
> 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:
or more targeted: You can find any glitched PCIe wakeup device with: You also have the option of: but for that you need to know some basic identifier of your glitchy device.Or if you want to shellscript it (less reliable than letting udev do it for you and needs to be done via systemd service file or another automation):
Yes I really hate this (and other) Linux sleep issues.