Contribute
Register

Asus X99 - Catalina Support

Joined
Nov 4, 2019
Messages
5
Motherboard
Asus X99 Deluxe II
CPU
E5-2678 V3
Graphics
RX 580
Working on updating from Mojave to Catalina. Ran into some issue and will post that in a bit but I wanted to drop this here for anyone who needs to unlock their BIOS. Or if you have a specific bios you need to be unlocked let me know (I can also preset settings need for your Hackintosh).
 

Attachments

Last edited:
Joined
Nov 4, 2019
Messages
5
Motherboard
Asus X99 Deluxe II
CPU
E5-2678 V3
Graphics
RX 580
Thanks working on fixing it now. SSDT issues are at least easy fixes.
THB I was just searching for apfs_module_start but 1683 yields much better results lol
 
Last edited:
Joined
Dec 17, 2019
Messages
1
Motherboard
Asus x99-PRO (First one, not usb3.1)
CPU
5930k
Graphics
Sapphire pulse Radeon 5700xt
After much trouble i got past apfs_module_start 1683, then prohabition sign, now im stuck on gi0screenlockstate 3 which causes it to just reboot, attached is my clover folder. Any help would be greatly appreciated.

Specs:
MB: Asus X99-Pro
CPU: 5930k
GPU: rx 5700xt
 

Attachments

Joined
Sep 21, 2013
Messages
23
Motherboard
Asus Sabertooth X99
CPU
i7-5820K
Graphics
RX Vega 56
Mac
MacBook Pro, Mac mini, Mac Pro
Classic Mac
iBook, iMac, Performa, Power Mac, PowerBook, Xserve
Mobile Phone
iOS
I updated my EFI distribution with the EC fix. I was stumped with the Catalina installer not booting and I researched the fixed. The EC patches are added for those who have a Sabertoooth X99 setup. It should work on other Asus X99 boards as well.
 
Joined
Mar 29, 2011
Messages
619
Motherboard
ASRock X99 Extreme6
CPU
E5-2690 v4
Graphics
Radeon VII
After much trouble i got past apfs_module_start 1683, then prohabition sign, now im stuck on gi0screenlockstate 3 which causes it to just reboot, attached is my clover folder. Any help would be greatly appreciated.
Sounds like a kernel panic during graphics initialization. You didn't say if this is booting the installer, or the installed system. If the latter, you might have a report left behind in /Library/Logs/DiagnosticReports that you can read from the installer in Terminal.
 
Joined
Mar 29, 2011
Messages
619
Motherboard
ASRock X99 Extreme6
CPU
E5-2690 v4
Graphics
Radeon VII
I'm on Mojave, not Catalina. But has anyone else on X99 seen kernel panics like the log below?

I've had two now, once from hidd and once from coreaudiod. But with the same panic message in _pmap_flush_tlbs, "IPI timeout, unresponsive CPU."

Code:
Thu Jan  2 17:11:07 2020

*** Panic Report ***
mp_kdp_enter() timed-out on cpu 2, NMI-ing
mp_kdp_enter() NMI pending on cpus: 0 8 9
mp_kdp_enter() timed-out during locked wait after NMI;expected 28 acks but received 26 after 26840347 loops in 1237971312 ticks
panic(cpu 2 caller 0xffffff801c8b6ead): "IPI timeout, unresponsive CPU bitmap: 0x100, NMIPI acks: 0x0, now: 0x0, deadline: 609775069647568, pre-NMIPI time: 0x22a96526b53fa, current: 0x22a967038ba84, global: 1"@/BuildRoot/Library/Caches/com.apple.xbs/Sources/xnu/xnu-4903.278.12/osfmk/x86_64/pmap.c:3038
Backtrace (CPU 2), Frame : Return Address
0xffffff87570ab620 : 0xffffff801c7af57d mach_kernel : _handle_debugger_trap + 0x47d
0xffffff87570ab670 : 0xffffff801c8eb065 mach_kernel : _kdp_i386_trap + 0x155
0xffffff87570ab6b0 : 0xffffff801c8dc79a mach_kernel : _kernel_trap + 0x50a
0xffffff87570ab720 : 0xffffff801c75c9d0 mach_kernel : _return_from_trap + 0xe0
0xffffff87570ab740 : 0xffffff801c7aef97 mach_kernel : _panic_trap_to_debugger + 0x197
0xffffff87570ab860 : 0xffffff801c7aede3 mach_kernel : _panic + 0x63
0xffffff87570ab8d0 : 0xffffff801c8b6ead mach_kernel : _pmap_flush_tlbs + 0x5ed
0xffffff87570ab990 : 0xffffff801c8bd576 mach_kernel : _pmap_remove_range_options + 0x266
0xffffff87570aba70 : 0xffffff801c8be226 mach_kernel : _pmap_remove_options + 0xb6
0xffffff87570abae0 : 0xffffff801c847949 mach_kernel : _vm_map_destroy + 0x909
0xffffff87570abc40 : 0xffffff801c84f545 mach_kernel : _vm_map_remove + 0x75
0xffffff87570abc80 : 0xffffff801c842c0b mach_kernel : _kmem_free + 0x8b
0xffffff87570abcb0 : 0xffffff801cdeaaf0 mach_kernel : __ZN11OSSerialize4freeEv + 0x30
0xffffff87570abcd0 : 0xffffff801ce8d6ff mach_kernel : _is_io_registry_entry_get_property_bin + 0x1df
0xffffff87570abd30 : 0xffffff801c898c48 mach_kernel : _iokit_server_routine + 0x75d8
0xffffff87570abd80 : 0xffffff801c7b4dbc mach_kernel : _ipc_kobject_server + 0x12c
0xffffff87570abdd0 : 0xffffff801c78fb31 mach_kernel : _ipc_kmsg_send + 0xd1
0xffffff87570abe50 : 0xffffff801c7a424e mach_kernel : _mach_msg_overwrite_trap + 0x3ce
0xffffff87570abef0 : 0xffffff801c8c26d7 mach_kernel : _mach_call_munger64 + 0x257
0xffffff87570abfa0 : 0xffffff801c75d1b6 mach_kernel : _hndl_mach_scall64 + 0x16

BSD process name corresponding to current thread: coreaudiod
Boot args: darkwake=0 npci=0x2000 keepsyms=1 debug=0x100 

Mac OS version:
18G1012

Kernel version:
Darwin Kernel Version 18.7.0: Sat Oct 12 00:02:19 PDT 2019; root:xnu-4903.278.12~1/RELEASE_X86_64
Kernel UUID: [snip]
Kernel slide:     0x000000001c400000
Kernel text base: 0xffffff801c600000
__HIB  text base: 0xffffff801c500000
System model name: iMacPro1,1 (Mac-7BA5B2D9E42DDD94)

System uptime in nanoseconds: 609776570943494
last loaded kext at 562230186695775: com.apple.driver.AppleXsanScheme    3 (addr 0xffffff7fa2c75000, size 32768)
last unloaded kext at 562313343194787: com.apple.driver.AppleXsanScheme    3 (addr 0xffffff7fa2c75000, size 32768)
loaded kexts:
com.radiosilenceapp.nke.filter    2.2
as.acidanthera.BrcmPatchRAM3    2.5.0
as.acidanthera.BrcmFirmwareStore    2.5.0
org.hwsensors.driver.GPUSensors    1802
org.hwsensors.driver.LPCSensors    1802
com.insanelymac.IntelMausiEthernet    2.3.0
hu.interferenc.TSCAdjustReset    1.1
org.hwsensors.driver.CPUSensors    1802
as.vit9696.AppleALC    1.3.6
org.tw.CodecCommander    2.6.3
org.netkas.driver.FakeSMC    1802
as.lvs1974.AirportBrcmFixup    2.0.4
as.vit9696.WhateverGreen    1.3.4
as.vit9696.Lilu    1.3.9
com.apple.driver.AudioAUUC    1.70
com.apple.fileutil    20.036.15
com.apple.filesystems.autofs    3.0
com.apple.driver.AppleUpstreamUserClient    3.6.5
com.apple.driver.AppleMCCSControl    1.5.9
com.apple.kext.AMDFramebuffer    2.1.1
com.apple.filesystems.ntfs    3.13
com.apple.driver.X86PlatformShim    1.0.0
com.apple.driver.ApplePlatformEnabler    2.7.0d0
com.apple.driver.AGPM    110.25.11
com.apple.driver.AppleHDA    282.54
com.apple.kext.AMDRadeonX5000    2.1.1
com.apple.AGDCPluginDisplayMetrics    3.50.14
com.apple.driver.AppleHV    1
com.apple.iokit.IOUserEthernet    1.0.1
com.apple.iokit.IOBluetoothSerialManager    6.0.14d3
com.apple.driver.pmtelemetry    1
com.apple.Dont_Steal_Mac_OS_X    7.0.0
com.apple.kext.AMD10000Controller    2.1.1
com.apple.driver.eficheck    1
com.apple.driver.AppleGFXHDA    100.1.414
com.apple.driver.AppleIntelSlowAdaptiveClocking    4.0.0
com.apple.driver.AppleOSXWatchdog    1
com.apple.driver.AppleVirtIO    2.1.3
com.apple.filesystems.hfs.kext    407.200.4
com.apple.AppleFSCompression.AppleFSCompressionTypeDataless    1.0.0d1
com.apple.BootCache    40
com.apple.AppleFSCompression.AppleFSCompressionTypeZlib    1.0.0
com.apple.AppleSystemPolicy    1.0
com.apple.iokit.SCSITaskUserClient    408.250.3
com.apple.filesystems.apfs    945.275.8
com.apple.driver.AirPort.Brcm4360    1400.1.1
com.apple.driver.AirPort.BrcmNIC    1400.1.1
com.apple.driver.AppleAHCIPort    329.260.5
com.apple.private.KextAudit    1.0
com.apple.driver.AppleACPIButtons    6.1
com.apple.driver.AppleHPET    1.8
com.apple.driver.AppleRTC    2.0
com.apple.driver.AppleSMBIOS    2.1
com.apple.driver.AppleAPIC    1.7
com.apple.nke.applicationfirewall    202
com.apple.security.TMSafetyNet    8
com.apple.driver.usb.IOUSBHostHIDDevice    1.2
com.apple.driver.usb.AppleUSBHostCompositeDevice    1.2
com.apple.kext.triggers    1.0
com.apple.driver.AppleSMBusController    1.0.18d1
com.apple.iokit.IOSMBusFamily    1.1
com.apple.driver.DspFuncLib    282.54
com.apple.kext.OSvKernDSPLib    528
com.apple.kext.AMDRadeonX5000HWLibs    1.0
com.apple.iokit.IOAcceleratorFamily2    404.14
com.apple.kext.AMDRadeonX5000HWServices    2.1.1
com.apple.iokit.IOAVBFamily    760.6
com.apple.plugin.IOgPTPPlugin    740.2
com.apple.iokit.IOEthernetAVBController    1.1.0
com.apple.iokit.IOSkywalkFamily    1
com.apple.driver.AppleSSE    1.0
com.apple.iokit.IOSurface    255.6.1
com.apple.driver.AppleHDAController    282.54
com.apple.iokit.IOHDAFamily    282.54
com.apple.AppleGPUWrangler    3.50.14
com.apple.iokit.IONDRVSupport    530.51
com.apple.kext.AMDSupport    2.1.1
com.apple.AppleGraphicsDeviceControl    3.50.14
com.apple.iokit.IOGraphicsFamily    530.67
com.apple.iokit.IOSlowAdaptiveClockingFamily    1.0.0
com.apple.driver.X86PlatformPlugin    1.0.0
com.apple.driver.IOPlatformPluginFamily    6.0.0d8
com.apple.driver.usb.networking    5.0.0
com.apple.iokit.BroadcomBluetoothHostControllerUSBTransport    6.0.14d3
com.apple.iokit.IOBluetoothHostControllerUSBTransport    6.0.14d3
com.apple.iokit.IOBluetoothHostControllerTransport    6.0.14d3
com.apple.iokit.IOBluetoothFamily    6.0.14d3
com.apple.driver.usb.AppleUSBHub    1.2
com.apple.iokit.IOSerialFamily    11
com.apple.filesystems.hfs.encodings.kext    1
com.apple.driver.AppleUSBMergeNub    900.4.2
com.apple.driver.AppleUSBHostMergeProperties    1.2
com.apple.driver.usb.AppleUSBHostPacketFilter    1.0
com.apple.iokit.IOUSBFamily    900.4.2
com.apple.iokit.IOSCSIMultimediaCommandsDevice    408.250.3
com.apple.iokit.IOBDStorageFamily    1.8
com.apple.iokit.IODVDStorageFamily    1.8
com.apple.iokit.IOCDStorageFamily    1.8
com.apple.iokit.IOAHCIBlockStorage    301.270.1
com.apple.iokit.IO80211Family    1200.12.2
com.apple.driver.mDNSOffloadUserClient    1.0.1b8
com.apple.driver.corecapture    1.0.4
com.apple.iokit.IOAHCISerialATAPI    267.50.1
com.apple.iokit.IONVMeFamily    2.1.0
com.apple.iokit.IOAHCIFamily    288
com.apple.driver.usb.AppleUSBXHCIPCI    1.2
com.apple.driver.usb.AppleUSBXHCI    1.2
com.apple.driver.AppleEFINVRAM    2.1
com.apple.iokit.IOHIDFamily    2.0.0
com.apple.driver.AppleEFIRuntime    2.1
com.apple.security.quarantine    3
com.apple.security.sandbox    300.0
com.apple.kext.AppleMatch    1.0.0d1
com.apple.iokit.IOAudioFamily    206.5
com.apple.vecLib.kext    1.2.0
com.apple.driver.DiskImages    493.0.0
com.apple.driver.AppleFDEKeyStore    28.30
com.apple.driver.AppleEffaceableStorage    1.0
com.apple.driver.AppleKeyStore    2
com.apple.driver.AppleUSBTDM    456.260.3
com.apple.driver.AppleMobileFileIntegrity    1.0.5
com.apple.iokit.IOUSBMassStorageDriver    145.200.2
com.apple.iokit.IOSCSIBlockCommandsDevice    408.250.3
com.apple.iokit.IOSCSIArchitectureModelFamily    408.250.3
com.apple.iokit.IOStorageFamily    2.1
com.apple.kext.CoreTrust    1
com.apple.driver.AppleCredentialManager    1.0
com.apple.driver.KernelRelayHost    1
com.apple.iokit.IOUSBHostFamily    1.2
com.apple.driver.usb.AppleUSBCommon    1.0
com.apple.driver.AppleBusPowerController    1.0
com.apple.driver.AppleSEPManager    1.0.1
com.apple.driver.IOSlaveProcessor    1
com.apple.iokit.IOReportFamily    47
com.apple.iokit.IOTimeSyncFamily    740.2
com.apple.iokit.IONetworkingFamily    3.4
com.apple.driver.AppleACPIPlatform    6.1
com.apple.driver.AppleSMC    3.1.9
com.apple.iokit.IOPCIFamily    2.9
com.apple.iokit.IOACPIFamily    1.4
com.apple.kec.pthread    1
com.apple.kec.Libm    1
com.apple.kec.corecrypto    1.0

EOF
 
Joined
Jul 23, 2011
Messages
58
Motherboard
Supermicro X11DAi-N
CPU
2x Platinum 8260M
Graphics
Radeon VII
Mac
Mac Pro
Classic Mac
Classic, Power Mac, PowerBook, Quadra, SE
Mobile Phone
iOS
I'm on Mojave, not Catalina. But has anyone else on X99 seen kernel panics like the log below?

I've had two now, once from hidd and once from coreaudiod. But with the same panic message in _pmap_flush_tlbs, "IPI timeout, unresponsive CPU."
Yes, I have seen that panic a number of times. I can tell you exactly what the cause is too, and how to fix it... or that you can't fix it, depending. If you aren't interested in the cause, just skip all this technical mumbo jumbo and go to the bottom of this post, where it says, 'OK, good news/bad news time.'

You may also see panics that reference TLB Invalidation, amongst other things. There are a few different situations that lead to this panic, so there are a few superficially different panic messages you may see, but they're all actually caused by the same issue. The smoking gun is this panic will always manifest as one or more CPUs locking up, so you'll see something like 'unresponsive CPU', timeout, NMI (non-maskable interrupt - something that should override whatever a CPU is doing and force it to perform a priority task), IPI timeouts, etc.

The BSD process it occurs in is irrelevant - this is simply whatever process was running on that CPU before a context switch (switching to a different process so it might have its share of CPU time) occurred (or more accurately, before the context switch was attempted... because instead of completing, the machine locked up and/or got a kernel panic).

You might notice that 'tlb' is in the name of the function in the stack trace you referenced. These panics always occur due to something involving the Translation lookaside buffer (TLB). This is table that typically lives in either the L1 or L2 cache of a CPU core. If you're curious, there is a fairly technical description of TLBs on wikipedia, but the quick and dirty description is that a TLB is table that maps virtual memory addresses being used for the currently running process on a CPU to physical memory addresses. In other words, it lets a CPU know where to look for whatever a running process has in memory.

Unfortunately, the moment a context switch occurs that is switching to a different process (versus merely switching to a different thread of the same process), this effectively means a completely different program is now being run by a given CPU, and the data it has stored in memory and addresses to that data is, understandably, completely different.

This causes a TLB invalidation, which is a fancy way of saying that the TLB is outdated and a new one generated. TLB flushing is part of this process, specifically clearing out the old table. So this is something that occurs when most (though there are certain exceptions) process-level context switches occur on any CPU core.

And a bug in Intel's microcode for certain CPU families causes TLB invalidation (which is handled in hardware by the CPU) to (very rarely) take much, much longer than it should.

This bug effects all CPUs in the following families:
  • Intel Xeon E5-2600-v4
  • Intel Xeon E5-4600-v4
  • Intel Xeon E7-8800-v4
  • Intel Xeon E7-4800-v4
  • Intel Xeon D-1500
In other words, your CPU, a Xeon E5-2690 v4, is most definitely one of the CPUs effected by this microcode bug. Understand that this is nothing involving macOS, and you can expect similar panics to occur (usually mentioning the same thing, TLB invalidation/flushing, and/or failed acks/NMI/IPI/processor lockup/unresponsive processor) in any operating system. It will occur in Linux as well as Windows, though it may simply manifest as an unrecoverable freeze/lockup, or may trigger a panic, it is really down to how the kernel is set up to handle this. And this (TLB invalidation taking an impossibly long time) is not really something that should ever happen, hence being handled in ungraceful ways like just locking up without even printing panic text.

This actually is likely happening to you several times without you even realizing it, but only sometimes is it severe enough to cause a panic.

A CPU should respond to an interrupt within a certain amount of time. Regardless, a CPU can only respond to an interrupt in between instructions. In other words, the transition where it has completed one instruction, but has yet to start the next one. TLB invalidation has a specific assembly instruction on x86 processors, INVLP. So this bug which causes TLB invalidation to take much longer than it should also occurs entirely during an instruction. Meaning that the CPU will not respond to any interrupt during this time. The panics are perfectly accurate - that CPU core was, in fact, completely unresponsive because it was processing this TLB invalidation instruction.


There are 3 ways this can play out:

1. A TLB invalidation takes an unusually long amount of time to complete, but it still completes quickly enough that the CPU core responds to an interrupt before some hard coded kernel/OS-specific timeout elapsed. As long as this timeout is never reached, there is never a panic. This sort of erroneous behavior, for reasons (maybe) only known to intel, tend to be clustered, meaning many will begin occurring over the span of a few seconds. This can manifest as sudden cursor choppiness or the system clock failing to update in the menu for a few seconds, only to skip ahead once the issue resolves. Besides briefly reducing system performance slightly, these are generally harmless, albeit annoying if you notice.
2. A TLB invalidation again takes a lot longer than it should, but this time it runs out an interrupt timeout timer in the OS, which results in a panic, but it is at least able to log the panic text etc.
3. Sometimes another core will timeout while the panic is being logged for another, initial timeout. What results is kind of hilarious: a panic log that is truncated by a second panic occurring in the middle of writing out the log of the first panic. Literally a panic inside a panic. This can be very bizarre to see in a panic log. Though, there often will not be one when this happens. Depending on the timing, this often simply results in a hard lockup of the system, just totally frozen (cursor movement may or may not be functional), but all other screen redraws will simply stop. No log, no panic text, the computer simply... stops. It'll burn watts in this state as power management is no longer functional as well. I have personally observed this one to occur in Windows and Ubuntu in addition to macOS.

No one outside of intel knows the exact nature of this bug, but it seems to have a very strong stochastic element to it. Don't try to look for any sort of pattern - these panics truly are random. The only thing that really has an impact is how many context switches are occurring. If you imagine that every context switch has an extremely small chance of causing this CPU hang to occur, then the more context switches that occur in a given time, the higher the chances of this lock up occurring. If you max out every core and all your RAM running a bunch of docker containers, you can almost certainly trigger this reliably in a span of 4-6 hours. Other times, it can occur every 1-3 days, and sometimes seem to vanish for a week or even 2 weeks, but it will never go away. It will inevitably crash your system. It is just as likely to occur while your computer is mostly idle or you aren't even using it (but it is awake), as when you are actively using it.


OK, good news/bad news time.

The good news is that if you have a production/retail version of any of the CPUs in any of the Xeon families I listed earlier (E5-2600-v4, E5-4600-v4, E7-8800-v4, and D-1500), then intel released a microcode update that fixes the bug entirely, and this will completely resolve these panics and TLB invalidation will no longer take anything except the normal amount of time to complete. Microcode is included in the BIOS, so the fix is, hopefully, as simple as updating your motherboard's BIOS to the latest version. Many mobo manufacturers aren't always the best at making sure to include the latest microcode in their BIOSes however, so if the latest Asus BIOS doesn't have microcode newer than, in your case, 0x0b00001b, then you're still not out of luck. You can replace the microcode with the newer version in the BIOS file before you flash it. The Win-raid forums will have all the information you need to do this safely, but such an involved procedure is beyond the scope of this post.

The bad news is that if you do not have a retail version of the E5-2690 v4, and instead have any of the 'ES' (engineering sample) processor steppings (you can tell by clock speed - retail is clocked at 2.6GHz, the engineering samples are clocked at either 2.1GHz or 2.4GHz)... then your CPU does not use the microcode mentioned above. It has a completely different microcode specific to the ES steppings, and intel has not released any updated microcode for these CPUs. The bug is still there, and there is no fix. Simply put, you're **** out of luck. Intel has not even released updated microcodes to fix critical security vulnerabilities like Spectre or Meltdown, none the less this bug, and its been over 2 years since the fix was issued for the retail cpu microcodes. It is safe to say that intel is never going to release updated microcodes that fix this bug for ES versions of these CPUS.

I hope you have the retail version of the E5-2690 v4. If you have an engineering sample, there is nothing you can do. You will suffer sporadic crashes that occur at random, usually every few days to couple of weeks, for as long as you use an E5 v4 engineering sample of any kind. Your options are to simply live with it, shell out the (very high) price for a full retail Xeon CPU, or downgrade to a non-xeon core cpu that fits in an LGA2011 v3. Or another option might be to switch to a v3 (Haswell) Xeon. Engineering samples included. I do not believe this bug effects the Haswell versions, retail or otherwise. I am not 100% certain about that however.

But I mean, this is the kind of risk one takes on when purchasing an engineering sample. The discounted price isn't due to being clocked 100 or 200MHz lower (and really, who cares), it is due to the chance of things like these. If microcode bugs are discovered, or security exploits, or what have you, then they aren't going to be fixed for the engineering sample steppings. Most of the time, ES versions of chips are totally fine and you get a sweet chip at a sweet price. But in this case, if you bought an ES version of any E5-26xx v4 Xeon, your luck ran out.

C'est la vie
 
Last edited:
Joined
Mar 29, 2011
Messages
619
Motherboard
ASRock X99 Extreme6
CPU
E5-2690 v4
Graphics
Radeon VII
@metacollin, Wow, thanks for that! I definitely didn't skip to the end - it was fascinating!

As for my exact choice of CPU, yeah, I'm out of luck. ;) I knew that I wouldn't be getting any updates from Intel when I got it, heh. That's too bad, though. I can live with it. The lockup is more like every couple weeks, for me.

This will give me an interesting story to tell the students who use this computer, if it happens while they're working on something. :lol: Thanks!
 
Top