It's been a while since I worked with Hibernation (S4 suspend) on Linux, so forgive me if any of the details is wrong. Hibernation involves booting a "clean" Ke

It's been a while since I worked with Hibernation (S4 suspend) on Linux, so forgive me if any of the details is wrong. Hibernation involves booting a "clean" Kernel and then switching on the fly to the previously stored Kernel after everything is up. 0. This is a highly unusual operation. There is no other code that exercises this scenario of switching form a hot state to another hot state, not even S3 sleep or runtime suspend (AKA s0ix, or PCI D3 Hot) although they are a little similar. You need to completely freeze the hardware (including invalidate every cache, stop all firmware, etc), then switch to the other Kernel and make sure this other Kernel can resume operation from the state the hardware is, which is probably different from the state left at boot or at S3. 1. AFAIK the hardware (BIOS, firmware, etc.) cannot detect this as well as it can detect, for example, S3, so it can not properly react. I know, sometimes hardware/firmware gets in the way, but sometimes it helps by setting state your driver may not otherwise be aware it needs to set. 2. Testing S4 is a pain. Basically if you want to guarantee S4 works you have to put the machine to S4, wake it up, run your whole test suite again, then put to S4 and wake up a few more times and then test again. Some bugs don't show up in the first S4 cycle. 3. Debugging S4 is even worse, since it involves two different Kernels and a lot of wasted time checking for everything. Do you think devs run S4 cycles before sending patches to the mailing list? 4. With machines booting so fast and both S3 and runtime suspend working so well (not necessarily on Linux), there is little reason to even want to hibernate. Seriously, why would I ever want to use S4? 4.5. Colorary: S4 bugs will always be very low priority for the devs I pay, unless I have a paying client explicitly yelling about it. 5. Every driver in your system needs to be properly working. Just a single broken driver may screw everything in your S4 cycles. So unless you're running on a machine where some dev team explicitly tested S4 to make sure it works, then there's a chance it won't work properly. 6. It's not impossible to get this right, it's not impossible to architect drivers so the S4 code benefits from the S3 code. It's not impossible to architect a driver so it's properly initialize and work on whatever state the registers are. But it's just almost never the priority to ensure S4 works. Edit: The driver I worked on was nicely designed and we tried to take advantage of S3 for S4 as much as we could. Still, sometimes an S4 bug would appear and would result in tons of debugging hours just for it. I remember one specific case where the hardware got a new cache and we forgot to invalidate it before switching, and that caused very weird memory corruption. We wasted probably 2 "man months" in debugging hours before the one line fix was committed. We had a client that was doing like 50 S4 cycles in their test procedures, and the bug for some reason would only appear after 2 S4 cycles.