i9 9820X kernel panic on install

[kgp]

@kgp I did implement my own TSCAdjustReset.kext, which I changed the IOCPUNumber to 19 (20 threads -1)

My setup:
Motherboard: Asus Prime X299 Deluxe II (latest BIOS version 0404)
CPU:i9-9820X (10 Cores 20 Threads)
GPU:GTX970 4GB / RX570&580 4GB
RAM:32GB Kingston DDR4 2666MHz
SSD: Sandisk A400 512GB
macOS USB Install Drive: Kingston DataTraveler 16GB

My BIOS setting screenshots are at #7

I mainly used your X299 EFI files to install macOS 10.13.6 and 10.14.2, and added AppleALC, Lilu, Whatevergreen, USBInjectAll, SmallTree-Intel-211-AT-PCIe-GBE and my ownTSCAdjustReset kext into the kext folder.
The EFI files now I am using are in the attachments but I am having the same KP with @dolgarrenan during the installation.

Thank you for your support in advance!!

Well flying over your BIOS settings and EFI-Folder, there is nothing really suspicious that could be the source of your kernel panics during early boot.

Are you observing the same KPs under both 10.13.6 and 10.14.2?

Note the following inconsistencies in your config.plist at least under 10.14.2.

a.) The USB port limit patch might not work at all. Thus even by using USBInjectAll.kext, most of your XHCI USB3.0 ports will be non-functional without any additional SSDT, where you explicitly define the 15 HS/SS ports to be implemented. I recommend to use in the meanwhile the truncated 15-port XHC USB kext for the Prime X299 Deluxe instead, which should be largely compatible also with the Prime X299 Deluxe II. Once you have a working build, I would like you to ask to do a USB port discovery and modify the fully implemented and truncated 15-port XHC USB kexts for the ASUS Prime X299 Deluxe for their use with the ASUS Prime X299 Deluxe II accordingly. The approach is easy and straight and might be a question of no more than 30 min of work to invest.

b.) Remove all USB entries in your config.plist under Section "devices" of Clover Configurator (uncheck "Inject" and "FixOwnership"). Also concerning Audio uncheck "AFGLowPowerState" and "ResetHDA". Also disable "LanInjection".

c.) Now the likely important part! In your config.plist under Kernel and Kext patches, xcpm_core_scope_msrs © Pike R. Alpha is enabled, although you disabled the MSR lock in your BIOS settings. Please disable xcpm_core_scope_msrs © Pike R. Alpha!

If your KP issues at early boot persist, try to play with the AVX and AVX-512 offsets.

Another issue might be the Sensor kexts, which might not be fully compatible with the Asus Prime X299 Deluxe II or the i9-9820X yet. Your KPs in a away point to that, although I would not really believe the Sensor kexts to be the source of your issue. You can remove all Sensor kexts for testing purposes. However, you will have to include some FakeSMC.kext though.

Take note that @izo1 repeatedly confirmed full compatibility of the ASUS Prime X299 Deluxe II and i9-7900X with my guide, including BIOS settings and EFI-Folder distribution. See e.g. but not only his recent post #1,208.

I therefore would not know any reason why your ASUS Prime X299 Deluxe II should behave differently.

There is a noob question though from my side:

I know about the Intel i9-99xx series. I never heard about an Intel i9-98XX series.. Can you explain me the difference between e.g. an i9-9920X and your i9-9820X, apart from the reduced core number, stock base frequency and stock turbo frequency? Maybe other differences with this CPU might be the source of your current issues?

Investigating https://ark.intel.com/products/189121/Intel-Core-i9-9820X-X-series-Processor-16-5M-Cache-up-to-4-20-GHz-, it says that the i9-9820X is rather a Skylake CPU than Skylake-X, which could imply some incompatibly with X299 and your ASUS Prime X299 Deluxe II.. Although investigating https://ark.intel.com/de/products/1...series-Processor-19-25M-Cache-up-to-4-50-GHz-, one finds similar statements and information and the i9-9920X is indeed fully compatible with X299 and the ASUS Prime X299 Deluxe II. Both the i9-9820X and i9-9920X are FCLGA2066 socket processors. Thus, also any incompatibly with X299 should be generally excluded. Maybe the i9-9820X is not yet considered in firmware 0404 for the ASUS Prime X299 Deluxe II, thus indeed some respective microcode still needs to implemented in the ASUS Prime X299 Deluxe II firmware?

 

[dolgarrenan]

The i9-7900X is one of the CPUs most used along my threads. It is absolutely free of issues, which also states for all other Skylake-X CPUs.

Above 4G decoding must not be necessarely enabled with X299.

And finally, what for are you making a TB SSDT, if the latter is anyway part of my X299 SSDT Github repository and just needs to be adopted in your case?

Hi @kgp thanks for your info, I have built around 10 to 12 x299 with 7900X for my studio and friends (obviously they where drooling with configurations!), and some presented issues while working adobe suit 2018, which can also be related to Nvidia gfx and cuda, playing a little with voltages seemed to soften the issue tho. I'm working on a SSDT because the integrated TB3 ports on the new X299D 2 is not being recognised with the SSDT we already have from the multiple efforts in your post.

And for some reason, above 4G seems mandatory :S

There is a modified FakeSMC and Sensor kext distribution by default implemented in my EFI-Folder distribution, which works OoB with X299 and Skylake-X.

No idea why you don’t use this EFI-Folder and what else you are doing in your system configuration to face issues with Skylake-X and X299.

Read and follow beginning of Section C of my guide to receive support in the respective thread.

Good luck!

I have tried your files, I have based some of my builds on the work in your post, but not the case here, I have my own configuration that has proven to work very well, I like to adapt things my way and have been working on for a long time now.

I truly appreciate your help, but I think this is new grounds for everyone, It just wont work with current methods, I am bit lost tbh.

EDIT: I have another build with the 9980XE and no probs, OOB...

 

[dolgarrenan]

Well flying over your BIOS settings and EFI-Folder, there is nothing really suspicious that could be the source of your kernel panics during early boot.

Are you observing the same KPs under both 10.13.6 and 10.14.2?

Note the following inconsistencies in your config.plist at least under 10.14.2.

a.) The USB port limit patch might not work at all. Thus even by using USBInjectAll.kext, most of your XHCI USB3.0 ports will be non-functional without any additional SSDT, where you explicitly define the 15 HS/SS ports to be implemented. I recommend to use in the meanwhile the truncated 15-port XHC USB kext for the Prime X299 Deluxe instead, which should be largely compatible also with the Prime X299 Deluxe II. Once you have a working build, I would like you to ask to do a USB port discovery and modify the fully implemented and truncated 15-port XHC USB kexts for the ASUS Prime X299 Deluxe for their use with the ASUS Prime X299 Deluxe II accordingly. The approach is easy and straight and might be a question of no more than 30 min of work to invest.

b.) Remove all USB entries in your config.plist under Section "devices" of Clover Configurator (uncheck "Inject" and "FixOwnership"). Also concerning Audio uncheck "AFGLowPowerState" and "ResetHDA". Also disable "LanInjection".

c.) Now the likely important part! In your config.plist under Kernel and Kext patches, xcpm_core_scope_msrs © Pike R. Alpha is enabled, although you disabled the MSR lock in your BIOS settings. Please disable xcpm_core_scope_msrs © Pike R. Alpha!

If your KP issues at early boot persist, try to play with the AVX and AVX-512 offsets.

Another issue might be the Sensor kexts, which might not be fully compatible with the Asus Prime X299 Deluxe II or the i9-9820X yet. Your KPs in a away point to that, although I would not really believe the Sensor kexts to be the source of your issue. You can remove all Sensor kexts for testing purposes. However, you will have to include some FakeSMC.kext though.

Take note that @izo1 repeatedly confirmed full compatibility of the ASUS Prime X299 Deluxe II and i9-7900X with my guide, including BIOS settings and EFI-Folder distribution. See e.g. but not only his recent post #1,208.

I therefore would not know any reason why your ASUS Prime X299 Deluxe II should behave differently.

There is a noob question though from my side:

I know about the Intel i9-99xx series. I never heard about an Intel i9-98XX series.. Can you explain me the difference between e.g. an i9-9920X and your i9-9820X, apart from the reduced core number, stock base frequency and stock turbo frequency? Maybe other differences with this CPU might be the source of your current issues?

Investigating https://ark.intel.com/products/189121/Intel-Core-i9-9820X-X-series-Processor-16-5M-Cache-up-to-4-20-GHz-, it says that the i9-9820X is rather a Skylake CPU than Skylake-X, which could imply some incompatibly with X299 and your ASUS Prime X299 Deluxe II.. Although investigating https://ark.intel.com/de/products/1...series-Processor-19-25M-Cache-up-to-4-50-GHz-, one finds similar statements and information and the i9-9920X is indeed fully compatible with X299 and the ASUS Prime X299 Deluxe II. Both the i9-9820X and i9-9920X are FCLGA2066 socket processors. Thus, also any incompatibly with X299 should be generally excluded. Maybe the i9-9820X is not yet considered in firmware 0404 for the ASUS Prime X299 Deluxe II, thus indeed some respective microcode still needs to implemented in the ASUS Prime X299 Deluxe II firmware?

there is nothing wrong with bios configuration to my eyes either, I also mentioned about the microcode possibility, but it seems so distant to be something like this... There are reports of people on a 9800X working without problems.

You reckon it would be a good idea to write Asus? I know you did in the past, where did you directed to speak with them if may I ask?

 

[AsEvil]

@kgp I've made revisions on my 10.14.2 EFI files based on your advice, but the same KPs still show during the installation. I will try changing AVX and AVX-512 offsets later.

As for the differences between i9-9820X and i9-9920X, what I found from Intel's website and document is similar to your finding. I do not see huge differences except for the cores, cache and clock speed, and they both belong to the"Intel Core X-series Processors" family.

 

[kgp]

Hi @kgp thanks for your info, I have built around 10 to 12 x299 with 7900X for my studio and friends (obviously they where drooling with configurations!), and some presented issues while working adobe suit 2018, which can also be related to Nvidia gfx and cuda, playing a little with voltages seemed to soften the issue tho. I'm working on a SSDT because the integrated TB3 ports on the new X299D 2 is not being recognised with the SSDT we already have from the multiple efforts in your post.

And for some reason, above 4G seems mandatory :S

I have tried your files, I have based some of my builds on the work in your post, but not the case here, I have my own configuration that has proven to work very well, I like to adapt things my way and have been working on for a long time now.

I truly appreciate your help, but I think this is new grounds for everyone, It just wont work with current methods, I am bit lost tbh.

EDIT: I have another build with the 9980XE and no probs, OOB...

Concerning the TB SSDT, all you need to do is properly adopting the ACPI path and ACPI replacements. Once you think that the SSDT is properly implemented, upload an IOREG.save and "PCI" snapshot of Apple's system report for verification. If the ACPI path and ACPI replacements are properly implemented, the integrated TB3 ports on the new PX299D2 also will be properly implemented. Yet we have to verify if HP will also work with the onboard TTR controller, always supposed that the ACPI path and ACPI replacements of the TB SSDT have been properly adopted (properly implemented TB ACPI table in IOREG).

Most former issues, as you also mention above, should be attributed to badly implemented and not well working Nvidia web drivers or Cuda drivers and very likely have never been ever related to X299 or Skylake-X. I abandoned Nvidia quite a while ago for several reasons and recommend also others to follow the same strategy, if possible.

Concerning the PX299D2 and i9-99xx series, I do not see any new grounds for anyone or any need for a thread decoupled for the X299 main threads. Basically, my actual guides, EFI-Folder distributions and SSDTs also should be fully compatible with the PX299D2 and i9-99xx (i9-98xx) series and also will fully account for this new hardware as everything is in continuous development and is kept up to date concerning new hardware developments. In my personal opinion, it would have been more clever to discuss your supposed issues within the X299 main threads, instead of creating your own thread here, which very likely will not be followed or read by anybody. Anyway your decision.

If you refuse to work with well established approaches and think that you should invent the wheel from the beginning, although in my personal opinion there is absolutely no need to do so, I wish you the best for your endeavour. After providing here some initial help and comments, I am off this thread anyway and I will not further comment on your further excursions. What I would dislike to see here anyway are well established approaches attributed to somebody, who is definitely not one of it's authors.

Good luck, man and please do not take my actual comment the wrong way,

KGP

 

[AsEvil]

I've found something interesting. When I put "Disable panic kext logging on 10.13 Release kernel" in my Kernel to Patch, one panic message shows that the thread amount is not properly registered.
I've made changes to the TSCAdjustReset.kext, but the message is still the same, and I can't find the folder or document in the panic line (BuildRoot/Library/Caches.....). Maybe the installation problem has something to do with this and changing the thread counts can fix it?

 

[dolgarrenan]

I've found something interesting. When I put "Disable panic kext logging on 10.13 Release kernel" in my Kernel to Patch, one panic message shows that the thread amount is not properly registered.
I've made changes to the TSCAdjustReset.kext, but the message is still the same, and I can't find the folder or document in the panic line (BuildRoot/Library/Caches.....). Maybe the installation problem has something to do with this and changing the thread counts can fix it?

I have seen the exact same behaviour! which is odd tbh, so I installed the OS on another computer I have and placed the ssd in the 9820X, but the outcome was the same...

I thinks its specific CPU problem. I was supposed to get the higher clocked version of the 9820X this week, but there has been some problems with the courier company so it might have been lost in the way.. Would be interesting to check if the same occurs.

I'll be posting anything I find here!

 

[dolgarrenan]

Concerning the TB SSDT, all you need to do is properly adopting the ACPI path and ACPI replacements. Once you think that the SSDT is properly implemented, upload an IOREG.save and "PCI" snapshot of Apple's system report for verification. If the ACPI path and ACPI replacements are properly implemented, the integrated TB3 ports on the new PX299D2 also will be properly implemented. Yet we have to verify if HP will also work with the onboard TTR controller, always supposed that the ACPI path and ACPI replacements of the TB SSDT have been properly adopted (properly implemented TB ACPI table in IOREG).

I will do, but there is a new device instead of DSB2 which I'm still trying to figure out how to adopt (haven't had much time with work and life altogether)

Most former issues, as you also mention above, should be attributed to badly implemented and not well working Nvidia web drivers or Cuda drivers and very likely have never been ever related to X299 or Skylake-X. I abandoned Nvidia quite a while ago for several reasons and recommend also others to follow the same strategy, if possible.

I'm on the same boat, so fed up with Nvidia and the mess they made 2018 with OS drivers and issues with Adobe suit.

Concerning the PX299D2 and i9-99xx series, I do not see any new grounds for anyone or any need for a thread decoupled for the X299 main threads. Basically, my actual guides, EFI-Folder distributions and SSDTs also should be fully compatible with the PX299D2 and i9-99xx (i9-98xx) series and also will fully account for this new hardware as everything is in continuous development and is kept up to date concerning new hardware developments. In my personal opinion, it would have been more clever to discuss your supposed issues within the X299 main threads, instead of creating your own thread here, which very likely will not be followed or read by anybody. Anyway your decision.

I'ts not a question of compatibility (which mostly it is compatible, except for couple of things that need to be modified obviously), I have been working with "X" platform since the days of X79, and have made tables for up to X299, my implementation is just like yours, except for few things that I have adopted from your guide, since they are good and reliable. I'm not up to create a "separate thread" or an "alternative guide to kgp's", I have a problem which isn't exactly what users with X299D and 7xxxX cpus have and wanted to find a solution instead of adding to the 100 pages++ of your thread so its easy to find if anyone has to look for it. instead of scrolling through hundreds of pages! once a solution is found it would be amazing if you'd just added to your main guide, the purpose is to find answers and have a clear place where to find them. I'm not up to followers, just answers, I think its out of place to say that its very likely will not be followed by anyone or read, AsEvil is reading

If you refuse to work with well established approaches and think that you should invent the wheel from the beginning, although in my personal opinion there is absolutely no need to do so, I wish you the best for your endeavour. After providing here some initial help and comments, I am off this thread anyway and I will not further comment on your further excursions. What I would dislike to see here anyway are well established approaches attributed to somebody, who is definitely not one of it's authors.

Well stablished approaches can need a little research if they are not fully working on a semi different platform. I am not inventing the wheel, nor you nor anyone nor am I on a excursion, this is not primary school lol. We are trying to find a solution, I'd love you to help around since I think you can surely provide inside in here. I'm not attributing anything here nor I want to, if you think your status as "the ultimate X299 guide master" (my invention haha) is being rivalled, I'm sorry but you are wrong. Besides, everyone's work here is based off other peoples work, so no one has invented anything except a few who need no mention. I'd love you to help, like you have been in other post from other people looking for answers, but hey, this is a free forum . no offence taken by the way! if I find anything relevant, I'll be sure to post it here and to your thread if you don't mind so the guide can be even further extended. haben Sie einen guten Tag!

 

[kgp]

I will do, but there is a new device instead of DSB2 which I'm still trying to figure out how to adopt (haven't had much time with work and life altogether)..I have been working with "X" platform since the days of X79, and have made tables for up to X299, my implementation is just like yours, except for few things that I have adopted from your guide, since they are good and reliable.

.. Despite your supposedly impressive experience, it rather seems you do not understand the very basics.. UPSB, DSB0, NHI0, DSB1, DSB2, XHC5 and DSB4 only show up in your ACPI table and IOREGExplorer after successfully adopting, implementing and applying the TB SSDT, which performs the necessary ACPI replacements. If after applying the TB-SSDT, the respective devices are still named differently, you did not properly adopt the TB SSDT, which therefore just crashes during the boot of your system.

Instead of big words, you should rather post facts and details about your current system and system configuration at the right place (i.e. IOReg-save, EFI-Folder, snapshot of Section "PCI", etc.), thus that others are able to help you in your issues.

To your other commends and excursions above I rather prefer not even to answer... others certainly know how to deal with it.

Just note that you are always invited to ask for help by posting along the main X299 threads and you will also receive help the best way possible. In the meanwhile good luck for your personal trip here and as you say in your own words,

Guten Tag..

 

[dolgarrenan]

.. Despite your supposedly impressive experience, it rather seems you do not understand the very basics.. UPSB, DSB0, NHI0, DSB1, DSB2, XHC5 and DSB4 only show up in your ACPI table and IOREGExplorer after successfully adopting, implementing and applying the TB SSDT, which performs the necessary ACPI replacements. If after applying the TB-SSDT, the respective devices are still named differently, you did not properly adopt the TB SSDT, which therefore just crashes during the boot of your system.

Instead of big words, you should rather post facts and details about your current system and system configuration at the right place (i.e. IOReg-save, EFI-Folder, snapshot of Section "PCI", etc.), thus that others are able to help you in your issues.

To your other commends and excursions above I rather prefer not even to answer... others certainly know how to deal with it.

Just note that you are always invited to ask for help by posting along the main X299 threads and you will also receive help the best way possible. In the meanwhile good luck for your personal trip here and as you say in your own words,

Guten Tag..

I will certainly do! my experience has nothing to do here, I don't say its impressive haha, its just that I'm not new to this, that's all. like I said, I haven't had time to post files, but I will do so in your post asap. I'm a bit lost with TB ssdt, when you'll see the files you'll understand what I mean about it.

Thx