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.

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

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).