TSC Problem on Gigabyte GA-X79-UP4 (rev 1.1)

[ahhyes]

Hi Guys,

Am hoping someone else might be able to share their experiences with the dreaded "TSC Unstable issue.

This is what I am seeing:

ahhyes@desktop:~/$ dmesg | grep -i tsc
tsc: Fast TSC calibration using PIT
tsc: Detected 3400.060 MHz processor
TSC deadline timer enabled
TSC synchronization [CPU#0 -> CPU#1]:
Measured 39472034539 cycles TSC warp between CPUs, turning off TSC clock.
tsc: Marking TSC unstable due to check_tsc_sync_source failed

Motherboard = GA-X79-UP4 revision 1.1
Bios = F4 (was already shipped with most current version).
CPU = Intel core i7 4930k @ 3.4Ghz (LGA 2011)

I have done some reading on this problem and everything seems to lead back to the bios being the issue. I have tried adjusting a few settings in BIOS relating to power saving/management since I have also read that it can screw up the TSC.

I have been able to disable the following for the CPU cores via BIOS:

* Disabled Enhanced CPU halt - C1E State
* Disabled C3/C6 State support
* Disabled EIST Function

Made no difference. Also tried turning off the CPU turbo speed options - nothing is overclocked, everything locked at the standard 3.4Ghz, has not helped either.

Software wise, I am using Ubuntu 13.10 x64 as the OS with a Custom kernel (the TSC problem also is evident in the stock generic kernel shipped with Ubuntu).

I read an interesting quote that is apparently from a kernel developer (whilst looking for answers to the problem:

the way the hardware works is that there is 1 "master" tsc in the CPU package, that gets started when the cpu package comes out of reset. all logical cpus keep an offset value from that, which starts at 0, and the "master + offset" value is what gets returned on rdtsc. if someone writes to the tsc (using an MSR), what actually happens is that the master tsc does not change, only the per logical cpu offset gets changed.

Linux does not write to the TSC since quite a while... which means the BIOS is doing that. It really should not.

Some bioses write to the TSC to "hide" the cpu cycles used in SMM from the OS..... maybe that is going on here.

I'm not convinced this is a software issue.

I got a "less than thrilling" response from gigabyte support, clearly the 1st level support jockey who answered doesnt understand the issue:

Thank you for your kindly mail and inquiry. As we mentioned on the driver download page of GIGABYTE website, due to different Linux support condition provided by chipset vendors, please download Linux driver from chipset vendors' website or 3rd party website. Since we do not receive proper driver from chipset vender, we cannot guarantee Linux to work on our system. We suggest you use genuine version of Windows OS and try later.

Regards,
GIGABYTE

Since it's likely to be BIOS that is leaving the TSC in a screwed up state, I fail to see the relevance with the OS.

I am wanting to have a working TSC clock source because I am have applications that depend on it in order to work efficiently. Seems my system has fallen back to the HPET timer:

ahhyes@desktop:~$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
hpet

ahhyes@desktop:~$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
hpet acpi_pm

The HPET is costly to use for timing in comparison to the TSC (I saw a benchmark (cant find the link now), but a guy wrote a program to generate 10,000,000 timestamps then behcnmarked it using TSC and HPET, the difference in the time it took to generate them via HPET was staggering, much much much much slower..

I guess at this point I am wondering if anyone else has this board and has been able to fix the issue or should I just cut my losses and get a different mainboard -- I have the money to do this, I just want the problem to go away. I have a feeling I am not going to get far with gigabyte support (I did respond back and ask the support person to escalate the case to a senior engineer, but I am not holding my breath on that).

Cheers,
A.

[invisiblek]

Did you ever figure anything out with this? I just stumbled across your thread today and I'm having the same issue. Been trying to diagnose an issue I've been having compiling AOSP (taking much much longer than my previous 1366 socket i7) and I'm hoping this may be the issue.

As I said, I just recently came across this post (only had the board a week or so) so I haven't begun to dig into the kernel at all yet.

[invisiblek]

For what it's worth, this seems to be a bigger issue than just a bug with this Gigabyte board:

http://www.tomshardware.com/forum/238732-50-unstable-check_tsc_sync_source-failed

That guy has had issues with several different manufacturers.

Had some guy on irc who has a server that has an LGA2011 chip (Xeon E5-1607) which is running in hpet as well.

This sounds like it falls on Intel...

[invisiblek]

Well, the theory that this is what's hurting my builds is pretty much out the window. I forced hpet on my laptop (i5 520 @ 2.4ghz, 4gb ram, ssd) and it built in the same amount of time as it did when it was on tsc (the builds were less than a minute apart, right around 52 minutes).

[Luke]

I get this on Gigabyte/AMD but it has no real-world effect I've ever observed

Hi Guys,

Am hoping someone else might be able to share their experiences with the dreaded "TSC Unstable issue.

This is what I am seeing:



Motherboard = GA-X79-UP4 revision 1.1
Bios = F4 (was already shipped with most current version).
CPU = Intel core i7 4930k @ 3.4Ghz (LGA 2011)

I have done some reading on this problem and everything seems to lead back to the bios being the issue. I have tried adjusting a few settings in BIOS relating to power saving/management since I have also read that it can screw up the TSC.

I have been able to disable the following for the CPU cores via BIOS:

* Disabled Enhanced CPU halt - C1E State
* Disabled C3/C6 State support
* Disabled EIST Function

Made no difference. Also tried turning off the CPU turbo speed options - nothing is overclocked, everything locked at the standard 3.4Ghz, has not helped either.

Software wise, I am using Ubuntu 13.10 x64 as the OS with a Custom kernel (the TSC problem also is evident in the stock generic kernel shipped with Ubuntu).

I read an interesting quote that is apparently from a kernel developer (whilst looking for answers to the problem:



I'm not convinced this is a software issue.

I got a "less than thrilling" response from gigabyte support, clearly the 1st level support jockey who answered doesnt understand the issue:



Since it's likely to be BIOS that is leaving the TSC in a screwed up state, I fail to see the relevance with the OS.

I am wanting to have a working TSC clock source because I am have applications that depend on it in order to work efficiently. Seems my system has fallen back to the HPET timer:



The HPET is costly to use for timing in comparison to the TSC (I saw a benchmark (cant find the link now), but a guy wrote a program to generate 10,000,000 timestamps then behcnmarked it using TSC and HPET, the difference in the time it took to generate them via HPET was staggering, much much much much slower..

I guess at this point I am wondering if anyone else has this board and has been able to fix the issue or should I just cut my losses and get a different mainboard -- I have the money to do this, I just want the problem to go away. I have a feeling I am not going to get far with gigabyte support (I did respond back and ask the support person to escalate the case to a senior engineer, but I am not holding my breath on that).

Cheers,
A.

I am running a Gigabyte board with an AMD processor and always get "Marking TSC unstable due to check_tsc_sync_source failed" in dmesg, in fact have ALWAYS seen this. I always assumed this was because I overclock my CPUs and totally ignored it, treating it as simply another line in dmesg. If this was an Intel issue, how come I see it with Bulldozer and Phenom II procs, unless it is simply a common chip maker screwup?

Never had trouble because of this, but my machines are video editors, web surfers and FOSS gamers, CPU intensity of a timestamp process must not effect those very much-or I've just never seen a machine without this. Can't understand why in the world anyone at Gigabyte would think this to be grounds to run Windows. I've used Gigabyte boards for years, never used vendor tech support for any board and I guess just never expected. My demand from Gigabyte is simple: sell me the board for cash and no ID, and do not attempt to actively prevent me from booting something other than Windows. Don't have to support it, just not interfere or I will trash their reputation online like I did to T-Mobile when I had to throw away their device after discovering un-advertised, no advance notice "web-guard" censorship of prepaid accounts.