Official ASUS Response to Resume/Hibernate Problem with Internal PLL Voltage Enabled

Hey @therat,

Thanks for jumping in. I tried exactly what you suggested, and I still get a wake from sleep if I resume quickly after putting my rig to sleep but anything that goes on for more that say 1 hours (give or take) starts up for 3 seconds, and then powers off.

I reset the bios, cleared the cmos and then only set what your changes were. Still won't wake from sleep.

I wish this would get fixed.

For some reason I feel it's either my power supply (AX-850) or my GTX580 graphics card. Those are the only two changes I have made to my system.

Any other suggestions?

corban
 
The Sleep issue is still not solved.
No one yet has accepted or confirmed officially that this problem exists (be it Intel, MS, Asus, Gigabyte or the others).
...
In conclusion: to stay on the positive side, the p67 is a big mess so go for a Z68.
Pierre

Hi,

We (=Intel) confirmed that "Override PLL Voltage" option in BIOS is incompatible with "S3". Actually this thread started with a post saying Intel confirmed that. We've did so publicly at the end of 2010.

I know this is somewhat ugly limitation, but we had no other option. It only affects people that want to overclock Sandy Bridge to >4.5GHz or so, and it only prevents S3 sleep state, still allowing S4 (hibernate to disk).

Actually, BIOS can still allow S3 sleep, but it must "forget" about extreme overclocking at S3-resume. Maybe this explain some "success stories" you have. No one will be able to S3-resume to >5.1Ghz, on any Sandy Bridge processor.

I've put this limitation in the first place. If you want more in-depth explanation, I can provide it.

Doron
 
OK.

As Sandy Bridge is a completely new product, designed from scratch, with new partitioning (iMC, PCIe, GFX, Media all on CPU), you can understand we were very busy get things on time, and overclocking was pushed aside. We've (=me) implemented overclocking features very late, and were focused on the digital part only (get the logic things done right). Only very late, after the final stepping (D-2) was out, we've started testing the analog part.

Very quickly we've detected a wall at 5.1GHz. Full "2D shmoo" on all voltages and temperature combination did not help. Few months later, when people got their critical tasks completed, we got the breakthrough we needed, related to PLL design. Basically we needed to update some voltage driver inside the PLL, and some more (this is why this is called PLL voltage override).

The thing is, that the PLL does not like this being changed when locked. It took some time to find (=hack, crack, whatever you want to call it) a flow that works, trust me it was not trivial, BUT it involved Warm Reset. So the flow is that we do Cold Reset, then BIOS detect unlimited overclocking support exists, check the user option, and if enabled, it write magic number (0x00060606) to some register somewhere, and issue Warm Reset. After that reset BIOS can use high frequencies, all the way to ratio 59 (another hack; originally it was 57).

The thing is, that on Sandy Bridge at least, BIOS warm reset causes a full platform reset, as xxPLATFORM_RESET is getting asserted. As such, we lose the state needed for S3-resume. And thus, this flow is inherently incompatible with S3. No Sandy Bridge platform will do S3-resume and keep the voltage override alive.

You can do S4 (=hibernate to disk). You can, theoretically, do S3-resume to <4.4GHz, which should be stable w/o this override. But that's all.

Doron
 
So...
That explains the interaction with PLL overvolt and S3. And you say they are not compatible. Fine.
But the point is that even when PLL overvolt is disabled, S3 doesn't resume properly.
Explain that please...
S3 works fine with Z68 which is also SandyBridge.
Explain that please...
If Z68 S3 is working properly with PLL overvolt Disabled, why isn't that solution applied to P67?
Explain that please...
ppo
 
it does work for most people, myself included.

if it doesn't work for you, state your settings and all your hardware and perhaps we can get it working...

just because something doesn't work for you doesn't mean there is a problem with the implementation...

people are having just as many problems with the giga and msi boards...
 
OK.

As Sandy Bridge is a completely new product, designed from scratch, with new partitioning (iMC, PCIe, GFX, Media all on CPU), you can understand we were very busy get things on time, and overclocking was pushed aside.
Doron

Thanks very much for the explanation, much appreciated. FWIW I can run 50x without PLL override but still experience some problems with sleep although I have a feeling this might be to do with other devices on wake-up.

Interesting about the multi. Some time ago I had a i5 655k that would max out at 99x multi even when bclk ratio with 100x was lower than using 99x. i.e. 99x 42MHz okay, 99x 44MHz okay, 100x 42MHz fail. I never got an answer why this happened and just put it down to jitter.

PS Should you really give out magic numbers? Wouldn't want you to get into trouble ;)
 
Last edited:
The magic numbers are in the BIOS, so you can dig them yourself.. no secret here.

Different combination of BCLK and Multiplier gives different results for different units. We know that. It does have to do with jitter, and mostly with the specific die. You know that better than me.

ppo:
I am not aware of any SLEEP issues except the one I've described. So I cannot help, except for generic recommendation to get the latest BIOS firmware, if you don't have it already.
 
The magic numbers are in the BIOS, so you can dig them yourself.. no secret here.
True enough* but that can be time consuming. If it were publicly documented it would be a lot easier.

*except me knowing better than you lol.
 
I made a few changes to my system. The GTX580 and the Corsair AX-850 were the main ones. Sleep no longer works. I am guessing that something with the AX-850 is not letting it wake from sleep. I have everything on default with the needed bios things turned off to support sleep, and yet I still can't sleep. Asus wants me to send the board back, but I know it will still be the same with a new board, and way to many sabertooh board have been returned and yet the new ones still don't wake from sleep.

@The Mac. I would love to know what your system specs are, and what your bios settings are for your system. Would you mind?

thanks

corban
 
Corsair AX850 Gold PS
Corsair 600T case
Intel 2500K
Coolermaster Hyper 212+ cooler
Asus P67 Deluxe
2x4gig Corsair Vengence 1600 cas9
600gig velociraptor gen 3, 2 gig WD20EARS, 1 gig WD10EACS
Soundblaster X-fi HD Titanium
Sapphire AMD HD6950 2gig (flashed to 6970 shaders OC'd to 900mhz,core and 1375mhz. mem 1.175 vcore)
Hauppauge HVR-1800 dual combo Qam/Atsc/Ntsc tuner.
Logitech Revolution BT mouse (has PIN memory on dongle so works in bios on reboot...mostly)
Logitech G19 color Keyboard
Hans-G 27.1 Inch monitor (using HDMI)
Advent 3-way self amplified speakers (2.0) - yeah they're old (1995), but they sound better than anything ive heard and they crank bass for 2.0s


settings:

XMS on
all stata ports hotplug
45x multi
100mhz
auto vcore
all legacy devices disabled including on-board sound, except Legacy USB.
Realtec LAN disabled
Marvel disabled.
boot proms for non-disk devices disabled
power at high, and 350.
 
Last edited:
double the post for double the pleasure...
 
Last edited:
Hey @The Mac,

Thanks for posting the info. Here is my info.

Everything Default in 1805 bios except:
Disabled PLL Overvoltage
Enabled "Power on by PCI"
Enabled "Power on by PCI-E"
All Sata port drive settings "Enabled" for hot swap.
Logo off.

Specs:

2600K
Sabertooth P67 rev3 (bios 1805)
8GB GSkill 1600 sniper
gtx580
Corsiar AX-850
C-300 SSD 120GB main OS drive.
Water Cooled
Currently not overclocked.


I feel like the Sabertooth/AX-850 combo is having issues? Does anyone else have an AX-850 PS and a Sabertooth with Sleep working?

I wonder if it's worth upgrading to a Z68. I just hate to tear this thing down as it's a major project re-doing the watercooling and cables.

AARRRGGGG... this is is a pain.

corban
 
im tellin ya, its not the PS, the AX series are rebadged seasonics with a updated cooling fan, u cant buy a better powersupply...

what do u have for usb devices plugged in?

do u have xms profile enabled?

try putting ur old vdeo card back in and see if it works...i had issues with my HD6950 back in jan (black screen retrun from sleep) and a catalyst update fixed it...
 
Last edited:
My P8P67 Deluxe board would not resume from extended sleep, over a couple hours, since day one in January. This week I swapped out my old XMS3 sticks for a pair of Vengeance and wouldn't you know it, after sleeping all night it resumed the next morning. Set my OC settings and it resumed again the next morning. I hope this keeps up!

Funny thing though, I also have a P8P67 Pro that resumes just fine with the XMS3's. Go figure!
 
My P8P67 Deluxe board would not resume from extended sleep, over a couple hours, since day one in January. This week I swapped out my old XMS3 sticks for a pair of Vengeance and wouldn't you know it, after sleeping all night it resumed the next morning. Set my OC settings and it resumed again the next morning. I hope this keeps up!

Funny thing though, I also have a P8P67 Pro that resumes just fine with the XMS3's. Go figure!

If the XMS was using 1.65V and the Vengeance 1.5V then it may be the CPU. Some are picky when it comes to memory voltage. I run my 1.65V rated memory at 1.5V to avoid issues.
 
I don't know cause even at 1.5V it wouldn't resume. I even swapped the XMS3's between both rigs and the Pro still resumed fine. So I'm having a hard time blaming the memory but then I can't explain it otherwise. It might just be the 2600K doesn't like this RAM. I have a 2500K on the Pro.
 
I realise that it is a sample size of one, but this seems to give credence to the idea that the P67 hardware is fundamentally flawed if a straight swap for a Z68 board fixed things.

Can you give us any details on what is being done to resolve the sleep issues with the P67 boards?

You asked for an AIDA64 report of my system last week, but I am not convinced that this is a software/driver issue at all, especially as the 1702/1801 BIOSes have made this worse in my system. (now powers off immediately, rather than hanging upon waking)

These issues have been around for months now—if they cannot be resolved, the board is unfit for use as far as I am concerned, and I still have problems with SATA drive access hanging for 30+ seconds at a time. (Intel or Marvell ports, happened on both my Sabertooth boards)

Unfortunately this is happening to Z68 boards including mine. It really sucks.
 
  1. Set the bios to optimized defaults and ONLY change the following
  2. PLL Overvoltage set to disabled
  3. Turbo Ratio manually set to 40 or 42 (I am testing 38 tonight)
  4. Voltage offset set to 0.010 (adjust higher if needed but worked fine for me on both 42 and 40)
  5. All C states (C1e, C3 & C6) set to enabled
  6. Under SATA configuration enable Hot-plugging for ALL ports
  7. you can safely disable any unused controllers and devices (Marvell, JMiron, Serial port)

also

  1. Enabled Wake on PCI-E

I did these, and so far sleep has started to work. I put the system to sleep waited until all devices powered down, and it came right back up. The big test will be tonight when I go to bed and wake up in the morning to have it start up. I'll post back.
 
I switched to Vengeance RAM and now S3 resumes fine on my Deluxe. I only needed to manually enable C states. So it was my XMS RAM after all. Worked fine on the 2500K/P8P67 Pro, but my 2600K/P8P67 Deluxe didn't like it.
 
donr forget the memory controller is on the CPU, so ita going to be dependent on the CPUs tolerance.
 
So it didn't wake this morning. Event ID 41 with a Kernal Power Failure on wake. Back to the setting.
 
Did the recent BIOS updates improve or correct this S3 resume issue?


Fix list basics are:

1) S3 resume with CPU PLL OV Enabled is patched - should work on most DRAM (cheaper ICs may have issues).

2) Ivy Bridge Support enabled.

I will update again when I get another list. P67 ORom is 10.5 until 10.6 goes final at Intel.

-Raja
 
Did the recent BIOS updates improve or correct this S3 resume issue?


Fix list basics are:

1) S3 resume with CPU PLL OV Enabled is patched - should work on most DRAM (cheaper ICs may have issues).

2) Ivy Bridge Support enabled.

I will update again when I get another list. P67 ORom is 10.5 until 10.6 goes final at Intel.

-Raja


I updated to 0706 on a p8z68-v came home from work and computer came back from sleep. Hopefully it's permanent.
 
AX-850 with Sabertooth P67, 1904 BIOS, cannot resume from sleep. Have tried every combination of BIOS settings. Woke from sleep fine with an OCZ Modxstream 700, not a single issue. With a coolermaster silent pro gold 1000w it would resume 50% of the time, other half it would BSOD with a C2. Rest of the hardware never changed, only the power supplies.

With the AX-850 the computer wakes up for a second (fans spin, monitor stays off) then it shuts off for a second, then turns back on and stays on but the monitor stays blank and the keyboard no longer has power going to it (it does while it's sleeping and during the first 1 second awakening, then loses power).

I've tried stock settings, overclocked settings, messed with C-states/hotplug settings/etc. Nothing gets this thing to wake up with the AX-850 and this is the 2nd one I've tried. First one was RMA'd due to excessive cap whine, I thought maybe the sleep issue was possibly related but apparently not.

Any recommendations for a new motherboard? I love this Sabertooth but I'm constantly in/out of the house during the day and I just can't justify sucking an extra ~120 watts all the time when I could have it sleeping instead.
 
Is there a 2001 bios release for the Sabertooth cre3d? I am sure there is and that is the bios you will want to flash to and try. I believe the release notes for the 2001 bios state that the sleep issue with PLL enabled has been patched to be working now.
 
The 1904 bios has a later release date than the 2001. I believe the 2001 is also a new bios type that people are having issues downgrading from, hence my reluctance to try it out. If I could get confirmation from someone that it does indeed fix the sleep issue I'd definitely give it a go though.

OPUGW.png
 
you cant downgrade from 2001, as 2xxx is a new codepath...anytime the 1st digit increases, you will not be able to downgrade without serious hoop jumping (uaually it means a microcode update, so it might break a downgrade so they do their best to prohibit it)
 
(uaually it means a microcode update, so it might break a downgrade so they do their best to prohibit it)

I'm curious as to why you think a microcode update will break a downgrade?

Microcode isn't persistent, every time the processor powers up it needs to be loaded if required. Microcode can even be updated from the OS but is usually best to do it before then.

FWIW I had successfully downgraded my P67EVO B3 to BIOS version 0303 from 1850 with no ill effects other than the inherent problems with that particular BIOS version.

It also seems by the time Asus get to releasing a BIOS update the microcode is already out of date. For instance BIOS 2001 contains microcode update 1A, whereas microcode update 1B dates back to July.
 
Upgraded to a P8Z68-V Pro, sleep is working flawlessly at stock clocks so far. Nothing else changed, just switched from the Sabertooth P67 to this board. Sigh.
 
I'm curious as to why you think a microcode update will break a downgrade?

Microcode isn't persistent, every time the processor powers up it needs to be loaded if required. Microcode can even be updated from the OS but is usually best to do it before then.

FWIW I had successfully downgraded my P67EVO B3 to BIOS version 0303 from 1850 with no ill effects other than the inherent problems with that particular BIOS version.

It also seems by the time Asus get to releasing a BIOS update the microcode is already out of date. For instance BIOS 2001 contains microcode update 1A, whereas microcode update 1B dates back to July.

im not suggesting otherwise. Ive force downgraded many bios' that had code updates against the manufacturers wishes.

Ive even forced downgrades, then reapplied the microcode from a later bios.

Im suggesting Asus doesnt want you to.

Ive seen the same patern from other bios makers over the years. As soon as a microcode update is included, they intentionally block easy downgrades.
 
Last edited:
So it really looks like it's my AX-850. I have tried with a antec true power 550 and it wakes from sleep, but no suck luck with my AX-850. This sucks as I have my AX-850 all wired into my case. It also is past it's return date to get a refund.

Any guesses as to why the AX-850 would not resume from sleep?

corban
 
So it really looks like it's my AX-850. I have tried with a antec true power 550 and it wakes from sleep, but no suck luck with my AX-850. This sucks as I have my AX-850 all wired into my case. It also is past it's return date to get a refund.

Any guesses as to why the AX-850 would not resume from sleep?

corban

It's the Sabertooth + AX850 combo, I just swapped mine to a P8Z68-V Pro and the problem is gone. There are a bunch of posts on the official asus forums in the sleep issue thread by people with the same combo having issues. I would sooner replace the motherboard than the power supply personally, see if you can get an RMA for a different board (different = newer and better ;) ).

On an unrelated note, using this new board I've been able to overclock the same 2600k to 5ghz using the same voltage I was having to use to max out at 4.8ghz on the Sabertooth. I am using offset to achieve this overclock which never worked on the Sabertooth either. For a "military grade" board it sure seems like their quality control was less than stellar. Or maybe I just got a dud. Regardless, I'll be RMA'ing the Sabertooth for sleep issues and reselling it on ebay, I'm sold on this z68.
 
Im suggesting Asus doesnt want you to.

I'd probably go along with that but I wonder why Asus thinks it's good to do that.

The downside is if the new update introduces a new bug that causes instability then the user is prevented from easily downgrading to a possibly more stable version. The up side is ???
 
Back
Top