I have the following issue, just noticed this by pure random luck. I have a new Dell XPS 15 9570 laptop with i7-8750H CPU. After putting the laptop to S3 sleep and waking it up, the 8750H CPU enters just C2 anymore for lowest C state. After Windows reboot, everything is normal, until putting it back to S3 sleep and waking up again.
Normal c states after clean Windows reboot (package power 0.6W):
Putting laptop to S3 sleep, waking up, and now CPU is stuck in C2 state as the lowest idle state, and won't enter lower C states anymore: (package power 1.5W):
Windows 10 latest version, all latest drivers installed by Dell.
I talked to Dell, and because I asked, they removed S3 from the 9570 because """it does not support S3""". This is purely disgusting and obviously a lie. I wont ever buy a Dell product ever again.
N.Scott.Pearson I had access to another laptop by Lenovo with 8th gen Intel CPU and it shows the same bug after waking up from S3 sleep under Windows 10 1803. I noticed by random luck, that if you use "hybrid sleep" the bug isnt triggered. Hybrid sleep under Windows 10 means S3+hibernate. I have no idea, why this is, or how it works, but that are the facts. It doesnt make any sense to be, because pure S3 and hybrid sleep both use S3, but just pure S3 triggers this C bug after wake up. So this seems to be a bug with the Intel CPU and/or with Windows 10.
I also noticed another bug after S3 sleep wake up, that from there are random screen flickerings happening, until Windows reboot. It just happens after S3 wake up.
Actually, this makes perfect sense. Let me explain...
In S3 (Sleep), the system goes to a lower power state, one that saves as much power as possible while still ensuring that memory refresh continues and thus memory contents are maintained. Other portions of the hardware will also remain powered. For example, the chipset USB support often remains powered so that keyboard and mouse activity is recognized. In this case, coming out of S3, the BIOS only needs to reinitialize a portion of the hardware (some drivers share responsibility for hardware reinitialization, however). In S4 (Hibernate), on the other hand, the contents of memory are saved to disk and the system goes to an even lower power state, one that does not (need to) power memory. It may still power other hardware (USB, etc.), however. In this case, coming out of S4 is treated like coming out of S5 and the BIOS (and Windows) completely reinitialize the hardware.
So, what's the difference? It should be pretty obvious; it is the amount of hardware reinitialization that needs to take place. What can go wrong? Well, some hardware may not be reinitialized by the BIOS (and the corresponding Windows driver has no support for taking care of this; think of this as the driver essentially having the rug pulled out from under it) or the initialization that is done by the BIOS is not consistent with the driver expectations. Both of these are BIOS and/or driver bugs.
Why does hybrid sleep not incur the same issues? This too should be obvious; resume from S4 is more complete in its hardware reinitialization.
Yes... and no. Of course, I know the difference. That was not what I meant with "it doesn't make any sense". You've mistaken here something. Hybrid sleep is still pure S3, Windows just writes RAM to disk (hibernate) as a backup.
S3 => pure S3 (suspend to RAM) => wake up triggers c state stuck in C2
Hybrid Sleep => S3 + hibernate as a backup => doesnt trigger c state bug
Hibernate => doesnt trigger it too obviously
The wake-up times between pure S3 and hybrid are identical. It seems to be, the only explanation is, that with hybrid sleep, Windows does something else (maybe reset or reinitiate the CPU), which will prevent the c state bug. Or it loads maybe the kernel memory always from disk, where it shouldn't actually.
From the logic point of view, it doesn't make sense. It would make sense if I said S3 compared to pure hibernate, but not S3 compared to hybrid sleep, where hibernate file is just a backup.
Anyway. This mostly seems like a Windows bug or a bug with 8th gen Intel CPUs. S3 is literally useless with this bug with Windows 10.
This is important because S3 is the only reliable sleep. Modern standby is just no option to it, because it drains at least 4x more battery during "sleep" and has a high potential to literally fail with a catastrophic drain.
It seems under Linux it works correctly, I saw people testing it in some Reddit post and this bug doesn't happen under Linux.
Would be nice if someone at Linux could do a reproduce test on a 8th gen core Intel laptop with S3 and Windows 10 1803, and report to Microsoft about this.
klumsch thanks for your original identification of this issue. I have been able to consistently reproduce this bug as well on my XPS 9570. Since your post, Dell has come out with BIOS 1.3.1 and 1.4.1, but unfortunately neither of those seem to solve this problem. I have also noticed the screen flickering issue as well after I have taken my computer out of S3 sleep. In addition to that, I've noticed that taking my computer out of S3 sleep sometimes caused Windows to crash and restart. I'll try to address these independently.
I found that if I installed the Intel display driver directly from Intel's website instead of from Dell's the flickering is fixed. I Googled "intel uhd graphics 630" and found https://downloadcenter.intel.com/product/126790/Intel-UHD-Graphics-630 this page for that driver. Dell has since released an updated version of the Intel driver (188.8.131.5237, A01) on their support page, but it's still an older version than the official Intel one. I haven't tried Dell's updated one since I'm on the newer Intel one (184.108.40.20686), but it's possible that this could have been resolved in Dell's updated one.
C State Bug
I've done a lot of experimenting with this to see if there was some way I could still use S3 sleep and not have the C State bug. I found that whenever I have a device plugged into the Thunderbolt 3 (USB-C) port, the computer will never go into a C State greater than C2. Just for reference, the USB-C devices I've tried are Dell DA300 dock and Dell D59GG ethernet dongle. Once I removed the device, from the port, my CPU would immediately go into deeper C States. I'm not sure if this is supposed to happen or not. This is true even if my computer had a fresh reboot and had not yet been put to S3 sleep.
With that new-found knowledge, I put my computer to S3 sleep and then brought it out. I noticed that it was stuck in C2. However, if I plug in either of my adapters and unplug them, the CPU would again work with C3, C8 and C10 (and sometimes C7). So, it appears that the hardware change forces the driver (I'm guessing) to snap out of its issue. This is not a long term workaround, but it may be enough information to help someone (Intel? or Dell?) to figure out where the issue lies.
Crashing when coming out of S3 sleep
An inspection of Windows' mini-dump upon the crash shows that it was the Intel Rapid Storage driver causing the crash. I had downloaded the newest one from Intel and I haven't had a crash since. Also, Dell has updated the driver on their support site too (though still order than Intel's) and that may have fixed that issue too.
Anyway, I'm hoping this is helpful.
@hjoelr You have to call/email Dell and link this post (also the Reddit post, and countless more posts about this on Youtube ect), tell them what you told me, and tell them, that they have to fix this.
I talked to a Dell person before about this, and he said to me, quote, "Dell won't fix this, because the 9570 hardware doesn't support S3." and that they don't care to fix it too, because "modern standby is way better than S3". You can judge both quotes by yourself, I won't give you my opinion on this. However, of course, it is BS.
Read about it also here:
The best about this is, how Lenovo also removed S3 from their latest laptops, and countless people complained about it here:
And a few weeks ago, Lenovo gave back S3, and ALL were happy. The c state bug isnt happening on the Lenovo laptops btw, I asked a few people to test it. You have to tell that too to Dell. I have little hope on this though because Dell doesn't give a ...
I advise you to never buy any Dell products anymore and advice also everyone you know the same, if they continue to refuse to fix this.
About your findings:
Screen flickering and other glitches
I never use drivers from Dell because they are months ahead, obviously, I always used Intels latest drivers. The funny thing is, people in this forum by Intel will tell you, this is forbidding and a bad thing, because OEM GPU drivers are totally different and edited. I still have glitches with original drivers, sometimes flickers, but also sometimes scrolling isnt smooth anymore for example in Chrome and stutters.
C state bug
I dont have any TB/usb c devices nor ever used any. So.. you see the issue I am forcing now? Mine is broken and I dont have any TB connected. How do you make yours work then? Your finding is amazing though. You HAVE to tell Dell about this. Please. I will try to contact someone at Dell too again about this. I doubt they will do anything about it though. Does it only work for you with plugging in and out a TB3 device? I tested it actually moments ago with a USB 3 stick, and that does nothing. CPU keeps stuck in C2.
Which version do you have? I actually made this thread the other day:
hjoelr Ok, this is getting weird... I actually found a USB3.1 to USB-C adapter I had around, tested your theory with it with a USB 3 stick + adapter in the TB slot of the XPS 9570 after I triggered S3, woke up, c2 stuck bug was triggered... and the result is the following:
- the moment I stuck in the USB-C adapter, C2 got unstuck and lowest energy state now was C3.
- removed the adapter, and C8 worked again normally.
So your theory is totally right. This issue somehow has to do with TB, or it can resolve the stuck c state somehow.
I went into bios and deactivated TB and tried to see if this may be resolved the whole issue, nope, no luck.
And there is a weird issue now. Because this workaround doesn't help 100% in this issue. Look at these two pictures:
The above is AFTER the TB adapter plug in and plug out. You see C8 is still working again... BUT, package power is still broken and around 2-3 higher as it should be of 1.3-1.5W. I noticed an abnormal C0 behavior, look at C0 activity on core0. I went into task manager, and there was no process, all on idle. So the CPU is still bugged after plugging out the TB adapter, just not as much as without the workaround.
This is how it should be (after a clean Windows boot, or with modern standby wakeup):
This will be really hard to explain to Dell customer support if they even bother to listen. Because the moment you say the word S3, they will mostly go on ignore mode and tell you, that this laptop doesnt support S3, which is totally BS of course.
Update: Ok it seems, the abnormal activity on core0 is already triggered the moment you come out of S3, and this is mostly the entire reason, why the CPU isnt going in lower energy state anymore. Why sticking in and out a TB adapter causes it to do it again is mostly another bug. So a bug out of a bug, which doesnt solve the first one.
Normal state (c0 0.x% activity) => S3 => broken state (12% c0 activity on core0, which mostly leads to stuck in c2) => TB stick in/out leads to CPU power logic ignore the 12% and go lower anymore, where it shouldnt actually => the 12% c0 activity stays though the entire time, causing a package power drain.
Is there maybe a way to debug, what is really using something on the CPU? Because neither task manager nor MS Process Explorer show anything. They claim a 98-99% idle, where TS says, there is a 12% c0 usage on core0 happening after S3 wake up.
and everyone else: Dell has published a new bios version 1.5.0 for the Dell XPS 15 9570 with the following change: - Improved sleep mode power management in Ubuntu.
I just flashed 1.5.0 taking the risk, and I can confirm, C2 stuck after S3 sleep is semi-fixed with 1.5.0. The CPU won't be stuck anymore in C2, and C8 works after S3. Yet, the abnormal 8-12% C0% on core0 is still present after S3 wakeup, resulting in a 1.5W drain instead of 0.5W for idle. "Improved sleep mode power management in Ubuntu" was the same phrase Lenovo used for giving back S3, because they don't want to use the word correctly with Windows which is "modern standy on paper".
I found out, that removing a Logitech Unifying (using a MX2s mouse with it) dongle causes the C0% to vanish after about 5-10 seconds, and you have 0.5W package power again... Doing now again S3 with no Logitech dongle, wake up, there is still a 12% C0% on core0 for about 10-20 seconds but then it vanishes from alone and you get 0.5W package power.
Doing some tests, now with Bluetooth for the MX2s (Intel 9260), and I still had a 8-12% c0% on core0 (resulting in 1.5W package power, though c8 works now) after s3 wake up, which didn't go away. The first one was resolved the moment I removed the Logitech dongle. Now I had none connected. I then deactivated BT and in that moment the c0% went away and I had 0.5W package power again. So there still seems to be some bug with USB after S3 wakeup, because BT is connected via USB on the XPS. The c2 stuck issue after S3 sleep is resolved though for me. Sigh... this will be fun, trying to explain to Dell CS. Anyone see the same?
Can maybe someone test around with this too? This will be hard to explain to Dell CS I guess, whats going on now, and that it is not 100% fixed. Maybe a bug in the USB PD firmware, or still some glitch in the bios, related to USB.