Jump to content

OpenCore General Discussion

dgsga

By dgsga,
in OpenCore

 Share
8,888 posts in this topic

Recommended Posts

SavageAUS
SavageAUS
Posted
Posted
From version 0.5.0 onward, the versioning is measured by time (in months), not in terms of features. So more than 2 years have passed since that.
 
I think it's kind of funny that the earliest builds had  IgnoreForWindows quirks which prohibited injecting ACPI tables into Windows.  They must have though "well that's way too easy – let's make them having to rewrite all their ACPI tables instead."

IgnoreForWindows was one of the best quirks.


Sent from my iPhone using Tapatalk
  • Like 2
Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted

I need some USBX advice after thinking I knew what I was doing...  Specifically - should the PowerSupply / CurrentLimit values in Device USBX be chosen based on the SMBIOS MacModel, should they somehow be derived from the actual USB current limits for the hack, or should they be universal constants?  Details below...

 

I have been creating my own SSDT-USBX patches based on my chosen SMBIOS MacModel for my hack.  For example, for my HackMini8,1, I used Device USBX from a real MacMini8,1.  For my HackBookPro15,2, I used Device USBX from a real MacBookPro15,2.

 

The Dortania guide provides pre-built SSDT-USBX patches (one for laptop and one for desktop) which implies that the same patch is universal for many hacks, despite being different SMBIOS models.

 

Many of the posted EFIs that I've reviewed use the Dortania-provided pre-built USBX.

 

What is the best way to generate the proper USBX PowerSupply / CurrentLimit values for each unique hack?

Link to comment
Share on other sites
Guest 5T33Z0
Guest 5T33Z0
Posted
Posted (edited)

@deeveedee This info used to be stored in the info.plist of "IOUSBHostFamily.kext" but I couldn't find it in there.  But a look in the DSDT of a MBP 15,1 revealed:

 

 "kUSBSleepPortCurrentLimit",
  0x0BB8,
  "kUSBWakePortCurrentLimit",
  0x0BB8

 

If it's working as is, wouldn't touch it.

 

Edited by 5T33Z0
Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted (edited)
6 minutes ago, 5T33Z0 said:

If it's working as is, wouldn't touch it.

 

That's my rule, too.  However, in this case, I and others have experienced current limit warnings when plugging newer iPhones / iPads into the USB3 ports of this HackMini8,1.  I'm wondering if the USB ports manage their own behavior (resulting in this warning) or if this warning is somehow due to the values in USBX.

Edited by deeveedee
Link to comment
Share on other sites
1Revenger1
1Revenger1
Posted
Posted (edited)

I had to set the values from @5T33Z0 on my X1 Extreme when plugging in an iPad over USB C. The default values in the Dortania SSDT gave me power error messages.
I think there are separate values for USB-C only devices, though I haven't really looked at enough model's values to really proof that though.

Edited by 1Revenger1
  • Like 1
Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted (edited)
8 minutes ago, 1Revenger1 said:

The default values in the Dortania SSDT gave me power error messages.

 

Very helpful - this confirms that the USBX values do pertain to this USB current warning.  As I mentioned, I am currently using the "real" USBX devices in my hacks (e.g., I am currently using the real MacBookPro15,2 USBX in my HackBookPro15,2.

Edited by deeveedee
Link to comment
Share on other sites
Guest 5T33Z0
Guest 5T33Z0
Posted
Posted

I could add a tabel with the used current values in USBX used of each SMBIOS to my OC-Little Repo. I just have to look through all the dsdt tables. WIll take some time, though.

Link to comment
Share on other sites
makk
makk
Posted
Posted

After enabling this, in the boot log of Opencore, I noticed

 

00:000 00:000 OC: Enable VMX - Write Protected

 

Interested in the definition of this being enabled is there a need for this to be enabled and if so, how to know if it is working?

Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted

@5T33Z0  You could do that, and that may help others.  As I mentioned here, I am already using the USBX values from the real Mac that corresponds to my chosen SMBIOS MacModel (an SMBIOS chosen to best match my Intel chipset/CPU/iGPU).  Your table will agree with the approach that I've already taken.  I'm wondering if that's the best I can do, or should I be experimenting with other USBX values that are somehow based on the actual current limits of my hardware. 

 

Before this gets dismissed as off-topic, this is relevant as long as we're talking about augmenting the Dortania guidelines (which is what @5T33Z0 has proposed).  I suspect that my experimentation will need be more tailored to the actual USB current limits of my rig, but I currently have no idea how those actual limits map to USBX.

Link to comment
Share on other sites
Guest 5T33Z0
Guest 5T33Z0
Posted
Posted (edited)

Why was this sub-forum renamed? Weird.

 

@Allan Can you change the title of this sub-forum back to "Open Core General Discussion"? Because that's what it's about. Thx

Edited by 5T33Z0
Link to comment
Share on other sites
jsl2000
jsl2000
Posted
Posted
3 hours ago, Stefanalmare said:

Hi guys! I'm struggling to boot Asus P5Q ICH10 on Monterey latest Beta. I'm stuck at PCI configuration. I bet is AHCI problem but I can't find the right patch. Any hint?

Try add these Kernel Patch:

Screen Shot 2022-02-11 at 8.51.42 AM.png

  • Like 1
Link to comment
Share on other sites
ghost8282
ghost8282
Posted
Posted (edited)

Updated from 12.2 to 12.2.1 in a qemu virtual machine with a 6900 xt passed through, during the last reboot I had a kernel panic: 

panic(cpu 2 caller 0xffffff8001bd5bf3): Kernel trap at 0xffffff7f910e1bf4, type 14=page fault, registers:
CR0: 0x000000008001003b, CR2: 0x0000000000000028, CR3: 0x0000000006a3b000, CR4: 0x00000000000626e0
RAX: 0x0000000000000000, RBX: 0xffffffd05c315008, RCX: 0xffffff7f9109f393, RDX: 0x0000000000000000
RSP: 0xffffffe0b29fb750, RBP: 0xffffffe0b29fb750, RSI: 0xffffff9038a93ef0, RDI: 0xffffff9038a93ef0
R8:  0x000000000000ffff, R9:  0x00000000ffffffff, R10: 0x0000000000000002, R11: 0xffffff99d29717c0
R12: 0xffffffe0b29fb901, R13: 0xffffffd05c2ae000, R14: 0x0000000000000000, R15: 0x0000000000000002
RFL: 0x0000000000010286, RIP: 0xffffff7f910e1bf4, CS:  0x0000000000000008, SS:  0x0000000000000010
Fault CR2: 0x0000000000000028, Error code: 0x0000000000000000, Fault CPU: 0x2 VMM, PL: 0, VF: 1

Panicked task 0xffffff8b6c088670: 205 threads: pid 0: kernel_task
Backtrace (CPU 2), panicked thread: 0xffffff8b6b133540, Frame : Return Address
0xffffffe0b29fb080 : 0xffffff8001a85ffd mach_kernel : _handle_debugger_trap + 0x41d
0xffffffe0b29fb0d0 : 0xffffff8001be6035 mach_kernel : _kdp_i386_trap + 0x145
0xffffffe0b29fb110 : 0xffffff8001bd5803 mach_kernel : _kernel_trap + 0x533
0xffffffe0b29fb160 : 0xffffff8005a415ca as.vit9696.VirtualSMC : __ZN18VirtualSMCProvider10kernelTrapI22x86_saved_state_1010_tEEvPT_Pm + 0x47a
0xffffffe0b29fb1e0 : 0xffffff8001a25a60 mach_kernel : _return_from_trap + 0xe0
0xffffffe0b29fb200 : 0xffffff8001a863cd mach_kernel : _DebuggerTrapWithState + 0xad
0xffffffe0b29fb320 : 0xffffff8001a85b86 mach_kernel : _panic_trap_to_debugger + 0x2b6
0xffffffe0b29fb380 : 0xffffff8002316409 mach_kernel : _panic + 0x54
0xffffffe0b29fb3f0 : 0xffffff8001bd5bf3 mach_kernel : _sync_iss_to_iks + 0x2c3
0xffffffe0b29fb570 : 0xffffff8001bd58d8 mach_kernel : _kernel_trap + 0x608
0xffffffe0b29fb5c0 : 0xffffff8005a415ca as.vit9696.VirtualSMC : __ZN18VirtualSMCProvider10kernelTrapI22x86_saved_state_1010_tEEvPT_Pm + 0x47a
0xffffffe0b29fb640 : 0xffffff8001a25a60 mach_kernel : _return_from_trap + 0xe0
0xffffffe0b29fb660 : 0xffffff7f910e1bf4 com.apple.kext.AMDRadeonX6000HWLibs : __ZN34AMDRadeonX6000_AMDRadeonHWLibsSWIP20callPlatformFunctionEPKcbPvS2_S2_S2_ + 0xb09c4
0xffffffe0b29fb750 : 0xffffff7f9109f622 com.apple.kext.AMDRadeonX6000HWLibs : __ZN34AMDRadeonX6000_AMDRadeonHWLibsSWIP20callPlatformFunctionEPKcbPvS2_S2_S2_ + 0x6e3f2
0xffffffe0b29fb760 : 0xffffff7f910a191d com.apple.kext.AMDRadeonX6000HWLibs : __ZN34AMDRadeonX6000_AMDRadeonHWLibsSWIP20callPlatformFunctionEPKcbPvS2_S2_S2_ + 0x706ed
0xffffffe0b29fb780 : 0xffffff7f9109f3b9 com.apple.kext.AMDRadeonX6000HWLibs : __ZN34AMDRadeonX6000_AMDRadeonHWLibsSWIP20callPlatformFunctionEPKcbPvS2_S2_S2_ + 0x6e189
0xffffffe0b29fb7a0 : 0xffffff7f910d793b com.apple.kext.AMDRadeonX6000HWLibs : __ZN34AMDRadeonX6000_AMDRadeonHWLibsSWIP20callPlatformFunctionEPKcbPvS2_S2_S2_ + 0xa670b
0xffffffe0b29fb7c0 : 0xffffff7f910cc3db com.apple.kext.AMDRadeonX6000HWLibs : __ZN34AMDRadeonX6000_AMDRadeonHWLibsSWIP20callPlatformFunctionEPKcbPvS2_S2_S2_ + 0x9b1ab
0xffffffe0b29fb820 : 0xffffff7f910cc542 com.apple.kext.AMDRadeonX6000HWLibs : __ZN34AMDRadeonX6000_AMDRadeonHWLibsSWIP20callPlatformFunctionEPKcbPvS2_S2_S2_ + 0x9b312
0xffffffe0b29fb850 : 0xffffff7f910c4f8b com.apple.kext.AMDRadeonX6000HWLibs : __ZN34AMDRadeonX6000_AMDRadeonHWLibsSWIP20callPlatformFunctionEPKcbPvS2_S2_S2_ + 0x93d5b
0xffffffe0b29fb880 : 0xffffff7f910c4b5f com.apple.kext.AMDRadeonX6000HWLibs : __ZN34AMDRadeonX6000_AMDRadeonHWLibsSWIP20callPlatformFunctionEPKcbPvS2_S2_S2_ + 0x9392f
0xffffffe0b29fb8f0 : 0xffffff7f910dd86d com.apple.kext.AMDRadeonX6000HWLibs : __ZN34AMDRadeonX6000_AMDRadeonHWLibsSWIP20callPlatformFunctionEPKcbPvS2_S2_S2_ + 0xac63d
0xffffffe0b29fb9e0 : 0xffffff7f910dd3ed com.apple.kext.AMDRadeonX6000HWLibs : __ZN34AMDRadeonX6000_AMDRadeonHWLibsSWIP20callPlatformFunctionEPKcbPvS2_S2_S2_ + 0xac1bd
0xffffffe0b29fba50 : 0xffffff7f90bb2ce6 com.apple.kext.AMDRadeonX6000 : __ZN28AMDRadeonX6000_AMDRTHardware13initializeTtlEP16_GART_PARAMETERS + 0x15a
0xffffffe0b29fbad0 : 0xffffff7f90bc3bbc com.apple.kext.AMDRadeonX6000 : __ZN26AMDRadeonX6000_AMDHardware4initEP11IOPCIDeviceP28AMDRadeonX6000_IAMDHWHandlerRjP16_GART_PARAMETERSP14_FB_PARAMETERS + 0x2b0
0xffffffe0b29fbb20 : 0xffffff7f90bb2b6a com.apple.kext.AMDRadeonX6000 : __ZN28AMDRadeonX6000_AMDRTHardware4initEP11IOPCIDeviceP28AMDRadeonX6000_IAMDHWHandlerRjP16_GART_PARAMETERSP14_FB_PARAMETERS + 0x82
0xffffffe0b29fbb70 : 0xffffff7f90bc8ab1 com.apple.kext.AMDRadeonX6000 : __ZN31AMDRadeonX6000_AMDGFX10Hardware4initEP11IOPCIDeviceP28AMDRadeonX6000_IAMDHWHandlerRjP16_GART_PARAMETERSP14_FB_PARAMETERS + 0x33
0xffffffe0b29fbba0 : 0xffffff7f90b5cbb9 com.apple.kext.AMDRadeonX6000 : __ZN37AMDRadeonX6000_AMDGraphicsAccelerator17createHWInterfaceEP11IOPCIDevice + 0x7b
0xffffffe0b29fbbe0 : 0xffffff7f90b59c76 com.apple.kext.AMDRadeonX6000 : __ZN37AMDRadeonX6000_AMDGraphicsAccelerator15configureDeviceEP11IOPCIDevice + 0x15a
0xffffffe0b29fbcf0 : 0xffffff7f9aa58257 com.apple.iokit.IOAcceleratorFamily2 : __ZN22IOGraphicsAccelerator25startEP9IOService + 0x2cb
0xffffffe0b29fbd70 : 0xffffff7f90b57d3d com.apple.kext.AMDRadeonX6000 : __ZN37AMDRadeonX6000_AMDGraphicsAccelerator5startEP9IOService + 0x11d
0xffffffe0b29fbdd0 : 0xffffff800222ebaa mach_kernel : __ZN9IOService14startCandidateEPS_ + 0x11a
0xffffffe0b29fbe30 : 0xffffff800222e715 mach_kernel : __ZN9IOService15probeCandidatesEP12OSOrderedSet + 0xe75
0xffffffe0b29fbef0 : 0xffffff800222d710 mach_kernel : __ZN9IOService14doServiceMatchEj + 0x3d0
0xffffffe0b29fbf50 : 0xffffff8002230779 mach_kernel : __ZN15_IOConfigThread4mainEPvi + 0x189
0xffffffe0b29fbfa0 : 0xffffff8001a2518e mach_kernel : _call_continuation + 0x2e
      Kernel Extensions in backtrace:
         as.vit9696.VirtualSMC(1.2.9)[9B9FE461-EF03-3B72-A37F-DF74A8C596A8]@0xffffff8005a32000->0xffffff8005a58fff
            dependency: as.vit9696.Lilu(1.6.0)[1048E1B9-6B92-344D-A9B4-4D0B29316743]@0xffffff80059a9000->0xffffff8005a2ffff
            dependency: com.apple.iokit.IOACPIFamily(1.4)[9AAF8737-B8CD-3A43-A654-69FD563A54CA]@0xffffff8004140000->0xffffff8004141fff
         com.apple.iokit.IOAcceleratorFamily2(462.4.1)[AE87E33B-5F2B-3614-88E0-66D4DA407F8F]@0xffffff7f9aa1d000->0xffffff7f9aa86fff
            dependency: com.apple.driver.AppleMobileFileIntegrity(1.0.5)[B0319B71-F6E6-39E1-AD7C-33CE7A82BDEC]@0xffffff800316c000->0xffffff800318dfff
            dependency: com.apple.iokit.IOGraphicsFamily(593)[212D9F00-4979-3ACB-9108-4BB19404BE85]@0xffffff7f9abaa000->0xffffff7f9abd8fff
            dependency: com.apple.iokit.IOPCIFamily(2.9)[897B72E0-B98F-30BA-8CB2-4E5E469CE4B6]@0xffffff80045e7000->0xffffff8004611fff
            dependency: com.apple.iokit.IOReportFamily(47)[FCE9B54C-4E85-371D-BB93-1B9AA324711A]@0xffffff8004623000->0xffffff8004625fff
            dependency: com.apple.iokit.IOSurface(302.11.1)[F1EAA19A-AF75-3AED-964C-A91C64B22744]@0xffffff8004756000->0xffffff8004772fff
         com.apple.kext.AMDRadeonX6000(4.0.7)[25BC7BD2-3299-3613-9C99-E9E3F1B5C218]@0xffffff7f90b57000->0xffffff7f90cd2fff
            dependency: com.apple.iokit.IOAcceleratorFamily2(462.4.1)[AE87E33B-5F2B-3614-88E0-66D4DA407F8F]@0xffffff7f9aa1d000->0xffffff7f9aa86fff
            dependency: com.apple.iokit.IOGraphicsFamily(593)[212D9F00-4979-3ACB-9108-4BB19404BE85]@0xffffff7f9abaa000->0xffffff7f9abd8fff
            dependency: com.apple.iokit.IOPCIFamily(2.9)[897B72E0-B98F-30BA-8CB2-4E5E469CE4B6]@0xffffff80045e7000->0xffffff8004611fff
            dependency: com.apple.iokit.IOSurface(302.11.1)[F1EAA19A-AF75-3AED-964C-A91C64B22744]@0xffffff8004756000->0xffffff8004772fff
         com.apple.kext.AMDRadeonX6000HWLibs(1.0)[30FAE287-5514-3D55-B92E-B89388FE98D5]@0xffffff7f9102f000->0xffffff7f9148dfff
            dependency: com.apple.iokit.IOPCIFamily(2.9)[897B72E0-B98F-30BA-8CB2-4E5E469CE4B6]@0xffffff80045e7000->0xffffff8004611fff

Process name corresponding to current thread (0xffffff8b6b133540): kernel_task
Boot args: -v agdpmod=pikera vti=12 keepsyms=1 chunklist-security-epoch=0 -chunklist-no-rev2-dev chunklist-security-epoch=0 -chunklist-no-rev2-dev

Mac OS version:
21D62

Kernel version:
Darwin Kernel Version 21.3.0: Wed Jan  5 21:37:58 PST 2022; root:xnu-8019.80.24~20/RELEASE_X86_64
Kernel UUID: 93729D02-FE6F-355B-BA76-BA930AA7103F
KernelCache slide: 0x0000000001800000
KernelCache base:  0xffffff8001a00000
Kernel slide:      0x0000000001810000
Kernel text base:  0xffffff8001a10000
__HIB  text base: 0xffffff8001900000
System model name: iMacPro1,1 (Mac-7BA5B2D9E42DDD94)
System shutdown begun: NO
Panic diags file available: NO (0xe00002bc)
Hibernation exit count: 0

System uptime in nanoseconds: 42847956628
Last Sleep:           absolute           base_tsc          base_nano
  Uptime  : 0x00000009fbb4c15f
  Sleep   : 0x000000000000

Force stopping the vm and rebooting it didn't solve the issue.

Luckily, rebooting the whole host and booting again the vm solved the issue.

I don't know the cause, but maybe related to my build/gpu driver.

 

UPDATE: probably fixed by this?

https://github.com/acidanthera/OpenCorePkg/commit/ad4414cf3bbc1aaea8d6f0c4e4ac8b64c2b3fb56

 

I will see on next update :D

thanks vit!

Edited by ghost8282
Link to comment
Share on other sites
stooovie
stooovie
Posted
Posted (edited)

Hi, my system is 100% perfect with OC 0.7.6 and Monterey 12.2.

 

After updating to either 0.7.7 or 0.7.8, system immediately fails with EXITBS (hence, no logs are even created).

 

ocvalidate finds no errors. Every update since 0.5.7 went fine until this, shouldn't be an user error.

 

Asked around on OC Discord and r/hackintosh to no avail.

 

i9 10850k on Asus Z490-P, RX 580, Monterey 12.2. No issues at all on 0.7.6. 0.7.7 and 0.7.8 have the same issue.

 

Tried, didnt fix:

-manually updated according to the Changes document, and also OC Auxilliary Tools, same result

-DevirtualizeMMIO "false"

-setting new properties to failsafe values or not

-resetting NVRAM

-booting just with Lilu, VirtualSMC, WEG kexts

-using Snapshot and Clean Snapshot from newly downloaded ProperTree

-making sure UEFI/Drivers is the correct new format (Enabled, Path, Arguments, Comments)

 

Here's the boot screen.

 

100% working 0.7.6 EFI here
Non-working 0.7.8 EFI here

 

Please help, thanks!

 

SOLUTION: ProvideCurrentCpuInfo has to be false. It was not an issue up to 076 and I just  don't understand the documentation in this case. But it's working fine now. 

Edited by stooovie
  • Sad 1
Link to comment
Share on other sites
jsl2000
jsl2000
Posted
Posted
27 minutes ago, stooovie said:

Config is correct, working flawlessly for 2+ years. That's not the issue. Thanks though.

For OC 0.7.8 I need ProvideCurrentCpuInfo = No in my Z490 hackintosh, otherwise it can not boot successfully at Monterey.

  • Like 4
  • Thanks 1
Link to comment
Share on other sites
deeveedee
deeveedee
Posted
Posted (edited)
6 hours ago, stooovie said:

Ah, okay, thank you, sorry for my tone. Yes, ProvideCurrentCpuInfo=false fixed the issue. 

 

Stoovie - be generous with a LIke or Thanks in MaLd0n's posted help for you and in jsl2000's posted help for you - doesn't cost you anything.  1795512886_ScreenShot2022-02-11at12_30_29PM.png.ba3af2bfd1e32d2402a7be4a564e0920.png 

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