All Activity

@Lost-Entrepreneur439 You might get more responses if you post your EFI (and if you can't upload it because of its size, post a link to it). Note that some offered assistance to you in your previous thread here and you never responded. Good luck.

Thats Great

Hi everyone, I've discovered a potential workaround for the long-standing shutdown issue on the Dell Inspiron 1520 (ICH8M + NVIDIA GPU). It appears that a substantial delay (sleep) is required for the system to shut down properly. By disabling SMI generation (writing 0 to SLP_SMI_EN) followed by a long sleep command—specifically Sleep(0xFFFF) or at least Sleep(0x2710)—I successfully managed to shut down the system on macOS 10.4 to 10.7, as well as Ventura (13), Sonoma (14), and Sequoia (15). Short delays like Sleep(0x10) or Sleep(0x16) invariably fail. Example 1: Standard Sleep Method OperationRegion (PMRS, SystemIO, 0x1030, One) Field (PMRS, ByteAcc, NoLock, Preserve) { , 4, SLPE, 1 } Method (_PTS, 1, NotSerialized) { If (LEqual (Arg0, 0x05)) { Store (Zero, SLPE) Sleep (0x2710) // 10sec // or // Sleep (0x2710) // 10sec // Sleep (0x2710) // 10sec total 20sec // or // Sleep (0x2710) // 10sec // Sleep (0x2710) // 10sec // Sleep (0x24B8) // 9.4sec total 29.4sec [Recommended] // or // Sleep (0xFFFF) // 65.5sec } } Behavior by macOS version (Example 1): 10.4 – 10.7: Mostly successful. However, it takes about 30 seconds to 1 minute for the machine to power off after the display goes black. (Note: 10.4 has NVDAResman disabled and shuts down normally even without the SLPE method). 10.8 – 10.10: Unstable. It sometimes succeeds, but often results in a black screen with fans spinning continuously or triggers a system reboot. 10.11 – 10.12: Always results in a reboot. 10.13 – macOS 12: The screen goes black, but the fans keep spinning indefinitely. 13 – 15: Mostly successful, though reboots still occur occasionally. Example 2: Stall Method (Higher Success Rate) There is an alternative method with a significantly higher success rate using Stall: Method (_PTS, 1, NotSerialized) { If (LEqual (Arg0, 0x05)) { Store (Zero, SLPE) Local0 = 0x4268 While ((Local0 > Zero)) { Local0-- Stall (0x64) } } } Behavior by macOS version (Example 2): 10.4: NVDAResman disabled; shuts down fine without this method. 10.5 – 10.7: Mostly successful, but takes 30 seconds to 1 minute to power off after the screen goes dark. 10.8 – 10.10: Unstable. Mostly results in a black screen with running fans or a reboot. 10.11 – 10.12: Results in a black screen with running fans or a reboot. 10.13 – macOS 12: Screen turns off, but fans spin indefinitely. 13 – 15: 100% successful. Furthermore, the system shuts down in less than 10 seconds. Example 3: While Loop + Short Sleep Method I also tested another approach using a While loop with shorter sleep increments: Method (_PTS, 1, NotSerialized) { If (LEqual (Arg0, 0x05)) { Store (Zero, SLPE) Local0 = 0x2710 While ((Local0 > Zero)) { Local0-- Sleep (0x10) } } } Behavior by macOS version (Example 3): 10.4: Works fine without this method (NVDAResman disabled). 10.5 – 10.6: Mostly successful, but takes 30 seconds to 1 minute to power off after the screen goes dark. 10.7: Unstable. Mostly results in a black screen with running fans or a reboot. 10.8 – 15: Always results in a reboot. Observations & Analysis It remains unclear why the success rate is high on very old and very new macOS versions, yet highly unstable on mid-generation OS versions. Additionally, the fact that the hardware takes about 30 seconds to a minute to complete the shutdown sequence suggests that it requires a significantly longer preparation time to power off compared to other machines of the same generation. This is almost certainly due to a firmware bug. While this is an unconventional workaround, it is encouraging to find a viable method for these models, which were previously thought to have no consistent solution for their shutdown issues. This fix might also apply to the following models: Inspiron 1420 / 1520 / 1720 Vostro 1400 / 1500 / 1700 XPS M1330 (Note: Rebooting on these models is also unstable—sometimes working, sometimes failing—which likely stems from the same root cause). What I've Tested So Far: USB Power: Investigated USB power behavior, but it doesn't seem to be the culprit. OSID: Tested with 0x10 (Windows XP) and 0x20 (Windows Vista), but saw no significant change. BIOS Settings: Disabled LAN, Wi-Fi, Bluetooth, SDHC, and the module bay in the BIOS, but the issue persists. For context, this older thread might be relevant: https://www.insanelymac.com/forum/topic/266803-dsdt-shutdown-nvidia-dells-not-zero-slpe-trick-alternate-ich8-method/ If anyone has any insights, suggestions, or ideas for a more fundamental/cleaner fix, I would love to hear them. Any feedback is highly appreciated!

Great to see you work hard for new versions. I did again test on my AMD RX560 (mobile RX 560 in MacBook Pro. Never had probs since first version, now on v .42. I did add that extra option text for RX 560/580 you recommend. 1,5 / 50.2 Will do bench later today also with my RX 5600XT and v .42 ToshLLM benchmark · 2026-06-27T08:05:29Z === model: Qwen3-4B-Q4_K_M.gguf GPU: AMD Radeon Pro 560X engine: bundled · K:f16 V:f16 FA: AMD Flash Attention (GPU) args: -m /Users/andreas/models/Qwen3-4B-Q4_K_M.gguf -ngl 99 --mmap 0 -r 2 -fa 1 ========================= ggml_metal_device_init: probed SIMD-group width = 64 ggml_metal: probed SIMD-group width = 64 (32 = Apple/AMD RDNA, 64 = AMD GCN/Vega) ggml_metal: wave64 safe mode ON (SIMD width 64, non-Apple GPU): simdgroup fast paths disabled for correct output ggml_metal_device_init: tensor API disabled for pre-M5 and pre-A19 devices ggml_metal_library_init: using embedded metal library ggml_metal_library_init: loaded precompiled '/Applications/ToshLLM.app/Contents/Resources/bin/default.metallib' ggml_metal_library_init: loaded in 0.013 sec ggml_metal_rsets_init: creating a residency set collection (keep_alive = 180 s) ggml_metal_device_init: GPU name: MTL0 (AMD Radeon Pro 560X) ggml_metal_device_init: GPU family: MTLGPUFamilyCommon3 (3003) ggml_metal_device_init: simdgroup reduction = false ggml_metal_device_init: simdgroup matrix mul. = false ggml_metal_device_init: has unified memory = false ggml_metal_device_init: has bfloat = false ggml_metal_device_init: has tensor = false ggml_metal_device_init: use residency sets = true ggml_metal_device_init: use shared buffers = false ggml_metal_device_init: recommendedMaxWorkingSetSize = 4294.97 MB

Update: Using some bits from a goldfish64 EFI on GitHub, I managed to get acceleration on Sierra, however High Sierra just gives me a black screen after verbose once it's installed (the recovery works fine, however).

To any who have been following this thread and who have hopefully benefited from it... now that macOS 27 is announced and the Beta is available, I have switched my hackintosh focus from tinkering and experimentation to maintaining productive usability of existing hackintosh systems. The fact that our HP EliteDesk 800 G4/G5 Minis are running Tahoe as well as they do is amazing and very satisfying to me. I won't be purchasing any more Intel-based hardware for hackintoshing and I look forward to my first Apple Silicon purchase next year in 2027 (a good used system). If you have any requests for improvements that make our hacks more useful, please don't hesitate to post them here.

@chris1111 Wow! Thanks, you’ll make me work once more on the project 😂

thanks for the info brother. If set to zero, it'l fallback to old function aka traditional?

Hi @miliuco Thank you for your effort! It is possible to add latest seven major OS's in Display GenericLCD see spoiler ive create 7 GenericLCD Attach file PNG Archive.zip Looks good on the App

Auto detect will be zero.

Uowwwww Congrats my friend !

Update Audio image, thanks to @chris1111 https://github.com/perez987/About-This-Hack/releases/tag/4.3.6

@Slice <key>LayoutId</key> <integer>80</integer> of all IDs, why 80? does it represent yours or auto detect?

Yes, I am aware this is a terrible GPU and I should get something else, but I like having my computers with their stock hardware. I recently got an OptiPlex 780 with a Radeon HD 5450, Dortania's GPU Buyers Guide says the 5450 is supported natively, but when I installed HS, no acceleration at all, GPU just came up as "Display 5 MB", display was stuck at 1024x768, tearing and no transparency. I did some Googling, and things about this card seem to be very mixed, some people say it works natively, other people say you need to bring back kexts from Sierra, some say you need spoofing, others just say you need to go back to Sierra. Can someone please give me clear info about this card? If I need to replace kexts or do root patching in any form, then I'd rather not; I'd rather just go back to the last version with native support. Device ID is 68F9.

@MaLd0n, I finally tested Prime26 under macOS 27 on my MacBook Pro M1 as well. While the CPU temperatures appear to be far too high (around 50–60°C at idle and 115°C under load), the GPU temperature remains fixed at exactly 102°C, both at idle and under load, and only occasionally jumps to exactly 112°C or 76°C for a few seconds. It would be great if you could revise the Apple silicon temperature reporting so that the CPU and GPU temperatures are displayed correctly in Prime26. Everything else works flawlessly.

@notobo Thank you for your testing and feedback!

You could do it, too! I am sure!

Updated Unknown imageset, thanks to @chris1111 https://github.com/perez987/About-This-Hack/releases/tag/4.3.5

@kgp Sorry, I was thinking about Intel hack. With real Macs (Intel or Silicon) audio info is different to be collected. This is the reason why About This Hack doesn't have audio tab, it was a complicated thing for me. @MaLd0n can do it, sure.

@miliuco, neither USB nor Thunderbolt. It’s just the built-in native audio of my MacBook Pro M1. Since Apple silicon Macs don’t use AppleALC or VoodooHDA, perhaps Mac-Info or About This Hack could also recognize the native Apple audio implementation in the future. The same applies to the network interface, which could also be added to About This Hack. @MaLd0n could also use the more general term "Bootloader" instead of specifically showing "OpenCore/Clover version".

Ok, thanks!

@kgp Are you using audio by USB or Thunderbolt? @MaLd0n 's app says "HDMI/DP/GPU is ignored", maybe he can add "HDMI/DP/GPU/USB/TB is ignored" since the app looks only for AppleALC or VoodooHDA audio.

Device trees and the like are very widely used with Arm devices. The Arm ecosystem is not homogenized into a set of standards like x86 systems are - you see a lot more variety in firmware, boot loaders, hardware, peripherals, etc. I doubt any of this has been purposely done to prevent hackintoshes. We are just seeing the side affects of them having custom silicon and having their own security requirements with regards to their boot chain. Remember too that they've been using ##### and their own silicon as far back as some of their earliest iPhones - bootloaders like u-boot were nowhere near as fleshed out back then than as they are now. You also see a lot of proprietary bootloaders afaik with android devices too. M1n1 was created by Asahi for what it is worth heh. You are probably thinking of #####. Edit: #####/i boot is getting censored? Huh? https://en.wikipedia.org/wiki/##### I'm not talking about anything related to tonymac or their tools, I'm trying to talk about Apple's bootloader ;-;

Now need add things for silicon 🙂 I'll check it soon.