UHD630 temperature jumps up to 80°C!

[Asural]

I'm using an HP400G5SFF.
I'm having trouble with the CPU temperature jumping to around 70-80°C when idle after utilization drops to 0 after booting up.

The temperature doesn't rise when using a dGPU.

 

If anyone knows a solution, please let me know.

 

UHD630 SMBIOS = Macmini8,1                                                /.               RX570 SMBIOS = iMac19,2

Edited January 18 by Asural

[verdazil]

@Asural, integrated Intel graphics always consume little power, this is normal.

The cause of overheating is in one of the processes served by the CPU.

To determine which process (or processes) it is, see Utilities --> Activity monitor --> CPU (sort by %CPU)

Depending on the result, further actions can be discussed.

[deeveedee]

@Asural Would you be able to post your full EFI for inspection?

[Asural]

53 minutes ago, verdazil said:

@Asural, integrated Intel graphics always consume little power, this is normal.

The cause of overheating is in one of the processes served by the CPU.

To determine which process (or processes) it is, see Utilities --> Activity monitor --> CPU (sort by %CPU)

Depending on the result, further actions can be discussed.

I have attached the results of the Activity monitor. This is my first time using it, so please let me know if there are any errors in the settings, etc.
I'm currently testing the UHD630 on a Sonoma, which is said to be the final MacOS supported device.

 

ADD:

The temperature rise occurs when the device is idle, not when it is running.
 

 

37 minutes ago, deeveedee said:

@Asural Would you be able to post your full EFI for inspection?

I have attached the EFI I am currently testing, but the same thing happens when I set SMBIOS to Macmini8,1.

(Rsource has been removed due to its large size.)

 

 

Sample HP400G5_EFI.zip

Edited January 18 by Asural

[deeveedee]

@Asural I don't see any obvious issues with your EFI that would explain the CPU temps.  If your hack has NVMe SSD, you should enable NVMeFix.kext for better power management.

 

I did notice that you specify boot-arg 'amfi_get_out_of_my_way=0x1' and inject AMFIPass.kext.  The boot-arg overrides AMFIPass.kext.  If AMFIPass.kext works for you, don't use the boot-arg.

 

What version of macOS are you testing?  EDIT: I see that you're using Sonoma.  I would think that would be well-suited to your hack.  I think Verdazil is on the right track with his process inspection.

Edited January 18 by deeveedee

[verdazil]

15 minutes ago, Asural said:

I'm currently testing the UHD630 on a Sonoma, which is said to be the final MacOS supported device.

Tahoe natively supports UHD 630, that's not the problem.

What you can do

• Wait 10–30 minutes after boot — in many cases the CPU load drops on its own.

• Clear the software update cache:

• sudo rm -rf /Library/Updates/* sudo softwareupdate --clear-catalog

• Restart the related services:

  sudo killall softwareupdated 
  sudo killall UpdateBrainService

[Asural]

39 minutes ago, deeveedee said:

@Asural I don't see any obvious issues with your EFI that would explain the CPU temps.  If your hack has NVMe SSD, you should enable NVMeFix.kext for better power management.

 

I did notice that you specify boot-arg 'amfi_get_out_of_my_way=0x1' and inject AMFIPass.kext.  The boot-arg overrides AMFIPass.kext.  If AMFIPass.kext works for you, don't use the boot-arg.

 

What version of macOS are you testing?  EDIT: I see that you're using Sonoma.  I would think that would be well-suited to your hack.  I think Verdazil is on the right track with his process inspection.

It does not have an M.2 SSD.
I want to use the UHD630 with the Tahoe, so I left the mod-OCLP settings as they were, but I'll try changing them.
 

ADD:

When I tried it, the screenshot function would no longer start and the keyboard (which required driver reconfiguration as I was using PFU-keyboard) stopped working.
This is a common issue that occurs when you change it, so I've gotten used to it.
 

Edited January 18 by Asural

[Asural]

59 minutes ago, verdazil said:

Tahoe natively supports UHD 630, that's not the problem.

What you can do

• Wait 10–30 minutes after boot — in many cases the CPU load drops on its own.

• Clear the software update cache:

• sudo rm -rf /Library/Updates/* sudo softwareupdate --clear-catalog

• Restart the related services:

  sudo killall softwareupdated 
  sudo killall UpdateBrainService

 

The time from startup to idle has been reduced but the temperature rise has not been fixed, I will wait about 30 minutes and see what happens.
 

ADD:

The temperature is now constantly rising.
I will correct the settings and test again after I wake up.
 

Edited January 18 by Asural

[deeveedee]

1 hour ago, Asural said:

It does not have an M.2 SSD.

You should enable Kernel > Quirks > ThirdPartyDrives to enable proper TRIM on non-Apple SSDs.

 

EDIT: I recognize some of your ACPI patches (maybe from my HackMini8,1?).  SSDT-AWAC-HPET-RTC.aml includes 

    Scope (_SB)
    {
        Method (_INI, 0, NotSerialized)  // _INI: Initialize
        {
            If (_OSI ("Darwin"))
            {
                STAS = 0x02
                HPTE = Zero
            }
        }
    }

Without seeing your unpatched DSDT, I can't be certain of how this affects your hack, but I wrote this SSDT patch to disable AWAC, disable RTC and disable HPET (Apple no longer enables Device HPET in Skylake and later).  With HPET Device disabled, the following HPET-related ACPI patches are unnecessary

• ACPI > Add > Item 1 (SSDT-HPET)
• ACPI > Patch > Item 2 (HPET _STA to XSTA Rename)
• ACPI > Patch > Item 3 (HPET _CRS to XCRS= Rename)
• ACPI > Patch > Item 4 (IPIC IRQ 2 Patch)
• ACPI > Patch > Item 5 (RTC IRQ 8 Patch)
• ACPI > Patch > Item 6 (TIMR IRQ 0 Patch)

 

These patches don't hurt anything, but you can safely remove them from your config.plist (and OC/ACPI folder) if you want to simplify your EFI.

 

EDIT2:  @Asural SSDT-AWAC-HPET-RTC.aml includes a new RTC0 Device that changes RTC memory length from 8 to 2.  This is supposed to fix the RTC POST error.  Do you still need ACPI > Patch > Item 1 (RTC POST ERROR FIX)?

Edited January 18 by deeveedee
Fixed typos

[Max.1974]

@Asural Are you trying to use the YogaSMC kext? It is used for fan control. Maybe works for your hardware.  

Intel Power Gadget is no longer recommended because it may cause errors. 

In some cases, over time it may be necessary to replace the CPU thermal paste. I did this recently on my Hackintosh systems, and the improvement was noticeable.

Edited January 18 by Max.1974

[Asural]

11 hours ago, Max.1974 said:

@Asural Are you trying to use the YogaSMC kext? It is used for fan control. Maybe works for your hardware.  

Intel Power Gadget is no longer recommended because it may cause errors. 

In some cases, over time it may be necessary to replace the CPU thermal paste. I did this recently on my Hackintosh systems, and the improvement was noticeable.

 

I don't remember checking the thermal paste, so I reapplied it myself.
This PC doesn't have fan control, so I never considered YogaSMC.

 

Intel Power Gadget doesn't support newer CPUs, and I'm starting to wonder if I can trust it.
Is there any other software I can use to check?
 

[verdazil]

11 minutes ago, Asural said:

Intel Power Gadget doesn't support newer CPUs

Indeed, official support for this app ended long ago. However, it works properly on all modern generations of chipsets and processors, including the Z890 and Intel Core Ultra CPUs.

The information this application provides is sufficient to adequately assess the CPUs operating parameters in terms of power consumption, frequency management, etc.

[Asural]

14 hours ago, deeveedee said:

You should enable Kernel > Quirks > ThirdPartyDrives to enable proper TRIM on non-Apple SSDs.

 

EDIT: I recognize some of your ACPI patches (maybe from my HackMini8,1?).  SSDT-AWAC-HPET-RTC.aml includes 

    Scope (_SB)
    {
        Method (_INI, 0, NotSerialized)  // _INI: Initialize
        {
            If (_OSI ("Darwin"))
            {
                STAS = 0x02
                HPTE = Zero
            }
        }
    }

Without seeing your unpatched DSDT, I can't be certain of how this affects your hack, but I wrote this SSDT patch to disable AWAC, disable RTC and disable HPET (Apple no longer enables Device HPET in Skylake and later).  With HPET Device disabled, the following HPET-related ACPI patches are unnecessary

• ACPI > Add > Item 1 (SSDT-HPET)
• ACPI > Patch > Item 2 (HPET _STA to XSTA Rename)
• ACPI > Patch > Item 3 (HPET _CRS to XCRS= Rename)
• ACPI > Patch > Item 4 (IPIC IRQ 2 Patch)
• ACPI > Patch > Item 5 (RTC IRQ 8 Patch)
• ACPI > Patch > Item 6 (TIMR IRQ 0 Patch)

 

These patches don't hurt anything, but you can safely remove them from your config.plist (and OC/ACPI folder) if you want to simplify your EFI.

 

EDIT2:  @Asural SSDT-AWAC-HPET-RTC.aml includes a new RTC0 Device that changes RTC memory length from 8 to 2.  This is supposed to fix the RTC POST error.  Do you still need ACPI > Patch > Item 1 (RTC POST ERROR FIX)?

 

About how I avoided the RTC-Error
I searched for workarounds and found a YouTube video where I found a workaround using ACPI > Patch > Item 0 (RTC POST ERROR FIX) created from RehabMan's laptop patch.
I then confirmed that your SSDT would work around the issue and used it, but when updating OCLP on Sequoia, a message saying "This SSDT is abnormal" appeared and the OS would no longer boot.
I've been using the ACPI-patch ever since.

 

About IRQ masking
I think I was unable to boot without the SSDT-HPET during USB installation.

 

Before the Tahoe, I was using a dGPU (LP-HD7750), but since OCLP will no longer be available, I'm currently adjusting the iGPU.
The RTC-Error can be avoided using either method.
I tried the SSDT-HPET and it worked without it, so it seems it's not necessary for the iGPU.
 

Edited January 19 by Asural

[Max.1974]

@Asural try TG Pro, but its necessary SSDT from your Thermal Zone, need check your DSDT. Maybe need combine RehabMan SSDTs too. Using Opencore or Clover I need check this and months to get correctly. Need be patient  

 

 

YogaSmc fan control with Opencore

 

Spoiler

 

YogaSmcAlter fan control with Clover 

 

Spoiler

 

Edited January 19 by Max.1974

[Asural]

1 hour ago, Max.1974 said:

@Asural try TG Pro, but its necessary SSDT from your Thermal Zone, need check your DSDT. Maybe need combine RehabMan SSDTs too. Using Opencore or Clover I need check this and months to get correctly. Need be patient  

 

 

YogaSmc fan control with Opencore

 

  Reveal hidden contents

 

YogaSmcAlter fan control with Clover 

 

  Reveal hidden contents

 

 

I tried TG Pro, but it doesn't seem to work.
I also tried HWMonitorSMC2, but it doesn't have a temperature sensor.

I'm starting to think Clover is more convenient.
I am currently doing a clean install of my Sonoma with OpenCore.
 

[Asural]

18 hours ago, deeveedee said:

You should enable Kernel > Quirks > ThirdPartyDrives to enable proper TRIM on non-Apple SSDs.

 

EDIT: I recognize some of your ACPI patches (maybe from my HackMini8,1?).  SSDT-AWAC-HPET-RTC.aml includes 

    Scope (_SB)
    {
        Method (_INI, 0, NotSerialized)  // _INI: Initialize
        {
            If (_OSI ("Darwin"))
            {
                STAS = 0x02
                HPTE = Zero
            }
        }
    }

Without seeing your unpatched DSDT, I can't be certain of how this affects your hack, but I wrote this SSDT patch to disable AWAC, disable RTC and disable HPET (Apple no longer enables Device HPET in Skylake and later).  With HPET Device disabled, the following HPET-related ACPI patches are unnecessary

• ACPI > Add > Item 1 (SSDT-HPET)
• ACPI > Patch > Item 2 (HPET _STA to XSTA Rename)
• ACPI > Patch > Item 3 (HPET _CRS to XCRS= Rename)
• ACPI > Patch > Item 4 (IPIC IRQ 2 Patch)
• ACPI > Patch > Item 5 (RTC IRQ 8 Patch)
• ACPI > Patch > Item 6 (TIMR IRQ 0 Patch)

 

These patches don't hurt anything, but you can safely remove them from your config.plist (and OC/ACPI folder) if you want to simplify your EFI.

 

EDIT2:  @Asural SSDT-AWAC-HPET-RTC.aml includes a new RTC0 Device that changes RTC memory length from 8 to 2.  This is supposed to fix the RTC POST error.  Do you still need ACPI > Patch > Item 1 (RTC POST ERROR FIX)?

 

I have attached the config.plist from the Sonoma I am testing. It seems to be going into idle state faster, but the temperature rise remains the same.

 

SonomaTest.plist

[deeveedee]

@Asural Why do you think there is something wrong with those CPU temps?

 

When you remove the dGPU, the CPU and iGPU will do more work, so CPU die temps will be higher.

[Asural]

14 minutes ago, deeveedee said:

@Asural Why do you think there is something wrong with those CPU temps?

 

When you remove the dGPU, the CPU and iGPU will do more work, so CPU die temps will be higher.

 

I searched for "HP 400 CPU Temperature" and began to wonder if this was normal.
Changing the power management in the BIOS and disabling VT-d didn't make a difference.

Does this happen with your HP800?
 

Edited January 19 by Asural

[deeveedee]

@Asural I haven't watched my CPU temps for a long time.  I find that the less I look, the fewer problems I find

 

If you post your unpatched DSDT, I'd be happy to take a look.  If you are seeing ACPI errors, then it's possible that the ACPI patches you copied from my HP 800 are not an exact match for your HP400.

 

EDIT: @Asural There are a couple of things in your SonomaTest.plist (also in your previous config.plist) that I'm not sure of:

• Do you really need to patch your DMAR table?  Your ACPI > Add > DMAR may not be working the way you think it is, because you are not dropping the original System DMAR.  You should be able to disable your ACPI > Add > Item 7 (DMAR)
• Do you really need DeviceProperty framebuffer-stolenmem?  You are restricting port count to 2, so you may not need to restrict stolenmem.  Try commenting out DeviceProperty framebuffer-stolenmem (#framebuffer-stolenmem) and testing.

Edited January 19 by deeveedee
fixed typos

[verdazil]

36 minutes ago, deeveedee said:

Do you really need to patch your DMAR table?

There is an objective criterion.

If DMAR.ssdt contains line [Reserved Memory Region], then it needs a patch in some scenarios.

[Asural]

50 minutes ago, deeveedee said:

@Asural I haven't watched my CPU temps for a long time.  I find that the less I look, the fewer problems I find

 

If you post your unpatched DSDT, I'd be happy to take a look.  If you are seeing ACPI errors, then it's possible that the ACPI patches you copied from my HP 800 are not an exact match for your HP400.

 

EDIT: @Asural There are a couple of things in your SonomaTest.plist (also in your previous config.plist) that I'm not sure of:

• Do you really need to patch your DMAR table?  Your ACPI > Add > DMAR may not be working the way you think it is, because you are not dropping the original System DMAR.  You should be able to disable your ACPI > Add > Item 7 (DMAR)
• Do you really need DeviceProperty framebuffer-stolenmem?  You are restricting port count to 2, so you may not need to restrict stolenmem.  Try commenting out DeviceProperty framebuffer-stolenmem (#framebuffer-stolenmem) and testing.

 

 I will consider your opinion and look into it.
I had DMAR installed because the ACPI guide said it was necessary for BigSur, but I couldn't tell what the difference was when I tested it without it.

I will read the OpenCore specification more carefully.

When I disabled framebuffer-stolenmem, my CPU temperature rose from 70°C to 75°C.
The last time I was troubled by rising CPU temperatures was when the Kepler card was discontinued with Catalina, so I will review my UHD630 settings.

 

I have attached the DSDT for the HP400G5, so please let me know if you notice anything.
 

10 minutes ago, verdazil said:

There is an objective criterion.

If DMAR.ssdt contains line [Reserved Memory Region], then it needs a patch in some scenarios.

 

I checked DMAR.dsl but there was no [Reserved Memory Region]. Please check the attached file.
 

Results.zip

[deeveedee]

@Asural I will inspect your extracted ACPI and let you know if I have suggestions.  Test without ACPI > Add > DMAR.  You probably don't need it.  The increase in CPU temp without framebuffer-stolenmem doesn't make sense to me.  If your hack does not crash when booting without framebuffer-stolemem and you don't see any functional issues while using your hack without framebuffer-stolenmem, then you don't need it.

 

EDIT: @Asural You won't notice any difference when you disable your "ACPI > Add > DMAR" patch because you implemented it incorrectly (and because you probably don't need it).  In order to add you own DMAR table, you must drop the original System DMAR with "ACPI > Delete".  See here.  Again, I doubt you need to patch DMAR.  Test without it to confirm.

Edited January 19 by deeveedee

[deeveedee]

@Asural I inspected your DSDT and confirmed that my SSDT-AWAC-HPET-RTC.aml is correct for your HP 400:

• SSDT-AWAC-HPET-RTC.aml sets HPTE = 0.  This disables Device HPET (HPET._STA = 0). This means that you don't need any of the other HPET patches as I mentioned earlier.
  Spoiler

           Device (HPET)
              {
                  Name (_HID, EisaId ("PNP0103") /* HPET System Timer */)  // _HID: Hardware ID
                  Name (_UID, Zero)  // _UID: Unique ID
                  Name (BUF0, ResourceTemplate ()
                  {
                      Memory32Fixed (ReadWrite,
                          0xFED00000,         // Address Base
                          0x00000400,         // Address Length
                          _Y17)
                  })
                  Method (_STA, 0, NotSerialized)  // _STA: Status
                  {
                      If (HPTE)
                      {
                          Return (0x0F)
                      }
  
                      Return (Zero)
                  }

• SSDT-AWAC-HPET-RTC.aml sets STAS = 2.  This means that your original System RTC device is disabled (RTC._STA = 0):

  Spoiler

              Device (RTC)
              {
                  Name (_HID, EisaId ("PNP0B00") /* AT Real-Time Clock */)  // _HID: Hardware ID
                  Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
                  {
                      IO (Decode16,
                          0x0070,             // Range Minimum
                          0x0070,             // Range Maximum
                          0x01,               // Alignment
                          0x08,               // Length
                          )
                      IRQNoFlags ()
                          {8}
                  })
                  Method (_STA, 0, NotSerialized)  // _STA: Status
                  {
                      If ((STAS == One))
                      {
                          Return (0x0F)
                      }
                      Else
                      {
                          Return (Zero)
                      }
                  }
              }

 

•  It also means that your original System AWAC is disabled (AWAC._STA= 0):

  Spoiler

          Device (AWAC)
          {
              Name (_HID, "ACPI000E" /* Time and Alarm Device */)  // _HID: Hardware ID
              Name (WAST, Zero)
              Name (WTTR, Zero)
              Method (_PRW, 0, NotSerialized)  // _PRW: Power Resources for Wake
              {
                  Return (GPRW (0x72, 0x04))
              }
  
              Method (_STA, 0, NotSerialized)  // _STA: Status
              {
                  If ((STAS == Zero))
                  {
                      Return (0x0F)
                  }
                  Else
                  {
                      Return (Zero)
                  }
              }

   

Conclusion: SSDT-AWAC-HPET-RTC.aml that you copied from my HP 800 is correct for your HP 400.

 

 

EDIT:

1 hour ago, Asural said:

I had DMAR installed because the ACPI guide said it was necessary for BigSur, but I couldn't tell what the difference was when I tested it without it.

 

The ACPI guide that said patching DMAR was necessary for BigSur is wrong unless it was patching DMAR for a specific case.  As Verdazil said, there are specific cases (e.g., certain Ethernet cards) that may require a patched DMAR or disabled VT-d.  My HP 800 doesn't need patched DMAR, so I doubt your HP 400 needs patched DMAR.

Edited January 19 by deeveedee

[Max.1974]

On 1/19/2026 at 5:03 AM, Asural said:

 

I tried TG Pro, but it doesn't seem to work.
I also tried HWMonitorSMC2, but it doesn't have a temperature sensor.

 

 

I'm starting to think Clover is more convenient.
I am currently doing a clean install of my Sonoma with OpenCore.
 

 

@AsuralClover works like a charm for me. It’s easier to use and provides more kexts from the Clover GitHub for system monitoring. 

 

Try my compiler app by RehabMan. It’s only for system monitoring. 

 

https://github.com/maxpicelli/HWSensors-RehabMan-HWSensors-Modify/releases/tag/FakeSMC 

 

 

 

 

 

Download HWMonitor DMG

 

HWMonitor.dmg

Edited January 20 by Max.1974

[Max.1974]

@Asural This EFI has been well structured for your model.

You can try adapting the SSDTs or extracting its ACPI tables using Hackintool. 

 

EFI-Hackintosh-HP400-G5-main.zip

 

 

Edited January 20 by Max.1974