Jump to content
37 posts in this topic

Recommended Posts

13 hours ago, Mirone said:

I have included version 1.0.1 in the link from the first post. I have also uploaded it to GitHub (the source code will be made available soon). This version includes a kext I developed called BlueWakeFixup, which fixes the issue where Bluetooth does not turn on after the PC wakes from sleep on some Wi-Fi adapters, such as my BCM4352. I hope it will be useful to some people.

Extract kext from patcher, works excellent with BCM4352.

 

One minor symptom, ater kext in OC 1.0.8 on Sequoia, my sleep/wake schedule which i cancell all and lock,  made my HP wakes to strange power events which does not exists before. That is the  same symptom as in your patched BlueToolFixup kext and -btlfxwakecrash boot arg.

  • Like 1

@notobo

You no longer need to use the patched version of BlueToolFixup or the boot argument -btlfxwakecrash. You can now use the standard BlueToolFixup without my wake-related fixes.

To fix the wake issue, simply use my BlueWakeFixup kext. No additional boot arguments or extra configuration are required.

  • Like 3
18 hours ago, Mirone said:

@notobo

You no longer need to use the patched version of BlueToolFixup or the boot argument -btlfxwakecrash. You can now use the standard BlueToolFixup without my wake-related fixes.

To fix the wake issue, simply use my BlueWakeFixup kext. No additional boot arguments or extra configuration are required.

You did not understand me. I was using only BlueWakeFixup kext in Sequoia and symptom was same when I used your old solution with boot arg and patched BlueToolFixup kext.

 

I made test in Ventura with  BlueWakeFixup kext and this symptom does not exists, it functions 100% safe. Ventura also had this problem with BT after wake which your kext finally fix. I will make further tests to see why Seqoia wake at random level approx. 2-3 hours.

 

Cheers on your work m8.

 

Edited by notobo
  • Like 2

Got around to testing it. My Asrock-Z690-PG-Riptide-hackintosh, Wi-Fi / BT: BCM94360 PCI-E adapter, Clover revision: 5172 (HEAD, commit 79c169ea9) / macOS 26.5.1 (25F80) worked fine.
 Great work @Mirone. 🤝

 

2026-06-2810_18_45.thumb.jpg.af354bae178e0efc1cc587cc923be8a8.jpg

2026-06-2809_52_46.thumb.jpg.f89f067eb1d17b41e4b47098db1c0199.jpg

Edited by MakAsrock
  • Like 4

After using Wi-Fi Patcher Pro, I experienced a kernel panic upon reboot. Booting from a USB drive with a backup EFI was successful, and flashing the EFI to the ESP partition restored normal boot. Your utility is somehow messing with the EFI.
As always, OCLP-Plus (Tahoe Patch Set)  worked great.

image.thumb.jpeg.0784add164fe39da1cd77b1dd9ba71e7.jpeg

OCLP-Plus_3.2.2_2026-06-30_07-36-23-787102.log

Edited by MakAsrock
18 minutes ago, LockDown said:

What was the KP @MakAsrock

The kernel panic log was not saved because it occurred before the main kernel boot started (Immediately at the partition selection stage). 
Asrock-Z690-PG-Riptide-hackintosh all final EFI folders are located here.
I am using the latest version of CloverBootloader.

Edited by MakAsrock
  • Like 1

Is it not possible to improve the EFI check algorithm, taking into account the fact that cookies can be in the correct folder (26), and not in the common one (Other)?
Due to KP, there were 3 extra kexts: AMFIPass.kext, IO80211FamilyLegacy.kext and IOSkywalkFamily.kext, which were already mistakenly placed in the folder "Other", although they were already in folder 26 at the address: EFI/CLOVER/kexts 😉

Edited by MakAsrock
×
×
  • Create New...