TheRacerMaster Posted July 7, 2017 Share Posted July 7, 2017 Has anyone come across the required patch to fix the boot glitch (Apple Logo) when starting High Sierra yet? Why not use IntelGraphicsFixup? 1 Link to comment Share on other sites More sharing options...
D-an-W Posted July 7, 2017 Share Posted July 7, 2017 I have no idea what it is basically...lol I will do some digging thought, thanks for the tip. EDIT: Found what I presume is what I need on your github, can I just add the kext and remove the patches for both Sierra and not bother with one for High Sierra? Link to comment Share on other sites More sharing options...
TheRacerMaster Posted July 7, 2017 Share Posted July 7, 2017 Remove whatever IOGraphicsFamily patches you have and install Lilu & IntelGraphicsFixup. That should be it. 2 Link to comment Share on other sites More sharing options...
D-an-W Posted July 7, 2017 Share Posted July 7, 2017 Had to add the beta argument for High Sierra but worked a treat, thanks for the heads up! Link to comment Share on other sites More sharing options...
azlvda Posted July 8, 2017 Share Posted July 8, 2017 Has anyone come across the required patch to fix the boot glitch (Apple Logo) when starting High Sierra yet? http://www.insanelymac.com/forum/topic/284656-clover-general-discussion/page-655?do=findComment&comment=2436330 1 Link to comment Share on other sites More sharing options...
lwfitzgerald Posted July 8, 2017 Share Posted July 8, 2017 I spent the afternoon today trying to figure out why my ATI connector patch had stopped working with an upgrade of Clover (to version 4097). When I switched on debug logging I saw that the controller kext was not being patched at all and the output showed the following: ATIConnectorsPatch: driverAddr ... Controller = 800 when ATIConnectorsController was actually set to "8000" in my configuration. I think a bug was introduced in r3987, truncating the value of ATIConnectorsController by 1 character. This is due to the DestMax (third) argument of AsciiStrToUnicodeStrS needing to include space for the NULL terminator character: @param DestMax The maximum number of Destination Unicode char, including terminating null char. but it is called with the length of the the ATIConnectorsController value/string: AsciiStrToUnicodeStrS (Prop->string, Patches->KPATIConnectorsController, AsciiStrnLenS(Prop->string, 255)); I think a simple fix is to include the space for the NULL-terminator: Index: rEFIt_UEFI/Platform/Settings.c =================================================================== --- rEFIt_UEFI/Platform/Settings.c (revision 4111) +++ rEFIt_UEFI/Platform/Settings.c (working copy) @@ -865,7 +865,7 @@ // ATIConnectors patch Patches->KPATIConnectorsController = AllocateZeroPool (AsciiStrnLenS(Prop->string, 255) * sizeof(CHAR16) + 2); - AsciiStrToUnicodeStrS (Prop->string, Patches->KPATIConnectorsController, AsciiStrnLenS(Prop->string, 255)); + AsciiStrToUnicodeStrS (Prop->string, Patches->KPATIConnectorsController, AsciiStrnLenS(Prop->string, 255) + 1); Patches->KPATIConnectorsData = GetDataSetting (DictPointer, "ATIConnectorsData", &len); Patches->KPATIConnectorsDataLen = len; I've worked around this until it can be fixed by setting my ATIConnectorsController to "8000x" (the "x" gets dropped leaving the correct "8000"). 4 Link to comment Share on other sites More sharing options...
Slice Posted July 10, 2017 Share Posted July 10, 2017 During XML parsing the "prop->string" should be already NULL-terminating. The error is somewhere else. PS. May be odd/even number of chars? Link to comment Share on other sites More sharing options...
mhaeuser Posted July 10, 2017 Share Posted July 10, 2017 During XML parsing the "prop->string" should be already NULL-terminating. The error is somewhere else. PS. May be odd/even number of chars? Of course it is NULL-terminated, if it wasn't, Ascii* wouldnt't work... "@param DestMax The maximum number of Destination Unicode char, !!including terminating null char.!!" 1 Link to comment Share on other sites More sharing options...
Slice Posted July 10, 2017 Share Posted July 10, 2017 Of course it is NULL-terminated, if it wasn't, Ascii* wouldnt't work... "@param DestMax The maximum number of Destination Unicode char, !!including terminating null char.!!" OK, I understand, thanks. Link to comment Share on other sites More sharing options...
apianti Posted July 10, 2017 Share Posted July 10, 2017 AsciiStrnLenS actually will work without a null-terminator since it uses a maximum length. Doesn't mean you'll get a valid string though... Link to comment Share on other sites More sharing options...
mhaeuser Posted July 10, 2017 Share Posted July 10, 2017 AsciiStrnLenS actually will work without a null-terminator since it uses a maximum length. Doesn't mean you'll get a valid string though... * wouldn't work as intended. -.- If that is working, I wonder what 'doesn't work'. Link to comment Share on other sites More sharing options...
Slice Posted July 10, 2017 Share Posted July 10, 2017 if (Prop && IsPropertyTrue (Prop)) { + gSettings.HWP = TRUE; + AsmWriteMsr64 (MSR_IA32_PM_ENABLE, 1); + } Here is the code for turning HWP on for Clover. But it became ineffective when computer waked up from sleep. Is there a way we can manually call this method so that HWP remains effective after sleep? I confirm the problem Loading AnVMSR.kext. AnVMSR.kext successfully loaded (or already loaded). bash-3.2# ./anvmsr read 0x770 RDMSR 770 returns value 0x1 bash-3.2# ./anvmsr read 0x770 RDMSR 770 returns value 0x0 bash-3.2# exit First read before sleep and second read after wake. RehabMan proposed to change SMBIOS to resolve the problem. But for me it appears to be better DISABLE HWP at Clover config. And now I have normal speedstep. Good working speedstep The test is LuzMark 0.3.1 which is able to load only GPU (centre) or GPU + CPU (right end of graphic). Link to comment Share on other sites More sharing options...
lwfitzgerald Posted July 10, 2017 Share Posted July 10, 2017 Looks like the ATIConnectorsController issue is fixed in r4113. A little disappointed to see no attribution in the commit message (as appears to be the convention?), but good to see the bug fixed. Link to comment Share on other sites More sharing options...
mhaeuser Posted July 10, 2017 Share Posted July 10, 2017 if (Prop && IsPropertyTrue (Prop)) { + gSettings.HWP = TRUE; + AsmWriteMsr64 (MSR_IA32_PM_ENABLE, 1); + } Here is the code for turning HWP on for Clover. But it became ineffective when computer waked up from sleep. Is there a way we can manually call this method so that HWP remains effective after sleep? Even though the other bits are 'reserved', better read, set the bit and write back instead of wiping whatever is currently there. 1 Link to comment Share on other sites More sharing options...
Slice Posted July 10, 2017 Share Posted July 10, 2017 Even though the other bits are 'reserved', better read, set the bit and write back instead of wiping whatever is currently there. Do you have a method to write back? Link to comment Share on other sites More sharing options...
apianti Posted July 10, 2017 Share Posted July 10, 2017 He means this: if (Prop && IsPropertyTrue (Prop)) { gSettings.HWP = TRUE; AsmWriteMsr64 (MSR_IA32_PM_ENABLE, AsmReadMsr64(MSR_IA32_PM_ENABLE) | 1); } 2 Link to comment Share on other sites More sharing options...
Slice Posted July 11, 2017 Share Posted July 11, 2017 He means this: if (Prop && IsPropertyTrue (Prop)) { gSettings.HWP = TRUE; AsmWriteMsr64 (MSR_IA32_PM_ENABLE, AsmReadMsr64(MSR_IA32_PM_ENABLE) | 1); } Other bits are not deserved to bother about. Anyway I tell about the problem that Clover can't set this bit after wake. There must be another technology. And so setting this bit in Clover has no sense at all. 1 Link to comment Share on other sites More sharing options...
mhaeuser Posted July 11, 2017 Share Posted July 11, 2017 Other bits are not deserved to bother about. Right, if some future platform will start using the other bits, it can still be fixed... If the issue is ever traced Link to comment Share on other sites More sharing options...
SavageAUS Posted July 11, 2017 Share Posted July 11, 2017 I confirm the problem Loading AnVMSR.kext. AnVMSR.kext successfully loaded (or already loaded). bash-3.2# ./anvmsr read 0x770 RDMSR 770 returns value 0x1 bash-3.2# ./anvmsr read 0x770 RDMSR 770 returns value 0x0 bash-3.2# exit First read before sleep and second read after wake. RehabMan proposed to change SMBIOS to resolve the problem. But for me it appears to be better DISABLE HWP at Clover config. And now I have normal speedstep. Good working speedstep Снимок экрана 2017-07-10 в 21.06.24.png The test is LuzMark 0.3.1 which is able to load only GPU (centre) or GPU + CPU (right end of graphic). Is this normal? Link to comment Share on other sites More sharing options...
Sherlocks Posted July 11, 2017 Share Posted July 11, 2017 I confirm the problem Loading AnVMSR.kext. AnVMSR.kext successfully loaded (or already loaded). bash-3.2# ./anvmsr read 0x770 RDMSR 770 returns value 0x1 bash-3.2# ./anvmsr read 0x770 RDMSR 770 returns value 0x0 bash-3.2# exit First read before sleep and second read after wake. RehabMan proposed to change SMBIOS to resolve the problem. But for me it appears to be better DISABLE HWP at Clover config. And now I have normal speedstep. Good working speedstep Снимок экрана 2017-07-10 в 21.06.24.png The test is LuzMark 0.3.1 which is able to load only GPU (centre) or GPU + CPU (right end of graphic). my case. skylake u smbios mbp13,3 pike idle patch check HWPEnable Sherlocksui-MBP:downloads sherlocks$ sudo kextload AnVMSR.kext <------- boot Sherlocksui-MBP:downloads sherlocks$ ./anvmsr read 0x770 RDMSR 770 returns value 0x1 Sherlocksui-MBP:downloads sherlocks$ sudo kextunload AnVMSR.kext Sherlocksui-MBP:downloads sherlocks$ sudo kextload AnVMSR.kext <------- wakeup Sherlocksui-MBP:downloads sherlocks$ ./anvmsr read 0x770 RDMSR 770 returns value 0x1 Sherlocksui-MBP:downloads sherlocks$ uncheck HWPEnable Sherlocksui-MBP:downloads sherlocks$ sudo kextload AnVMSR.kext <------- boot Sherlocksui-MBP:downloads sherlocks$ ./anvmsr read 0x770 RDMSR 770 returns value 0x1 Sherlocksui-MBP:downloads sherlocks$ sudo kextunload AnVMSR.kext Sherlocksui-MBP:downloads sherlocks$ sudo kextload AnVMSR.kext <------- wakeup Sherlocksui-MBP:downloads sherlocks$ ./anvmsr read 0x770 RDMSR 770 returns value 0x1 Sherlocksui-MBP:downloads sherlocks$ i didn't see difference. Link to comment Share on other sites More sharing options...
PMheart Posted July 11, 2017 Share Posted July 11, 2017 my case. skylake u smbios mbp13,3 pike idle patch check HWPEnable Sherlocksui-MBP:downloads sherlocks$ sudo kextload AnVMSR.kext <------- boot Sherlocksui-MBP:downloads sherlocks$ ./anvmsr read 0x770 RDMSR 770 returns value 0x1 Sherlocksui-MBP:downloads sherlocks$ sudo kextunload AnVMSR.kext Sherlocksui-MBP:downloads sherlocks$ sudo kextload AnVMSR.kext <------- wakeup Sherlocksui-MBP:downloads sherlocks$ ./anvmsr read 0x770 RDMSR 770 returns value 0x1 Sherlocksui-MBP:downloads sherlocks$ uncheck HWPEnable Sherlocksui-MBP:downloads sherlocks$ sudo kextload AnVMSR.kext <------- boot Sherlocksui-MBP:downloads sherlocks$ ./anvmsr read 0x770 RDMSR 770 returns value 0x1 Sherlocksui-MBP:downloads sherlocks$ sudo kextunload AnVMSR.kext Sherlocksui-MBP:downloads sherlocks$ sudo kextload AnVMSR.kext <------- wakeup Sherlocksui-MBP:downloads sherlocks$ ./anvmsr read 0x770 RDMSR 770 returns value 0x1 Sherlocksui-MBP:downloads sherlocks$ i didn't see difference. Well, checking HWPEnable just writes MSR 0x770 according to the source code: #13688 And you've done that manually via AnvMSR.kext and `anvmsr`, so there won't be any difference I guess. Link to comment Share on other sites More sharing options...
Slice Posted July 11, 2017 Share Posted July 11, 2017 Well, checking HWPEnable just writes MSR 0x770 according to the source code: #13688 And you've done that manually via AnvMSR.kext and `anvmsr`, so there won't be any difference I guess. He only read the value. Is this normal? Screen Shot 2017-07-11 at 3.44.27 pm.png You have no ordinary speedstep which depends on MacModel and SSDT tables. 2 Link to comment Share on other sites More sharing options...
SavageAUS Posted July 11, 2017 Share Posted July 11, 2017 He only read the value. You have no ordinary speedstep which depends on MacModel and SSDT tables. I used pikes script for ssdt.aml and using MacBook pro 11,1. Sent from my SM-G930F using Tapatalk Link to comment Share on other sites More sharing options...
Slice Posted July 11, 2017 Share Posted July 11, 2017 I am not using pike script. 1 Link to comment Share on other sites More sharing options...
SavageAUS Posted July 11, 2017 Share Posted July 11, 2017 @fusion71au Can you help again please, having trouble renaming macOS High Sierra recovery partition. bootlog.log.txt Terminal Saved Output.zip Terminal Saved Output UUID.zip Link to comment Share on other sites More sharing options...
Recommended Posts