Jump to content

Asus W790 Installation.

Balamut

By Balamut,
in OSx86 13.0 (Ventura)

 Share
64 posts in this topic

Recommended Posts

Balamut
Balamut
Posted
  • Author
Posted

Ok after spending some time of poking around this I came up with.

 

I've had a hypothesis that the issue might not actually be the USB but deeper, so I've setup OC on the EFI partition of NVME, installed 2 separate NVME drivers with Monterey and Ventura Installed on them, also I've dusted off and old SATA drive with early version of Monterey installed on it and manage to get interesting results.

 

I'll attach all the logs at the end of the post. 

 

1. Booting from OC from USB and trying to boot USB Installer, gets waiting for root device and then panics on IONVmeFamily. 

[AHCI][HBA][00170000] start::512:Successfully initialized AHCI controller
Still waiting for root device
void AppleNVMeRequest::PrintRequest()::519:QID=0 fSubmissionTimeNS=0 Deadline=46420165279 DW0=00010009 DW10=00000007 DW11=00000000 DW12=00000000 DW13=00000000 DW14=00000000 DW15=00000000
panic(cpu 0 caller 0xffffff801201e674): nvme: "3rd party NVMe controller. Loss of MMIO space. Delete IO submission queue. fBuiltIn=1 MODEL=WD_BLACK SN750 SE 1TB FW=711130WD CSTS=0xffffffff US[1]=0x0 US[0]=0x0 VID=0x15b7 DID=0x501e CRITICAL_WARNING=0x0.\n" @IONVMeController.cpp:6147
Panicked task 0xffffff878b6d9698: 135 threads: pid 0: kernel_task
Backtrace (CPU 0), panicked thread: 0xffffff8c53236b30, Frame : Return Address
0xffffffa14c293a90 : 0xffffff800f8705fd mach_kernel : _handle_debugger_trap + 0x4ad
0xffffffa14c293ae0 : 0xffffff800f9c4b84 mach_kernel : _kdp_i386_trap + 0x114
0xffffffa14c293b20 : 0xffffff800f9b4619 mach_kernel : _kernel_trap + 0x3c9
0xffffffa14c293b80 : 0xffffff800f810951 mach_kernel : _return_from_trap + 0xc1
0xffffffa14c293ba0 : 0xffffff800f8708dd mach_kernel : _DebuggerTrapWithState + 0x5d
0xffffffa14c293c90 : 0xffffff800f86ff87 mach_kernel : _panic_trap_to_debugger + 0x1a7
0xffffffa14c293cf0 : 0xffffff800ffdd09b mach_kernel : _panic + 0x84
0xffffffa14c293de0 : 0xffffff801201e674 com.apple.iokit.IONVMeFamily : __ZN16IONVMeController14CommandTimeoutEP16AppleNVMeRequest.cold.1
0xffffffa14c293df0 : 0xffffff8012001852 com.apple.iokit.IONVMeFamily : __ZN16IONVMeController13FatalHandlingEv + 0xfe
0xffffffa14c293e20 : 0xffffff800ff1c936 mach_kernel : __ZN18IOTimerEventSource15timeoutSignaledEPvS0_ + 0x96
0xffffffa14c293e70 : 0xffffff800ff1c846 mach_kernel : __ZN18IOTimerEventSource17timeoutAndReleaseEPvS0_ + 0xc6
0xffffffa14c293ea0 : 0xffffff800f8c6c08 mach_kernel : _thread_call_delayed_timer + 0x508
0xffffffa14c293ee0 : 0xffffff800f8c7cb8 mach_kernel : _thread_call_delayed_timer + 0x15b8
0xffffffa14c293fa0 : 0xffffff800f81019e mach_kernel : _call_continuation + 0x2e
      Kernel Extensions in backtrace:
         com.apple.iokit.IONVMeFamily(2.1)[2C32FDE9-ECB0-310C-85D0-E87ABAF02E37]@0xffffff8011ff9000->0xffffff8012025fff
            dependency: com.apple.driver.AppleMobileFileIntegrity(1.0.5)[51EB454D-1515-39A1-A67B-305B05451E22]@0xffffff8010de2000->0xffffff8010e15fff
            dependency: com.apple.iokit.IOPCIFamily(2.9)[98683EFC-EF7A-3169-8DD1-9227B9A27BAA]@0xffffff8012291000->0xffffff80122c1fff
            dependency: com.apple.iokit.IOReportFamily(47)[491DDA55-D371-3A28-9A77-C28DB013D8AE]@0xffffff80122d2000->0xffffff80122d4fff
            dependency: com.apple.iokit.IOStorageFamily(2.1)[EA2A9009-708A-36D7-8AD6-829DEA8C4FE3]@0xffffff80123c5000->0xffffff80123dcfff

Process name corresponding to current thread (0xffffff8c53236b30): kernel_task
Boot args: -v serial=5 keepsyms=1 debug=0x100 acpi_layer=0x8 msgbuf=1048576 root-dmg=file:///BaseSystem/BaseSystem.dmg

Mac OS version:
Not yet set

Kernel version:
Darwin Kernel Version 22.4.0: Mon Mar  6 21:00:17 PST 2023; root:xnu-8796.101.5~3/RELEASE_X86_64
Kernel UUID: CF2A42DA-3F7C-30C6-9433-6F2076FF1F94
roots installed: 0
KernelCache slide: 0x000000000f400000
KernelCache base:  0xffffff800f600000
Kernel slide:      0x000000000f4dc000
Kernel text base:  0xffffff800f6dc000
__HIB  text base: 0xffffff800f500000
System model name: MacPro7,1 (Mac-27AD2F918AE68F61)
System shutdown begun: NO
Panic diags file unavailable, panic occurred prior to initialization
Hibernation exit count: 0

System uptime in nanoseconds: 85717365498
Last Sleep:           absolute           base_tsc          base_nano
  Uptime  : 0x00000013f5ce0bbb
  Sleep   : 0x0000000000000000 0x0000000000000000 0x0000000000000000
  Wake    : 0x0000000000000000 0x000000533bf16339 0x0000000000000000
Compressor Info: 0% of compressed pages limit (OK) and 0% of segments limit (OK) with 0 swapfiles and OK swap space
Zone info:
  Zone map: 0xffffff810b610000 - 0xffffffa10b610000
  . PGZ   : 0xffffff810b610000 - 0xffffff812b60d000
  . VM    : 0xffffff812b60d000 - 0xffffff85f360d000
  . RO    : 0xffffff85f360d000 - 0xffffff878b60d000
  . GEN0  : 0xffffff878b60d000 - 0xffffff8c5360d000
  . GEN1  : 0xffffff8c5360d000 - 0xffffff911b60d000
  . GEN2  : 0xffffff911b60d000 - 0xffffff95e360d000
  . GEN3  : 0xffffff95e360d000 - 0xffffff9aab60e000
  . DATA  : 0xffffff9aab60e000 - 0xffffffa10b610000
  Metadata: 0xffffffca048aa000 - 0xffffffca248aa000
  Bitmaps : 0xffffffca248aa000 - 0xffffffca348aa000
  Extra   : 0 - 0

 

2. Booting from OC from USB booting SATA Drive with Monterey on it gets a different panic.

  

IOPlatformPanicAction -> AppleAHCIDiskDriver
panic(cpu 8 caller 0xffffff80171d0773): Kernel trap at 0xffffff8017169a30, type 14=page fault, registers:
CR0: 0x000000008001003b, CR2: 0xffffff8100000000, CR3: 0x00000000226b0000, CR4: 0x00000000003626e0
RAX: 0x0000000003992492, RBX: 0xffffff8036800000, RCX: 0x0000000000000006, RDX: 0xffffff801805cb14
RSP: 0xffffffd21499be20, RBP: 0xffffffd21499be50, RSI: 0x0000000003a4d7b2, RDI: 0xffffffd21499be2c
R8:  0x000000000055f8ea, R9:  0x0000000000000008, R10: 0xffffff80ffffffb8, R11: 0xffffff80ffffff80
R12: 0x00000000c97ffff0, R13: 0x0000000000000000, R14: 0x0000000000000000, R15: 0x0000000003a4d7b2
RFL: 0x0000000000010206, RIP: 0xffffff8017169a30, CS:  0x0000000000000008, SS:  0x0000000000000000
Fault CR2: 0xffffff8100000000, Error code: 0x0000000000000002, Fault CPU: 0x8, PL: 0, VF: 2

Panicked task 0xffffff9122d24670: 140 threads: pid 0: kernel_task
Backtrace (CPU 8), panicked thread: 0xffffff9122d04aa0, Frame : Return Address
0xffffffd21499b7d0 : 0xffffff801707fd6d mach_kernel : _handle_debugger_trap + 0x41d
0xffffffd21499b820 : 0xffffff80171e1016 mach_kernel : _kdp_i386_trap + 0x116
0xffffffd21499b860 : 0xffffff80171d0383 mach_kernel : _kernel_trap + 0x4d3
0xffffffd21499b8b0 : 0xffffff801701fa70 mach_kernel : _return_from_trap + 0xe0
0xffffffd21499b8d0 : 0xffffff801708013d mach_kernel : _DebuggerTrapWithState + 0xad
0xffffffd21499b9f0 : 0xffffff801707f8f6 mach_kernel : _panic_trap_to_debugger + 0x2b6
0xffffffd21499ba50 : 0xffffff8017914d93 mach_kernel : _panic + 0x84
0xffffffd21499bb40 : 0xffffff80171d0773 mach_kernel : _sync_iss_to_iks + 0x2c3
0xffffffd21499bcc0 : 0xffffff80171d0456 mach_kernel : _kernel_trap + 0x5a6
0xffffffd21499bd10 : 0xffffff801701fa70 mach_kernel : _return_from_trap + 0xe0
0xffffffd21499bd30 : 0xffffff8017169a30 mach_kernel : _vm_free_delayed_pages + 0x190
0xffffffd21499be50 : 0xffffff80171698b7 mach_kernel : _vm_free_delayed_pages + 0x17
0xffffffd21499be70 : 0xffffff80170b6c2a mach_kernel : _max_valid_stack_address + 0x145a
0xffffffd21499bfa0 : 0xffffff801701f19e mach_kernel : _call_continuation + 0x2e

Process name corresponding to current thread (0xffffff9122d04aa0): kernel_task
Boot args: -v serial=5 keepsyms=1 debug=0x100 acpi_layer=0x8 msgbuf=1048576

Mac OS version:
21G72

Kernel version:
Darwin Kernel Version 21.6.0: Sat Jun 18 17:07:25 PDT 2022; root:xnu-8020.140.41~1/RELEASE_X86_64
Kernel UUID: E3E2BC4D-7B6F-39CC-8890-73A6FB513830
KernelCache slide: 0x0000000016e00000
KernelCache base:  0xffffff8017000000
Kernel slide:      0x0000000016e10000
Kernel text base:  0xffffff8017010000
__HIB  text base: 0xffffff8016f00000
System model name: MacPro7,1 (Mac-27AD2F918AE68F61)
System shutdown begun: NO
Panic diags file available: YES (0x0)
Hibernation exit count: 0

System uptime in nanoseconds: 21948109058
Last Sleep:           absolute           base_tsc          base_nano
  Uptime  : 0x000000051cdbf330
  Sleep   : 0x0000000000000000 0x0000000000000000 0x0000000000000000
  Wake    : 0x0000000000000000 0x000000539ee677f7 0x0000000000000000
Compressor Info: 0% of compressed pages limit (OK) and 0% of segments limit (OK) with 0 swapfiles and OK swap space
Zone info:
  Zone map: 0xffffff8112da7000 - 0xffffffa112da7000
  . PGZ   : 0xffffff8112da7000 - 0xffffff8132da4000
  . VM    : 0xffffff8132da4000 - 0xffffff85fada4000
  . RO    : 0xffffff85fada4000 - 0xffffff8792da4000
  . GEN0  : 0xffffff8792da4000 - 0xffffff8c5ada4000
  . GEN1  : 0xffffff8c5ada4000 - 0xffffff9122da4000
  . GEN2  : 0xffffff9122da4000 - 0xffffff95eada4000
  . GEN3  : 0xffffff95eada4000 - 0xffffff9ab2da5000
  . DATA  : 0xffffff9ab2da5000 - 0xffffffa112da7000
  Metadata: 0xffffffd153bf7000 - 0xffffffd173bf7000
  Bitmaps : 0xffffffd173bf7000 - 0xffffffd193bf7000


** In Memory Panic Stackshot Succeeded ** Bytes Traced 85745 (Uncompressed 214944) **
IOPolledInterface::startIO[0] 0xe00002c7
IOPolledFileWrite(0x0xffffff8c5b245a00, 0x0, 0, 0x0) : IOStartPolledIO(0x0xffffff95eaaf7f80, kIOPolledWrite, 0, 0x1b9520000, 8192) returned 0xe00002c7
IOPolledFileWrite(gIOPolledCoreFileVars, 0, 0x0, NULL) returned 0xe00002c7
progress_notify_stage_outproc (during forwarding) returned 0xe00002c7
(kern_dump_write_public_key) outproc data flush returned 0xe00002c7
(do_kern_dump write public key) returned 0xe00002c7
IOPolledFileWrite(0x0xffffff8c5b245a00, 0x0, 0, 0x0) : IOStartPolledIO(0x0xffffff95eaaf7f80, kIOPolledWrite, 0, 0x1b9520000, 8192) returned 0xffffffff
IOPolledFileWrite (during EOF) returned 0xffffffff
progress_notify_stage_outproc (during forwarding) returned 0xffffffff
(do_kern_dump close) outproc(KDP_EOF, NULL, 0, 0) returned 0xffffffff
IOPlatformPanicAction -> AppleAHCIDiskDriver
Attempting system restart...
IOPlatformPanicAction -> AppleAHCIDiskDriver
IOPlatformPanicAction -> AppleAHCIDiskDriver

 

3. Booting from OC from USB booting Ventura from NVME I've once manage to almost get to the login scree but reboot, I've got a feeling that this one might have been a fluke. 

  

IOG flags 0x3 (0x51)

  

ACMRM: _mapAndPublishTRM: set TRM_CacheMiss = False.
ACMRM: _mapAndPublishTRM: sending kIOMessageServicePropertyChange(n=1) while LOCKED, TRM: 259200 U/0 172800 -/ff miss=0 (CUR: 259200 U/0 172800 X/0).
ACMRM: _logPolicy: SAVING (sync): ver=8 smTm=0 poRsn=0 gpTm=0 smExp=NO gpBlk=NO suTm=0 svTm=1684374591 gpRsn=0 cMs=NO.
ACMRM-S: setData: saving policy (len=41) in 1 seconds.
ACMRM: _registerBioNotifier: Biometric driver not detected.
awdd[239] triggered unnest of range 0x7ff842000000->0x7ff842200000 of DYLD shared region in VM map 0x6ec4e9f63ca8830d. While not abnormal for debuggers, this increases system memory footprint until the target exits.
AppleKeyStore:11114:246: operation failed (sel: 17 ret: e00002f0, 205, 100005)
virtual bool CoreAnalyticsUserClient::initWithTask(task_t, void *, UInt32, OSDictionary *)::165:success
IOReturn CoreAnalyticsHub::setClientGated(CoreAnalyticsUserClient *)::321:adding userClient
IOReturn CoreAnalyticsHub::__newUserClientGated(task_t, void *, UInt32, OSDictionary *, IOUserClient **)::276:Successfully opened
virtual IOReturn CoreAnalyticsUserClient::clientMemoryForType(UInt32, IOOptionBits *, IOMemoryDescriptor **)::269: got memory descriptor with 16432
ACMRM-S: _saveAll: pushing policy -> daemon (gen=1 len=41).
apfs_keybag_init:2214: failed to initialize volume keybag, err = 2
EXC_RESOURCE -> coreduetd[108] exceeded mem limit: ActiveSoft 50 MB (non-fatal)
apfs_keybag_init:2214: failed to initialize volume keybag, err = 2
KextLog: kernelmanagerd is not active
apfs_keybag_init:2214: failed to initialize volume keybag, err = 2
cryptoAlloc:676: Using 64 buffers with size 16384, 512 buffers size 65536
dev_init:314: disk2s2 device accelerated crypto: 0 (compiled @ Jul 13 2022 22:54:35)
dev_init:317: disk2s2 device_handle block size 4096 block count 122092289 features 0 internal 
apfs_keybag_init:2214: failed to initialize volume keybag, err = 2
nx_mount:1184: disk2s2 initializing cache w/hash_size 8192 and cache size 32768
nx_mount:1460: disk2s2 checkpoint search: largest xid 15296, best xid 15296 @ 111
nx_mount:1462: disk2s2 reloading after unclean unmount, checkpoint xid 15296, superblock xid 15294
nx_get_volume_group:7912: disk2s2 volume groups tree is not setup yet
getVolumeGroupMountFrom:7453: disk2s2 nx_get_volume_group(49712122-1B10-4BB8-9EFB-55D91655A2DF) failed with error 2
nx_get_volume_group:7912: disk2s2 volume groups tree is not setup yet
getVolumeGroupMountFrom:7453: disk2s2 nx_get_volume_group(49712122-1B10-4BB8-9EFB-55D91655A2DF) failed with error 2
apfs_keybag_init:2214: failed to initialize volume keybag, err = 2
KextLog: Loading FileSet KC(s)
KextLog: Loading Pageable KC from file /System/Library/KernelCollections/SystemKernelExtensions.kc
KextLog: Collection UUID matches with loaded KCs.
deferred rematching count 0
IOG flags 0x3 (0x51)
Apple16X50ACPI1: Identified Serial Port on ACPI Device=UAR2
PROGRESS CODE: V00061000 I0

 

Plus many, many versions, File name kind of explains what they are. 

 

 

6 hours ago, etorix said:

Wow! I didn't know that this class of system could even boot without the flag npci=0x2000. That opens a potential field of research.

Yup it does boots without it.

 

 

6 hours ago, etorix said:

Browsing through my archives, I've found the same identifier 8086:7AE0 in the SysReport from a Gigabyte Z690 board, where it's obviously supported. And it seems logical that W790 uses the same USB controller as Z690. Let's release this suspect…

From what I can see I started doubting that the issue is the USB it might be deeper than that.

 

 

 

6 hours ago, etorix said:

AppleVTD not working, but you have enabled Kernel>Quirk>DisableIoMapper so it cannot work.

Also DMAR is dropped but no alternate table is loaded.

 

If I stable the DisableIoMapper Quirk I get instant panic.

 

So I've disabled the DisableIoMapper quirk, dropped DMAR and Replaced it with the Fixed DMAR table still gets panic.

  

pci (build 20:54:36 Mar  6 2023), flags 0xc3080
panic(cpu 0 caller 0xffffff8005bb4ad3): Kernel trap at 0xffffff80084a8d5f, type 14=page fault, registers:
CR0: 0x000000008001003b, CR2: 0xffffff91000000b4, CR3: 0x0000000021fe0000, CR4: 0x00000000003606e0
RAX: 0x00000000000c3080, RBX: 0xffffffdde1b9e000, RCX: 0x000000000000000a, RDX: 0x0000000000000008
RSP: 0xfffffff4ac4f3c40, RBP: 0xfffffff4ac4f3c80, RSI: 0xffffff9100000030, RDI: 0x0000000000000200
R8:  0x000000000000ffff, R9:  0x00000000ffffffff, R10: 0x0000000000000001, R11: 0x0000000000001001
R12: 0xffffff8c5a85c900, R13: 0x00000000d4f52801, R14: 0xffffff80084c9b88, R15: 0xffffff9ab2250e00
RFL: 0x0000000000010286, RIP: 0xffffff80084a8d5f, CS:  0x0000000000000008, SS:  0x0000000000000000
Fault CR2: 0xffffff91000000b4, Error code: 0x0000000000000000, Fault CPU: 0x0, PL: 0, VF: 1

Panicked task 0xffffff95ea506bf8: 28 threads: pid 0: 
Backtrace (CPU 0), panicked thread: 0xffffff8c5a3deb30, Frame : Return Address
0xfffffff4ac4f3600 : 0xffffff8005a705fd mach_kernel : _handle_debugger_trap + 0x4ad
0xfffffff4ac4f3650 : 0xffffff8005bc4b84 mach_kernel : _kdp_i386_trap + 0x114
0xfffffff4ac4f3690 : 0xffffff8005bb4619 mach_kernel : _kernel_trap + 0x3c9
0xfffffff4ac4f36f0 : 0xffffff8005a10951 mach_kernel : _return_from_trap + 0xc1
0xfffffff4ac4f3710 : 0xffffff8005a708dd mach_kernel : _DebuggerTrapWithState + 0x5d
0xfffffff4ac4f3800 : 0xffffff8005a6ff87 mach_kernel : _panic_trap_to_debugger + 0x1a7
0xfffffff4ac4f3860 : 0xffffff80061dd09b mach_kernel : _panic + 0x84
0xfffffff4ac4f3950 : 0xffffff8005bb4ad3 mach_kernel : _sync_iss_to_iks + 0x2c3
0xfffffff4ac4f3ad0 : 0xffffff8005bb47c4 mach_kernel : _kernel_trap + 0x574
0xfffffff4ac4f3b30 : 0xffffff8005a10951 mach_kernel : _return_from_trap + 0xc1
0xfffffff4ac4f3b50 : 0xffffff80084a8d5f com.apple.iokit.IOPCIFamily : __ZN8AppleVTD12initHardwareEP9IOService + 0x127
0xfffffff4ac4f3c80 : 0xffffff800612277a mach_kernel : __ZN8IOMapper5startEP9IOService + 0x1a
0xfffffff4ac4f3cb0 : 0xffffff80084a5dd7 com.apple.iokit.IOPCIFamily : __ZN8AppleVTD7installEP10IOWorkLoopjP9IOServicePK6OSDataP32IOPCIMessagedInterruptController + 0xdb
0xfffffff4ac4f3cf0 : 0xffffff80084b86e4 com.apple.iokit.IOPCIFamily : __Z23IOPCIPlatformInitializev + 0x21c
0xfffffff4ac4f3d40 : 0xffffff80069690c3 com.apple.driver.AppleACPIPlatform : __ZN23AppleACPIPlatformExpert21initPCIExpressSupportEv + 0x19f
0xfffffff4ac4f3d90 : 0xffffff8006962788 com.apple.driver.AppleACPIPlatform : __ZN23AppleACPIPlatformExpert5startEP9IOService + 0x2c4
0xfffffff4ac4f3dd0 : 0xffffff80060ec991 mach_kernel : __ZN9IOService14startCandidateEPS_ + 0xd1
0xfffffff4ac4f3e30 : 0xffffff80060ec50a mach_kernel : __ZN9IOService15probeCandidatesEP12OSOrderedSet + 0xdba
0xfffffff4ac4f3ef0 : 0xffffff80060eb5bf mach_kernel : __ZN9IOService14doServiceMatchEj + 0x3af
0xfffffff4ac4f3f50 : 0xffffff80060ee5f7 mach_kernel : __ZN15_IOConfigThread4mainEPvi + 0x157
0xfffffff4ac4f3fa0 : 0xffffff8005a1019e mach_kernel : _call_continuation + 0x2e
      Kernel Extensions in backtrace:
         com.apple.iokit.IOPCIFamily(2.9)[98683EFC-EF7A-3169-8DD1-9227B9A27BAA]@0xffffff8008491000->0xffffff80084c1fff
         com.apple.driver.AppleACPIPlatform(6.1)[19DE4373-3744-3B75-A4EE-3C799E649D8F]@0xffffff8006961000->0xffffff80069d8fff
            dependency: com.apple.driver.AppleSMC(3.1.9)[DD55DA6A-679A-3797-947C-0B50B7B5B659]@0xffffff80070c3000->0xffffff80070dffff
            dependency: com.apple.iokit.IOACPIFamily(1.4)[D342E754-A422-3F44-BFFB-DEE93F6723BC]@0xffffff8008021000->0xffffff8008022fff
            dependency: com.apple.iokit.IOPCIFamily(2.9)[98683EFC-EF7A-3169-8DD1-9227B9A27BAA]@0xffffff8008491000->0xffffff80084c1fff

Process name corresponding to current thread (0xffffff8c5a3deb30): Unknown
Boot args: -v serial=5 keepsyms=1 debug=0x100 acpi_layer=0x8 msgbuf=1048576 root-dmg=file:///BaseSystem/BaseSystem.dmg

Mac OS version:
Not yet set

Kernel version:
Darwin Kernel Version 22.4.0: Mon Mar  6 21:00:17 PST 2023; root:xnu-8796.101.5~3/RELEASE_X86_64
Kernel UUID: CF2A42DA-3F7C-30C6-9433-6F2076FF1F94
roots installed: 0
KernelCache slide: 0x0000000005600000
KernelCache base:  0xffffff8005800000
Kernel slide:      0x00000000056dc000
Kernel text base:  0xffffff80058dc000
__HIB  text base: 0xffffff8005700000
System model name: MacPro7,1 (Mac-27AD2F918AE68F61)
System shutdown begun: NO
Panic diags file unavailable, panic occurred prior to initialization
Hibernation exit count: 0

System uptime in nanoseconds: 4470827513
Last Sleep:           absolute           base_tsc          base_nano
  Uptime  : 0x000000010b20cf88
  Sleep   : 0x0000000000000000 0x0000000000000000 0x0000000000000000
  Wake    : 0x0000000000000000 0x00000061110c5657 0x0000000000000000
Compressor Info: 0% of compressed pages limit (OK) and 0% of segments limit (OK) with 0 swapfiles and OK swap space
Zone info:
  Zone map: 0xffffff81124a1000 - 0xffffffa1124a1000
  . PGZ   : 0xffffff81124a1000 - 0xffffff813249e000
  . VM    : 0xffffff813249e000 - 0xffffff85fa49e000
  . RO    : 0xffffff85fa49e000 - 0xffffff879249e000
  . GEN0  : 0xffffff879249e000 - 0xffffff8c5a49e000
  . GEN1  : 0xffffff8c5a49e000 - 0xffffff912249e000
  . GEN2  : 0xffffff912249e000 - 0xffffff95ea49e000
  . GEN3  : 0xffffff95ea49e000 - 0xffffff9ab249f000
  . DATA  : 0xffffff9ab249f000 - 0xffffffa1124a1000
  Metadata: 0xffffffd760fd3000 - 0xffffffd780fd3000
  Bitmaps : 0xffffffd780fd3000 - 0xffffffd790fd3000
  Extra   : 0 - 0


** In Memory Panic Stackshot Succeeded ** Bytes Traced 4801 (Uncompressed 11408) **

Please go to https://panic.apple.com to report this panic

 

The region in DMAR is this correct?

  

[180h 0384   2]                Subtable Type : 0001 [Reserved Memory Region]
[182h 0386   2]                       Length : 0020

[184h 0388   2]                     Reserved : 0000
[186h 0390   2]           PCI Segment Number : 0000
[188h 0392   8]                 Base Address : 000000006EF67000
[190h 0400   8]          End Address (limit) : 000000006EF8CFFF

[198h 0408   1]            Device Scope Type : 01 [PCI Endpoint Device]
[199h 0409   1]                 Entry Length : 08
[19Ah 0410   2]                     Reserved : 0000
[19Ch 0412   1]               Enumeration ID : 00
[19Dh 0413   1]               PCI Bus Number : 00

[19Eh 0414   2]                     PCI Path : 14,00

 

Also in the DMAR there is this weird part that I had to remove.

  

[2B8h 0696   2]                Subtable Type : 0005 [Unknown Subtable Type]
[2BAh 0698   2]                       Length : 0010


**** Unknown DMAR subtable type 0x5

 

 

 

6 hours ago, etorix said:

The OpenCore log indicates that MAT is supported (first option: RebuildAppleMemoryMap + SyncRuntimePermissions). But further up was a panic report involving CR2 register, which may invite to rather use EnableWriteUnprotector and disable the other two quirks. So two possibilities to test.

Tried every possible combination,  no go.

 

Also attaching the ACPI Dump from Clover with the latest BIOS.

 

Logs:

NVME BOOTER - Ventura.txt

 

USB Booter - DMAR.txt

 

USB Booter - NVME Ventura - EnableWriteUnprotector.txt

 

USB Booter - SATA Monterey.txt

 

USB Booter - USB Installer - EnableWriteUnprotector No Panic.txt

 

USB Booter - USB Installer.txt

 

USB Booter -NVME Ventura BOOT But restart.txt

 

USB Booter -USB Installer - DMAR Droped.txt

 

 

ACPI Dump.

 

origin.zip

 

 

 

  • Like 2
Link to comment
Share on other sites
Balamut
Balamut
Posted
  • Author
Posted (edited)

Small update, I've got the kernel debugger running and boy did it threw up data.

OC from USB and booting from USB Installer 13.4.

  

Still waiting for root device
IOResources: family specific matching fails

Still waiting for root device
IOResources: family specific matching fails

From my limited understanding maybe we can fake device ID and see if it works?

 

 

Full log.

CoolTerm Capture 2023-05-18 14-06-42.txt

 

 

Edited by Balamut
Grammar
  • Like 2
Link to comment
Share on other sites
etorix
etorix
Posted
Posted

Kernel debugging land… My first thought was that, maybe, we should get @Casey_S.J. interested in Sapphire Rapids. But maybe Casey has been there already? This failure to initialise PCIe devices is not unlike the "PCIe zombie" on AM5.

 

Try boot-arg "pci=0x8000000".

If it works (or at least does something…) you may try the kernel patch to disable 10-bit Extended Tag Features only. 

    Arch: x86_64
    Identifier: com.apple.iokit.IOPCIFamily
    Base: __ZN11IOPCIBridge13probeBusGatedEP14probeBusParams
    Comment: CaseySJ - probeBusGated Disable 10 bit tags 12.x/13.x
    Find: E6117206
    Replace: E6117306
    Min Kernel: 21.0.0
    Max Kernel: 22.99.99
    Count: 1
    Enabled: True

 

  • Like 3
Link to comment
Share on other sites
etorix
etorix
Posted
Posted (edited)

After a good reading of section 20.3 of ACPI Specification 6.5 (the list of opcodes…) and some fun with a hex editor, I've come to the conclusion that the wall of ACPI warnings 

ACPI Warning: Unsupported module-level executable opcode 0x70 at table offset 0x388D9 (20160930/psloop-285)

comes from the DSDT itself (as seen from the offsets) and relate to these lines in the _INI () initialisation method of root ports RP01 to RP28 

SIPV = GSIP ()

(0x70 is the '='). SIPV is actually used exactly nowhere else. It should be possible to get rid of the warnings without adverse effect with a DSDT patch:

image.thumb.png.4db79bfbd5c1a31bc1be6618555ec3f9.png

 

Now if I could figure out the more serious ACPI error from \_SB.PC00.XHCI.RHUB.HS01 in the SSDT…

 

P.S. I got report that the patch fails to remove the ACPI warnings on WS W790-ACE.

patch.plist

Edited by etorix
correction
  • Like 3
Link to comment
Share on other sites
Balamut
Balamut
Posted
  • Author
Posted (edited)

Will test it out today and report, sorry work got me pretty busy.

 

Mods: @EVILGENIUS cannot post here for some reason and since and I are the only ones with this type of system can we do anything about it please?

Edited by Balamut
  • Like 2
Link to comment
Share on other sites
Casey_S.J.
Casey_S.J.
Posted
Posted (edited)

It may be a good idea to add both of these patches from AMD-OSX repository because they affect PCI zombies and PCI bus enumeration problems. These are not AMD-specific issues.

 

P.S. I'll watch from the sidelines, but cannot take an active role at this time. It's also a good idea to start with Big Sur or Monterey.

 

359959356_Screenshot2023-05-21at9_46_19AM.thumb.png.465f8c9df2852bcff7ba8c0f2aa848d6.png

Edited by Casey_S.J.
  • Like 4
Link to comment
Share on other sites
etorix
etorix
Posted
Posted

Indeed, I had forgotten the PCI enumeration patch. Trying it cannot hurt. But, after re-reading the story of these AMD-OSX patches, I fear that the issue with Sapphire Rapids is more fundamental, and possibly more serious.

Another idea which could be taken out of the Ryzentosh toolbox is whitelisting memory.

Quote

33:163 00:031 OCABC: MMIO devirt start
33:190 00:027 OCABC: MMIO devirt 0x80000000 (0x10000 pages, 0x8000000000000001) skip 0
33:222 00:031 OCABC: MMIO devirt 0xFE010000 (0x1 pages, 0x8000000000000001) skip 0
33:253 00:031 OCABC: MMIO devirt 0xFF000000 (0x1000 pages, 0x800000000000100D) skip 0
33:285 00:031 OCABC: MMIO devirt end, saved 278532 KB

 

On 5/20/2023 at 8:05 PM, Balamut said:

Mods: @EVILGENIUS cannot post here for some reason and since and I are the only ones with this type of system can we do anything about it please?

@EVILGENIUS can help himself out… by bumping his post count in the New Users Lounge until he is allowed out of the sandbox.

  • Like 2
Link to comment
Share on other sites
Balamut
Balamut
Posted
  • Author
Posted
3 hours ago, etorix said:

Another idea which could be taken out of the Ryzentosh toolbox is whitelisting memory.

I went trough the logs and I couldn't find MMIO memory issue, since last night I had so many logs I've started dreaming OC/Kernel debug logs.

 

 

5 hours ago, Casey_S.J. said:

It may be a good idea to add both of these patches from AMD-OSX repository because they affect PCI zombies and PCI bus enumeration problems. These are not AMD-specific issues.

Thank you will dig deeper into it.

 

5 hours ago, Casey_S.J. said:

 

P.S. I'll watch from the sidelines, but cannot take an active role at this time. It's also a good idea to start with Big Sur or Monterey.

I actually have the Monterey installed on the SATA Drive and was going to do the same with the Big Sur. We appreciate any and all help in any capacity and your input is very much appreciated thank you.

 

 

On 5/19/2023 at 6:58 AM, etorix said:

P.S. I got report that the patch fails to remove the ACPI warnings on WS W790-ACE.

Yup can confirm, didn't do anything.

 

Attaching the latest log.

 

CoolTerm Capture 2023-05-21 15-15-35.txt

Link to comment
Share on other sites
etorix
etorix
Posted
Posted
8 hours ago, Balamut said:

I went trough the logs and I couldn't find MMIO memory issue, since last night I had so many logs I've started dreaming OC/Kernel debug logs.

There's an MMIO issue in "NVME booter" logs. 

panic(cpu 0 caller 0xffffff801af856a2): nvme: "3rd party NVMe controller. Loss of MMIO space. Write. fBuiltIn=1 MODEL=WD_BLACK SN750 SE 1TB FW=711130WD CSTS=0xffffffff US[1]=0x0 US[0]=0x64 VID=0x15b7 DID=0x501e CRITICAL_WARNING=0x0.\n" @IONVMeController.cpp:6090

Of course, the best situation would be to have AppleVTD working and NOT use Disable IoMapper, so whitelisting cannot be the best solution. :wallbash:

  • Like 2
Link to comment
Share on other sites
Balamut
Balamut
Posted
  • Author
Posted (edited)
12 hours ago, etorix said:

There's an MMIO issue in "NVME booter" logs.

Ah that. I was trying to recreate that but for some odd reason I can't remember how did it in the first place.

 

12 hours ago, etorix said:

Of course, the best situation would be to have AppleVTD working and NOT use Disable IoMapper, so whitelisting cannot be the best solution. :wallbash:

Been working on it for a while, and no mater what I do the Dropping DMAR and replacing it with modded one does nothing. 

 

@EVILGENIUS had a little more success with AppleVTD, hopefully he'll be able to post here soon.

 

Is AppleVTD started on Monterey or Ventura?

 

 

I've been in IT since 1995 when I build my very first PC based on Athlon K7 and been building servers and server/render farms ever since, I've yet to see more crappier, half baked product than the W790 BIOS from ASSRock and Asus. Sorry had to vent.

 

 

 

Edited by Balamut
  • Like 1
Link to comment
Share on other sites
Balamut
Balamut
Posted
  • Author
Posted (edited)

New update, trying the same config but with the Monterey Installer NO warning, no ACPI errors, but still the same waiting for the root device.

  

ACPI: DSDT 0x0000000065F85000 07AA4E (v02 ALASKA A M I    01072009 INTL 20091013)AssertMacros: value (ACPI: FACS 0x000000006897C000 000040
ACPI: SPMI 0x0000000066000000 000041 (v05 ALASKA A M I    00000000 AMI. 00000000)value: 0x0), ---, file: /System/Volumes/Data/SWE/macOS/BuildRoots/533514bb11/Library/Caches/com.apple.xbs
ACPI: FIDT 0x0000000065F84000 00009C (v01 ALASKA A M I    01072009 AMI  00010013)
ACPI: SSDT 0x0000000065F82000 0006ED (v02 INTEL  RAS_ACPI 00000001 INTL 20200430)/Sources/AppleCredentialManager/AppleCredentialManager-496.60.3/AppleCredentialManager/Services/ACMKernel
ACPI: ERST 0x0000000065F81000 000230 (v01 ALASKA A M I    00000001 INTL 00000001)
ACPI: MCFG 0x0000000065F7F000 00003C (v01 ALASKA A M I    01072009 MSFT 00000097)Service.cpp:182
ACPI: FACS 0x000000006897C000 000040
ACPI: SPMI 0x0000000066000000 000041 (v05 ALASK
ACPI: BDAT 0x0000000065F7E000 000030 (v01 ALASKA A M I    00000000 INTL 20091013)
ACPI: HPET 0x0000000065F7D000 000038 (v01 ALASKA A M I    00000001 INTL 20091013)A A M I    00000000 AMI. 00000000)
ACPI: FIDT 0x0000000065F84000 00009C (v01 ALASKA A M I    01072009 A
ACPI: MSCT 0x0000000065F7C000 00004E (v01 ALASKA A M I    00000001 INTL 20091013)
ACPI: WDDT 0x0000000065F7B000 000040 (v01 ALASKA A M I    00000000 INTL 20091013)MI  00010013)
ACPI: SSDT 0x0000000065F82000 0006ED (v02 INTEL  RAS_ACPI 00000001 INTL 20200430)
ACPI: 
ACPI: APIC 0x0000000065F79000 00025E (v04 ALASKA A M I    00000000 INTL 20091013)
ACPI: ERST 0x0000000065F81000 000230 (v01 ALASKA A M I    00000001 INTL 00000001)
ACPI: MCFG 0x0000000065F7F00SRAT 0x0000000065F77000 001E30 (v03 ALASKA A M I    00000002 AMI  01000013)
ACPI: SLIT 0x0000000065F76000 000030 (v01 ALASKA A M I    01072009 AMI  01000013)0 00003C (v01 ALASKA A M I    01072009 MSFT 00000097)
ACPI: BDAT 0x0000000065F7E000 000030 (v01 ALASKA A
ACPI: HMAT 0x0000000065F75000 000158 (v02 ALASKA A M I    01072009 AMI  01000013)
 M I    00000000 INTL 20091013)
ACPI: HPET 0x0000000065F7D000 000038 (v01 ALASKA A M I    00000001 INTL 20091013)
ACPI: MSCT 0x0000000065F7C000 00004E (v01 ALASKA A M I    00000001 INTL 20091013)
ACPI: WDDT 0x0000000065F7B000 000040 (v01 ALASKA A M I    00000000 INTL 20091013)
ACPI: APIC 0x0000000065F79000 00025E (v04 ALASKA A M I    00000000 INTL 20091013)
ACPI: SRAT 0x0000000065F77000 001E30 (v03 ALASKA A M I    00000002 AMI  01000013)
ACPI: SLIT 0x0000000065F76000 000030 (v01 ALASKA A M I    01072009 AMI  01000013)
ACPI: HMAT 0x0000000065F75000 000158 (v02 ALASKA A M I    01072009 AMI  01000013)
AppleCredentialManager: init: EOSDevice: 0 [SEP over: KernelRelay=NO SEPManager=NO] [booted into: BaseSystem=YES InternalSystem=NO].
ACM: Env_SetVariableWithParams: set var[6] len=1 <00>.
ACM: InitCredentialEngine: Global credential set created, CS[20].
ACM: Env_SetVariableWithParams: set var[5] len=1 <00>.
ACM: Env_SetVariableWithParams: set var[23] len=1 <01>.
ACM: Env_SetVariableWithParams: set var[24] len=22 <4a616e202036203ACPI: OEM4 0x0000000065F13000 061ED1 (v02 INTEL  CPU  CST 00003000 INTL 20200430)23032322c2032323a34323a323200>.
ACPI: ACM: Env_SetDataProvider: data provider *set* for var[25].
ACM: 
Env_SetDataProvider: data provider *set* for var[27].
OEM4 0x0000000065F13000 061ED1 (v02 INTEL  CPU  CST 00003000 INTL 20200430)
ACM: Env_SetDataProvider: data provider *set* for var[22].
ACM: Env_SetDataProvider: data provider *set* for var[29].
ACM: Env_SetVariableWithParams: set var[7] len=1 <00>.
ACM: Env_SetVariableWithParams: set var[26] len=1 <00>.
ACM: Env_SetVariableWithParams: set var[33] len=1 <01>.
ACM: Env_SetVariableWithParams: set var[34] len=1 <00>.
ACMFirstResponderKernelService: init: called, .
ACMRM-S: init: called, starting PersistentStore service.
ACMRM-C: init: called, starting AccessoryCachACPI: OEM1 0x0000000065ECE000 044379 (v02 INTEL  CPU EIST 00003000 INTL 20200430)e service.
ACPI: ACMKernelService: initValueFromBootArgAliasesUInt32: acc-cache size = 16 (default).
AC

MKernelService: initValueFromBootArgAliasesUInt32: acc-cache expiration = 2592000 (default).
OEM1 0x0000ACPI: OEM2 0x0000000065EBC000 011831 (v02 INTEL  CPU  HWP 00003000 INTL 20200430)000065ECE000 044379 (v02 INTEL  CPU EIST 00003000 INTL 20200430)
ACPI: ACMRM: init: called, starting TRM

 service.
OEM2 0x0000000065EBC000 011831 (v02 INTEL  CPU  HWP 00003000 INTL 20200430)
ACMRM-A: init: called, starting TRM Analytics service.
ACMKernelService: initValueFromBootArgAliasesUInt32: analytics collACPI: SSDT 0x0000000065EA1000 01A65E (v02 INTEL  SSDT  PM 00004000 INTL 20200430)ection period = 86400 (default).
ACPI: ACMKernelService: initValueFromBootArgAliasesUInt32: policy mode 
ACPI: DBG2 0x0000000065E9F000 00005C (v00 ALASKA A M I    01072009 AMI  01000013)
ACPI: HEST 0x0000000065E9E000 00013C (v01 ALASKA A M I    00000001 INTL 00000001)timeout = 259200 (default).
SSDT 0x0000000065EA1000 01A65E (v02 INTEL  SSDT  PM 00004000 INTL 20200430)
ACPI: BERT 0x0000000065E9D000 000030 (v01 ALASKA A M I    00000001 INTL 00000001)
ACPI: SSDT 0x0000000065E9C000 00076E (v02 INTEL  ADDRXLAT 00000001 INTL 20200430)
ACPI: DBG2 0x0000000065E9F000 00005C (v00 ALASKA A M I    01072009 AMI  01000013)
ACPI: HEST 0x00000000
ACPI: DMAR 0x0000000065E9B000 0002C8 (v01 ALASKA A M I    00000001 INTL 20091013)
ACPI: FPDT 0x0000000065E9A000 000044 (v01 ALASKA A M I    01072009 AMI  01000013)65E9E000 00013C (v01 ALASKA A M I    00000001 INTL 00000001)
ACPI: BERT 0x0000000065E9D000 000030 (v01 A
LASKA A M I    00000001 INTL 00000001)
ACPI: SSDT 0x0000000065E9C000 00076E (v02 INTEL  ADDRXLAT 00000001ACPI: VFCT 0x0000000065E8B000 00E684 (v01 ALASKA A M I    00000001 AMD  31504F47) INTL 20200430)
ACPI: DMAR 0x0000000065E9B000 0002C8 (v01 ALASKA A M I    00000001 INTL 20091013)
ACPI:
ACPI: SPCR 0x0000000065E8A000 000050 (v02 ALASKA A M I    01072009 AMI  0005001D)
ACPI: WPBT 0x0000000065D3D000 000040 (v01 ALASKA A M I    00000001 ASUS 00000001) FPDT 0x0000000065E9A000 000044 (v01 ALASKA A M I    01072009 AMI  01000013)
ACPI: VFCT 0x0000000065E8B0
ACPI: TPM2 0x0000000065D3C000 00004C (v04 ALASKA A M I    00000001 AMI  00000000)
ACPI: WSMT 0x0000000065F7A000 000028 (v01 ALASKA A M I    01072009 AMI  00010013)00 00E684 (v01 ALASKA A M I    00000001 AMD  31504F47)
ACPI: SPCR 0x0000000065E8A000 000050 (v02 ALASKA
ACPI: SSDT 0x0000000066855000 0017C2 (v02 ETRX   CPUWRAP  00000000 INTL 20200925)
ACPI:  A M I    01072009 AMI  0005001D)
ACPI: WPBT 0x0000000065D3D000 000040 (v01 ALASKA A M I    00000001 ASUSSDT 0x0000000066854000 000179 (v02 ACDT   SsdtEC   00001000 INTL 20200925)
S 00000001)
ACPI: TPM2 0x0000000065D3C000 00004C (v04 ALASKA A M I    00000001 AMI  00000000)
ACPI: WSMT 0x0000000065F7A000 000028 (v01 ALASKA A M I    01072009 AMI  00010013)
ACPI: SSDT 0x0000000066855000 0017C2 (v02 ETRX   CPUWRAP  00000000 INTL 20200925)
ACPI: SSDT 0x0000000066854000 000179 (v02 ACDT   SsdtEC   00001000 INTL 20200925)
ACMRM-A: notifyStandardModeTimeoutChanged: called, value = 259200 (modified = YES).
ACMKernelService: initValueFromBootArgAliasesUInt32: (bounded) grace period timeout = 172800 (default).
ACMRM-A: notifyGracePeriodTimeoutChanged: called, value = 172800 (modified = YES).
ACMKernelService: initValueFromBootArgAliasesUInt32: enabled = 0 (default).
ACMRM: _disableBy: [TRM ENABLED=NO] (mask=2, DISABLED BY: Def=YES* BtArg=NO LegHW=NO OSEnv=NO | MngCo=NO DwnOS=NO ChkBd=NO coGSw=NO).
ACMRM: _disableBy: [TRM ENABLED=NO] (mask=2, DISABLED BY: Def=YES BtArg=NO* LegHW=NO OSEnv=NO | MngCo=NO DwnOS=NO ChkBd=NO coGSw=NO).
AssertMacros: value (value: 0x0), ---, file: /System/Volumes/Data/SWE/macOS/BuildRoots/533514bb11/Library/Caches/com.apple.xbs/Sources/AppleCredentialManager/AppleCredentialManager-496.60.3/AppleCredentialManager/Services/ACMKernelService.cpp:182
ACMRM: _disableBy: [TRM ENABLED=NO] (mask=a, DISABLED BY: Def=YES BtArg=NO LegHW=YES* OSEnv=NO | MngCo=NO DwnOS=NO ChkBd=NO coGSw=NO).
AssertMacros: data (value: 0x0), 'disable-transport-rm' property not found, file: /System/Volumes/Data/SWE/macOS/BuildRoots/533514bb11/Library/Caches/com.apple.xbs/Sources/AppleCredentialManager/AppleCredentialManager-496.60.3/AppleCredentialManager/Services/ACMRestrictedModeKernelService.cpp:1165
ACMRM: _loadDisabledByOSEnvironment:ACPI: 6 ACPI AML tables successfully acquired and loaded disabled by OSEnvironment: NO.
ACPI: ACMRM: _disableBy: [TRM ENABLED=NO] (mask=a, DISABLED BY: Def=YES

config.plist

CoolTerm Capture 2023-05-22 15-55-42.txt

 

Interesting observation, the Ventura cannot load one of the tables but Monterey can.

 

Monterey: 

ACPI: 6 ACPI AML tables successfully acquired and loaded

 

Ventura
  

ACPI Error: [\_SB_.PC00.XHCI.RHUB.HS01] Namespace lookup failure, AE_NOT_FOUND (20160930/dswload-292)
ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20160930/psobject-310)
ACPI Exception: AE_NOT_FOUND, (SSDT:  A M I ) while loading table (20160930/tbxfload-319)
ACPI Error: 1 table load failures, 5 successful (20160930/tbxfload-342)

 

This is freaking weird.

 

 

 

 

Edited by Balamut
  • Like 2
  • Sad 1
Link to comment
Share on other sites
Casey_S.J.
Casey_S.J.
Posted
Posted

If you’re using a USB install disk, have you tried using a SATA disk instead (installed internally)? 
 

“Still waiting for root device” typically indicates loss of USB bus, hence the suggestion to switch to SATA bus. 

  • Like 1
Link to comment
Share on other sites
etorix
etorix
Posted
Posted
11 hours ago, Balamut said:

New update, trying the same config but with the Monterey Installer NO warning, no ACPI errors, but still the same waiting for the root device.

Well, it seems that the DSDT patch works after all. There are 28 root ports, it's applied 28 times, and the ACPI errors have disappeared. 

11:773 00:039 OC: Applying 9 byte ACPI patch (ACPI warnings for W790) at 0, skip 0, count 0
11:816 00:043 OCA: Patching DSDT of 502350 bytes with 0000000000000000 ID replaced 28 of 0
11:863 00:047 OCA: Refreshed DSDT checksum to 9F

 

The ACPI error for \_SB_.PC00.XHCI.RHUB.HS01 with Ventura is even more puzzling now. Apple must have made some changes in Ventura.

 

There are 2168 instances of "family specific matching fails" in the log (plus mangled ones), of which 109 "IOResources: family specific matching fails". Many entries appear to be duplicates from repeated attempts.

This is different from the Extended Tag Flags issue (fixed by kernel patch for ETF 10b; pci=0x8000000 removes both 08b and 10b) and the PCI bus enumeration issue (patch for Ventura only).

 

Comparing with older CoolTerm logs, the "family specific matching fails" were entirely absent in earlier attempts where 'npci=0x2000' flag was used. Could it be an issue of IRQ conflicts on the PCI bus?

Suggestions: Put back 'npci=0x2000', or even try 'npci=0x3000'. Run SSDTime from Linux or Windows and see whether it comes out with a SSDT-HPET and patches for IRQ conflicts.

 

Alternatively, you may keep going back in time with Big Sur or Catalina.

 

  • Like 1
Link to comment
Share on other sites
Balamut
Balamut
Posted
  • Author
Posted (edited)
9 hours ago, Casey_S.J. said:

If you’re using a USB install disk, have you tried using a SATA disk instead (installed internally)? 

Installer from SATA or already installed on SATA?

It was actually my second step to install OS on SATA drive on a different system then try to boot on W790 I just wanted to test different OS Installers to see if there were any big changes between them.

 

 

9 hours ago, Casey_S.J. said:

 

“Still waiting for root device” typically indicates loss of USB bus, hence the suggestion to switch to SATA bus. 

The part that rises and eye brow for me is that even if you boot OC from EFI partition on the NVME drive and then try to load the OC from the NVME drive you still get the "Still waiting for the root deice" error even thou you're not touching the USB at all,

 

 

9 hours ago, etorix said:

The ACPI error for \_SB_.PC00.XHCI.RHUB.HS01 with Ventura is even more puzzling now. Apple must have made some changes in Ventura.

 

There are 2168 instances of "family specific matching fails" in the log (plus mangled ones), of which 109 "IOResources: family specific matching fails". Many entries appear to be duplicates from repeated attempts.

This is different from the Extended Tag Flags issue (fixed by kernel patch for ETF 10b; pci=0x8000000 removes both 08b and 10b) and the PCI bus enumeration issue (patch for Ventura only).

 

Comparing with older CoolTerm logs, the "family specific matching fails" were entirely absent in earlier attempts where 'npci=0x2000' flag was used. Could it be an issue of IRQ conflicts on the PCI bus?

Suggestions: Put back 'npci=0x2000', or even try 'npci=0x3000'. Run SSDTime from Linux or Windows and see whether it comes out with a SSDT-HPET and patches for IRQ conflict

Slow but progress, SSDTime was next step for me, I wanted to see if there was a significant changes between Monterey and Ventura (They were). Still I wonder why Ventura fails to land AMI table but Monterey have no issues with it. 

Back to more testing and more logs.

 

9 hours ago, etorix said:

Alternatively, you may keep going back in time with Big Sur or Catalina.

Yup downloading them as I type will be trying to boot both of them and see if any changes in there.

 

Again I'd want to thank you ALL for ALL your help, it's very much appreciated.

 

 

P.S. I'm going over my old notes and can't seem to find how did we used to debug ACPI to get complete picture in the logs. Any suggestions?

 

 

Edited by Balamut
Link to comment
Share on other sites
etorix
etorix
Posted
Posted
1 hour ago, Balamut said:

Installer from SATA or already installed on SATA?

Either, as the idea is to get around the non-working USB controller by going to a SATA controller.

What may occur here, however, is that there's no working controller of any type (USB, SATA, NVMe) because they all fail to match their class…

 

On 5/22/2023 at 9:47 PM, Balamut said:

 

@EVILGENIUS had a little more success with AppleVTD, hopefully he'll be able to post here soon.

 

Is AppleVTD started on Monterey or Ventura?

AppleVTD has been there for a long time, for i210 NIC and/or devices over the Thunderbolt bus, which mattered to few users—especially if it was possible to work around it by forcefully loading a kext. But with the increasing emphasis on DriverKit, properly working AppleVTD becomes more and more important, in particular for native support of 10 GbE NICs: Aquantia, Intel X500, Intel X700, and now Mellanox.

@EVILGENIUS is currently half-way through (5: Newbie; five more posts for full access). If he cracked AppleVTD—at least to the point of being stuck "waiting for root device" but no KP—, he may publish on "the other forum" or use private messages to pass you critical information. A Xeon Scalable system should be able to boot with Intel VT-d ON in BIOS (but possibly SR-IOV OFF) and DisableIoMapper OFF.

Dropping DMAR may not be necessary as first intention, even with reserved regions. At worst, reservations are known to cause sleep issues or non-functioning networking, but not to completely prevent booting. The same goes for the new quirk DisableIoMappingMapper for Ventura: It restores networking functionality in some circumstances (which may very well apply here), but it is not required to boot.

 

2 hours ago, Balamut said:

Again I'd want to thank you ALL for ALL your help, it's very much appreciated.

You're welcome! Not having a similar system to try directly, all we can offer is moral support.

  • Like 2
Link to comment
Share on other sites
Casey_S.J.
Casey_S.J.
Posted
Posted

Incidentally, those “Family Mismatch” errors can generally be ignored. We see them quite often on AMD Ryzentoshes. 
 

Previous HEDT systems needed kernel patches that are injected via kernel quirk “AppleXcpmExtraMsrs”. 
 

If “still waiting for root device” is the current obstacle, and it happens on all buses (USB, PCI, SATA) then it may still be a good idea to enable IOPCIFamily debug logs. We do that by adding boot argument pci=0x3

  • Like 2
  • Thanks 1
Link to comment
Share on other sites
Balamut
Balamut
Posted
  • Author
Posted (edited)

Ok another update. I'm grown enough to call myself an idiot because I am. 

 

The ACPI warning and the RHUB errors are OS independent, it doesn't matter if you're on Monterey or Ventura the ACPI tables is utterly broken. I was dropping AMI table AND suppressing the Warning, the moment I remove both of them the warnings and the RHUB error came right back, so my original assumption that Monterey was processing it but Ventura didn't was completely wrong, sorry about that.

 

175055440_Screenshot2023-05-23at9_13_07PM.thumb.png.b3c21d699435969ac7846b5c391eae23.png

 

 

 

6 hours ago, Casey_S.J. said:

If “still waiting for root device” is the current obstacle, and it happens on all buses (USB, PCI, SATA) then it may still be a good idea to enable IOPCIFamily debug logs. We do that by adding boot argument pci=0x3

 

Thank you very much for the tip. From the MANY MANY logs that I've got and besides getting even more confused I've came to a conclusion(probably a wrong one) that OS somehow does not correctly process the ACPI tables or which is more likely that thanks to ASSUSes great wisdom and laziness they've royally screwed up the entire ACPI (they tech saying saying don't install anything other that windows comes to mind.)

 

 

8 hours ago, etorix said:

Dropping DMAR may not be necessary as first intention, even with reserved regions. At worst, reservations are known to cause sleep issues or non-functioning networking, but not to completely prevent booting. The same goes for the new quirk DisableIoMappingMapper for Ventura: It restores networking functionality in some circumstances (which may very well apply here), but it is not required to boot.

 

For some off reason the AppleVTD warning no longer there, still trying to figure out why. Also Did SSDTTime for HPET/IRQs with almost no effect.

 

 

The logs:

 

Monterey USB 3000 No Patches AMI Drop Warning Patch

Loading Monterey Installer from the USB, not kernel patches, NPCI=0x3000, only dropping AMI, ACPI Warning Patch.

Monterey USB 3000 No Patches AMI Drop Warning Patch.txt

 

 

Monterey USB 3000 No Patches AMI Drop

Loading Monterey Installer from the USB, not kernel patches, NPCI=0x3000, only dropping AMI, no other patch is active.

Monterey USB 3000 No Patches AMI Drop.txt

 

 

Monterey USB 3000 No Patches

Loading Monterey Installer from the USB, not kernel patches, NPCI=0x3000, no table dropping, no other patch is active.

Monterey USB 3000 No Patches.txt

 

 

Ventura USB 3000 No Patches

Loading Ventura Installer from the USB, not kernel patches, NPCI=0x3000, no table dropping, no other patch is active.

Ventura USB 3000 No Patches.txt

 

 

Monterey USB Installer - NPCI2000

Loading Monterey Installer from the USB, CaseySJs  patches, NPCI=0x2000, only dropping AMI, ACPI Warning Patch.

Monterey USB Installer - NPCI2000.txt

 

 

Ventura USB 3000 HPET

Loading Monterey Installer from the USB, not kernel patches, NPCI=0x3000, only dropping AMI, ACPI Warning Patch and HPET stuff.

Ventura USB 3000 HPET.txt

 

 

 

ACPI Stuff

SSDT-USBPORTS-W790.aml

SSDT-HPET.aml

SSDT-CPU-WRAP3.aml

 

 

OC Config File.

config.plist

 

 

 

8 hours ago, etorix said:

You're welcome! Not having a similar system to try directly, all we can offer is moral support.

 

Thank you, trust me I do now how hard it is try to help someone to debug something without actually having the hardware on the front of you, and I say thank you again to ALL of you for your amazing support and help. 

Monterey USB Installer - NPCI3000.txt Ventura USB Installer - NPCI2000.txt Ventura USB Installer - NPCI3000.txt

 

 

P.S. Ok I'm baffled. in comparing the log Ventura USB 3000 HPET I've got this, so somehow it didn't drop the AMI table and no errors?! I need a break, start getting a headache.
I need sleep I forgot I'm injecting HPET tables. 🤣

 

 

 

 

 

Edited by Balamut
  • Like 3
Link to comment
Share on other sites
etorix
etorix
Posted
Posted
15 hours ago, Casey_S.J. said:

If “still waiting for root device” is the current obstacle, and it happens on all buses (USB, PCI, SATA) then it may still be a good idea to enable IOPCIFamily debug logs. We do that by adding boot argument pci=0x3

Thanks for the tip! Is there a comprehensive documentation of these boot arguments somewhere? Or should one gather it piecemeal from Darwin header files?

 

9 hours ago, Balamut said:

The ACPI warning and the RHUB errors are OS independent, it doesn't matter if you're on Monterey or Ventura the ACPI tables is utterly broken. I was dropping AMI table AND suppressing the Warning, the moment I remove both of them the warnings and the RHUB error came right back, so my original assumption that Monterey was processing it but Ventura didn't was completely wrong, sorry about that.

On the other hand, ACPI errors are usually reported by OpenCore but these ones are only found in serial console logs, after OpenCore has handed control over to XNU. So it may be an issue with how macOS specifically processes these tables rather than the tables themselves.

One further proposal: Drop SSDT-2 ('A M I ') and inject SSDT-RHUB-W790 instead. This one assumes, without any conditional finesse, that HS/SS devices are not created in the DSDT and forcefully create everything as the DSDT+SSDT-2 should have done. (No combination with the earlier SSDT-PUC or SSDT-USBPORTS-W790.) If the devices were already created by the DSDT, SSDT-RHUB-W790 will generate a whole new wall of ACPI errors—and I will understand even less why the native SSDT does not load properly.

SSDT-RHUB-W790.aml

  • Like 2
Link to comment
Share on other sites
etorix
etorix
Posted
Posted

I browsed through, searched for errors and tried to find patterns. Logs with a leading * feature a "AppleNVMe assert failed" error which I had not noticed before.

 

* Monterey USB Installer - NPCI2000

Loading Monterey Installer from the USB, CaseySJs  patches, NPCI=0x2000, only dropping AMI, ACPI Warning Patch.

* Monterey USB Installer - NPCI3000

same with npci=0x3000

Monterey USB 3000 No Patches AMI Drop Warning Patch

Loading Monterey Installer from the USB, not kernel patches, NPCI=0x3000, only dropping AMI, ACPI Warning Patch.

* Monterey USB 3000 No Patches AMI Drop

Loading Monterey Installer from the USB, not kernel patches, NPCI=0x3000, only dropping AMI, no other patch is active.

Monterey USB 3000 No Patches

Loading Monterey Installer from the USB, not kernel patches, NPCI=0x3000, no table dropping, no other patch is active.

 

Ventura USB Installer - NPCI2000

same as Monterey installer above: CaseySJ patches, npci=0x2000, dropping AMI, ACPI warning patch

* Ventura USB Installer - NPCI3000

same with npci=0x3000

* Ventura USB 3000 No Patches

Loading Ventura Installer from the USB, not kernel patches, NPCI=0x3000, no table dropping, no other patch is active.

Ventura USB 3000 HPET

Loading Monterey Installer from the USB, not kernel patches, NPCI=0x3000, only dropping AMI, ACPI Warning Patch and HPET stuff.

 

npci=0x2000 or 0x3000 do not appear to make a difference. The HPET patches+SSDT would best be tested alone, without npci boot-arg since they serve a similar purpose of avoiding conflicts in the PCI bus, but I'm not very optimistic at this stage.

The NVMe assert error has no discernible pattern. In particular, it is not affected by @Casey_S.J.'s patches. I then browsed through my little archive of W790 logs and found the same error in most, but not all, logs from May 18 (USB Installer.txt, both EnableWriteUnprotector, SATA Monterey and NVME Booter—but it is not present in DMAR and DMAR Dropped), in the log from April 30, and even in a log of May 20 from @EVILGENIUS. As a seemingly random error, it cannot be the root cause of the failure to boot macOS.

 

Dropping AMI removes the corresponding ACPI error, for no actual benefit.

The ACPI warning patch works as intended and does not appear to have adverse effects—it was expected to be cosmetic only. This is a little personal satisfaction, but I would suggest to disable it for now to streamline the configuration. I'm getting vaguely concerned that the offending line of code ("SIPV = GSIP ()") actually serves a purpose and that we should get to work, but I don't understand the failure. 0x70 is the assignment operator. SIPV is an object which is initialised as a byte object (opcodes 0A 00). Method GIPV returns 0x0E or 0x11 as byte objects. There should be no type cast error in the assignment…)

 

Spoiler

AML opcodes and DSL code. Where's the error? 

53495056 0A   00
S I V P  Byte
1417      47534950 00 A0 0B   93 50434853 0A   05 A4     0A   0E  A1   04 A4     0A   11
MethodOp  G S I P     If Word == P C H S  Byte    Return Byte     Else    Return Byte

        Name (SIPV, 0x00)
        Method (GSIP, 0, NotSerialized)
        {
            If ((PCHS == 0x05))
            {
                Return (0x0E)
            }
            Else
            {
                Return (0x11)
            }
        }
        
70      47534950 53495056
StoreOp G S I P  S I P V

         SIPV = GSIP ()


 

I guess the next step is 'pci=0x3' to enable IOPCIFamily debug, as suggested by @Casey_S.J..

(From IOPCIConfigurator.h, this flag is the sum of

    kIOPCIConfiguratorIOLog          = 0x00000001, and
    kIOPCIConfiguratorKPrintf        = 0x00000002.

Which is not much in the way of documentation… And if we throw in

    kIOPCIConfiguratorVTLog          = 0x00000004,

do we get AppleVTD debugging as well?)

  • Like 1
Link to comment
Share on other sites
Balamut
Balamut
Posted
  • Author
Posted
7 hours ago, etorix said:

SSDT-RHUB-W790 will generate a whole new wall of ACPI errors—and I will understand even less why the native SSDT does not load properly.

Thank you, will test it in a bit.

 

 

2 hours ago, etorix said:

feature a "AppleNVMe assert failed" error which I had not noticed before.

Yup they've been there even in some earlier logs.

 

 

2 hours ago, etorix said:

Dropping AMI removes the corresponding ACPI error, for no actual benefit.

The ACPI warning patch works as intended and does not appear to have adverse effects—it was expected to be cosmetic only. This is a little personal satisfaction, but I would suggest to disable it for now to streamline the configuration. I'm getting vaguely concerned that the offending line of code ("SIPV = GSIP ()") actually serves a purpose and that we should get to work, but I don't understand the failure. 0x70 is the assignment operator. SIPV is an object which is initialised as a byte object (opcodes 0A 00). Method GIPV returns 0x0E or 0x11 as byte objects. There should be no type cast error in the assignment…)

Head scratcher isn't it.

 

 

2 hours ago, etorix said:

I guess the next step is 'pci=0x3' to enable IOPCIFamily debug, as suggested by @Casey_S.J..

(From IOPCIConfigurator.h, this flag is the sum of

    kIOPCIConfiguratorIOLog          = 0x00000001, and
    kIOPCIConfiguratorKPrintf        = 0x00000002.

Which is not much in the way of documentation… And if we throw in

    kIOPCIConfiguratorVTLog          = 0x00000004,

do we get AppleVTD debugging as well?)

 

pci=0x03 is already in every log. So basically its a combination of kIOPCIConfiguratorIOLog and kIOPCIConfiguratorKPrintf?

 

 

 

  • Like 1
Link to comment
Share on other sites
Balamut
Balamut
Posted
  • Author
Posted

Ok another update, with the SSDT-RHUB-W790 injection doesn't see to be anything different.

 

I was browsing trough the logs and found couple of interesting things, might be nothing but still.

 

Are there because there cores doesn't exist?

Spoiler

AppleACPICPU::start(CP7C) <1> failed
AppleAPICInterruptController::attach(io-apic)
AppleACPICPU::start(CP7D) <1> failed
AppleACPICPU::attach(CP7F)
config(0x5378ab4e73b6e3bf): terminating
AppleACPICPU::detach(CP7F)
AppleAPICInterruptController::probe(io-apic)
AppleACPICPU::start(CP7E) <1> failed
config(0x5378ab4e73b81e27): terminating
AppleACPICPU::start(CP7B) <1> failed
config(0x5378ab4e73772957): terminating
config(0x5378ab4e7376d957): terminating
AppleACPICPU::start(CP7F) <1> failed

 

NVMEController fails to start. 

IONVMeController::detach(PXSX)
IOPCI2PCIBridge::start(BRB8) <1>
config(0x5378ab4e73e503bf): starting on IOPP, 10
IONVMeController::start(PXSX) <1> failed
config(0x5378ab4e73e503bf): terminating

 

And finally the Big Sur log finally gave the panic.

 

Spoiler

DSA0: family specific matching fails
Debugger: Unexpected kernel trap number: 0xe, RIP: 0xffffff8011701057, CR2: 0xffffff94f7822000
pci8086,9a7: family specific matching fails
CPU 16 panic trap number 0xe, rip 0xffffff8011701057
cr0 0x000000008001003b cr2 0xffffff94f7822000 cr3 0x000000002dc46000 cr4 0x00000000003626e0
config(0xb96b86453678cf3): terminating
Debugger called: <panic>
IOPlatformPanicAction -> IONVMeController
IOPlatformPanicAction -> AppleAHCIDiskDriver
panic(cpu 16 caller 0xffffff80119bb676): Kernel trap at 0xffffff8011701057, type 14=page fault, registers:
CR0: 0x000000008001003b, CR2: 0xffffff94f7822000, CR3: 0x000000002dc46000, CR4: 0x00000000003626e0
RAX: 0xffffff80128a526c, RBX: 0xffffff80128a524c, RCX: 0x0000000000000094, RDX: 0x00000000000003c4
RSP: 0xffffffa3e99bb998, RBP: 0xffffffa3e99bba20, RSI: 0xffffff94f7822000, RDI: 0xffffff80128a559c
R8:  0x0000000000000002, R9:  0x0000000000000002, R10: 0x000000000000003f, R11: 0x0000000000000004
R12: 0xffffff80128a5234, R13: 0x0000000000000001, R14: 0x0000000000000003, R15: 0xffffffa3e99bba38
RFL: 0x0000000000010202, RIP: 0xffffff8011701057, CS:  0x0000000000000008, SS:  0x0000000000000000
Fault CR2: 0xffffff94f7822000, Error code: 0x0000000000000000, Fault CPU: 0x10, PL: 0, VF: 1

Backtrace (CPU 16), Frame : Return Address
0xffffffa3e99bb3b0 : 0xffffff80118822bd mach_kernel : _handle_debugger_trap + 0x3fd
0xffffffa3e99bb400 : 0xffffff80119cacb3 mach_kernel : _kdp_i386_trap + 0x143
0xffffffa3e99bb440 : 0xffffff80119bb2aa mach_kernel : _kernel_trap + 0x55a
0xffffffa3e99bb490 : 0xffffff8011826a2f mach_kernel : _return_from_trap + 0xff
0xffffffa3e99bb4b0 : 0xffffff8011881add mach_kernel : _DebuggerTrapWithState + 0xad
0xffffffa3e99bb5d0 : 0xffffff8011881dd3 mach_kernel : _panic_trap_to_debugger + 0x273
0xffffffa3e99bb640 : 0xffffff8012095f7a mach_kernel : _panic + 0x54
0xffffffa3e99bb6b0 : 0xffffff80119bb676 mach_kernel : _sync_iss_to_iks + 0x2c6
0xffffffa3e99bb830 : 0xffffff80119bb35d mach_kernel : _kernel_trap + 0x60d
0xffffffa3e99bb880 : 0xffffff8011826a2f mach_kernel : _return_from_trap + 0xff
0xffffffa3e99bb8a0 : 0xffffff8011701057 
0xffffffa3e99bba20 : 0xffffff8011f8009f mach_kernel : __os_log_internal + 0x5ff
0xffffffa3e99bbcd0 : 0xffffff8011f8066d mach_kernel : _os_log_with_args + 0x1d
0xffffffa3e99bbcf0 : 0xffffff801206d9c7 mach_kernel : _kprintf + 0x227
0xffffffa3e99bbd90 : 0xffffff80120038c8 mach_kernel : __ZN16IOPlatformExpert5PMLogEPKcmmm + 0x158
0xffffffa3e99bbdd0 : 0xffffff8011fd3264 mach_kernel : __ZN9IOService25handleRegisterPowerDriverEP11IOPMRequest + 0xb4
0xffffffa3e99bbe10 : 0xffffff8011fcb08c mach_kernel : __ZN9IOService23actionPMWorkQueueInvokeEP11IOPMRequestP13IOPMWorkQueue + 0x18c
0xffffffa3e99bbe60 : 0xffffff8011fc8910 mach_kernel : __ZN13IOPMWorkQueue17checkRequestQueueEP11queue_entryPb + 0x90
0xffffffa3e99bbeb0 : 0xffffff8011fd5d38 mach_kernel : __ZN13IOPMWorkQueue14queuePMRequestEP11IOPMRequestP11IOServicePM + 0x118
0xffffffa3e99bbee0 : 0xffffff8011fc8322 mach_kernel : __ZN16IOPMRequestQueue12checkForWorkEv + 0x92
0xffffffa3e99bbf30 : 0xffffff8011fe613e mach_kernel : __ZN10IOWorkLoop15runEventSourcesEv + 0x11e
0xffffffa3e99bbf70 : 0xffffff8011fe5726 mach_kernel : __ZN10IOWorkLoop10threadMainEv + 0x36
0xffffffa3e99bbfa0 : 0xffffff801182613e mach_kernel : _call_continuation + 0x2e

Process name corresponding to current thread: kernel_task
Boot args: -v -dbgenhdbg pci=0x3 serial=5 keepsyms=1 debug=0x12a acpi_layer=0x8 acpi_level=0x2 msgbuf=1048576 io=0xff root-dmg=file:///BaseSystem/BaseSystem.dmg

Mac OS version:
Not yet set

Kernel version:
Darwin Kernel Version 20.6.0: Mon Apr 24 23:00:57 PDT 2023; root:xnu-7195.141.49.701.3~1/RELEASE_X86_64
Kernel UUID: DFEEBE97-2F7E-3B03-8EF4-3494BD417758
KernelCache slide: 0x0000000011600000
KernelCache base:  0xffffff8011800000
Kernel slide:      0x0000000011610000
Kernel text base:  0xffffff8011810000
__HIB  text base: 0xffffff8011700000
System model name: MacPro7,1 (Mac-27AD2F918AE68F61)
System shutdown begun: NO
Panic diags file unavailable, panic occurred prior to initialization
Hibernation exit count: 0

System uptime in nanoseconds: 49703071115
Last Sleep:           absolute           base_tsc          base_nano
  Uptime  : 0x0000000b9320e419
  Sleep   : 0x0000000000000000 0x0000000000000000 0x0000000000000000
  Wake    : 0x0000000000000000 0x00000063c0e3ccd5 0x0000000000000000
Attempting to commit panic log to NVRAM
EFI: couldn't save panic info (err = 8000001a)

** In Memory Panic Stackshot Succeeded ** Bytes Traced 15474 (Uncompressed 51984) **
Attempting to commit panic log to NVRAM
IOPlatformPanicAction -> IONVMeController
IOPlatformPanicAction -> AppleAHCIDiskDriver

Please go to https://panic.apple.com to report this panic

 

Attaching the logs.

Big Sur USB.txt

 

Ventura USB - RHUB Injection with HPET.txt

 

 

Can ACPI table be somehow off? OS Parsing it wrong? Is it worth specifying device properties for NVME and USB controller with OpenCore? Well, Big Sur, Monterey and Ventura does exactly the same thing.

 

 

  • Like 1
Link to comment
Share on other sites
etorix
etorix
Posted
Posted
7 hours ago, Balamut said:

Ok another update, with the SSDT-RHUB-W790 injection doesn't see to be anything different.

Thanks. Upon a second look, intermixed with another message, there seems to be an ACPI error because HS01 already exists. 

ACPI Error: ACPfiEr0xf: fff882b15d3f0): terminating

[HS01]coS0ig(0xffffff882b154b48): starting on AppleAPICInterruptController, 10

 Namespace lookup failure, AE_ALREADY_EXISTS Nnfisp0xf lfffup2bailb4e,  t_AminADinEXISTS (20160930/dswload2-411)

I don't understand what's going on with the XHCI device. :wallbash:

 

Looking one thing at a time, I had not noticed that pci=0x3 was already there. Many potential traces to follow. The last Big Sur log points very clearly to a general issue within IOPlatform, affecting all controllers.

 

Clover is no different, except for one thing: 

ACPI Error: [CPU0] Namespace lookup failure, AE_NOT_FOUND (20160930/dswload-292)

ACPI Exception: AE_NOT_FOUND, During name lookup(SSDT:  CpuCst) while loading table (20160930/tbxfload-319)

What this SSDT "CpuCst" (with small caps, native OEM-4 is "CPU  CST") and its CPU0?

  • Like 3
Link to comment
Share on other sites
Balamut
Balamut
Posted
  • Author
Posted
13 hours ago, etorix said:

I don't understand what's going on with the XHCI device

Welcome to the club.

 

13 hours ago, etorix said:

The last Big Sur log points very clearly to a general issue within IOPlatform, affecting all controllers

That's was my very first reaction when I saw all those mismatches. Somehow between BIOS->OC->XNU ether ACPI gets corrupter, OS forgot how to parse it or there is there is something different in ACPI and OS can't read it correctly.

 

 

13 hours ago, etorix said:

What this SSDT "CpuCst" (with small caps, native OEM-4 is "CPU  CST") and its CPU0?

CPU CST is OEM-4 but there is no CPU0, look in the preboot.log nothing else is being loaded.

 

 

Link to comment
Share on other sites
etorix
etorix
Posted
Posted
6 hours ago, Balamut said:

Welcome to the club.

I'm afraid I already broke in quite some time ago…

 

6 hours ago, Balamut said:

CPU CST is OEM-4 but there is no CPU0, look in the preboot.log nothing else is being loaded.

OEM-4 is "CPU  CST", in all caps and with two spaces. "CpuCst" has to be something else, and this offending "CPU0" has to come from somewhere. Are you using the "Generate CStates" option, by any chance?

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