deeveedee Posted September 20, 2021 Share Posted September 20, 2021 @Pluskat5000Schiffe I reviewed the last EFI you posted and see that you have not fully implemented the XOSI patch. You need to add the ACPI patch to rename _OSI to XOSI. Examine my last sample config.plist to learn. You indicate that your PC does not shutdown. Did it ever shutdown before? If so, which changes did you make that resulted in broken shutdown? Link to comment Share on other sites More sharing options...
Pluskat5000Schiffe Posted September 20, 2021 Author Share Posted September 20, 2021 @tonyx86 I'm not totally sure. However it shut now correct seems to be a hit and or miss if it does a full shutdown. From the open core menu it works flawlessly stable though. Link to comment Share on other sites More sharing options...
deeveedee Posted September 20, 2021 Share Posted September 20, 2021 @Pluskat5000Schiffe Can you please post your latest IORegistry explorer dump using IORegistryExplorer 2.1? Link to comment Share on other sites More sharing options...
Pluskat5000Schiffe Posted September 20, 2021 Author Share Posted September 20, 2021 (edited) @tonyx86 Sure Here you go. Regarding the XOSI just put yours in my OC / ACPI and adjust config.plist? Included DSDT too. Edited September 20, 2021 by Pluskat5000Schiffe Link to comment Share on other sites More sharing options...
deeveedee Posted September 20, 2021 Share Posted September 20, 2021 (edited) On 9/20/2021 at 9:14 AM, Pluskat5000Schiffe said: @tonyx86 Regarding the XOSI just put yours in my OC / ACPI and adjust config.plist? There are two changes required in the config.plist. See my last example plist in ACPI>Add and ACPI>Patch. @Pluskat5000Schiffe I just looked at the last plist example that I provided and see that I forgot to include the XOSI rename patch. Please accept my apology. A new plist example is attached. See the XOSI rename patch in ACPI>Patch. config.plist.zip Edited September 20, 2021 by tonyx86 Added new plist with XOSI rename patch Link to comment Share on other sites More sharing options...
deeveedee Posted September 20, 2021 Share Posted September 20, 2021 @Pluskat5000Schiffe Why do you use RtWlanU1827.kext? If you're using a real Apple Wi-Fi card, remove these Realtek Wi-Fi kexts from your config.plist. They could contribute to your shutdown problem. Link to comment Share on other sites More sharing options...
Pluskat5000Schiffe Posted September 20, 2021 Author Share Posted September 20, 2021 On 9/20/2021 at 4:03 PM, tonyx86 said: @Pluskat5000Schiffe Why do you use RtWlanU1827.kext? If you're using a real Apple Wi-Fi card, remove these Realtek Wi-Fi kexts from your config.plist. They could contribute to your shutdown problem. I know but that real Apple Card is just shipped from the UK and the M2 NGFF adapter is shipped from china so I need that indeed {censored} wifi card. The shutdown problem remains without the USB Wifi dongle inserted. Can that driver still give issues? Link to comment Share on other sites More sharing options...
deeveedee Posted September 20, 2021 Share Posted September 20, 2021 (edited) @Pluskat5000Schiffe My original plist example did not include the XOSI rename patch. I'm so sorry! I attached a new example plist here. I think the driver can still cause shutdown issues even without the dongle. You should test this by disabling the kexts. If after disabling the Realtek Wi-Fi kexts, you still have shutdown problems, read this. Edited September 20, 2021 by tonyx86 Link to comment Share on other sites More sharing options...
Pluskat5000Schiffe Posted September 20, 2021 Author Share Posted September 20, 2021 (edited) @tonyx86 indeed tried that one already. Didn't help. Will try to disable the kexts. New Config with XOSI + PTSWAK and new IOReg. Next try to disable drivers and see what it will do with shutdown. Edited September 20, 2021 by Pluskat5000Schiffe Link to comment Share on other sites More sharing options...
deeveedee Posted September 20, 2021 Share Posted September 20, 2021 @Pluskat5000Schiffe I looked at the last 'EFI XOSI + PTSWAK.zip' that you posted and don't see the required patches. Did you post the wrong file? Please note that the PTS/WAK examples that I provided are from my HP Envy and were intended to be examples only. I did not determine whether my HP Envy PTS/WAK patches would be suitable for your G3. I have to go now and will check back in a day or two. Link to comment Share on other sites More sharing options...
Pluskat5000Schiffe Posted September 20, 2021 Author Share Posted September 20, 2021 On 9/20/2021 at 4:40 PM, tonyx86 said: @Pluskat5000Schiffe I looked at the last 'EFI XOSI + PTSWAK.zip' that you posted and don't see the required patches. Did you post the wrong file? Please note that the PTS/WAK examples that I provided are from my HP Envy and were intended to be examples only. I did not determine whether my HP Envy PTS/WAK patches would be suitable for your G3. I have to go now and will check back in a day or two. Ah ok. Yes indeed I think I posted wrong stuff. I will try to be more precise because I have to much EFIs on desktop etc. I did however a test without the dongle and without the kexts but ti didn't solve the shutdown. Link to comment Share on other sites More sharing options...
deeveedee Posted September 20, 2021 Share Posted September 20, 2021 @Pluskat5000Schiffe Always Reset NVRAM after any EFI changes before you conduct any testing. Link to comment Share on other sites More sharing options...
Pluskat5000Schiffe Posted September 20, 2021 Author Share Posted September 20, 2021 @tonyx86 I have corrected and implemented your 2 SSDTs with the 3 patched (indeed just with your example file) and it works now consequent for 4 times (shutdown). Link to comment Share on other sites More sharing options...
Pluskat5000Schiffe Posted September 20, 2021 Author Share Posted September 20, 2021 @tonyx86 ps. I forgot you to tell … A big thank you from my daughter! Link to comment Share on other sites More sharing options...
deeveedee Posted September 21, 2021 Share Posted September 21, 2021 @Pluskat5000Schiffe You and your daughter are both very welcome! When you get a chance, please post your latest working EFI. Great team work! 1 Link to comment Share on other sites More sharing options...
Pluskat5000Schiffe Posted September 21, 2021 Author Share Posted September 21, 2021 @tonyx86 see post 1 cheers! 1 Link to comment Share on other sites More sharing options...
deeveedee Posted September 27, 2021 Share Posted September 27, 2021 (edited) @Pluskat5000Schiffe I recently experienced kernel panics on my HP Envy (Kabylake R i5-8250U/UHD620) and have resolved the issue by increasing framebuffer-stolenmem and framebuffer-fbmem in my config.plist DeviceProperties. I'm not suggesting that you make any changes to your daughter's Prodesk G3 unless you experience a kernel panic that implies com.apple.driver.AppleIntelKBLGraphics. More details below... My HP Envy laptop (Kabylake R i5-8250U/UHD620) BIOS does not permit any configuration of video memory. After reading this, I assumed that I needed to specify framebuffer-stolenmem and framebuffer-fbmem in my config.plist DeviceProperties. I initially used the values 19MB and 9MB respectively which were provided here in order to keep total VRAM under 32MB. With these values, I found that I experienced kernel panics (com.apple.driver.AppleIntelKBLGraphics) when simultaneously running a combination of firefox video streaming, safari and TunnelBlick OpenVPN client. After experimentation and trial and error, I have achieved system stability (no more kernel panics) by increasing framebuffer-stolenmem to 39MB (<00007002>) and increasing framebuffer-fbmem to 21MB (<00005001>). I chose these new values based on the values here for my rig's AAPL,ig-platform-id: <00001B59>. I'm not certain, but I think this means that I don't need to configure framebuffer-stolenmem and framebuffer-fbmem for my HP Envy (because the framebuffer-stolenmem and framebuffer-fbmem values I specify in my config.plist DeviceProperties are those already defined by the framebuffer I am using). EDIT: I have deleted framebuffer-stolenmem and framebuffer-fbmem from my rig's DeviceProperties and still no com.apple.driver.AppleIntelKBLGraphics kernel panics. I believe this means that my rig has enough pre-allocated DVMT (at least 64MB) for the stolenmem and fbmem required by my chosen framebuffer (AAPL,ig-platform-id) as defined here, so there is no need to limit stolenmem and fbmem. For those reading this, my suggestion would be to first test without defining framebuffer-stolenmem and framebuffer-fbmem. If all is good, there is no need to define these values. Edited October 6, 2021 by tonyx86 1 Link to comment Share on other sites More sharing options...
Pluskat5000Schiffe Posted September 27, 2021 Author Share Posted September 27, 2021 [mention=486181]Pluskat5000Schiffe[/mention] … BIOS does not permit any configuration of video memory. I do have this option. Configured 128MB if I’m correct. Until now no issue. Thanks for reporting.Verzonden vanaf mijn iPhone met Tapatalk Link to comment Share on other sites More sharing options...
deeveedee Posted September 27, 2021 Share Posted September 27, 2021 @Pluskat5000Schiffe If you are able to configure VRAM in BIOS, then it is very possible that you do not need to specify framebuffer-stolenmem in your DeviceProperties. 1 Link to comment Share on other sites More sharing options...
Pluskat5000Schiffe Posted September 28, 2021 Author Share Posted September 28, 2021 3 hours ago, tonyx86 said: @Pluskat5000Schiffe If you are able to configure VRAM in BIOS, then it is very possible that you do not need to specify framebuffer-stolenmem in your DeviceProperties. I will try ASAP without these. She loves her hack... although I need to remind her every time to shut it down to reduce the CO2 footprint 😉 Unverified statement / my idea: Although the iMac 18,1 uses a Kaby Lake CPU the processor in the 18,1 is quite different. Its a i5-7360U which uses a totally different iGPU. It uses a Intel® Iris® Plus Graphics 640 instead of an intel® HD Graphics 630. The 18,2 and 18,3 iMac's are using The Kaby Lake with indeed HD Graphics 630 but that iGPU is not used for video because these iMacs do have a discrete GPU. I suppose for rendering (correct?). So in order to get wake from sleep working and with proper video reinitialisationwe need to spoof the iPGU as a Intel® Iris® Plus Graphics 640 or even the hole cpu as a i5-7360 spoofed CPU? Is this possible or are the differences between the 640 / 630 too big? 1 Link to comment Share on other sites More sharing options...
deeveedee Posted September 28, 2021 Share Posted September 28, 2021 I use MBP15,2 for my HP Envy. The real MBP15,2 has integrated Intel Iris Plus Graphics 655 graphics. My hack has UHD620. I don't know enough about the differences between the iGPUs, but my hack sleeps/wakes fine. You might be able to learn more here. Link to comment Share on other sites More sharing options...
deeveedee Posted October 5, 2021 Share Posted October 5, 2021 @Pluskat5000Schiffe This Acidanthera kext claims to fix some kernel panics after wake. It might be worth reading about. I never tested it to see if it fixed the Kabylake wake problem. 1 Link to comment Share on other sites More sharing options...
Pluskat5000Schiffe Posted October 12, 2021 Author Share Posted October 12, 2021 @tonyx86 I tried but that Kext didn't fix the wake from sleep issue. 1 Link to comment Share on other sites More sharing options...
Pluskat5000Schiffe Posted November 16, 2021 Author Share Posted November 16, 2021 (edited) Hi, Today I added a BCM94360CS2 653-0020 wifi card with an M.2 Ngff 12 + 6 Pin adaptor card. Everything went fine until I encountered 1 issues. 1) The antennes I bought from aliexpress do have a connector (the very tiny clamps) which is too large it doesn't fit on the tow antenne points in the CS2 card. Do you know what I need to purchase instead? 2) The bluetooth is not showing up in the Hack. Is this normal when you only connect the CS2 with a M.2 Ngff 12 + 6 Pin adaptor card? I see PCI express cards with a separate cable to make a connection to an USB header in a regular PC. Thx for feedback. Edited November 16, 2021 by Pluskat5000Schiffe Link to comment Share on other sites More sharing options...
deeveedee Posted December 5, 2021 Share Posted December 5, 2021 @Pluskat5000Schiffe In response to a question I asked, Andrey1970 mentioned a couple of boot-args for IGPUs here. Does the boot-arg "igfxrpsc=1 " that he mentions have any affect on the sleep/wake behavior of your G3? Link to comment Share on other sites More sharing options...
Recommended Posts