Overclock.net banner

SB-E Marking TSC unstable due to check_tsc_sync_source failed [xpost Intel CPUs]

9.2K views 37 replies 8 participants last post by  KoSoVaR  
#1 ·
xpost from Intel CPUs

Turned off HPET, but TSC is unstable. I'm getting this error in dmesg:

TSC synchronization [CPU#0 -> CPU#1]:
Measured 45807324137 cycles TSC warp between CPUs, turning off TSC clock.
Marking TSC unstable due to check_tsc_sync_source failed

Mobo - R4E
CPU - i7 3970X @ 5.1GHz
Memory - Corsair 32GB kit 2400mhz
BIOS - 3301
OS: Fedora 17
Custom water

CPU is overclocked to 5.1GHz, prime stable for 15hrs+ in Windows. I'm trying the Linux 3.2 kernel but when the kernel tries to use the TSC as its clock source I'm getting the above error. Time even seems to go backwards between two cores, and TSC just can't be used at all. I've tried to manually change the clocksource once the system is booted, but this is when time goes backwards - which defeats the purpose. HPET is far too slow for what I'm trying to accomplish and why I would like to use TSC.

Interestingly, as stated in my original post on Intel CPUs, I've tried plugging this SAME hard drive in to an x58 board with a 920 at stock and bam - it works just fine.

Any help would be appreciated.
 
#3 ·
Quote:
Originally Posted by Shrak View Post

Windows Stable != Linux Stable

Linux is much pickier with overclocks, you'll have to restart if you want it to be Linux stable.
What do you recommend? Problem is, I even went stock and still no dice. Stock + c states off, no dice. Also why would this work on my 920 and not this? I literally plugged the hd in to my 920 rig and boom, magic.

I have a feeling it has something to do with the kernel and TSC, but I'm really not sure what to do. I can definitely run stability benchmarks if that's what you're suggesting, but I think the problem is somewhere else.

I'm downloading a Ubuntu live CD to rule out the kernel and SB-E.
 
#5 ·
Quote:
Originally Posted by Transhour View Post

seems to be an actual bug in the kernel.

one thing you could check, make sure your system clock (in bios) is correct, as i've had a similar problem when i switched from local time to UTC.
Unfortunately I received this response from ASUS:
Quote:
Thank you for contacting ASUS Customer Service.

My name is Carter and it''s my pleasure to help you with your problem.

I am afraid to say this board doesn't support linux offically,so we can't assure the compatibility.
If possible,please install another OS like Windows 7 on this board for a further test.

If you continue to experience issues in the future, please do not hesitate
to contact us.
I have another disk that I will be testing TSC on Windows with, but I still believe it is something with the board. I tested this exact scenario out on my x58 EVGA board with a i7 920 and TSC sync was successful. I used Ubuntu 12.10 and again this worked on my x58 board but not my X79.

Any help would be appreciated - or even if anyone with a Linux distro (Debian desktop, Ubuntu, anything) and using this board could just type
Quote:
dmesg | grep -i tsc
That will tell you the status of TSC...
 
#6 ·
Was the 3.2 kernel ready for SB-E? I'm just wondering why you're using an older kernel. Seems like a good idea would be to try another more recent kernel.
 
#7 ·
Quote:
Originally Posted by Rookie1337 View Post

Was the 3.2 kernel ready for SB-E? I'm just wondering why you're using an older kernel. Seems like a good idea would be to try another more recent kernel.
Tried Ubuntu 12.10 which has 3.5 kernel. It's definitely the board. I plugged both my 3.2 kernel and the Ubuntu in to my little brother machine (3930k + R4E) and the same thing happened. Machine is clocked at 4.9GHz.

I'm going to test my Z77 board right now, it's an ASUS Sabertooth Z77 with a 3770k.
 
#8 ·
Confirmed, my 650 Dominator rig in my sig shows TSC sync is successful.

I think it's the board. I'm going to pickup the X79 Sabertooth and maybe the P9X79 .. I'm not sure.

Gah this is annoying. ASUS support is lackluster.
 
#9 ·
Quote:
Originally Posted by KoSoVaR View Post

Confirmed, my 650 Dominator rig in my sig shows TSC sync is successful.

I think it's the board. I'm going to pickup the X79 Sabertooth and maybe the P9X79 .. I'm not sure.

Gah this is annoying. ASUS support is lackluster.
I might have missed this but you tested without the OC right? And yes...Linux support is hard to find most of the time.
 
#10 ·
Quote:
Originally Posted by Rookie1337 View Post

I might have missed this but you tested without the OC right? And yes...Linux support is hard to find most of the time.
Yep. I just bought two new boards.. the ASUS X79 and the ASUS P9X79PRO. My ASROCK Extreme11 will be here tomorrow.

All blame to ASUS R4E for now.
 
#11 ·
Quote:
Originally Posted by KoSoVaR View Post

Yep. I just bought two new boards.. the ASUS X79 and the ASUS P9X79PRO. My ASROCK Extreme11 will be here tomorrow.

All blame to ASUS R4E for now.
Yeah IDK what to say if it's doing that without an OC or incorrect voltages.
 
#12 ·
Aaaaaand FAIL.

X79 Fail boat - alllll aboard. Can anyone with ANY x79 board test this out for me? Any board, any CPU. I ordered my Extreme11 and it will be here tomorrow so I can test that then. I have only tried x79 ASUS boards so far.

Any kernel, doesn't matter. You can even boot in to a LiveCD. I need just the output of:
Quote:
dmesg | grep -i tsc
I can't believe this crazyness.
 
#13 ·
Verified, I have an Asus P9X79 and P9X79 PRO, they both have the problem and it's a bios problem.
The bios change from 1203 to 2104(windows bios cap support) broke the TSC initialization. I've complained to them and got the same response you received. I'm running 12.10 also.
 
#14 ·
Quote:
Originally Posted by Pagannini980 View Post

Verified, I have an Asus P9X79 and P9X79 PRO, they both have the problem and it's a bios problem.
The bios change from 1203 to 2104(windows bios cap support) broke the TSC initialization. I've complained to them and got the same response you received. I'm running 12.10 also.
Any way to go back to non CAP BIOS on any of these boards? Guess I have some Googling to do... ugh

GG http://support.asus.com/Search/KDetail.aspx?SLanguage=en&no=CCBF53F7-9084-B397-C729-7C5579704573&t=2 #3
 
#20 ·
Quote:
Originally Posted by Pagannini980 View Post

clock_gettime time should be fine now!! ;-)
And that it is. Thank you very much for the information. I owe you one.

How do we get ASUS to fix this in the latest BIOS now.. is the question. My CPU is the 3970x which isn't supported until a later BIOS, but it works.. for the most part so far
smile.gif


Gah. Annoying ASUS.
 
#22 ·
Quote:
Originally Posted by Pagannini980 View Post

I'll probably install Windoze 8, and write a program that reads the tsc's across all the cores
and show them that cpu 0's tsc is incorrect. Already did it for linux. Then they might fix it since it's Windoze.

my chip is a 3930k, btw.
Let me know if you need any help with this. I'm pretty disappointed that this happened in the first place. Pretty big bug if you ask me.
 
#24 ·
Quote:
Originally Posted by Pagannini980 View Post

Yeah, hackintosh as a kext patch that fixes this. Can't understand why linux doesn't adopt it.
Just set the tsc's upon boot... Simple...
I saw this too.. VoodooTSCSync or something like that.

I'm going to look in to it more for a possible kernel patch.
 
#26 ·
Quote:
Originally Posted by Pagannini980 View Post

Yeah, hackintosh as a kext patch that fixes this. Can't understand why linux doesn't adopt it.
Just set the tsc's upon boot... Simple...
cause there are other clock sources one can set the kernel to use, as tsc is nortorious on intel cpu's not to be "accurate". I once had my linux install refuse to boot up cause i changed from localtime to utc time, and it was the tsc not being in sync, disabled tsc on the kernel commandline with notsc, haven't had a problem since.