Jump to content

Random System Shutdown/KP Every Few Hours (Solved)


vettz500
 Share

4 posts in this topic

Recommended Posts

Problem has been solved. I tracked it down to the VoodooI2C kext. There was a memory leak in the kext and it was causing kernel_task to steadily increase RAM usage while using the laptop until it maxed out all 32gigs of RAM, which then caused the system to try and shut down and crash. 
Problem was fixed in the latest version of VoodooI2C that patched the memory leak. 


Razer Blade 15 2018 (Advanced)
i7-8750H

UHD 630
Nvidia GTX 1060 
High Sierra: 17G3025

Have my system up and running almost 100% at this point. Trackpad, battery status, sleep, brightness controls, audio. But the one thing I am hung up on is every few hours the system will just randomly try to shut itself down. No matter what I'm doing, I could be watching a video, working in Pro Tools or just browsing the internet. The laptop will all of the sudden close out of the apps that I am using, iCloud will throw a password error message and one by one everything starts to disappear off of the screen as if it's trying to shut down. Until it eventually just gets to just my desktop background and becomes totally unresponsive and my fans just start to spin at full speed. 
It also doesn't seem to be exactly time specific. If I use the laptop for 4+ hours straight it will try and shut itself down. But if I use the laptop on and off over the course of a full day or 2 and just put it to sleep when I'm not using it, it will be fine for a full day or 2 until I start to use it for a long period of time. 

I've went through one by one and removed kexts I've installed to see if it was something I was using, so far nothing has taken care of it. 
I've also tried different SMBIOS, a clean install and even Mojave. All have the same issue. 

I'm kind of at a loss, wondering if anyone has had a similar issue? Or can maybe point me in a direction of where to look next? 

Attached some files to help, as well as a few screenshots of the system log I was able to grab while the system was in the middle of this shutdown/right before it kernel panicked and locked up. Not sure if they would be any help, but maybe they can tell something. I tried to find the spot right before it started the process of closing me out of everything and take a screenshot from there.

debug_16485.zip

Screen Shot 2018-12-27 at 9.02.20 PM.png

Screen Shot 2018-12-27 at 9.02.11 PM.png

Screen Shot 2018-12-27 at 9.01.27 PM.png

Screen Shot 2018-12-27 at 9.01.11 PM.png

Edited by vettz500
Link to comment
Share on other sites

5 hours ago, Hervé said:

I think your trouble most probably derive from an inadequate Clover config:

  • you inject all sorts of NVIDIA and ATI properties
  • you apply incorrect graphics settings
  • you apply quite a lot of ACPI patches
  • you use a 4th gen Haswell SMBIOS when you have an 8th gen Coffee Lake platform

 

I believe many of your Clover settings are irrelevant to your laptop. How did you get this Clover configuration? Retrieved from somewhere or built it yourself?

 

 

I have went through and disabled the Nvidia and ATI properties, they were left overs from the very beginning stages of the config.plist build, back when the laptop was still being sorted. 

  • What graphics settings are incorrect?
  • As far as the ACPI Patches go
    DSDT edit for battery status and trackpad patch.
    SSDT-PNLF to activate brightness controls.
    SSDT-10-OptTabl to disable the Nvidia Graphics card (It only works with HDMI out, but is constantly running even when not being used, consuming battery life. This disables it from being activated and keeps it turned off)
    SSDT-UIAC-ALL for proper USB Configuration of only the ports my laptop has
    SSDT-USBX for proper USB Power Configuration (I was told to use this in a different forum, I question if it's actually needed)
    SSDT-XOSI for the "change _OSI to XOSI" patch in Clover for the proper Windows emulation for Darwin. 
  • I know the SMBIOS I was using was for Haswell, I've been bouncing back and forth between 11,1 and 15,2 testing things. Sometimes issues are fixed by a simple SMBIOS change. Which is why the PR files I posted had the 11,2 SMBIOS being used. I was testing to see if it made a difference and just never changed it back. 
  • As far as the config.plist settings came about. I started with a version that another person had working on the same laptop and have added to it since then. Aside from the Nvidia and ATI Properties, what else do you see that is irrelevant? 

I appreciate your help! 

Link to comment
Share on other sites

2 minutes ago, Hervé said:

You've applied a lot of ACPI patches. Did you check if they all applied to your DSDT?

You inject a graphics layout-id but not inject Intel. That's incoherent. You either do both or none if you've installed Lilu + WEG kexts

You're clearly not injecting any kexts through Clover so I can only presume you cached add-on kexts through /S/L/E or (ideally) /L/E. It would be a good idea to list them.

According to WEG developers that have been working to make WEG 100% compatible with the UHD630 graphics, Injecting Intel is no longer needed/no longer works with the new Framebuffer Patching requirements for High Sierra build numbers 17G2112+ and into Mojave. All that is needed with the framebuffer patching is the graphics layout-id + framebuffer specific patches in the config.plist under Devices-Properties-PciRoot(0)/Pci(0x02,0). 
According to RehabMan on a different site I'm sure you're aware of, the ACPI Patches are correct for my system. As far as those go, I was going off of the advice of him and other developers. 


All of my Kexts are installed to /L/E:
WEG

Lilu

LiluFriend
ACPIBatteryManager

AppleALC

BrcmFirmwareRepo

BrcmPatchRAM2

FakePCIID_Broadcom_WiFi
FakePCIID
FakeSMC_ACPISensors
FakeSMC_CPUSensors
FakeSMC_GPUSensors
FakeSMC_LPCSensors
(The FakeSMC Sensor kexts above are for my hardware monitor app)
FakeSMC
USBInjectAll
VoodooI2C
VoodooI2CHID
VoodooPS2Controller

Link to comment
Share on other sites

  • 2 weeks later...

Problem has been solved. I tracked it down to the VoodooI2C kext. There was a memory leak in the kext and it was causing kernel_task to steadily increase RAM usage while using the laptop until it maxed out all 32gigs of RAM, which then caused the system to try and shut down and crash. 
Problem was fixed in the latest version of VoodooI2C that patched the memory leak. 

Link to comment
Share on other sites

 Share

×
×
  • Create New...