Jump to content

Clover Problems and Solutions


ErmaC
3,206 posts in this topic

Recommended Posts

  • 1 month later...

We should take into account NVME device type

((DevicePathType (DevicePath) == MESSAGING_DEVICE_PATH) &&
          ((DevicePathSubType (DevicePath) == MSG_NVME_NAMESPACE_DP)

defined in new EDK and in new UEFI BIOSes.

#define MSG_NVME_NAMESPACE_DP     0x17

  • Like 4
Link to comment
Share on other sites

This MSR is supported by Conroe and Penryn. Don't know about Dothan if it is still suitable for Hackintosh.

It will be better to implement safe_readMSR as Apple do but it requires to catch interrupts from unknown instructions.

OK, I'll set the condition to not use this MSR on Pentium-M.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

  • 4 weeks later...

Some changes I made in my Clover fork on github...

 

First is to support VirtualSMC.kext same as FakeSMC.kext with respect to InjectKexts=Detect.

Simple change to CheckForFakeSMC: https://github.com/RehabMan/Clover/commit/a12126299ba622290c7573e6200fadf3570dca24

 

Another is a critical fix for AcpiPatcher.c (broken somewhere between r4444 and r4658).

The bug: merged SSDTs (AutoMerge=true) are not being patched with patches in ACPI/DSDT/Patches.

These are the rules:

- any table that was merged (eg. replaced its original in the XSDT) via AutoMerge=true and correct naming shall be subject to ACPI/DSDT/Patches

- any add-on table (eg. added to the end of XSDT) because it could not be matched (naming/header) shall not be subject to ACPI/DSDT/Patches

 

The fix is here: https://github.com/RehabMan/Clover/commit/1b344368b9960904ad6e0eaf7ad0cd9500d60d85

 

Another change has to do with the installer defaults for drivers64/drivers64UEFI content.

For my build, decided it was better to set AptioMemoryFix, ApfsDriverLoader (and required AppleImageLoader), and AppleUiSupport (replaces many others) as default.

This one took me a couple of tries to get it completely right (misread XhciDxe as default... [only default for drivers64]):

https://github.com/RehabMan/Clover/commit/b81dd0cc7cadf826ef91ee29523a2cbfefd28814

https://github.com/RehabMan/Clover/commit/ca9576f33d5d2a186f9d32a11e12320eeaeb39cc

 

--

 

And another problem I noticed.  At first, I synced to latest svn, which at the time was r4672.

But there was a serious performance regression.  Navigating in the GUI is extremely laggy (less noticeable on a fast computer, but still noticeable).

So, I went back to r4658 before all the svg stuff was added.  No performance issue with r4658.

It appears the svg support causes a serious performance issue in the Clover GUI.

 

My current build is therefore based on svn r4658 until that performance regression is fixed in the svn Clover.

 

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

10 hours ago, Slice said:

No, svg support is not currently used so it can't influence.

...

The performance regression is caused by one or more commits between r4658 and r4672.

I did not try to determine which (one or more) of the 14 is the cause.

  • Like 1
Link to comment
Share on other sites

23 hours ago, Slice said:

No, svg support is not currently used so it can't influence.

About ACPI update I am on vacancy about 3 weeks so I propose someone else can commit. Sherlocks?

 

ACPI update was committed. 

since added AppleKeyFeeder as default, many users reported issues(GUI/Boot). can we consider to exclude AppleKeyFeeder from default(always checked when installing clover)?

  • Like 2
Link to comment
Share on other sites

10 minutes ago, Sherlocks said:

 

ACPI update was committed. 

since added AppleKeyFeeder as default, many users reported issues(GUI/Boot). can we consider to exclude AppleKeyFeeder from default(always checked when installing clover)?

Causes issues with shell as well.

  • Like 1
Link to comment
Share on other sites

35 minutes ago, Sherlocks said:

 

ACPI update was committed. 

since added AppleKeyFeeder as default, many users reported issues(GUI/Boot). can we consider to exclude AppleKeyFeeder from default(always checked when installing clover)?

Yes, it will be better all FV2 drivers to be not default.

  • Like 1
Link to comment
Share on other sites

Builds on github, nice!

I tried every build there, now 4677 and it seems to be working

The problem is the build on sf and my own build of 4676 (using latest xcode on hs and buildClover script)

The 4677 installer is weird, drivers in my efi folder were not selected and there s a new default hpfs driver.

What s the difference between this new driver and vboxHpfs?

Thanks

Link to comment
Share on other sites

Builds on github, nice!

I tried every build there, now 4677 and it seems to be working

The problem is the build on sf and my own build of 4676 (using latest xcode on hs and buildClover script)

The 4677 installer is weird, drivers in my efi folder were not selected and there s a new default hpfs driver.

What s the difference between this new driver and vboxHpfs?

Thanks
r4677 is not good. try to use 4678 and cleanup your driver64uefi and use drivers like before. i don't know why issue happen after i committed it on r4677. when i test it, it worked. but strangely package of installation is randomly failed. i returned buildpkg on r4678. i don't have time now. i have to sleep for tommorow. hope someone need to fix this issue.

나의 LG-F800S 의 Tapatalk에서 보냄

  • Like 2
Link to comment
Share on other sites

8 hours ago, Sherlocks said:

 

ACPI update was committed. 

 

Awesome.  Thanks.

 

And I see a few other fixes in that commit that look like a good idea also.

 

Except for perhaps the extra SaveMergedXsdtEntrySize (will review).  If that was added just for the possibility of memory leak, please realize there are a ton of memory leaks in the ACPI patching code (but really, these memory amounts are small, and the leaks are 'one-time' so really don't matter much).  Fixing all the leaks would require some time to review all the code very carefully.

  • Like 1
Link to comment
Share on other sites

Awesome.  Thanks.

 

And I see a few other fixes in that commit that look like a good idea also.

 

Except for perhaps the extra SaveMergedXsdtEntrySize (will review).  If that was added just for the possibility of memory leak, please realize there are a ton of memory leaks in the ACPI patching code (but really, these memory amounts are small, and the leaks are 'one-time' so really don't matter much).  Fixing all the leaks would require some time to review all the code very carefully.

i don't touch acpipatcher.c. i took your acpipatcher.c from your github. is there something wrong?

 

EDIT1. any idea for r4677?

package randomly has fail. i don't know why issue happen

 

나의 LG-F800S 의 Tapatalk에서 보냄

 

 

 

Link to comment
Share on other sites

6 minutes ago, Sherlocks said:

thanks vector. i didn't see iso image part. also i first hear iso image related in FV2 drivers


나의 LG-F800S 의 Tapatalk에서 보냄
 

Yep, Usually if you have an encrypted volume and a virtual disk-file is inside that disk is already protected. But if you export that disk it lost its protection. Basically I'm asking if anyone cares about that... i.e. the iso image will not load FV drivers and your VM should not use this technology.

EDIT

I'm at Job and can't check if the .iso image generated usually had FV drivers

Edited by vector sigma
  • Like 1
Link to comment
Share on other sites

Yep, Usually if you have an encrypted volume and a virtual disk-file is inside that disk is already protected. But if you export that disk it lost its protection. Basically I'm asking if anyone cares about that... i.e. the iso image will not load FV drivers and your VM should not use this technology.
EDIT
I'm at Job and can't check if the .iso image generated usually had FV drivers
if you consider or improve it, it's good. now i have to sleep for job tommorow. thank you for info

나의 LG-F800S 의 Tapatalk에서 보냄

  • Like 1
Link to comment
Share on other sites

49 minutes ago, Sherlocks said:

i don't touch acpipatcher.c. i took your acpipatcher.c from your github. is there something wrong?

Going from memory, the diffs on sourceforge looked more than my diffs.  Maybe there were further downsteam changes, ... I will review when I have time.

  • Like 1
Link to comment
Share on other sites

Going from memory, the diffs on sourceforge looked more than my diffs.  Maybe there were further downsteam changes, ... I will review when I have time.
seems your acpipatcher.c has downsteam parts compared to clover acpipatcher.c in github. because i took only latest acpipatcher.c file from your github. please check your file.

나의 LG-F800S 의 Tapatalk에서 보냄

Link to comment
Share on other sites

2 hours ago, Sherlocks said:

seems your acpipatcher.c has downsteam parts compared to clover acpipatcher.c in github. because i took only latest acpipatcher.c file from your github. please check your file.

나의 LG-F800S 의 Tapatalk에서 보냄
 

 

My changes were based on AcpiPatcher.c from r4658.  I didn't go further with my svn sync due to the performance issues in later builds.

But yeah, I'll check what you have in a bit...

Link to comment
Share on other sites

On 9/27/2018 at 9:34 AM, RehabMan said:

 

My changes were based on AcpiPatcher.c from r4658.  I didn't go further with my svn sync due to the performance issues in later builds.

But yeah, I'll check what you have in a bit...

 

I put the difference back to the original state of the clover again before applying your file.

https://sourceforge.net/p/cloverefiboot/code/4682/

There is a definite difference between your file and an existing clover file.

Because I commit your file as it is. And once again I have received your file and compared it with the acpipatcher file of r4674, but there are other parts in addition to the commit like r4682 in your github.

also between r4658 and r4674, there was no change for acpipatcher file. you can see a history of commits

 

Edited by Sherlocks
Link to comment
Share on other sites

@Slice @vector sigma @savvas @Zenith432

I'm committing on Windows
If i commit the postinstall file in Windows, when you receive the source from sf on a Mac, the postinstall file does not work(exec feature was lost)

 and you are currently experiencing a package problem.
Currently I can not commit on the Mac. Please commit the postinstall file in the AppleUiSupport folder inside the package folder templete folder to the file I uploaded now.

 

I discovered this problem while debugging. Other files have never had a problem before. This problem occurred when only the postinstall file was committed in Windows.

 

contents of postinstall are same like before, i don't know why this issue happen. just need to remove and commit postinstall again. 

just found that postinstall committed in windows has white icon, postinstall commited in mac has black icon.

 

AppleUiSupport.zip

 

EDIT

between r4684 and r4685, i tried to delete postinstall and commit it again. but still postinstall file has white icon.

postinstall file needs to be commit in mac os.

189974135_2018-09-306_01_06.png.87c24b39633ac4313e359570a3d4fa53.png

509648450_2018-09-306_01_54.png.0bb517335f3027dd5008d21c1302a051.png

 

Edited by Sherlocks
Link to comment
Share on other sites

×
×
  • Create New...