trx40 [Discussion] - TRX40 Bare Metal - Vanilla Patches

[fabiosun]

a bit OT (only I mean for my interest) 🙂

I discovered the source of the instability in my system if I use the high sierra system.

Or rather, I figured out how to fix the crashes and restarts I have when performing operations.

It is mathematical that by executing these the system restarts, producing a report with a CPU NMIPI for spinlock acquisition timeout, spinlock: error at the next restart.

I don't have the problem if I force my bios to use 2 CCDs (instead of 4) 

 

I specify that this happens exclusively in the High Sierra

On higher systems this problem does not occur

Obviously even in VM never had this problem

Could it be some High Sierra kernel patches that don't digest well with many cores / threads?

[Ploddles]

Updated OC 0.6.2, Lilu, Whatevergreen, VirtualSMC etc have just been officially released.

[fabiosun]

I did the update easily

all new values could stay at their default value as proposed by new sample.plist file

[fabiosun]

12:659 00:000 OCOS: OS set: Apple Inc. macOS 11.0
12:730 00:070 OC: Kext reservation size info 554000 exe 26A000
12:731 00:000 OC: Trying 64-bit XNU hook on boot\System\Library\KernelCollections\BootKernelExtensions.kc
13:195 00:464 OC: Result of 64-bit XNU hook on boot\System\Library\KernelCollections\BootKernelExtensions.kc (00000000) is Success
13:208 00:013 OCAK: Read kernel version 20.1.0 (200100)
13:211 00:002 OCAK: 64-bit algrey - Disable _i386_switch_lbrs base lookup failure Not Found
13:212 00:001 OC: Kernel patcher result 0 for kernel (algrey - Disable _i386_switch_lbrs) - Not Found
13:216 00:004 OCAK: 64-bit algrey - Disable _i386_lbr_init base lookup failure Not Found
13:218 00:001 OC: Kernel patcher result 1 for kernel (algrey - Disable _i386_lbr_init) - Not Found
13:301 00:083 OCAK: 64-bit algrey - _i386_init_slave - Remove wrmsr 0x1c8 replace count - 0
13:302 00:000 OC: Kernel patcher result 2 for kernel (algrey - _i386_init_slave - Remove wrmsr 0x1c8) - Not Found
13:307 00:005 OCAK: 64-bit algrey - Disable _i386_lbr_native_state_to_mach_thread_state base lookup failure Not Found
13:308 00:000 OC: Kernel patcher result 3 for kernel (algrey - Disable _i386_lbr_native_state_to_mach_thread_state) - Not Found
13:313 00:005 OCAK: 64-bit commpage_populate -remove rdmsr replace count - 1
13:314 00:000 OC: Kernel patcher result 4 for kernel (commpage_populate -remove rdmsr) - Success
13:316 00:001 OCAK: 64-bit cpu_topology_sort -disable _x86_validate_topology replace count - 1
13:318 00:001 OC: Kernel patcher result 5 for kernel (cpu_topology_sort -disable _x86_validate_topology) - Success

i am not following anymore on AMD osx discords I can't say if this I am saying here is well known ..

in beta 9 these new patches are not useful anymore to boot fine?

in my case it seems system boot without loading those patches

I need of them in beta 7 and 8

also for you?

[Ploddles]

Are you saying those top 4 patches (result 0 - 3) are no longer needed but result 4 - 5 are needed?

 

I will try and test mine tomorrow.

[fabiosun]

If you see

not found means not used because are not found in beta 9 kernel

the latest two are useful and they have success( found in beta 9 kernel)

this means that beta 9 kernel is different than beta 7 and 8 where those patches were useful and mandatory to boot fine

[meina222]

@fabiosun - you're right. I disabled patches 0-3 and beta 9 boots just fine.

[Rox67er]

Great to see Apple is so supportive of the AMD community, first they announce the move to ARM which drives adobe to remove all intel specific code, next they remove the AMD needed patches one by one... I guess the kernel panic reports @fabiosun is sending them must help... 😁😂

[Ploddles]

The Aorus Xtreme boots Big Sur Beta 9 fine with the latest OC and those 4 patches disabled. I have, however, lost my internal Wifi - so that could be either OC 0.6.2 or possibly one of those 4 patches - which I doubt, but will test at the weekend when I have time.

[Driftwood]

 

  On 10/2/2020 at 6:33 PM, fojerhar said:

Thank you

You was right, I was missing the testing with a hard drive.

I did it now, the drive was popped up for me in windows with macdrive, but not in osx.

 

And yes, in windows everything is fine.

 

I checked the UAD Apollo 16 interface with my laptop with catalina, and works well trough a TB3-Firewire adaptor (i have only thunderbolts in my MBP 14,3), and the latest driver was not needed for catalina compatibility, and with the trx40 I tried the same and the latest also (i can see at boot, that the UAD kext is loaded at the last step in verbose mode)

and my MBP was the testing hard drive, started in target mode and was working trough adapters in windows. (my old external firewire hd power adaptor is dead)

 

I also used firewire in the last 8 years without any problems in the hacks z370 and earlier too, thats why this issue is strange for me, should work easily

Expand  

 

@fojerhar

 

These are the Catalina drivers that Hackintools (see PCIe) will show what is running for firewire. Please check yours.

 

 

 

Edited October 7, 2020 by Driftwood

[Jaidy]

Hello everyone,

I tried upgrading to OpenCore 0.6.2, but I am getting random kernel panics leading to system being restarted.  It has to do something with power management, but that's all my (lack of any) expertise tells me.

EFI

 

The message for the panics is the following:

panic(cpu 0 caller 0xffffff7fa05a6f3d): CPU 63 has no HPET assigned to it
Backtrace (CPU 0), Frame : Return Address
0xffffff93dec43c90 : 0xffffff801d11a65d 
0xffffff93dec43ce0 : 0xffffff801d254a75 
0xffffff93dec43d20 : 0xffffff801d2465fe 
0xffffff93dec43d70 : 0xffffff801d0c0a40 
0xffffff93dec43d90 : 0xffffff801d119d27 
0xffffff93dec43e90 : 0xffffff801d11a117 
0xffffff93dec43ee0 : 0xffffff801d8c1a6c 
0xffffff93dec43f50 : 0xffffff7fa05a6f3d 
0xffffff93dec43f60 : 0xffffff7fa0591882 
0xffffff93dec43fa0 : 0xffffff801d0c013e 
      Kernel Extensions in backtrace:
         com.apple.driver.AppleIntelCPUPowerManagement(222.0)[C5BB0AFD-CB31-3FD1-BF3B-773B2919A970]@0xffffff7fa058b000->0xffffff7fa05b4fff

BSD process name corresponding to current thread: kernel_task
Boot args: -v -wegbeta -no_compat_check amfi_get_out_of_my_way=1 

Mac OS version:
19H2

Kernel version:
Darwin Kernel Version 19.6.0: Mon Aug 31 22:12:52 PDT 2020; root:xnu-6153.141.2~1/RELEASE_X86_64
Kernel UUID: 05D51A3D-3A87-3FF0-98C3-9CF3827A3EDD
Kernel slide:     0x000000001ce00000
Kernel text base: 0xffffff801d000000
__HIB  text base: 0xffffff801cf00000
System model name: MacPro7,1 (Mac-27AD2F918AE68F61)
System shutdown begun: NO
Panic diags file available: YES (0x0)

System uptime in nanoseconds: 91267996860

 

[meina222]

@Jaidy

 

Most other people  with 3970x don't seem to have this issue, but I was getting similar "random" kernel panics when DummyPowerManagement was disabled. In OC 0.6.2 this option moved to a different section of the config file (see the sample.plist) - make sure its value didn't get overwritten compared to your previous value by some editor trying to comply with the new structure.

[fabiosun]

 

if you have kernel panics in your system that are always reproducible in certain situations, try taking a look here

For those with CPU related errors (HPET not found) the CPU Core control part can help you

For those who have problems like the error I wrote in a previous message, the solution (not satisfactory because it reduces the power of the cpu by limiting the number of cores) is in the CPU CCD Control section

For systems higher than high sierra it should not be useful ..

But, on High Sierra only then it is possible to use everything without problems

Because?

I don't know :P

[Rox67er]

  On 10/8/2020 at 2:00 AM, Jaidy said:

Hello everyone,

I tried upgrading to OpenCore 0.6.2, but I am getting random kernel panics leading to system being restarted.  It has to do something with power management, but that's all my (lack of any) expertise tells me.

EFI

 

The message for the panics is the following:

 

panic(cpu 0 caller 0xffffff7fa05a6f3d): CPU 63 has no HPET assigned to it
Backtrace (CPU 0), Frame : Return Address
0xffffff93dec43c90 : 0xffffff801d11a65d 
0xffffff93dec43ce0 : 0xffffff801d254a75 
0xffffff93dec43d20 : 0xffffff801d2465fe 
0xffffff93dec43d70 : 0xffffff801d0c0a40 
0xffffff93dec43d90 : 0xffffff801d119d27 
0xffffff93dec43e90 : 0xffffff801d11a117 
0xffffff93dec43ee0 : 0xffffff801d8c1a6c 
0xffffff93dec43f50 : 0xffffff7fa05a6f3d 
0xffffff93dec43f60 : 0xffffff7fa0591882 
0xffffff93dec43fa0 : 0xffffff801d0c013e 
      Kernel Extensions in backtrace:
         com.apple.driver.AppleIntelCPUPowerManagement(222.0)[C5BB0AFD-CB31-3FD1-BF3B-773B2919A970]@0xffffff7fa058b000->0xffffff7fa05b4fff

BSD process name corresponding to current thread: kernel_task
Boot args: -v -wegbeta -no_compat_check amfi_get_out_of_my_way=1 

Mac OS version:
19H2

Kernel version:
Darwin Kernel Version 19.6.0: Mon Aug 31 22:12:52 PDT 2020; root:xnu-6153.141.2~1/RELEASE_X86_64
Kernel UUID: 05D51A3D-3A87-3FF0-98C3-9CF3827A3EDD
Kernel slide:     0x000000001ce00000
Kernel text base: 0xffffff801d000000
__HIB  text base: 0xffffff801cf00000
System model name: MacPro7,1 (Mac-27AD2F918AE68F61)
System shutdown begun: NO
Panic diags file available: YES (0x0)

System uptime in nanoseconds: 91267996860

 

Expand  

Interesting, I still have an immediate wake after sleep in Big Sur with cause the cpu cores. I removed the _pwr method for all 64 cores in DSDT and then get the same error. I use the AMD power management kext. So somehow the cpu sleep is waking my system. Other than that cpu clockspeed is working fine. 

[fabiosun]

😂

[meina222]

So essentially like a 3070 more or less - but MacOS compatible and hopefully actually available  to buy. Not too bad, not terrific considering the competition.

[Ploddles]

Not being a gamer, are those scores good, bad or indifferent?

[Driftwood]

Instruments is a nice little app if you're on 'Developers'. In Preferences you can reduce cores on the fly to test out errant apps! You can monitor apps or other preferences for a variety of different scenarious.

 

[fabiosun]

@Ploddles
It depends by the price of the card..

better than previous amd card

probably lower than Nvidia latest cards

 

[Ploddles]

Anyone wanting to use an X-Rite i1Profiler to colour profile your display, you need the same fix as the DaVinci Resolve AMD fix. Just replace the mentioned file and boom, it works.

[ckrueger99]

  On 10/8/2020 at 5:15 PM, meina222 said:

So essentially like a 3070 more or less - but MacOS compatible and hopefully actually available  to buy. Not too bad, not terrific considering the competition.

Expand  

 

Closer to a 3080 than a 3070. Only question for me is whether supported right away in Big Sur.

 

 

[meina222]

@ckrueger99

 

Yes, it should be. Not only that, Big Sur is also used to as a clue for yet unannounced Navi cards bigger than 21 if these online sourced are to be believed e.g.

 

https://www.techradar.com/news/macos-big-sur-driver-code-hints-at-mysterious-amd-navi-31-gpu

 

 

[iGPU]

  On 10/6/2020 at 7:25 AM, fabiosun said:

12:659 00:000 OCOS: OS set: Apple Inc. macOS 11.0
12:730 00:070 OC: Kext reservation size info 554000 exe 26A000
12:731 00:000 OC: Trying 64-bit XNU hook on boot\System\Library\KernelCollections\BootKernelExtensions.kc
13:195 00:464 OC: Result of 64-bit XNU hook on boot\System\Library\KernelCollections\BootKernelExtensions.kc (00000000) is Success
13:208 00:013 OCAK: Read kernel version 20.1.0 (200100)
13:211 00:002 OCAK: 64-bit algrey - Disable _i386_switch_lbrs base lookup failure Not Found
13:212 00:001 OC: Kernel patcher result 0 for kernel (algrey - Disable _i386_switch_lbrs) - Not Found
13:216 00:004 OCAK: 64-bit algrey - Disable _i386_lbr_init base lookup failure Not Found
13:218 00:001 OC: Kernel patcher result 1 for kernel (algrey - Disable _i386_lbr_init) - Not Found
13:301 00:083 OCAK: 64-bit algrey - _i386_init_slave - Remove wrmsr 0x1c8 replace count - 0
13:302 00:000 OC: Kernel patcher result 2 for kernel (algrey - _i386_init_slave - Remove wrmsr 0x1c8) - Not Found
13:307 00:005 OCAK: 64-bit algrey - Disable _i386_lbr_native_state_to_mach_thread_state base lookup failure Not Found
13:308 00:000 OC: Kernel patcher result 3 for kernel (algrey - Disable _i386_lbr_native_state_to_mach_thread_state) - Not Found
13:313 00:005 OCAK: 64-bit commpage_populate -remove rdmsr replace count - 1
13:314 00:000 OC: Kernel patcher result 4 for kernel (commpage_populate -remove rdmsr) - Success
13:316 00:001 OCAK: 64-bit cpu_topology_sort -disable _x86_validate_topology replace count - 1
13:318 00:001 OC: Kernel patcher result 5 for kernel (cpu_topology_sort -disable _x86_validate_topology) - Success

i am not following anymore on AMD osx discords I can't say if this I am saying here is well known ..

in beta 9 these new patches are not useful anymore to boot fine?

in my case it seems system boot without loading those patches

I need of them in beta 7 and 8

also for you?

Expand  

 

Yes, disabling these 4 patches, still allows booting into Big Sur ß6 and ß9 (I have no ß7 or 8 to test), as well as Catalina.

[fabiosun]

  On 10/8/2020 at 5:56 PM, Driftwood said:

Instruments is a nice little app if you're on 'Developers'. In Preferences you can reduce cores on the fly to test out errant apps! You can monitor apps or other preferences for a variety of different scenarious.

 

Expand  

 

It is an Xcode features....and.. @Driftwood you made my day

 

I can leave my bios @stock configuration with all cores and threads and limit here in High Sierra

 

All seems to work perfectly and I have no anymore any instant reboot or kp using 3d physical renderer in Cinema 4d or in some operations with photoshop

Obviously I am not happy to loose half of my total power...but in High Sierra there is this problem!
I hope in system greater than High Sierra will be fine without this trick

it seems so , but I can't say for sure because I have no GPU power for now...

will see with big navi

 

[fabiosun]

it is also possible to use cpus=32 as bootarg (thanks @Gengik84to remind me this)