Squall

Yes, I did try that, and I went quite deep into it. I worked through the ACPI and EFI side, dumped the relevant addresses with different tools, checked the drivers, and looked at the address tables to see whether I could patch or override the thermal behavior there. So the usual PROCHOT / ACPI / EFI path was definitely part of the process and not something I skipped. From what I found, though, that was not the real blocker. The actual problem seems to sit deeper in the platform. The temperature sensor path appears to be handled through the embedded controller, most likely over SPI/eSPI, which means the important logic is not really exposed in a way that can be cleanly patched through EFI or ACPI alone. I could inspect parts of the firmware-facing side, but I had no real access to the controller logic that actually handles the sensor behavior and triggers the throttling response. I was able to confirm the sensor behavior under Windows with a sensor tool. That tool even offers a slower protocol mode, and when I warmed up the area slightly, I could clearly see the temperature rising there. So the sensor itself was definitely reacting. The interesting part was that it did not behave the same way under Windows as it did under macOS. Under Windows, the whole system was much more usable, and the thermal reaction kicked in noticeably later. Under macOS, the throttling was far more aggressive and started too early, which is why I believe Windows is applying a different thermal policy or handling the controller path differently. If that same behavior could be reproduced under macOS, the device would probably be fine. I also tested this across three different mainboards and saw the same pattern every time, so it was not just a one-off faulty board. I tried a hardware-side fix for the sensor as well, but that did not solve it reliably, especially once the case was closed again. I also looked into solving it in software, but without proper access to the embedded controller or its command set, there was no safe or reliable way to change the reported values or the thermal thresholds. So yes, I tried the EFI / ACPI / driver route. I tried reading and analyzing the relevant addresses and tables. I verified the sensor behavior under Windows. I tested multiple boards. I even tried a hardware fix. In the end, the real limitation was that the decisive thermal behavior seems to be controlled behind the embedded controller, and without access to that layer, I could not properly solve it. That is why I eventually shelved the project. It was not because macOS itself would not run. It was because the thermal path was being handled in a way I could analyze to a point, but not truly control.

I agree with you that voltage shifting is probably the best way to handle it. That said, in my case the problem went beyond what was practical. I actually got macOS running, but the real issue was thermal behavior. The heat pipe runs from the fan toward the CPU, and there is a small exposed section of the motherboard in that area. Right underneath sits the temperature sensor. That sensor seems to get affected so heavily that the system constantly reports overheating to the motherboard microcontrollers, which then immediately throttles the device hard. So yes, it works, but only to the point where using it stops being enjoyable. On Windows, the same hardware performs much better because the thermal response kicks in around 10 to 12°C later. If that same behavior could be achieved under macOS, the device would actually run very well. I tested this on three different mainboards and saw the exact same issue on all of them, so at least in my case it was not just a one-off board defect. I also tried a hardware fix for the sensor, but once the case was closed, the problem came back. I looked into solving it in software as well, but without access to the board’s microcontroller, that was basically a dead end. Disabling the sensor entirely would have been another option, but that was simply too risky. So in the end, I put the project aside. It is not that macOS itself was the problem. The main issue was a temperature sensor that reacts too quickly or too aggressively. If someone finds a reliable way to handle that under macOS, the project has real potential. In my case, though, it just was not worth pushing further.

Subject: Possible Solution for CPU Throttling to 400MHz on Dell Latitude Hello, I am writing this because I saw your post from October 2024 describing a CPU power management issue, and I believe I had the exact same problem with my Dell Latitude 7210 2-in-1 (i5-10310U). I have finally found a solution, and I wanted to share it in the hope that it might help you too. The Problem I Had: My CPU would immediately drop to 0.4 GHz (400 MHz) the moment macOS started to boot. The system would become almost completely unresponsive. If I waited long enough for the CPU "request" to drop, the frequency would slowly recover, but as soon as any load was applied, it would throttle down again. No amount of SSDT patching or config.plist changes could fix this core issue. The Solution: After extensive testing, I discovered the cause was related to the battery and its management system. By simply physically disconnecting the internal battery, all my power management problems were instantly solved. After disconnecting the battery and running only on AC power: * The CPU no longer drops to 400 MHz at boot. * Intel Turbo Boost now works correctly, reaching its full potential. * The system is stable and performs as expected, even though it runs a bit warmer now (around 60°C+ under load), which is normal for proper performance. How I Found This: I ran Intel Power Gadget and the system Console log simultaneously to capture the exact moment the failure occurred. I saw a "Plochfehler" (which I believe might be related to IOPlatformPlugin or power plane errors). This led me to research causes outside of the typical Hackintosh configuration, such as faulty power adapters and battery management issues. Testing without the battery confirmed the source of the problem. How You Can Test This: If you still have this issue, I highly recommend you try this as a diagnostic step: * Power off your device completely. * Unplug the AC adapter. * Carefully open the bottom case of your laptop. * Disconnect the battery connector from the motherboard. * Close the case (or leave it open for testing), plug in the AC adapter, and boot up. If your system suddenly works perfectly, then you know the issue lies with the battery hardware or how macOS is interacting with its power management controller. This might mean the battery needs replacing or that a more specific ACPI patch is required to handle battery status correctly, but at least you will have identified the root cause. I truly hope this helps you finally enjoy your device. It was a very frustrating problem, and I wanted to make sure nobody else had to give up on it. Best of luck!