Contribute
Register

Z690 Chipset Motherboards and Alder Lake CPU

Okay I have some good news and some bad news...

The good news is, the new Asus BIOS update I made yesterday has finally enabled AVX-512!

View attachment 534718

And the bad news is, the same update has now stopped me from booting macOS properly.
I've turned off TPM, hyperthreading & Secure Boot in the BIOS with no effect.

View attachment 534719
Turn off CFG lock too? Or turn on one of the patches to workaround it?
 
Turn off CFG lock too? Or turn on one of the patches to workaround it?
CFG Lock should be off (it's not in the BIOS).
 
CFG Lock should be off (it's not in the BIOS).
"Not in BIOS" is often CFGLock ON. You can check that with UEFI tool ControlMsrE2.
Or maybe it's an inconsistent AVX setting with this brand new BIOS?
 
Just completed both tests:
  • BIOS:
    • P-cores = 6
    • E-cores = 4
    • HT = enabled
  • Test 1:
    • APIC --> fake1 with SSDT-CPUR --> fake1 (and original APIC table dropped)
    • Result: x86_validate_topology() 10 threads but 20 registered from MADT
View attachment 534684
  • Test 2:
    • APIC --> fake1 with SSDT-CPUR --> fake1 (and original APIC table dropped)
    • Result: x86_validate_topology() 10 threads but 20 registered from MADT
View attachment 534685
@CaseySJ

I have a little doubt on TEST 1 and TEST 2 results : As we have all P-cores and E-cores with hyper threading, we should have result like :x86_validate_topology() 12 threads but 20 registered from MADT.
It seem that you might forget enabling hyper-threading ? Maybe I'm wrong !
 
@CaseySJ

I have a little doubt on TEST 1 and TEST 2 results : As we have all P-cores and E-cores with hyper threading, we should have result like :x86_validate_topology() 12 threads but 20 registered from MADT.
It seem that you might forget enabling hyper-threading ? Maybe I'm wrong !
Hyper threading is enabled, but when E-cores are enabled, then nLThreadsPerCore evaluates to 1, so total detected threads (nCPUs) is 10, which is P+E.
C:
nLThreadsPerCore = thread_count / core_count = 16 / 10 = 1;
nLThreadsPerPackage = nLCoresPerPackage * nLThreadsPerCore = 10 * 1 = 10;
nCPUs = nPackages * nLThreadsPerPackage = 1 * 10 = 10;
So macOS starts off by detecting the correct number of threads (16), but in line 1 it uses integer division that sets nLThreadsPerCore to 1.

Then x86_validate_topology() compares nCPUs with total active processors in APIC (real_ncpus), which is 20, and says:

x86_validate_topology() 10 threads but 20 registered from MADT

C:
    if (nCPUs != real_ncpus) {
        panic("x86_validate_topology() %d threads but %d registered from MADT",
            nCPUs, real_ncpus);
    }

But changing nLThreadsPerCore to 2 sets nCPUs to 20, hence topology check passes.
 
Last edited:
** Kernel Patching Update **
x86_validate_topology() passes with nCPUs=20 and real_ncpus=20​


Thanks to a built-in assembler in the Hopper app, I was able to change this section:
View attachment 534713

... to this:

View attachment 534712

This translates into a kernel patch as follows:
View attachment 534714
Arch: x86_64
Identifier: kernel
Comment: caseysj_set_thread_per_core_count_to_2
Find: 01000041 8B879401 000031D2 F7F18905
Replace: 010000B8 02000000 90909090 90908905
Count: 1
Limit: 0
Skip: 0
Enabled: True

After (a) enabling this patch and (b) applying @Elias64Fr's APIC and CPUR tables that define 20 processors, x86_validate_topology() passes with:
  • All P-cores enabled
  • All E-cores enabled
  • Hyper Threading enabled
But then we're hit -- expectedly -- with a different fatal problem!

View attachment 534715

This one is:
  • mp_kdp_enter() timed-out on cpu 8, NMI-ing
  • mp_kdp_enter() NMI pending on cpus: 0 1 2 3 4 5 6 7 9 10 11 12
  • mp_kdp_enter() timed-out during locked wait after NMI;expected 13 asks but received 1 after 8819248 loops...
  • panic(cpu 8 caller 0xffffff80007cff37): "mp_rv_action() exit: 12 of 13 responses, ..."
Good night! :)
Last night, on my bed, I have been thinking ... without any APIC and kernel patching, 2 questions came to me :
  • Where thread_count and core_count datas are located and called by Kernel ?
  • How can we modify these datas ?

And .. I thought about SMBIOS .. then dmidecode command.

If we use this command on Terminal, we can see that there is information on CPU threads and cores (for example on my laptop):
Capture d’écran 2021-11-17 à 10.30.12.png


On Z690, in case of all P and E cores enabled with hyper-threading, I think (but should be confirmed by @Casey), we have Core count to 10 and Thread count to 12.

So the next step, I think, should be to see which result if we change these datas on SMBIOS...

Could you post informations about dmidecode command with our Three cases ?
As full enabled cores with HT can boot macOS, you can use smbiosview shell command after moving to your EFI partition ( FSx: )
smbiosview > mysmbiosFullCoresHT.txt
 
Last night, on my bed, I have been thinking ... without any APIC and kernel patching, 2 questions came to me :
  • Where thread_count and core_count datas are located and called by Kernel ?
  • How can we modify these datas ?

And .. I thought about SMBIOS .. then dmidecode command.

If we use this command on Terminal, we can see that there is information on CPU threads and cores (for example on my laptop):
View attachment 534726

On Z690, in case of all P and E cores enabled with hyper-threading, I think (but should be confirmed by @Casey), we have Core count to 10 and Thread count to 12.

So the next step, I think, should be to see which result if we change these datas on SMBIOS...

Could you post informations about dmidecode command with our Three cases ?
As full enabled cores with HT can boot macOS, you can use smbiosview shell command after moving to your EFI partition ( FSx: )
smbiosview > mysmbiosFullCoresHT.txt
Can we assign HT to each core specifically ?
what is the order of the cores? 0-5 P, 5-9 E? I wonder if macOS can run stable with the thread count NOT being x2 times the core count.
 
So I managed to solve another issue today - sound is now working on the Asus board!
The alcid to use is 66.

Screen Shot 2021-11-17 at 5.58.13 PM.png


Screen Shot 2021-11-17 at 5.45.57 PM.png


Turns out the issue of it not working was not with Monterey itself, but Opencore (or later versions of from 7.4 onwards). I'm not sure if it is AppleALC or Lilu, but I found that it wasn't just affecting the Z690 but the Z490 board I had as well. Whenever I tried to update to Monterey, the problem persisted even though it was working before. It was while I was working on Big Sur with a 0.7.5 build on my Z490, and finding sound output was also affected that I realized it was not the Z690's issue at all.

The solution I found therefore was to downgrade back to OC 0.6.8. including using retrograded OC kexts. Once I did that the system worked.

For those interested I also attach a pic of the now more complete Asus PCI devices listing which has revealed itself more thoroughly with OC 0.6.8.

Screen Shot 2021-11-17 at 9.03.11 AM.png
 
So I managed to solve another issue today - sound is now working on the Asus board!
The alcid to use is 66.

View attachment 534729

View attachment 534730

Turns out the issue of it not working was not with Monterey itself, but Opencore (or later versions of from 7.4 onwards). I'm not sure if it is AppleALC or Lilu, but I found that it wasn't just affecting the Z690 but the Z490 board I had as well. Whenever I tried to update to Monterey, the problem persisted even though it was working before. It was while I was working on Big Sur with a 0.7.5 build on my Z490, and finding sound output was also affected that I realized it was not the Z690's issue at all.

The solution I found therefore was to downgrade back to OC 0.6.8. including using retrograded OC kexts. Once I did that the system worked.

For those interested I also attach a pic of the now more complete Asus PCI devices listing which has revealed itself more thoroughly with OC 0.6.8.

View attachment 534733
Very interesting. Sounds like a regression bug that needs to be fixed. Are you able to activate the Boot Chime by doing this:

Screen Shot 2021-11-17 at 2.15.39 AM.png
Screen Shot 2021-11-17 at 2.16.16 AM.png
Screen Shot 2021-11-17 at 2.17.24 AM.png
 
Last night, on my bed, I have been thinking ... without any APIC and kernel patching, 2 questions came to me :
  • Where thread_count and core_count datas are located and called by Kernel ?
  • How can we modify these datas ?
I know, I have those crazy background (low power) threads running in my brain at bedtime as well! :)

And .. I thought about SMBIOS .. then dmidecode command.

If we use this command on Terminal, we can see that there is information on CPU threads and cores (for example on my laptop):
View attachment 534726

On Z690, in case of all P and E cores enabled with hyper-threading, I think (but should be confirmed by @Casey), we have Core count to 10 and Thread count to 12.

So the next step, I think, should be to see which result if we change these datas on SMBIOS...

Could you post informations about dmidecode command with our Three cases ?
As full enabled cores with HT can boot macOS, you can use smbiosview shell command after moving to your EFI partition ( FSx: )
smbiosview > mysmbiosFullCoresHT.txt
Case 1: E + P + HT
  • smbiosview in EFI Shell actually freezes when running this command, but we get enough information on screen by typing smbiosview -t 4 to show only the processor information.
  • We see:
    • Core Count = 10
    • Thread Count = 16
IMG_5213.jpg


Case 2: E + P only (no HT)
  • Using Terminal command system_profiler SPHardwareDataType
  • (dmidecode is not present in macOS, but needs to be installed/compiled separately)
  • We see:
    • Processors: 1
    • Total Cores: 10
    • Hyper-Threading Technology: Disabled
Bash:
Hardware:

    Hardware Overview:

      Model Name: Mac Pro
      Model Identifier: MacPro7,1
      Processor Name: 10-Core Intel Xeon W
      Processor Speed: 3.68 GHz
      Number of Processors: 1
      Total Number of Cores: 10
      L2 Cache (per Core): 1.3 MB
      L3 Cache: 20 MB
      Hyper-Threading Technology: Disabled
      Memory: 16 GB
      System Firmware Version: 1715.40.15.0.0
      OS Loader Version: 540.60.2~69
IMG_5215.jpg

Case 3: P + HT (no E)
  • We see:
    • Processors: 1
    • Total Cores: 6
    • Hyper-Threading Technology: Enabled
Bash:
Hardware:

    Hardware Overview:

      Model Name: Mac Pro
      Model Identifier: MacPro7,1
      Processor Name: Unknown
      Processor Speed: 3.68 GHz
      Number of Processors: 1
      Total Number of Cores: 6
      L2 Cache (per Core): 1.3 MB
      L3 Cache: 20 MB
      Hyper-Threading Technology: Enabled
      Memory: 16 GB
      System Firmware Version: 1715.40.15.0.0
      OS Loader Version: 540.60.2~69
IMG_5214.jpg
 
Last edited:
Back
Top