OpenCore General Discussion

[deeveedee]

On 9/21/2021 at 2:19 PM, Hervé said:

1. "hex swapped"-> incorrect term which does not mean much, it should be "byte reverse(d) order"

 

Many of us adopted "hex swapped" because of the terminology used in the Dortania guide (see use of "hexswap" here).  Maybe this needs to be corrected in the Dortania guide?

[mhaeuser]

Neither "hex swapped" nor "byte reverse order" are technical terms, please do not replace things with "equally bad" things for no reason. People understand it, so let it live.

[Henties]

For those that are keen and have time to refresh their understanding of "Endianness" I suggest you dive into the link below:

https://en.wikipedia.org/wiki/Endianness

Edited September 28, 2021 by Henties

[deeveedee]

Wanted to share a lesson learned after misinterpreting Dortania documentation here.  Bottom line is that framebuffer-stolenmem and framebuffer-fbmem were unnecessary on my rig and actually caused problems (my fault, not the documentation).  I ended up removing these parms from my config.plist with much better performance/stability.  See details below...

 

My HP Envy x360 15 / HackBookPro15,2 (i5-8250U / UHD620) does not allow any VRAM configuration in BIOS.  This was my first laptop hack since my Dell Latitude E6410.  After seeing similar hacks that defined framebuffer-stolenmem and framebuffer-fbmem in OC's config.plist DeviceProperties and after misinterpreting this Dortania guide, I assumed that I had to define framebuffer-stolenmem and framebuffer-fbmem because I couldn't configure VRAM in my BIOS config.  I chose the values 19MB and 9MB respectively as per the example in the guide.  After upgrading to BS 11.6, I started experiencing com.apple.driver.AppleIntelKBLGraphics kernel panics when streaming video in firefox and when establishing remote desktop via Tunnelblick OpenVPN.  After some experimentation, I increased framebuffer-stolenmem and framebuffer-fbmem to 39MB and 21MB respectively (based on my framebuffer memory utilization specified here) and found that the kernel panics stopped.  This lead me to realize that I did not need to constrain framebuffer-stolenmem and framebuffer-fbmem, so I deleted them from my config.plist.  My rig is now rock solid.  My lesson learned is that I should first test without framebuffer-stolenmem and framebuffer-fbmem before unnecessarily (and wrongly) defining these.  I suspect that if I booted Windows (not installed on my rig) and examined video memory, I would see that my rig has plenty of allocated VRAM for my chosen framebuffer (AAPL,ig-platform-id) and there is no need to constrain framebuffer-stolenmem and framebuffer-fbmem.

Edited September 29, 2021 by tonyx86
Fixed typo

[deeveedee]

Developers - at the risk of receiving your constructive criticism for this comment, I think it would be a good idea to add an example here where adding framebuffer-stolenmem and framebuffer-fbmem is determined to be unnecessary.  After reviewing many sample EFIs posted in InsanelyMac, it appears to me that the addition of framebuffer-stolenmem and framebuffer-fbmem has become somewhat "automatic" if VRAM can't be configured in BIOS.  Further, the automatic entry of these parms uses the 19MB and 9MB values from the Dortania example.  As I mentioned here, adding framebuffer-stolenmem and framebuffer-fbmem created problems for me in 11.6.  Advising people that these parms are unnecessary if there's enough allocated VRAM (and how to determine whether there's enough allocated VRAM even if not configurable in BIOS) might be helpful.  Thank you and thank you for all the great work you have done and continue to do.

[pkdesign]

Question about SIP. I updated my csr-active-config to FF070000 as suggested in the OpenCore guide. I used to have it set to 67000000.

 

But now I find the following when I run csrutil status I get the following:

Apple Internal: enabled
Kext Signing: disabled
Filesystem Protections: disabled
Debugging Restrictions: disabled
DTrace Restrictions: disabled
NVRAM Protections: disabled
BaseSystem Verification: disabled

Shouldn't Apple Internal be disabled? According to OC Guide:

Quote

Enabling CSR_ALLOW_UNAUTHENTICATED_ROOT and CSR_ALLOW_APPLE_INTERNAL are common options that can break OS updates for users

 

With 67000000 I would just get "System Integrity Protection status: disabled"

 

Using CsrDecode; 67000000, FF070000, FF0F0000 all come up with the same values.

 

I'm confused. What is correct or suggested?

[pkdesign]

The issue @Hervé is that you get conflicting information from all over the place. Yes I searched here and elsewhere, and other that your own posts, found different suggestions everywhere. And considering that the official OpenCore guide seems to contradict your advice is not helpful. That is what I was trying to get clarification for.

Edited October 1, 2021 by pkdesign

[MacNB]

Hmmm....interesting

On my Legacy Dell Inspiron 530 running Big Sur 11.6 booted via OC 0.7.3, I have csr-active-config set to 0FFF :

macnb@iMac-530 ~ % nvram -p | grep csr
csr-active-config	%ff%0f%00%00
macnb@iMac-530 ~ % 

and I get :

macnb@iMac-530 ~ % csrutil status
System Integrity Protection status: unknown (Custom Configuration).

Configuration:
	Apple Internal: disabled
	Kext Signing: disabled
	Filesystem Protections: disabled
	Debugging Restrictions: disabled
	DTrace Restrictions: disabled
	NVRAM Protections: disabled
	BaseSystem Verification: disabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

Thus CSR_ALLOW_APPLE_INTERNAL bit is SET in my case but the status command returns disabled. 

 

OTA update worked today as I received a minor supplemental update for Device Support Update for newer iOS & iPad devices syncing with macOS.

 

 

Edited October 2, 2021 by MacNB

[joevt]

8 hours ago, tonyx86 said:

Wanted to share a lesson learned after misinterpreting Dortania documentation here.  Bottom line is that framebuffer-stolenmem and framebuffer-fbmem were unnecessary on my rig and actually caused problems (my fault, not the documentation).  I ended up removing these parms from my config.plist with much better performance/stability.  See details below...

 

My HP Envy x360 15 / HackBookPro15,2 (i5-8250U / UHD620) does not allow any VRAM configuration in BIOS.  This was my first laptop hack since my Dell Latitude E6410.  After seeing similar hacks that defined framebuffer-stolenmem and framebuffer-fbmem in OC's config.plist DeviceProperties and after misinterpreting this Dortania guide, I assumed that I had to define framebuffer-stolenmem and framebuffer-fbmem because I couldn't configure VRAM in my BIOS config.  I chose the values 19MB and 9MB respectively as per the example in the guide.  After upgrading to BS 11.6, I started experiencing com.apple.driver.AppleIntelKBLGraphics kernel panics when streaming video in firefox and when establishing remote desktop via Tunnelblick OpenVPN.  After some experimentation, I increased framebuffer-stolenmem and framebuffer-fbmem to 39MB and 21MB respectively (based on my framebuffer memory utilization specified here) and found that the kernel panics stopped.  This lead me to realize that I did not need to constrain framebuffer-stolenmem and framebuffer-fbmem, so I deleted them from my config.plist.  My rig is now rock solid.  My lesson learned is that I should first test without framebuffer-stolenmem and framebuffer-fbmem before unnecessarily (and wrongly) defining these.  I suspect that if I booted Windows (not installed on my rig) and examined video memory, I would see that my rig has plenty of allocated VRAM for my chosen framebuffer (AAPL,ig-platform-id) and there is no need to constrain framebuffer-stolenmem and framebuffer-fbmem.

 

Documentation is unclear.

 

Quote

Here the main entries we care about:

Entry	Value	Comment
STOLEN	32MB	Memory reserved for the iGPU
FBMEM	19MB	Memory reserved for the framebuffer
TOTAL CURSOR	1 MB	Memory reserved for cursor
TOTAL STOLEN	52 MB	Combination of the above

Now let's say for example your motherboard only allocates 32MB for the iGPU, this will be too little for what the framebuffer expects and so will most likely kernel panic when it tries to write into an area of memory that does not exist.

That's where WhateverGreen's patching capabilities come in, here we're able to set the exact amount of iGPU memory the framebuffer expects with the following properties:

Value	Comment
framebuffer-patch-enable	This enables WhateverGreen's patching capabilities
framebuffer-stolenmem	This sets the value used by STOLEN entry
framebuffer-fbmem	This sets the value used by FBMEM entry

#Creating our patch

So to lower this VRAM requirement, we'll want to set STOLEN to 19MB and FBMEM to 9MB. This will get us underneath the 32MB limit.

 

 

 

It doesn't say where the the "32MB for the iGPU" comes from (maybe it's the STOLEN number but the last line infers something else) or what the framebuffer expects (maybe that's TOTAL STOLEN?).

It doesn't say why the solution is to reduce STOLEN and FBMEM instead of increasing something else (like what the motherboard allocates to the iGPU).

 

[ghost8282]

Hi, sorry if this is a stupid question, probably it is..

From monterey beta 7 we lost native compatibility for nvidia kepler gpus: it's a shame, because my gtx titan black is still capable of running monterey, but hey we know that apple likes to drop "old" hardware, sometimes with no reasons (at least this is what I think).

If one wants to still use its kepler he/she needs to copy old files in /System/Library/Extensions and make a new snapshot disk.

However, as you know, this means disabling secure boot, authenticated-root and disable/enable sip to perform all the steps.

Moreover, I'm worried about os updates, most probably they will show as full installers instead of deltas.

 

To be able to have back a kepler gpu we need: GeForce.kext, GeForceAIRPlugin.bundle, GeForceGLDriver.bundle, GeForceMTLDriver.bundle, GeForceVADriver.bundle, NVDAGF100Hal.kext, NVDAGK100Hal.kext, NVDAResman.kext and NVDAStartup.kext

 

So, kexts and bundles files: is it possible to inject these with opencore? I think bundles cannot be injected?

 

Thank you

[MacNB]

6 hours ago, Hervé said:

@MacNB 

Nope; as shown by your own SIP status check, AppleInternal bit is NOT set and therefore shown as disabled. It's your csr-active-config parameter which is clearly ineffective.

 

I'd say there is something incorrect in your config or with your (emulated?) NVRAM or an unreported bug with OC 0.7.3 because, under normal/full operational conditions, setting csr-active-config to 0xFFF cannot leave AppleInternal set to disabled. It's a plain binary matter and therefore an absolute impossibility if the csr-active-config parameter is properly applied.

 

 

@Hervé

Yes I know SIP status is showing AppleInternal bit as disabled but clearly nvram command is clearly showing that bit is & was set.

Checking the OC log now shows that macOS (or boot.efi) is changing that bit (for whatever reason):

 

...

22:433 00:002 AAPL: [EB|#CSR:IN] 0x00000FFF
22:436 00:002 AAPL: [EB|#CSR:OUT] 0x00000FEF
...

That is the log output from Apple and proves that csr-active-config was properly set to 0x00000FFF but changed to 0x00000FEF.

So, "It's a plain binary matter and therefore an absolute impossibility if the csr-active-config parameter is properly applied" is not true as "something" is flipping that bit.

 

Thanks for checking your various systems.

I downgraded my OC back to 0.7.0 like yours just incase it's an issue in latest OC 0.7.3 Release but that's clearly that's not the case as I get the same result.

 

With emulated NVRAM, there's not reset NVRAM capability in OC from Bootpicker (though the feature function has been requested).

The only thing you can do is to delete the csr-active-config variable in macOS nvram via nvram command and delete the nvram.plist file before you reboot. Which I did but made no difference.

 

Not sure setting csr-active-config via Recovery OS would work for emulated nvram as it has no LogoutHook.command mechanism to save the nvram to the emulated nvram.plist.

 

So why is the AppleInternal bit being changed from 1 to 0 in some cases ?

Plot thickens.

Edited October 2, 2021 by MacNB

[ghost8282]

3 hours ago, Hervé said:

why don't you try & cache them from /E/E?

thank you, it seems it doesn't work.

no prompt to enable any of the kexts/bundles from security.

 

Edited October 2, 2021 by ghost8282

[ghost8282]

yes, thank you, I looked before posting at the script (chris1111) and also made my gtx working, but it creates a new snapshot with all the drawbacks I listed; also oclp does a root patch, I have not looked at the code, but it seems it does the same thing as the script by looking at the oclp warning.

Anyway, thank you for your suggestions.

Edited October 2, 2021 by ghost8282

[MacNB]

1 hour ago, Hervé said:

Ok, so csr-active-config changing value to 0xFEF -for whatever unidentified reason- does explain why AppleInternal is shown as disabled, the bit being actually unset. At least there's a consistency from the binary point of view.

 

As you said, the mystery to resolve is why the parameter value you specify in your config gets changed as shown in the log. But at least, we've confirmed that setting it to 0xFFF does not keep AppleInternal set to disabled. Which is re-assuring.

 

One thing bothers me though when you say:

I must disagree. Emulated NVRAM does work as expected on my Dell Vostro 200 which, as you know, is 99% identical to the Inspiron 530 (100% if you have the G33M02 motherboard rather than the G33M03 one). I use an older OC version on that old C2D desktop computer (v0.6.8 or v0.6.9, I can't remember) but it does offer the "Reset NVRAM" option in the Picker and the feature is fully functional as far as I'm concerned.

 

If you cannot Reset NVRAM, then it's as I suspected: you most probably have an emulated NVRAM-related issue.

 

Do you have a file called nvram.plist at the root of your EFI partition (next to boot file and OPenCore's EFI folder) ? If you do, do you see it updated (contents & date) after you make changes to NVRAM parameters and reboot? The timestamp should be that off the reboot. You may look at the contents of the file with a plist editor and check the value of csr-active-config stored in there.

 

Might have to raise a bug report on Acidathera's bug tracker as why macOS is not honouring csr-active-config value.

 

Regarding my NVRAM. It is working perfectly across High Sierra, Catalina and Big Sur (all three OS's have LogoutHook.command installed).

So yes of course I have nvram.plist file where it should be on the EFI.

I know a bit about the working of the emulated NVRAM as worked with the Devs to solve a few issues in the early days.

 

I know about the Reset NVRAM tool in the bootlicker; here's mine:

 

(BTW, that screenshot was done with hitting Function F10 with the OC CrScreenshotDxe.efi driver installed so that one does not have to take photos of the bootpicker with a camera 😉)

 

My motherboard is G33M03 running Quad Core Xeon E540 but regarding NVRAM, the motherboards are irrelevant as they both do not have native hardware NVRAM.

 

Have you actually tested it by clicking it and checking that your nvram variables were cleared ?

That is, what do mean "as expected" ? What did you expect it to do ?

BootPicker offers the Reset NVRAM tool but for emulated NVRAM it can't do much since I checked las time. There's an open related issue here.

 

 

 

Edited October 2, 2021 by MacNB

[MacNB]

1 minute ago, Hervé said:

Yes I know about the module that supports screenshot but it's not installed. I switch from Clover/High Sierra to OC/Big Sur on that old PC. If I don't Reset NVRAM when booting OC/Big sur, I have leftover from Clover/High Sierra, that's how I know that Reset NVRAM works.

Ah OK. Clover emulated NVRAM implementation is not the same as OC.

[MacNB]

1 hour ago, Hervé said:

Yes I know about the module that supports taking screenshots but it's not installed.

 

I switch from Clover/High Sierra to OC/Big Sur on that old PC. If I don't Reset NVRAM when switching from former to latter, I have leftover from Clover/High Sierra that can prevent booting OC/Big Sur, that's how I know that Reset NVRAM works as expected.

 

The reference I made to motherboards was to highlight the closeness between our 2 x systems and therefore the expected similar behaviour with regards to emulated NVRAM. Nothing else and no mention was made to hardware/native NVRAM.

 

Maybe you can post your OC config or its NVRAM section.

 

When switching Clover to OC, you have to clear out left over Clover stuff from your system...especially NVRAM scripts. See this guide

Sure. Here is my OC config.plist.

 

MacNB-Dell-530-config.plist

Edited October 2, 2021 by MacNB

[MacNB]

13 minutes ago, Hervé said:

That's right and Clover is better suited to our old Penryn/Wolfdale/Yorkfield/Harpertown systems than OC. 

 

Well that is very debatable.

I am quite impressed with OC on the Legacy PC's.

Makes my Hack more like a Mac (bootpicker function, startup disk, bootcamp, etc).

Mine boots faster.

Properly documented throughout its development and importantly, still being developed even though we're coming to an end of Hacks.

NVRAM issue is a non-issue for me as it works as I expect (mainly for proper startup boot disk selection and controlling the default boot disk). 

 

Like you, I grew up with Clover but having switched, there's no going back - even on Legacy PC's.

I even use OC on my ageing real MacPro5,1 like many real Mac users with unsupported Macs.

Lol real Mac have now become Hackingtosh's thanks to OC 🤣

 

[deeveedee]

17 hours ago, joevt said:

Documentation is unclear.

 

It doesn't say where the the "32MB for the iGPU" comes from ...

 

@joevt Thank you for expressing interest in this topic and for continuing the discussion.  I think that the Dortania doc does "say where the 32MB" comes from.  My interpretation of the documentation was that the motherboard allocates this 32MB.  I believe this is an allocation that is easily confirmed when running Windows, but I'm not sure how to view the allocation in macOS.  Further, I believe the Dortania docs imply that the 32MB is an allocation that is not configurable by the end user.

 

17 hours ago, joevt said:

It doesn't say why the solution is to reduce STOLEN and FBMEM instead of increasing something else (like what the motherboard allocates to the iGPU).

 

Maybe this is unclear.  I assumed that the Dortania doc implied that "increasing the motherboard allocation" was not possible, thus the need to constrain STOLEN and FBMEM.

 

Regardless, if the two of us have different interpretations of the Dortania docs and numerous others appear to be using framebuffer-stolenmem=19MB and framebuffer-fbmem=9MB without knowing why, whether it's even necessary and whether 19MB and 9MB are the correct values if it is necessary (as evidenced by their posted EFIs), I agree that the documentation is unclear.

[deeveedee]

@Hervé Great explanation.  Thank you.  I referenced the term VRAM and not DVMT to remain consistent with this guide.  If they are not the same thing, should the guide have stated DVMT instead of VRAM?

 

P.S. I wasn't sure, but I think there's a math error in the calcs you provided here unless I'm not following this example: "In that case, FBmem + Cursormem = 21MB + 9MB = 25MB which remains lower than Stolenmem at 32MB. All is therefore well. " Herve has fixed this math mistake in his post.

Edited October 3, 2021 by tonyx86
Noted that Herve fixed his mistake

[makk]

16 hours ago, MacNB said:

 

@Hervé

Yes I know SIP status is showing AppleInternal bit as disabled but clearly nvram command is clearly showing that bit is & was set.

Checking the OC log now shows that macOS (or boot.efi) is changing that bit (for whatever reason):

 

...

22:433 00:002 AAPL: [EB|#CSR:IN] 0x00000FFF
22:436 00:002 AAPL: [EB|#CSR:OUT] 0x00000FEF
...

That is the log output from Apple and proves that csr-active-config was properly set to 0x00000FFF but changed to 0x00000FEF.

So, "It's a plain binary matter and therefore an absolute impossibility if the csr-active-config parameter is properly applied" is not true as "something" is flipping that bit.

 

Thanks for checking your various systems.

I downgraded my OC back to 0.7.0 like yours just incase it's an issue in latest OC 0.7.3 Release but that's clearly that's not the case as I get the same result.

 

With emulated NVRAM, there's not reset NVRAM capability in OC from Bootpicker (though the feature function has been requested).

The only thing you can do is to delete the csr-active-config variable in macOS nvram via nvram command and delete the nvram.plist file before you reboot. Which I did but made no difference.

 

Not sure setting csr-active-config via Recovery OS would work for emulated nvram as it has no LogoutHook.command mechanism to save the nvram to the emulated nvram.plist.

 

So why is the AppleInternal bit being changed from 1 to 0 in some cases ?

Plot thickens.

 

I agreee with you here about SIP and OTA

 

 

Edited October 3, 2021 by makk

[makk]

Question Regarding (IOHIDFamily) Invalid digitizer transducer

Where is this fix located?

 

I had this with another unit and it did not work.

 

Is this a bug in OC or Apple?

 

In debug OC the first line is fix your kext

[Avery B]

1 hour ago, makk said:

Question Regarding (IOHIDFamily) Invalid digitizer transducer

 

Is this a bug in OC or Apple?

This is an Apple bug, I think it might happen with the Magic Trackpad 2 as well? Certainly happens with VoodooInput, though that still works just fine. Doesn't mean much.

1 hour ago, makk said:

In debug OC the first line is fix your kext

Seperate issue, should say what kext is causing the issue (likely some form of VoodooPS2) and what it replaced the dependency with.

[ghost8282]

@vit9696

Latest batch of commits about SB applied on Big Sur 11.6 (latest: OcMacInfoLib: Fix SB model case)

SecureBootModel: Default

SMBIOS: iMacPro1,1

 

produces a kernel panic, like if the seal is broken and the root volume is in r/w

 

kernel panic:

panic(cpu 0 caller 0xffffff8016c28fa2): "Rooting from the live fs of a sealed volume is not allowed on a RELEASE build\n"@/System/Volumes/Data/SWE/macOS/BuildRoots/38cf1d983f/Library/Caches/com.apple.xbs/Sources/apfs/apfs-1677.141.2/kext/apfs_vfsops.c:2047
Backtrace (CPU 0), Frame : Return Address
0xffffffa08f502e40 : 0xffffff8013a8cfdd mach_kernel : _handle_debugger_trap + 0x3fd
0xffffffa08f502e90 : 0xffffff8013bd3fd3 mach_kernel : _kdp_i386_trap + 0x143
0xffffffa08f502ed0 : 0xffffff8013bc45ca mach_kernel : _kernel_trap + 0x55a
0xffffffa08f502f20 : 0xffffff80178dc356 as.vit9696.VirtualSMC : __ZN18VirtualSMCProvider10kernelTrapI22x86_saved_state_1010_tEEvPT_Pm + 0x4b6
0xffffffa08f502fa0 : 0xffffff8013a31a2f mach_kernel : _return_from_trap + 0xff
0xffffffa08f502fc0 : 0xffffff8013a8c7fd mach_kernel : _DebuggerTrapWithState + 0xad
0xffffffa08f5030e0 : 0xffffff8013a8caf3 mach_kernel : _panic_trap_to_debugger + 0x273
0xffffffa08f503150 : 0xffffff801429cdca mach_kernel : _panic + 0x54
0xffffffa08f5031c0 : 0xffffff8016c28fa2 com.apple.filesystems.apfs : _apfs_vfsop_mount + 0x3596
0xffffffa08f5039b0 : 0xffffff8016c32353 com.apple.filesystems.apfs : _apfs_vfsop_mountroot + 0x3d
0xffffffa08f5039e0 : 0xffffff8013d1870c mach_kernel : _vfs_mountroot + 0x13c
0xffffffa08f503b60 : 0xffffff8013fd4633 mach_kernel : _set_rootvnode + 0x2cd3
0xffffffa08f503e80 : 0xffffff8013abb507 mach_kernel : _max_valid_stack_address + 0xd77
0xffffffa08f503fa0 : 0xffffff8013a3113e mach_kernel : _call_continuation + 0x2e
      Kernel Extensions in backtrace:
         as.vit9696.VirtualSMC(1.2.7)[31F93F0F-326D-33B6-874B-D66CEDE41846]@0xffffff80178cc000->0xffffff80178f3fff
            dependency: as.vit9696.Lilu(1.5.6)[CB1A03D7-259F-38B6-80CC-FF4D67CFC043]@0xffffff8017841000->0xffffff80178c8fff
            dependency: com.apple.iokit.IOACPIFamily(1.4)[59A305C2-E322-3EA6-B8DB-475512053CDE]@0xffffff8016044000->0xffffff8016045fff
         com.apple.filesystems.apfs(1677.141.2)[C27BB72B-DD05-3577-AF93-ECB5FBF79B46]@0xffffff8016bac000->0xffffff8016d1bfff
            dependency: com.apple.driver.AppleEFINVRAM(2.1)[4E1980E9-004D-36DF-A5D3-C536B34A9E7A]@0xffffff8014efe000->0xffffff8014f07fff
            dependency: com.apple.driver.AppleEffaceableStorage(1.0)[5B734F34-DF9F-3478-8365-8314846DDD3C]@0xffffff8014f11000->0xffffff8014f16fff
            dependency: com.apple.iokit.CoreAnalyticsFamily(1)[F9C68CEA-A200-3BF1-96B0-17B5D58B5E32]@0xffffff801536d000->0xffffff8015373fff
            dependency: com.apple.iokit.IOStorageFamily(2.1)[7C0E4949-640F-3D1D-97AF-030903A22663]@0xffffff801666f000->0xffffff8016680fff
            dependency: com.apple.kec.corecrypto(11.1)[E38D30E6-600F-30A0-8E38-E3EC38B9D929]@0xffffff8016d49000->0xffffff8016ddafff
            dependency: com.apple.security.AppleImage4(3.0.0)[94010577-1544-331F-97F2-28A99361745E]@0xffffff8014f7d000->0xffffff8014f8dfff

Process name corresponding to current thread: kernel_task
Boot args: vti=12 keepsyms=1 chunklist-security-epoch=0 -chunklist-no-rev2-dev chunklist-security-epoch=0 -chunklist-no-rev2-dev

Mac OS version:
Not yet set

Kernel version:
Darwin Kernel Version 20.6.0: Mon Aug 30 06:12:21 PDT 2021; root:xnu-7195.141.6~3/RELEASE_X86_64
Kernel UUID: C2591F4E-EE82-33CC-8C59-DB81D9AD80DD
KernelCache slide: 0x0000000013800000
KernelCache base:  0xffffff8013a00000
Kernel slide:      0x0000000013810000
Kernel text base:  0xffffff8013a10000
__HIB  text base: 0xffffff8013900000
System model name: iMacPro1,1 (Mac-7BA5B2D9E42DDD94)
System shutdown begun: NO
Panic diags file unavailable, panic occurred prior to initialization
Hibernation exit count: 0

System uptime in nanoseconds: 3242169432
Last Sleep:           absolute           base_tsc          base_nano
  Uptime  : 0x00000000c13f9bd1
  Sleep   : 0x0000000000000000 0x0000000000000000 0x0000000000000000
  Wake    : 0x0000000000000000 0x0000004670c823a7 0x0000000000000000
last started kext at 3171887010: @filesystems.apfs	1677.141.2 (addr 0xffffff8016bac000, size 1507328)
loaded kexts:
com.Ralink.driver.RT2870USBWirelessDriver	5.0.1
as.vit9696.VirtualSMC	1.2.7
as.vit9696.!AALC	1.6.5
as.vit9696.WhateverGreen	1.5.4
as.vit9696.Lilu	1.5.6
@filesystems.apfs	1677.141.2
>!AFileSystemDriver	3.0.1
@filesystems.tmpfs	1
@filesystems.hfs.kext	556.100.11
@BootCache	40
@!AFSCompression.!AFSCompressionTypeZlib	1.0.0
@!AFSCompression.!AFSCompressionTypeDataless	1.0.0d1
@private.KextAudit	1.0
>!AAHCIPort	346.100.2
>!AACPIButtons	6.1
>!ARTC	2.0
>!ASMBIOS	2.1
>!AAPIC	1.7
@!ASystemPolicy	2.0.0
@nke.applicationfirewall	311
|IOKitRegistryCompatibility	1
|EndpointSecurity	1
>!AXsanScheme	3
|IOAHCIBlock!S	332
>usb.IOUSBHostHIDDevice	1.2
>usb.!UHub	1.2
>usb.cdc	5.0.0
>usb.networking	5.0.0
>usb.!UHostCompositeDevice	1.2
>!UMergeNub	900.4.2
>!ABSDKextStarter	3
|IOSurface	290.8.1
|IOSkywalk!F	1
>mDNSOffloadUserClient	1.0.1b8
@filesystems.hfs.encodings.kext	1
>usb.!UXHCIPCI	1.2
>usb.!UXHCI	1.2
>usb.!UEHCIPCI	1.2
>!AEFINVRAM	2.1
>usb.!UUHCIPCI	1.2
>usb.!UUHCI	1.2
>usb.!UEHCI	1.2
>!AVirtIO	74.120.4
|IOSerial!F	11
|IOAHCI!F	294.100.1
>usb.!UHostPacketFilter	1.0
|IOUSB!F	900.4.2
>!AEFIRuntime	2.1
|IOHID!F	2.0.0
$!AImage4	3.0.0
|IOTimeSync!F	985.2
|IONetworking!F	3.4
>DiskImages	493.0.0
|IO!B!F	8.0.5d7
|IOReport!F	47
|IO!BPacketLogger	8.0.5d7
$quarantine	4
$sandbox	300.0
@kext.!AMatch	1.0.0d1
|CoreAnalytics!F	1
>!ASSE	1.0
>!AKeyStore	2
>!UTDM	511.141.1
|IOUSBMass!SDriver	184.140.2
|IOSCSIBlockCommandsDevice	436.140.1
|IO!S!F	2.1
|IOSCSIArchitectureModel!F	436.140.1
>!AMobileFileIntegrity	1.0.5
@kext.CoreTrust	1
>!AFDEKeyStore	28.30
>!AEffaceable!S	1.0
>!ACredentialManager	1.0
>KernelRelayHost	1
|IOUSBHost!F	1.2
>!UHostMergeProperties	1.2
>usb.!UCommon	1.0
>!ABusPower!C	1.0
>!ASEPManager	1.0.1
>IOSlaveProcessor	1
>!AACPIPlatform	6.1
>!ASMC	3.1.9
|IOPCI!F	2.9
|IOACPI!F	1.4
>watchdog	1
@kec.pthread	1
@kec.corecrypto	11.1
@kec.Libm	1

 

No kernel panic with SecureBootModel: x86legacy

 

Is it supposed to be expected? I suppose so, since the documentations recommends to use x86legacy for vms?

Edited October 3, 2021 by ghost8282

[makk]

10 hours ago, 1Revenger1 said:

This is an Apple bug, I think it might happen with the Magic Trackpad 2 as well? Certainly happens with VoodooInput, though that still works just fine. Doesn't mean much.

Seperate issue, should say what kext is causing the issue (likely some form of VoodooPS2) and what it replaced the dependency with.

Thank you 1Revenger1

 

This shows in the kernel log took care of time stamp.

From the Bootloader when in Debug version the first line says fix your kexts, I believe regarding the VoodooPS2Controller which is annoying to look at so I turned off Debug

 

Fallback to IOxxxSystem message,  

 

Debug 0x57d  0x583 kernel: (IOHIDFamily) IOHIDPointingEventDevice:0x100000290 open by IOHIDEventDriver 0x100000365 (0x0)

Error 0x57d  0x583 kernel: (IOHIDFamily) Invalid digitizer transducer

Default 0x57d  0x583 kernel: (IOHIDFamily) HID: Legacy shim 2

 

I recall a few years back when dealing with this issue Vit had link to go to to input into info.plist some new numbers

I can't find that page anymore

 

 

 

[Avery B]

1 minute ago, makk said:

Debug 0x57d  0x583 kernel: (IOHIDFamily) IOHIDPointingEventDevice:0x100000290 open by IOHIDEventDriver 0x100000365 (0x0)

Error 0x57d  0x583 kernel: (IOHIDFamily) Invalid digitizer transducer

Default 0x57d  0x583 kernel: (IOHIDFamily) HID: Legacy shim 2

Right, nothing to worry about. I get it on my systems as well.

1 minute ago, makk said:

I recall a few years back when dealing with this issue Vit had link to go to to input into info.plist some new numbers

I can't find that page anymore

Probably need to change the dependency from IOHIDSystem to IOHIDFamily. Comment about it here: https://github.com/acidanthera/OpenCorePkg/blob/d5693d1b73c21c308e2720771cf5d03c1d01bb3d/Library/OcAppleKernelLib/PrelinkedKext.c#L879-L884