ASUS Official X79 Motherboards Support Thread

Hi again,

Status: Almost perfect now, occasional "code 19" halts (rarely) - not due to the workload, something else weird is going on.
It seems to me that after a "code 19" halt, even though the system has been reset, the R4E is picking up previous "code 19" trail on startup and doesn't really start fresh.
This leads to repeating boot (POST) code 19 problems, even though when the system once has started it seems to run rock solid now (e.g. full load LinX without any sign of issues etc.).

Actions taken thus far:

WAVE 1
1. Started with a "clean" table: Reloaded default BIOS (F5) -> save & reset (F10). Note that the CPU is overclocked by default! (target 3900G)
2. Disabled all unused components/features (e.g. BT, Asmedia OPROM, etc.) -> save & reset
3. Set OC mode to manual and typed in the Kingston XMP values manually (VCCSA left to Auto!) -> save & reset

Gave it one pass with Memtest86+ (150 minutes) = 0 errors (Memtest86+ version 4.20)
On exit from Memtest86+ got "code 19" halt
Restarted the rig and it stopped on BIOS setup with a message: "Overclocking failed..."
Observed that the BIOS was pushing DDR3-1333 mode, rather than the manually set target DDR3-1600 (XMP)

WAVE 2
1. Increased the VCCSA voltage stepwise (0.05v increments) to 1.05v -> save & reset several times = all Ok
2. Started Windows and ran various stress tests (AIDA64, SiSandra, LinX), repeatedly - everything Ok
3. At some point Windows crashed on starting AIDA64 (when loading BIOS data) -> rebooting halted on "code 19" again
This time R4E went into a real "code 19" cycle, and it was very hard to get out of it. It seems that crashing Windows is causing harder R4E hangups.
Eventually the boot moved on and halted on code 94, and then finally next reboot went back to a working system.

I was curious so without changing anything else (other than the VCCSA=1.05v adjustment), I gave this setup another pass with Memtest86+ = 0 errors!
Basically, Memtest86+ has never complained about the memory or the way it works. Something else is going on...
Indeed, on exiting Memtest86+ I got the "code 19" halt again.
However, rebooting the system went fine this time, and I guess R4E just don't like the way Memtest86+ is terminating :)

Note that I've been running all the way with memory in a DDR3-1600 mode (checked regularly with CPU-Z)

WAVE 3
I decided to test the rig with a heavy workload, just to see if stressing the system is what is causing these problems, or there's something else.
1. Started with running AIDA64 stability stresstest for 30 minutes - no problems and everythings was Ok during
2. Ran full load LinX 0.6.4 for 30 minutes - no problems whatsoever (I was actually able to run other programs on top, the system didn't get sluggish at all!)
3. I went thru all the SiSandra queries collecting various HW information - worked like a charm

So at this point, I'm convinced that the RAM in itself is Ok, once started it's working fine, while "code 19" halts appear (now only occasionally) in various rebooting scenarios.
Finally, I entered 1.15v for VCCSA and 10 for CAS and tRCD as recommended, but unfortunately it does not eliminate the occasional "code 19" halts in between.

Any ideas? Why is "code 19" (Pre-memory PCH initialization is started) so persistent here? Is there any reason to look at the PCH itself?

Cheers,
Willy

Btw, interesting observation that may be indicating some related condition:
Disabled CPU spread spectrum - R4E got right into "code 19" and wanted me to set DDR3-1333 mode.
Resetting the CPU spread spectrum back to Auto resulted in a normal boot and no problems with the DDR3-1600 setting!
How about that! (Normally, all OC gurus would tell you to disable the CPU & PCIe spread spectrum - here it seems to be working the other way around...)
 
Last edited:
Code 19 after setting CPU Spread Spectrum is just a red hearing after the reset.
Power down at AC and remove half of the memory modules. Use a single kit for a few days with its XMP profile and see how many issues you get, before you try adding the second ki into the mix.

-Raja
 
Figures... This is going to be a really painstaking exercise, especially since the RAM is part of the water cooling loop.

What I don't understand is that once in Windows the system is evidently running Ok under various stressloads (also Memtest86+ always passes too). Why wouldn't R4E simply let me get there? To me it seems like R4E is not resetting and cleaning up properly after a crash, and some "rests" are getting in the way of performing a truly fresh restart. How can R4E run under given setup for hours and then suddenly start rejecting the exact same setup in the next turn after a "code 19" incident? I don't get that...

Frankly, I thought that a board with so rich functionality would be more capable of handling unfavorable situations, even if it doesn't give you the optimal solution at the end of the day.
The experience so far makes me wonder now if a simpler board would have been more resilient...
 
Last edited:
The memory controller performs DRAM training at each POST. If the DIMMs are on the edge of being stable they will sometimes fail training. Nothing we can do about that. The "overclocking failed" message appears because the board had to reset the memory to defaults as it was NOT stable. The board only provides start up sequence code and power and the physical interconnect layers.

If you don't want to remove the modules then run them at DDR3-1333 for a while, and relax more of the timings. Add +2 clocks to each of the third timing set also.

-Raja
 
Hi Raja! I was doing just that before I discovered your response. I was thinking in the same alley.

I.e. given that no memory tests have failed and Windows runs stable under heavy loads, I decided to set the memory in a very relaxed mode in order to see if this would help, and did exactly what you're suggesting... Selected manually DDR3-1333 mode with increased timings (starting with 10,10,9,27 etc.). Guess what... code 19 did not disappear or change its behavior!

Then I increased the VDIMM to 1.65v (XMP) while keeping the lower DDR3-1333 frequency setting, invreased VCCSA and later also VTT to 1.15v... Still no effect on the occasional code 19 halts!

What does that tell you? Could it be that we've been on a wild goose chase and the RAM is not the real root cause after all? There's no hard evidence about any errors with it, rather the opposite.

Based on the experiences thus far, it seems to me that "code 19" is just a symptom not actually pointing out what's wrong with the setup. I'm also thinking about the other observations of programs failing to collect BIOS or MB information from the HW. Finally, I still don't get that R4E would fail to reset to a previously working setup.

What do you make out of all that?

I really do appreciate your help and time, and I've read your R4E recommendations both in this forum and on the ROG site, and it's been very helpful for me!

Thanks for helping out!


Btw, part about the DRAM training was awesome :) I don't suppose the training on my board has somehow gotten oversensitive or too stringent in regards to a setup that seems to be working otherwise?
NOTE half of the times I'm getting "code 19" is after shutting down Windows. I suppose there's no DRAM training at this point? Isn't that an interesting indication?
 
Last edited:
Now I've tested +2 increments of all third timing as well... no difference, actually may have done things worse (stuck into a "code 19" as we speak).
I suppose it's not possible that too relaxed RAM settings could pose a problem in itself, or...?

NOTE! Successful boot with "Memory Ok!" changes the memory settings according to what R4E found to be working (and tells med that: "Memory Ok! succeeds in booting the system. Save your memory settings... etc.".
I've done exactly that too - going into BIOS setup, simply hitting F10, Enter, and ... the R4E goes right into "code 19". So what's the problem? Why Memory Ok! confirms successful setting, and R4E crashes with this exact setting on exiting BIOS setup?

Anyway, once R4E gets into a "code 19" halt, it seems stuck there, and relaxing the memory settings did not seem to help.

What else can I try?
 
Last edited:
What USB devices do you have plugged in?


As for why does this happen when you reboot, the DRAM is trained EVERY time you reset. There are two types of training, the first is from AC power cycle (this is longer). The second retrains the modules for variations in temperature etc. There is always the chance that two sets of these DIMMs are VERY difficult to get stable irrespective of timings. Might need VCCSA to 1.20V and even then might be flaky if the memory controller on your CPU is not one of the better samples out there.

If it's not the DRAM it will likely be a plug in peripheral.
 
I haven't plugged in any USB devices since the clean install of Windows 7 x64 Ultimate.
The keyboard (and the mouse) are the only USB gear I'm using, at the dedicated USB port.

Meanwhile, I started from scratch, reloaded the default BIOS settings and I didn't touch any settings around CPU and DRAM, only turned off (disabled) some items. Then I checked that Windows is running stable, and performed an extensive stability testing as follows:
- LinX, full load ("All") for 2 hours
- AIDA64 stability test, all options included, for about 2 hours
- Prime95, full load with RAM stressing focus, 3 runs

NOT A SINGLE ERROR! I really don't need a system more stable than that.
I'd believe this indicates also that the memory controller is not too bad.

However, "code 19" still shows up on shutting down and restarting the rig (e.g. right after resetting to the plain default BIOS settings).

Do you think that manipulating the VCCSA/VTT boot up voltages might help? I.e. increasing stability exactly during boot? (On the other hand this won't help the code 19 halt on shutdown.)

I really wonder if there's something else beside the RAM that we should have tried, but I have no clue what this could be...
 
Last edited:
Btw, similar issues that I have experienced before, most often have been resolved in the next BIOS release. Now, I'm using the latest BIOS (v.2003) just released a couple of days ago, so I guess this is not it (in any case it's probably gonna take a while until the next BIOS release).

There are some "Enhanced DRAM training" settings in the BIOS setup (I tried disabling those before but it didn't make any difference). I suppose you're talking about the more basic DRAM training that cannot be manipulated though. If ... it's the DRAM training causing the issue (ref. the shutdown problem).

Imagine the scenario that after putting the huge effort in disassembling the rig, replacing all the memory with a 32G XMP kit, and I still got the same problem!!! I'd really like to eliminate any alternative scenarios before jumping into that. I'm sure you understand.
Here's how my build looks initially stripped for all remaining PCIe gear etc. Just for fun I've also enclosed a picture of my "old" system that I built last year (P8Z68, i7-2600K @ 4.7G).

wc.jpg
cool-pc.jpg
 
Last edited:
Raja, WE MAY HAVE SOLVED THE PROBLEM!

In the current BIOS setup, I manually set the VCCSA = 1.2v. R4E didn't like that (went straight on into another "code 19" cycle). When it eventually got thru, it made a "F1" stop with a message that "Overclocking failed".

In the BIOS setup, I REDUCED the VCCSA with -1 unit, down to 1.195v (nothing else touched). After hitting F10+Enter (save & restart) the R4E rebooted without complaining about anything, and Windows came up as it should.

Then I performed a dozen restarts including: Windows restart, shutdown/start, simulated "crash" restart (using the "Reset" button)... NOT A SINGLE "code 19" HALT! Looks very promising :)

Another interesting observation is that R4E now shows (on the BIOS boot screen) a memory setting of DDR3-1337 indicating for the first time that the memory autotuning (training?) is taking action! I can also see in CPU-Z that R4E has adjusted the bus speed to 100.3 MHz, and that the DRAM frequency is 668.7 MHz (otherwise standard Jedec4 timings and 2T rate).

Of course, it's too early to claim that the problem has been solved, but things really look very promising at this point (at least this is a huge step forward).

I'll be back with more information later on.

Take care,
Willy
 
Last edited:
Raja,

I tried updating my BIOS to the latest 2003 version using the BIOS flashback port. I renamed the converter to R4E.ROM prior to the flash and now when powering on the board I get debug code 01 and will not boot. Any reason for this or how I can recover?

Thanks,
 
HydrasunGQ said:
Raja,

I tried updating my BIOS to the latest 2003 version using the BIOS flashback port. I renamed the converter to R4E.ROM prior to the flash and now when powering on the board I get debug code 01 and will not boot. Any reason for this or how I can recover?

Thanks,
Click to expand...

never mind, I was able to recover.
 
HydrasunGQ said:
never mind, I was able to recover.
Click to expand...

Yeah the latest bios update is a little different then before. If you haven't been able to update yet please read the instructions that come with the new bios update. You should NOT have to rename any files.

You should first download " SABERTOOTH-X79-CAP-Converter" from "BIOS-Utilities" and read the guide that comes with it. I did just that and had no problems at all in upgrading to the new "cap" bios.
 
pwrusr said:
Yeah the latest bios update is a little different then before. If you haven't been able to update yet please read the instructions that come with the new bios update. You should NOT have to rename any files.

You should first download " SABERTOOTH-X79-CAP-Converter" from "BIOS-Utilities" and read the guide that comes with it. I did just that and had no problems at all in upgrading to the new "cap" bios.
Click to expand...

Looks like something was corrupted on BIOS1. I booted in BIOS2 and did a copy to BIOS1 to recover and attempted the update a second time on BIOS1 with success.

Looks like this update forces an update on both BIOS1 and 2.

Not sure what went wrong the first time around but I'm all set now.
 
Regarding the "code 19" problem. It's back...

After a long overnight run with heavy stresstesting, completely flawless (!), I got a "code 19" halt again after Windows shutdown, and ... it won't go away.

I haven't changed anything! A couple of times the rig managed to boot thru to the BIOS screen with a message "Overclocking failed!". Yet, this BIOS setup has been completely stable since yesterday! At this point, either I save & reset (F10), or ignore it and exit BIOS setup without saving, on exiting the BIOS setup R4E goes right into a code 19 halt regardless. After that I tested adjusting VCCSA a little up/down without any effect. Finally, I increased the VTT CPU to 1.125v thinking that it might help the memory controller and also reduces the "native" delta between VCCSA and VTT, but ... it didn't work out. So I did reset everything back to the last working setting for now. Still won't boot.

What's going on here? Why the exact same BIOS setup would work awesome for hours, and then it suddently wouldn't, even though no settings have been changed? I really don't get this. Sure, I understand that with so many "Auto" settings R4E is making its own decisions all the time, but why it wouldn't remember "the last working setting" and hold on to it? Or "rediscover" it for that matter...

Any suggestions? Please help...
 
Last edited:
Try setting clockgen filter on various settings. No need to do lengthy write ups at this point. Also try setting PCIe to Gen 2 mode instead of Gen 3. That is in the Advanced section of UEFI in one of the sub-menus. Navigate through them and you should find it. Ignore what is happening when you get into the OS, the whole reason you get into the OS is because the system manages to train the memory and PEG lanes. If they don't train right, then you don't make it into the OS. Known weaknesses in the X79 are using the wrong memory and or using Gen 3 PCIe mode with some CPUs. If you have removed just about every other component (no self powered USB hubs, card readers etc, that would include a monitor or keyboard with a built in hub), and the Intel SSD firmware is up to date, then it points back at the CPU, memory and/or GPU. The only other thing I know of that can cause POST~BOOT issues is using cheap display port cables with ATI cards - which is not the case for you obviously.



If that does not work, bite the bullet and remove some DIMMs and see what happens at DDR3-1333. I would advise not to put a complex waterloop together until a system has been thoroughly tested. I always spend a week or so on air cooling before I start adding waterblocks.
 
Last edited:
Hmmm... I've been wondering myself about the GEN3 on the VGA (slot 1) since I've had a few code 94 (PCIe enumeration) cases in between, but I was preoccupied with the code 19 trouble. Maybe those are interrelated?

I'll definitely test what you're suggesting. Thank you so much!

Maybe I forgot to mention it before, but I had the system working in the beginning (though not for weeks), before I mounted the watercooling etc. I really didn't expect any post-testing issues of this magnitude (my previous experience). I got ambushed...

Something else... I used one of the "F1" breaks forcing BIOS setup, and just for the h... of it, I selected XMP mode again, keeping my current VCCSA setting and not touching anything else.
Guess what... R4E booted up and it's been stable on DDR3-1600 setting for the past hour... Here some evidence:
r4e-xmp.jpg


It's probably only a temporary lucky break, but it still makes me wonder...

Btw, I couldn't find any Asus QVL for 32GB kits. Care to share some tips on what specifc RAM to look after? (preferably Kingston HyperX if possible)
Just in case... Thank you!

(Btw sorry for the information overload. Point taken.)
 
Last edited:
If all of this started after adding the waterblocks, make sure you have not overclamped the CPU block, or that none of the blocks are pulling on any of the components.
 
Absolutely. Very valid point. After adding the WC, the rig continued working fine for almost a week. I've rechecked carefully the entire build, and there were never any leaks too, so ... Also the temperatures and all component status/data reports have been consistently fine. Of course, you never know. How all this started is en excellent question though... It started with a Windows crash followed by a "code 19" on the next R4E boot. And it's been like this ever since. For all I know, maybe it was the R4E causing the Windows crash in first place, but what happened? That's what we've been trying to figure out, right :)
 
Last edited:
Could it be USB? I replaced my Logitech G15/G9 gear with my good old KeyTronic (PS2) and a simple Logitech mouse... Haven't had any code 19 halts yet. It's ridiculous if it's turn out that R4E - The ROG King - doesn't handle regular gaming gear like G15/G9 ... lol

Interesting observation is that the R4E cold boot runs a bit faster now. I know USB could cause BIOS problems before, but this is a top-line 1 year old board after all...

Well, let me give it some more testing before celebrating... We've been fooled before :)
 
Last edited:
USB is a possibility, which is why I was asking you which devices you had plugged in. Plus I did ask about keyboards with USB hubs etc, which the G15 has. The Logitech keyboards have had issues with UEFI in the past.
 
No such luck, it didn't work out... BUT I'm beginning to see a weird pattern here:
1) After making some suggested change, the R4E eventually would start booting.
2) Then for a substantial period of time, regular (dozens!) of flawless reboots/restarts would follow (so the change must have been significant).
3) At some point - without touching anything (the working BIOS setup is "frozen"!) - the "code 19" halt hits in again, and that's the end of the happy hour...

Can you explain that? This behavior pattern has repeated itself several times now. I have never experienced a board to change its behavior on its own out of a "frozen" configuration. If anything, I've seen boards "learn from experience" and optimize the settings, but never making things worse... I would understand if it should fail occasionally in between and then get back to normal, but R4E simply locks itself into a "code 19" loop, and can't get out of it on its own.

Raja, I fully understand that your patience is not unlimited, and I'm so sorry for nagging you with all that. I'm a bit frustrated at this point, and I really have no clue what could be the logical explanation of this R4E behavior. Please bear with me one last time... Why is R4E giving me such a hard time by being so inconsistent in its behavior? Am I the only case? Any clues? I get it that disassembling and starting from scratch is an option - but I need to understand why R4E is behaving like this, otherwise there's no guarantee that I won't get into the exact same situation a few months down the road...

I'm only buying high-quality components, and I've done this a couple of times before so I'm pretty sure that I haven't damaged any parts.
I think it's very unlikely that a $1000 CPU would arrive bad, the RAM has been tested end-to-end, and the GPU is the one I had in my previous workstation - fully working without a problem.
What's left? The R4E board... could it be faulty (or the BIOS)? I wonder...
 
Last edited:
its a faulty bios send the board back for a replacement chip or replace the chip yourself if you can
 
infospace said:
its a faulty bios send the board back for a replacement chip or replace the chip yourself if you can
Click to expand...

Thanks pal, much appreciated. Your conclusion makes a lot of sense.
However, the R4E board have 2x BIOS and I've tried them both...

BUT I'm beginning to see what's going on... I'll be back :)
 
WillyK said:
No such luck, it didn't work out... BUT I'm beginning to see a weird pattern here:
1) After making some suggested change, the R4E eventually would start booting.
2) Then for a substantial period of time, regular (dozens!) of flawless reboots/restarts would follow (so the change must have been significant).
3) At some point - without touching anything (the working BIOS setup is "frozen"!) - the "code 19" halt hits in again, and that's the end of the happy hour...

Can you explain that? This behavior pattern has repeated itself several times now. I have never experienced a board to change its behavior on its own out of a "frozen" configuration. If anything, I've seen boards "learn from experience" and optimize the settings, but never making things worse... I would understand if it should fail occasionally in between and then get back to normal, but R4E simply locks itself into a "code 19" loop, and can't get out of it on its own.

Raja, I fully understand that your patience is not unlimited, and I'm so sorry for nagging you with all that. I'm a bit frustrated at this point, and I really have no clue what could be the logical explanation of this R4E behavior. Please bear with me one last time... Why is R4E giving me such a hard time by being so inconsistent in its behavior? Am I the only case? Any clues? I get it that disassembling and starting from scratch is an option - but I need to understand why R4E is behaving like this, otherwise there's no guarantee that I won't get into the exact same situation a few months down the road...

I'm only buying high-quality components, and I've done this a couple of times before so I'm pretty sure that I haven't damaged any parts.
I think it's very unlikely that a $1000 CPU would arrive bad, the RAM has been tested end-to-end, and the GPU is the one I had in my previous workstation - fully working without a problem.
What's left? The R4E board... could it be faulty (or the BIOS)? I wonder...
Click to expand...


Without having the system here in front of me, I cannot be 100% certain. What I will say is, yes, this seems specific to you, so I can only go by parts choices at first approximation.
 
Thanks Raja! You've been a great pal and advisor.

Since I can't make R4E "think" like me, I had to adapt myself to its thinking...
I believe I have the solution in sight but ... let me recheck and test this thoroughly, before spamming the forum any further... I'll be back. Really!
 
Hi guys,

Revealing the secrets of R4E has been a painful experience for me, and I decided to share with you what I've learned for what it's worth.
This might prove useful for R4E owners, and probably others as well (Certified OC gurus may find this less interesting.)

First of all, I assume you're not taking R4E for "just another mobo"... Don't. It's special.
Other mobos are somewhat less complex and easier to understand. R4E is different.

My 2b lessons learned:
- Extensive automation makes it virtually impossible to have any "static" configuration (you only specify a few parameters out of hundreds)
- Memory tuning starting with already overclocked CPU is probably not a good idea (R4E's fabric setting for the CPU ratio/multiplier is x39)
- Various POST debug codes (on the 2-digit Q LED) have their specific meanings, but most of them (especially code 19) actually indicate:
1) either you have some badly configured component (could be anything!), or
2) disagreement between the configurations of collaborating components, e.g. voltage delta (assuming they are compatible to begin with)

So what? Well, for me it proved crucial to understand the above. I've briefly summarized how things worked out for me below.
Disclaimer: This message is reflecting my experiences with a properly cooled system (watercooling in my case).
Use this information on your own risk. I assume you know how to do BIOS setup, if not - don't.

NOTE-1: The order of carrying on the actions below is significant for the most part (you can't just jump around at will).


STARTING RIGHT...

- Turn off the default CPU overclocking, use your native CPU frequency (select manual overclocking, specify the right multiplier for your CPU)


INCREASE THE PREDICTABILITY OF HOW YOUR BIOS BEHAVES

Provide fixed values for critical parameters (thus reducing the potential automation hazard)

1) Start with the memory settings and enter manually:
- DRAM standard timings (hit F10 = save & reboot)
- DRAM standard voltages (F10)
- VCCSA voltage value, starting with the standard value (F10) and stepwise increasing it (F10 each time) if necessary until stable boot
- VTT CPU and CPU PLL voltage values (one at the time, F10, next...)

NOTE-2: It's very important that all value manipulation is done in small increments, one at the time, saved and reinitialized by hitting F10, etc.
(This allows the remaining "Auto" settings to follow up gracefully and smoothly adjust accordingly - "jump" changes may confuse the internal "optimizer".)

2) Next, for the CPU enter manually:
- CPU VCORE base voltage, starting with 1.25v or slightly less (F10)
- CPU RATIO multiplier (for all cores), increase by +1 (F10) - REPEAT +1 (F10) until unstable boot, then take the action that follows below
- CPU VCORE voltage increment of +0.025v or less (max 1.4v), whenever the multiplier starts causing unstability (F10), then try next multiplier (above), and so on...
How far you wanna push the CPU is entirely up to you (and of course of the type, quality and desired lifespan of your components).

NOTE-3: Don't believe the "Auto" settings always give the optimal values (see the example below). These only provide a starting point.

r4e-oc.jpg

Also keep in mind that R4E is still young and has a lot to learn... My point is, always check what you're getting out of "Auto" and act accordingly.


ENSURE YOUR (OC) SETUP IS STABLE

- Assuming successful OC result and that your OS starts normally, take a few more reboots/restarts, make sure the BIOS boots up/terminates Ok.
- Simulate an OS "crash" (hit the "Restart" button), or deliberately make the OS to crash, and see if the BIOS reboots Ok regardless.
- Run various stress tests (Prime95, LinX, AIDA64, SiSandra, Unigine,...) for a few hours (at least 2h) and see if the system remains stable.

NOTE-4: Watch your rig temperatures! Stop the stress test immediately if the CPU temps exceed 80C! The same for GPU and others.

If your system is not stable - you might need to increase the CPU VCORE some more, but not more than 1.4v if you care about your CPU.
If you are there (1.4v) already, you'll have to decrease the CPU ratio (multiplier) by -1 instead, until your system becomes stable again under stress testing.

-------------------------------------------------------------------------------------------------------------

That's it! No more nightmares with code 19, also codes 0E, 0D, 94 etc. in between, for my part!
I still need to do some more extensive stability testing, but things look very promising at this point.

Cheers,
Willy

CURRENT SETUP (STABLE)

r4e-ocx.jpg
 
Last edited:
Raja, I have just one small issue with my build (see sig)
The computer won't stay asleep. It wakes up sometime after I leave the room. 15 minutes to a few hours, I'm not sure exactly how long.

Any ideas what could be causing this?
Bios is the latest version.
chipset drivers are (I think) up to the latest version.
Video card drivers are up to date.
 
pwrusr said:
Raja, I have just one small issue with my build (see sig)
The computer won't stay asleep. It wakes up sometime after I leave the room. 15 minutes to a few hours, I'm not sure exactly how long.

Any ideas what could be causing this?
Bios is the latest version.
chipset drivers are (I think) up to the latest version.
Video card drivers are up to date.
Click to expand...

Are you using the onboard LAN? If so check the driver and ensure all wake patterns are set to disabled.
 
So I just built a new rig with the Saberooth X79 that I've been pretty happy with so far, but I had one question. Upon shutting down the computer (from the OS) it seems that the computer shuts down but remains in a low power state (num lock on keyboard remains on, external hard drive light starts blinking). Is there a way to disable this feature (from the BIOS perhaps?) The only reason I'm not a fan of it is because the light on my external harddrive is really bright and just keeps blinking to show it's sleep mode, and I'd rather just have the system completely powered down if possible without having to resort to flipping the switch on the power supply or my UPS.
 
Depending upon hwo your PSU handles the power rails when ErP is enabled you might be able to switch off those standby LEDs. Go to Advanced>APM and enable ErP. On the Corsair AX series this works, not sure about other PSUs.

-Raja
 
Greetings,

this is my first post here and I`m allready starting with problems,.....sorry for that!

I`m constantly getting a systemfreeze, when trying to enable CrossfireX (or shortly after) on my two Firepro v8800. I`ve never had any problems with this cards in my old system and both of them seperated are working without any issues in this new build. I had even tested them together (Crossfire disabled) in luxmark and and Aida64 with no Problems.

my System Specs:

MB: Asus P9X79 DELUXE (BIOS 2002)
CPU: i7 3960x
GPU: 2x FirePro V8800 (Driver 8.911.3.3000 isv)
RAM: 2x Corsair CMX32GX3M4A1600C1 (64GB)
PSU: Corsair TX850W
SSD: Crucial M4 256 GB
O/S: Windows 7 64bit Professional SP01

I did a clean Win/ installation I updated every driver and the MOBO (2002) BIOS... recognized that the newest chipsetdrivers are more than one year old.
I also tested older GPU drivers.......no luck

The system is prime95-stable both cards did very well running Furmak.
Memtest shows no issues.........

The cards are installed in slot 1 and 4, as recommended. Ive allready tested the other ones with same results

My old System had never had any problems running both cards in CF

All Temps are OK.....I don`t know what to do anymore :(

any suggestions?
 
thank you Raja,


already tried your advise, only to use one kit with no difference...

EDIT: RMA it is! ..... I talked to the AMD and Asus Germany support via telephone...
 
Last edited:
Raja@ASUS said:
Are you using the onboard LAN? If so check the driver and ensure all wake patterns are set to disabled.
Click to expand...
Yes I am using the on-board lan.

Are you talking about these (under Wake on LAN):
intelpower.png


I have disabled them however my computer was on when I woke up in the morning.

***EDIT***
I just stepped away from my computer for a couple of hours after putting it to sleep. Still asleep. however when I woke it up it didn't wake up completely. A hard reset didn't work, Had to hard power (by holding power button for 5 seconds) it off then on again.

When it powered back up it said "overclocking failed press F1"... I haven't overclocked this computer at all since I put it together.
I'm using BIOS version 2002 if that makes any difference at all.
 
Last edited:
What memory modules are you using? Overclocking Failed when the CPU is at stock frequency is usually down to memory instability or possibly Gen 3 PCIe mode.

Did you have this problem and the auto wake from sleep issue on the previous BIOS?
 
Raja@ASUS said:
What memory modules are you using? Overclocking Failed when the CPU is at stock frequency is usually down to memory instability or possibly Gen 3 PCIe mode.

Did you have this problem and the auto wake from sleep issue on the previous BIOS?
Click to expand...

I'm using two sticks of corsair vengeance 1600 c9. Was using the XMP profile before. However this morning when I woke up I heard my fans running full steam again, so I know it woke up again sometime last night.

I didn't have this problem with the last BIOS :(
 
You must log in or register to reply here.
Back
Top