Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
30,171 posts in this topic

Recommended Posts

Andres ZeroCross
Andres ZeroCross
Posted
Posted (edited)

I got kernel panic with CLOVER 5142 in Legacy Mode . but if i use CLOVER 5119 Legacy Mode then there is no kernel panic.

I use latest Lilu, AppleALC.kext, VirtualSMC.kext, RestrictEvent.kext, WhateverGreen.kext.

The KP logs show about Lilu and RestrictEvent.kext, i tried to delete RestrictEvent.kext but then KP Logs will show KP about Lilu and VirtualSMC,kext.

Then i revert to Clover 5119 with same version of Lilu, AppleALC.kext, VirtualSMC.kext, RestrictEvent.kext, WhateverGreen.kext and booting is fine.

Any special trick to inject kext in CLOVER 5142???

image.thumb.png.1e202bfd6e7d48ef77f0c8535b820e97.png 

Edited by Andres ZeroCross
Link to comment
Share on other sites
Slice
Slice
Posted
Posted
18 hours ago, Jief_Machak said:

I'll take a look.

I have to download a version 12 first, which will take some time.

Could you paste me the patch from the config.plist ? 

		<key>KernelToPatch</key>
		<array>
			<dict>
				<key>Comment</key>
				<string>Monterey RDRAND instruction #1</string>
				<key>MatchOS</key>
				<string>12</string>
				<key>Disabled</key>
				<false/>
				<key>Procedure</key>
				<string>_work_interval_port_type_render_server</string>
				<key>RangeFind</key>
				<integer>3900</integer>
				<key>Find</key>
				<data>D8fxc/sh8TnRc/WJyUiLlM3Q/f//</data>
				<key>Replace</key>
				<data>McmQkJAh8TnRc/WJyUiLlM3Q/f//</data>
			</dict>
			<dict>
				<key>Comment</key>
				<string>Monterey RDRAND instruction #2</string>
				<key>MatchOS</key>
				<string>12</string>
				<key>Disabled</key>
				<false/>
				<key>Procedure</key>
				<string>_panic_with_thread_context</string>
				<key>RangeFind</key>
				<integer>10100</integer>
				<key>Find</key>
				<data>D8fyc/uD4g+D+gd38w+3NEE=</data>
				<key>Replace</key>
				<data>MdKQkJCD4g+D+gd38w+3NEE=</data>
			</dict>
		</array>

 

8 hours ago, simmel said:

RDRAND patch is not needed anymore. Apple removed the instruction.

Anyway the bug should be resolved.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted
11 hours ago, Jief_Machak said:

@Slice looking at the code that was moved in AbstractMacOsVersion::match(MacOsVersionPattern), "12" will only match version 12. Not 12.0 or 12.1 etc.

To match any version 12, "12.x" should be used as the pattern.

But kexts folder "12" matched to OS 12.2? Expected same logic.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted
1 hour ago, Slice said:

But kexts folder "12" matched to OS 12.2? Expected same logic.

OK, let it be 12.x

 

@5T33Z0

Look please your instructions about MatchOS.There should be masked strings 12.x, 11.5.x etc.

 

16 minutes ago, SavageAUS said:

Just to test I tried 5143 and still same result. Double speed.


Sent from my iPhone using Tapatalk

Set BusSpeedkHz as 200000 and give me boot-log.

 

bdmesg > boot-log.txt

Link to comment
Share on other sites
Jief_Machak
Jief_Machak
Posted
Posted
11 hours ago, Slice said:

But kexts folder "12" matched to OS 12.2? Expected same logic.

Yes, true.

I think it was already like that before refactoring to MacOSVersion object. Not 100% sure though.

The problem of 12 (or any other single number) matching any 12 version is that there would’ve no way of matching the version 12, but not version 12.1

I remember that Big Sur had a version 11, then a version 11.1. Was it the same for Monterey ? 12, then 12.1 ?

Link to comment
Share on other sites
Jief_Machak
Jief_Machak
Posted
Posted (edited)

A refactor of the logic, to make it simpler, would be to use “version start” - “version stop” logic ?

The “version stop” would NOT match.

11 : matches only 11

11.2-11.3 : matches 11.2 11.2.1 etc.

11.2.1-11.3.4 matches from 11.2.1 until 11.3.3

11.4-12.5 matches 11.4.x to 12.4.x

12- matches 12 and greater

 

we can then apply the same logic for next folders.

Edited by Jief_Machak
  • Like 2
Link to comment
Share on other sites
Jief_Machak
Jief_Machak
Posted
Posted (edited)

Let’s explain why we need “start-stop” to disambiguate.

The problem we have is that, in kext folder naming, no suffix means “match”. 12 matches 12 and 12.1, 12.2, etc. Therefore there is no way of specifying 12 that doesn’t match 12.1

 

For the 12.x notation, 12 matches only 12, but 12.x also matches 12, which is a bit counter-intuitive.

 

Nothing major and because changing something is always a bit of trouble, should we leave it ?…

Edited by Jief_Machak
  • Like 2
Link to comment
Share on other sites
Slice
Slice
Posted
Posted
47 minutes ago, Jief_Machak said:

A refactor of the logic, to make it simpler, would be to use “version start” - “version stop” logic ?

The “version stop” would NOT match.

11 : matches only 11

11.2-11.3 : matches 11.2 11.2.1 etc.

11.2.1-11.3.4 matches from 11.2.1 until 11.3.3

11.4-12.5 matches 11.4.x to 12.4.x

12- matches 12 and greater

 

we can then apply the same logic for next folders.

Great idea! 

To not make new troubles I will propose to keep backward compatibility. Yes, I agree that 12 should correspond only 12 and not 12.1. But we already have kexts folder "12" not "12.x". Keep for folders old logic?

They are de-facto different for folders and for patching.

On the other hand nobody keeps OS version 12. All of us already updated to 12.0.1, 12.1 or 12.2.

  • Like 2
Link to comment
Share on other sites
PG7
PG7
Posted
Posted
On 12/24/2021 at 2:18 PM, Andres ZeroCross said:

I got kernel panic with CLOVER 5142 in Legacy Mode . but if i use CLOVER 5119 Legacy Mode then there is no kernel panic.

I use latest Lilu, AppleALC.kext, VirtualSMC.kext, RestrictEvent.kext, WhateverGreen.kext.

The KP logs show about Lilu and RestrictEvent.kext, i tried to delete RestrictEvent.kext but then KP Logs will show KP about Lilu and VirtualSMC,kext.

Then i revert to Clover 5119 with same version of Lilu, AppleALC.kext, VirtualSMC.kext, RestrictEvent.kext, WhateverGreen.kext and booting is fine.

Any special trick to inject kext in CLOVER 5142???

image.thumb.png.1e202bfd6e7d48ef77f0c8535b820e97.png 

takes the OpenRuntime.efi driver and UEFI file and puts it into Bios

test it, I have this same error here and using this formula it works without problems (I don't have it at all, only on the HP DV6)

On 12/6/2021 at 9:47 PM, PG7 said:

@Jief_Machak @Slice

 

Good afternoon night

 

I have a question:


- it would be possible to put this code of OpenCore Legacy Patcher in Clover config

I use some Hackintosh that I need to patch to activate the graphics NOT metal

to be able to use this patch we must use an ARG "amfi_get_out_of_my_way=1" which blocks Micro and Webcam authorizations on Chrome, Edge and more places

with this last code we can use without problems

I use Google Translate but any doubts I can try to use other translate to facilitate

 

since already thanks 

            <key>4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14</key>
			<dict>
				<key>DefaultBackgroundColor</key>
				<data>AAAAAA==</data>
				<key>OC_BID</key>
				<string>Mac-F60DEB81FF30ACF6</string>
			</dict>


           Code Work

			<key>4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102</key>
			<dict>
				<key>rtc-blacklist</key>
				<data></data>
				<key>OCLP-Settings</key>
				<string>-allow_amfi -allow_fv</string>
				<key>OCLP-Version</key>
				<string>0.3.2</string>
			</dict>

 

I tested it and it's fixed

thanks


 @Slice @Jief_Machak

relaunch

thanks 

Link to comment
Share on other sites
Jief_Machak
Jief_Machak
Posted
Posted
8 hours ago, Slice said:

Great idea! 

To not make new troubles I will propose to keep backward compatibility. Yes, I agree that 12 should correspond only 12 and not 12.1. But we already have kexts folder "12" not "12.x". Keep for folders old logic?

They are de-facto different for folders and for patching.

On the other hand nobody keeps OS version 12. All of us already updated to 12.0.1, 12.1 or 12.2.

If we want to keep backward compatibility, we can't unified the logic (12 means 12.x.x in kext folder and means only 12 in patches).

If we can't unified the logic, maybe we should keep what we already have ?

 

I would be against a special intermediary version that warns users that their kext folder "12" should be renamed "12.x" or "12-13" (for only 12), or "12-" for 12 and more.

After few weeks, we switch to a proper unified logic...

  • Like 2
Link to comment
Share on other sites
SavageAUS
SavageAUS
Posted
Posted
427053649_Screenshot2021-12-26at19_19_52.png.41543c1cf8b0801185fcebeefbce8710.png
Value 51397  makes  every everything even  faster
sysctl -a | grep freq                       
hw.busfrequency: 48000000
hw.busfrequency_max: 48000000
hw.busfrequency_min: 48000000
hw.cpufrequency: 1850000000
hw.cpufrequency_max: 1850000000
hw.cpufrequency_min: 1850000000
hw.tbfrequency: 1000000000
machdep.tsc.frequency: 873749000
 
boot-log.txt

It seems like the lower the value the faster the animations and the higher value slows everything down.
Link to comment
Share on other sites
Guest 5T33Z0
Guest 5T33Z0
Posted
Posted
On 12/26/2021 at 8:30 AM, Slice said:

@5T33Z0

Look please your instructions about MatchOS.There should be masked strings 12.x, 11.5.x etc.


Ok, I've changed the description of "MatchOS":

 

https://github.com/5T33Z0/Clover-Crate/blob/main/Kernel_And_Kext_Patches/README.md#about-patching-masks

 

I will add a chapter about the way Clover handles kexts in the kext folder once this is decided for macOS 12.

Link to comment
Share on other sites
Slice
Slice
Posted
Posted
On 12/27/2021 at 7:03 AM, SavageAUS said:

Value 51397  makes  every everything even  faster
sysctl -a | grep freq                       
hw.busfrequency: 48000000
hw.busfrequency_max: 48000000
hw.busfrequency_min: 48000000
hw.cpufrequency: 1850000000
hw.cpufrequency_max: 1850000000
hw.cpufrequency_min: 1850000000
hw.tbfrequency: 1000000000
machdep.tsc.frequency: 873749000
 
boot-log.txt

It seems like the lower the value the faster the animations and the higher value slows everything down.

No, the value must exactly correspond hardware.

I think you need additional kernel patches for AMD Ryzen.

 

Link to comment
Share on other sites
SavageAUS
SavageAUS
Posted
Posted
No, the value must exactly correspond hardware.
I think you need additional kernel patches for AMD Ryzen.
 

Clover was working perfectly prior to this issue which may have coincided with the upgrade of parts so I think it’s an underlying issue somewhere rather than the patches.


Sent from my iPhone using Tapatalk
Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...