TR Forums

1307 is not stable for me. The stuttering/freezing symptoms occur after some 30-45 minutes.

I'm probably going to RMA, since I've put far more research into this than it's worth.

danielgme wrote:

thr- wrote:

Seems like the new BIOS update doesn't do anything for me to improve stability, I've been testing it with the warm reboot solution and it seems to work. Asus Inquiry couldn't do much about it except suggest a few things to test which I already did, after that they told me to RMA it at the point of purchase.

Hi. My hardware is the same as yours (processor, mobo and RAM). I bought it one year ago and have been suffering exactly that symptoms. I've tried absolutely everything and I'm still getting random freezes, crashes and BSOD. Could you tell me if you solved your problem and how?. I'm wondering if I must RMA either my P6T SE, my i7 920 or my OCZ Platinum XTC.

I've applied the following fixes. Although the crashes still occur for me, some may be of use to you.

- install bios 1202, clear CMOS
- install bios 1307, clear CMOS
- install intel storage matrix 8.8 because 8.9 has some known stability issues
- update firmware SSD's
- memtest RAM (ok)
- manually install latest drivers for chipset, LAN, sound, graphics, usb and other peripherals
- disabled windows quicklaunch (may have worked for some people)
- disabled media sharing (may have worked for some people)
- use a different antivirus program (seemed to work for several people)
- applied some of the fixes mentioned in this thread for logitech USB2 peripherals
- extra stable BIOS settings (not overclocked)
for cpu: 1,25 V
for QPI: 1,35 V
for RAM: loose timings, back-to-back 12, 1,65 volt
Doublechecked to make sure there was no heat problem on CPU, RAM, NB, SB (and there definitely wasn't in my case)

I'm probably forgetting to mention a few fixes I also tried, as I've been trying to get this piece of plastic to run smoothly for more than 7 months now.
I can only conclude that the problems with this board are manifold, people have problems with it all over the web. Often they post something they say works for them, but often they post a few days later that their problem isn't fixed after all. RMA's seem to work, so I'm going to give it a shot. I'll post back.

I was a bit busy, but two weeks ago I finally RMA'd the board.
I simplified the problem to the following:
- Problem occurs only when booting from power-off, not when rebooting
- when running a 3d application (game) like this, stutters and a freeze occur after 10-45 minutes
- Flashing to a different bios didn't solve it, but did influence the time before freezing

- [list of measures that didn't work]

The supplier tested the board and after two weeks agreed that it was defective. They couldn't solve it either. Now I'm just waiting for Asus to either fix it or replace it. Happy Problem almost solved!

I'm certainly curious to see if the RMA will fix it.

I've seen a few tales on the Asus forum of no change. =/ Keep us posted.

I got a replacement motherboard (different serial), but the problem isn't (completely) fixed. So now I'm back to the rebooting "fix".
So it might be something to do with the harddisks (raid of 2 M225 SSD's), the memory (Viper 12800), the PSU (HX850) or the CPU (920). Will replace HD if the system BSODs too often.
Or maybe not. Those parts don't seem to give anyone else these problems.
I really don't care anymore, rebooting every time is annoying but I'm tired of trying to fix something I can't properly test.

I've seen somewhat close problems out of a DFI LanParty board too.

I'm not sure if it's a bug with the X58 itself, with the firmware, or with the vendor board designs or what.

I'm just gonna change platforms when the new sockets arrive.

So, two years later and I think I might have finally stumbled onto the answer for this strange bug.

It would seem the HPET in the ICH9 and ICH10 wasn't so hot.

Lo and behold people who disable HPET find that sleep problems get resolved.

More interestingly it seems that NVIDIA in the 285.79 Beta pushed out a fix silently for the issue.

Bad thing is, I don't recall Asus offering a BIOS option to disable HPET. :(

I'm so glad I found the answer to this mere weeks before I transition to X79.

Random thought: IIRC certain Linux kernels had issues with the HPET on my Asus M3A78-CM too. The solution was to force the Linux kernel to use the ACPI timer as its timebase instead.

So perhaps HPET issues were not uncommon on motherboards from a few years ago. (HPET was apparently introduced around 2005, so maybe they were still working the bugs out...)

After some more hitting of the search engine it appears that Asus is one of the only manufacturers who does not expose the ability to cut off the HPET on the X58. It's no wonder their forums are littered with threads just like this one.

My searches have more or less uncovered your answer. Using DSDT on an Apple or Linux based system is an easy way to force the system into a behavior not exposed by the BIOS. Unfortunately I seem far more jammed up. Windows is less giving in this regard.

In the Linux case it did not even require mucking with DSDT. All it took was adding a "clocksource=acpi_pm" to the bootloader options.

You saying that gave me an epiphany regarding BCDEdit.

Seems there is a solution in Windows there.

bcdedit /set useplatformclock true (HPET on)

bcdedit /set useplatformclock false (HPET off)

Since a picture is worth a thousand words.

http://www.youtube.com/watch?v=nNShaHCF3sE

just brew it! wrote:

In the Linux case it did not even require mucking with DSDT. All it took was adding a "clocksource=acpi_pm" to the bootloader options.

Ah-hah! I've got a Gigabyte EX58-DS4 with a Core i7 920 and I run Ubuntu (now 11.10 but been through several versions on this issue). It refused to come out of sleep with turbo mode enabled so up till now I've just turned off the turbo given it isn't much difference on a 920. After seeing this, I just added this to my boot line and turbo mode and sleep now works!!!

Interestingly enough without the clocksource line, it starts off on the HPET but then switches to TSC. I presume that as the processor is going down during sleep it switches back from the TSC and was on the buggy HPET but is now on the ACPI clocksource.

For those Windows users that are still having trouble after sleep it may be worth trying turning off Turbo mode in the BIOS.

Glad to see my tip has helped a few people. In my case it wasn't to fix a BSOD or sleep issue; it was just that the system time was running so far out of whack that even enabling Internet time sync (NTP) wouldn't keep the clock synchronized. I guess HPET is pretty messed up on a lot of motherboards...

I'm glad to see this thread resolve something as well.

Unfortunately the Windows commands I listed above aren't much of a fix for me. Windows appears to default to TSC out of the box (same as the false switch). There's some implications that when HPET is enabled in the BIOS it manages/acts like the TSC by running at a lower frequency: 2.x MHz versus the HPET native 14.x MHz. So you're sort of jammed up on the buggy timer either way if HPET is enabled.

Only after using the true command does it adjust over to HPET (if enabled in the BIOS) or the PM timer (HPET is disabled in the BIOS). So having access to disabling HPET in the BIOS is key for Windows, which is an unfortunate limitation.

Ryu Connor wrote:

Lo and behold people who disable HPET find that sleep problems get resolved.

More interestingly it seems that NVIDIA in the 285.79 Beta pushed out a fix silently for the issue.

Just FWIW, for completeness' sake, I feel I should note:

I could not sleep my PC. Ryu and I tinkered with it for quite a while, no 100% resolution. Finally left it on 64bit HPET.

RMAed my GTX260 to eVGA, got a GTX460. Sleep is now flawless.

My i7-920 has died, but that's another issue entirely.