Jump to content

i7 4930k and 10.9.2 Unsynchronized TSC Errors

macattackjack

By macattackjack,
in OSx86 10.9 (Mavericks)

 Share
19 posts in this topic

Recommended Posts

macattackjack
macattackjack
Posted
Posted

Okay, reloaded system, and changed bios settings. System works

 

MSI x79MA-GD4 bios 7735v2.6

i7 4930

16gb ram (for now)

10.9.2

EVGA GeForce GT 620 2048

 

Boot Flags

 

<key>EthernetBuiltIn</key>
<string>Yes</string>
<key>GraphicsEnabler</key>
<string>no</string>
<key>Kernel Flags</key>
<string>npci=0x3000</string>
<key>UseKernelCache</key>
<string>No</string>
<key>IGPEnabler</key>
<string>Yes</string>
<key>Theme</key>
<string>Legacy</string>
<key>Timeout</key>
<string>2</string>
 

 

Graphics work with vanilla apple drivers, Internal NIC works. Sound does not work yet.

 

During boot, I'm getting these errors

 

 

"Unsynchronized TSC for cpu1: 0x0000000...... delta 0x0000000

"Unsynchronized TSC for cpu5: 0x0000000 etc"

 

The cpu numbers can vary. 

 

I am using FakeSMC, NullCPUPowerManagement from the DP1 v2 from the installation forum on this site, and the latest VoodooTCSync from it's page. NO SSDT or DSDT.

 

Using RealtekR1000SL for Internal NIC.

 

Without VoodooTCSync it goes in a boot loop. Without NullCPU PowerManagement it gets a kernel panic.

 

I've tried a modded AppleACPIPlatform with no change. Also modded VoodooTCSync supposedly for the 4930k, and the errors still come up.

 

Any ideas appreciated.

Link to comment
Share on other sites
macattackjack
macattackjack
Posted
  • Author
Posted

I tried a few different bios for the the board, starting with the first one to work with the cpu, to the latest, and they had no effect. I'm wondering as well if there's some setting in the bios for the cpu that may affect it? There are some turboboost and extra turboboost settings, etc that I wonder about. Also there's a speed limit in the bios settings for each thread, and they are not all saying the same number....

Link to comment
Share on other sites
macattackjack
macattackjack
Posted
  • Author
Posted

Makes no difference.

 

I'm using an unedited VoodooTSCSync.kext. currently the IOCPUNumber is set to 7. Setting to 1 or 11 as indicated below makes no difference. 

 

Post Installation

6 and 8 core CPUs need a special kext called 

VoodooTSCSync

 by Cosmosis Jones of VoodooProjects.


Edited for 6 core CPU with 12 Threads (IOCPUNumber=11)
Edited for 8 core CPU with 16 Threads (IOCPUNumber=15)
Link to comment
Share on other sites
macattackjack
macattackjack
Posted
  • Author
Posted

I can't remember what it was, but I think that setting a boot argument (TSC_sync_margin=0)also worked. Correct?

Well I tried that, and it didn't work, though I'm not quite sure of the syntax. I tried -tscsync=0 and -tsc_sync_margin=0. Plus, I couldn't find any documentation for it with Chameleon. Frustrated..... This OS works fine, except for this. Could it be related to the fakesmc?

Link to comment
Share on other sites
Pike R. Alpha
Pike R. Alpha
Posted
Posted

Well I tried that, and it didn't work, though I'm not quite sure of the syntax. I tried -tscsync=0 and -tsc_sync_margin=0. Plus, I couldn't find any documentation for it with Chameleon. Frustrated..... This OS works fine, except for this. Could it be related to the fakesmc?

It is "TSC_sync_margin=0" thus without the dash symbol (-) and it is also case sensitive, and with that there is no TSC checking. Just look at the XNU source code snippet from mp.c:

static void start_cpu(void *arg)
{
int i = 1000;
processor_start_info_t *psip = (processor_start_info_t *) arg;

/* Ignore this if the current processor is not the starter */
if (cpu_number() != psip->starter_cpu)
return;

DBG("start_cpu(%p) about to start cpu %d, lapic %d\n",
arg, psip->target_cpu, psip->target_lapic);

KERNEL_DEBUG_CONSTANT(
TRACE_MP_CPU_START | DBG_FUNC_START,
psip->target_cpu,
psip->target_lapic, 0, 0, 0);

i386_start_cpu(psip->target_lapic, psip->target_cpu);


#ifdef POSTCODE_DELAY
/* Wait much longer if postcodes are displayed for a delay period. */
i *= 10000;
#endif
DBG("start_cpu(%p) about to wait for cpu %d\n",
arg, psip->target_cpu);

mp_wait_for_cpu_up(psip->target_cpu, i*100, 100);

KERNEL_DEBUG_CONSTANT(
TRACE_MP_CPU_START | DBG_FUNC_END,
psip->target_cpu,
cpu_datap(psip->target_cpu)->cpu_running, 0, 0, 0);

if (TSC_sync_margin &&
   cpu_datap(psip->target_cpu)->cpu_running) {
/*
* Compare the TSC from the started processor with ours.
* Report and log/panic if it diverges by more than
* TSC_sync_margin (TSC_SYNC_MARGIN) ticks. This margin
* can be overriden by boot-arg (with 0 meaning no checking).
*/
uint64_t tsc_starter;
int64_t tsc_delta;
atomic_decl(&tsc_entry_barrier, 1);
while (tsc_entry_barrier != 0)
; /* spin for both processors at barrier */
tsc_starter = rdtsc64();
atomic_decl(&tsc_exit_barrier, 1);
while (tsc_exit_barrier != 0)
; /* spin for target to store its TSC */
tsc_delta = tsc_target - tsc_starter;
kprintf("TSC sync for cpu %d: 0x%016llx delta 0x%llx (%lld)\n",
psip->target_cpu, tsc_target, tsc_delta, tsc_delta);
if (ABS(tsc_delta) > (int64_t) TSC_sync_margin) { 
#if DEBUG
panic(
#else
printf(
#endif
"Unsynchronized  TSC for cpu %d: "
"0x%016llx, delta 0x%llx\n",
psip->target_cpu, tsc_target, tsc_delta);
}
}
}

source: http://www.opensource.apple.com/source/xnu/xnu-2422.1.72/osfmk/i386/mp.c

 

Not related to FakeSMC.kext and Chameleon doesn't know jack.

 

p.s. sorry for the broken layout but that's just caused by the broken forum software.

Link to comment
Share on other sites
macattackjack
macattackjack
Posted
  • Author
Posted

Okay... that removed that error. Thanks :)

 

If I understand it correctly then, it's telling the OS Not to check if the cores are synced.

 

The question is, is this a bad thing?

 

There's a person on the forum that has the asus sabertooth x79, and it has a "sync all cores" setting in the bios, which solves this problem too. Alas, the MSI board doesn't have that option either in the regular bios settings or the overclocking settings.

 

Interestingly, (or maybe not) when I called MSI about this, the tech said he'd have to elevate the problem to the next tech level and they'd call me back. They didn't and I haven't had time to call them yet. It's frustrating that the i7-3820 with the older bios doesn't cause the error, but the i7-3820 with the updated bios needed to run the i7-4930k does.

Link to comment
Share on other sites
Pike R. Alpha
Pike R. Alpha
Posted
Posted
Okay... that removed that error. Thanks :)

Cool.

 

If I understand it correctly then, it's telling the OS Not to check if the cores are synced.

Sort of. Normally the margin is set to 4096 but now there is no check anymore. Same thing happens when you run OS X in a virtual machine.

 

The question is, is this a bad thing?

Maybe. Have you tried sleep/wake? Fact is. You can boot without the kext.

 

There's a person on the forum that has the asus sabertooth x79, and it has a "sync all cores" setting in the bios, which solves this problem too. Alas, the MSI board doesn't have that option either in the regular bios settings or the overclocking settings.

Contact that person and ask him to run sysctl -a and check the cpu features. In particular bit 24. Does that change?

 

Perhaps you can try TSC_deadline_timer=0 as well. With and without the TSC_sync_margin=0.

Note that the line: ""TSC Deadline Timer supported and enabled" will change into: ""TSC Deadline Timer supported but not enabled" (see: sudo dmesg and/or cat /var/log/system.log) 

 

It's frustrating that the i7-3820 with the older bios doesn't cause the error, but the i7-3820 with the updated bios needed to run the i7-4930k does.

Huh? Sorry, but you lost me there.

Link to comment
Share on other sites
macattackjack
macattackjack
Posted
  • Author
Posted

"Maybe. Have you tried sleep/wake? Fact is. You can boot without the kext."

 

I can't boot without the VoodooTSCSync.kext. It goes into a boot cycle

 

"Huh? Sorry, but you lost me there."

 

I have another computer with a MSI X79A-GD45 and i7-3820. It has two bios on the board with the capability to go back and forth between the two. Using the 10.9.2 install on the drive for the MSI X79MA-GD45 i7-4930k @3.4, I connected it on the 3820 computer, and using the bios version 7735v1.6 the system reports no unsynchronized TCS errors. Switching to bios 7735v2.7 (The latest UEFI enabled bios) the verbose booting shows the unsynchronized errors, unknown cpu and smc errors, the same as the 4930k computer.

 

I will try those other options as well and see what comes up. 

Link to comment
Share on other sites
joe75
joe75
Posted
Posted

Okay... that removed that error. Thanks :)

 

If I understand it correctly then, it's telling the OS Not to check if the cores are synced.

 

The question is, is this a bad thing?

 

There's a person on the forum that has the asus sabertooth x79, and it has a "sync all cores" setting in the bios, which solves this problem too. Alas, the MSI board doesn't have that option either in the regular bios settings or the overclocking settings.

 

Interestingly, (or maybe not) when I called MSI about this, the tech said he'd have to elevate the problem to the next tech level and they'd call me back. They didn't and I haven't had time to call them yet. It's frustrating that the i7-3820 with the older bios doesn't cause the error, but the i7-3820 with the updated bios needed to run the i7-4930k does.

 

* Compare the TSC from the started processor with ours.

* Report and log/panic if it diverges by more than

* TSC_sync_margin (TSC_SYNC_MARGIN) ticks. This margin

* can be overriden by boot-arg (with 0 meaning no checking).

 

That masked the error and did not remove it.. Yes, this command is telling the kernel to ignore the out of spec timing that would normally panic the system and yes it is a bad thing to run an os without tsc synced across all cores. This is something that should not happen normally.. It is up to the OEMs on how to incorporate tsc support into the system so different bios or different vendors will always handle it differently.

 

I have first hand knowledge of tscsync problems from having a T5500 Merom cpu which were one of the first chips to experience the problem with osx in 4.8. We had no choice but to boot with cpus=1. I spent a couple months working with a few different people to try figuring it out. After much whining and complaining to all the kernel devs at that time I finally got an old user named oui to agree to look in to making an actual fix, luckily he had a dell laptop that had a similar cpu with the same problem. oui came back to me with a tscsync patched kernel to test and it worked! That turned into the voodoo tsc kernel patch. I later shared the patch and some work Kabyl and I had tried with cosmo1t and he came back with the voodootscsync kext and we have seemed to have it fixed for the most part ever since. :D  One bad thing about osx is if the system is able to boot with out of sync cores the timing goes even further out of sync the longer the up time, so even if you manage to boot a system panic is inevitable.

  • Like 1
Link to comment
Share on other sites
Pike R. Alpha
Pike R. Alpha
Posted
Posted

"Maybe. Have you tried sleep/wake? Fact is. You can boot without the kext."

 

I can't boot without the VoodooTSCSync.kext. It goes into a boot cycle

Ok. Your: "Okay... that removed that error. Thanks" somehow gave me the impression that the boot argument worked. I don't understand why you didn't mention the reboot cycle, which by the way is rather strange because that should not happen. Even with a huge TSC drift.

 

But having a board with two different BIOS versions is cool. That enables you to run sysctl -a with both and see if there is something that pops out. Can you zip the output (of both) and attach it here?

Link to comment
Share on other sites
macattackjack
macattackjack
Posted
  • Author
Posted

Ok. Your: "Okay... that removed that error. Thanks" somehow gave me the impression that the boot argument worked. I don't understand why you didn't mention the reboot cycle, which by the way is rather strange because that should not happen. Even with a huge TSC drift.

 

But having a board with two different BIOS versions is cool. That enables you to run sysctl -a with both and see if there is something that pops out. Can you zip the output (of both) and attach it here?

Yes, and the switch also allows you to boot with a good bios, flip the switch, then reflash a bad bios, so you don't have to send it back to the manufacturer.

 

Joe75, is that patched VoodooTSCSync.kext you ended up with posted anywhere?

 

Pike, I will try that. I forget, how do I get the output?

Link to comment
Share on other sites
Pike R. Alpha
Pike R. Alpha
Posted
Posted

Unless I hear otherwise, getting those errors is not a good thing. Nor do I think that the system logging would report those errors if it wasn't important. 

Ok. I located the error in the CPU microcode and what you can do is use the old microcode, or ask the vendor to fix this for you. My advise is to replace the microcode in the latest BIOS with the one without the TSC errors. Only then the TSC messages will stop showing up in your log file. That's a fact.

 

Tip: http://donovan6000.blogspot.nl/2013/06/insyde-bios-modding-cpu-microcodes.html

 

Good luck!

Link to comment
Share on other sites
  • 4 weeks later...
macattackjack
macattackjack
Posted
  • Author
Posted

Well, after some consideration, most of which was the fact that MSI was not really responding to the microcode issue, plus the fact that their support of physically damaged MB's is to issue a refurbished one replacement even if the board is new, I got myself an Asus Sabertooth X79 and all the problems went away.

 

I have not attempted to get audio working, though I may at some point.

 

Multiple LAN cards, that is, using the internal LAN plus a PCI-E gigabit card continue to be a challenge on this board as well. The main program I use midioverlan, will see the card, but does not completely communicate with it and is not functional if both LANs are on. I had this same issue with 10.9.2 on the MSI X79A-GD45, and the MSI X58M. By itself the LAN kext works fine. Combined with another LAN card, it doesn't like it. Some afternoon when I'm in the mood to torture myself I will see if I can get it to work, but it's not looking good.

 

For now, the system runs well and the main sequencing app runs well and is faster than my build with the 3820, which is what I was going for.

 

Thanks all for your help and thanks Pike for the micro codes, but it just got to be too mod-y of an install for me. 

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...