troorl

I'm not sure how this works, but I solved it by loading Ubuntu. Bluetooth was available in it, and after rebooting to macOS it showed up in USBMap under HS08. I think it might be some soft airplane mode that was turned on but couldn't be turned off in macOS itself. And then Ubuntu reset it. I don't know, just a theory. Unfortunately I discovered another unrelated issue. When the laptop is charging, the trackpad is practically unusable. Oh well...

Yes, I've done all that, following the guide. With USBInjectAll and xhciportlimit=true, Bluetooth doesn't show up anywhere, including the USB section in the System Report. Just checked with Hackintool to be sure, no luck. Initially I used a different pack with an older OC, and at first Bluetooth worked (or at least it was detected). Then after one of the countless iterations it just disappeared. Interestingly enough, when I return to that exact pack, Bluetooth still doesn't work. And of course it's enabled in BIOS, I checked. It feels like some kind of magic is involved. I used to experience something similar on E6430, specifically with Bluetooth.

Hi. It's my first experience with this laptop. I'm using the default Intel combo card with Jake Lo's E7x70 pack. WiFi works well, but Bluetooth is not detected at all, despite all the right kexts in place. I mapped USB ports using USBMap. The number of ports is limited now, everything works including the webcam. Yet there is no sign of Bluetooth. It didn't show up in USBMap at any point. I'm using Big Sur and the latest BIOS if it makes a difference. Does someone have any ideas? The list of the kexts and config.plist are down below. AirportBrcmFixup.kext SMCBatteryManager.kext AirportItlwm.kext SMCDellSensors.kext AppleALC.kext SMCLightSensor.kext BrcmBluetoothInjector.kext SMCProcessor.kext BrcmFirmwareData.kext SMCSuperIO.kext BrcmPatchRAM3.kext Sinetek-rtsx.kext BrightnessKeys.kext USBMap.kext IntelBluetoothFirmware.kext VerbStub.kext IntelBluetoothInjector.kext VirtualSMC.kext IntelMausi.kext VoodooPS2Controller.kext Lilu.kext WhateverGreen.kext NVMeFix.kext config.plist.zip

I understand that. It just was the DSDT I started with.

Okay, so I went on a bit of a journey and by the process of elimination established that the issue must be in Hervé's DSDT. It's the only thing that is consistently present when the system fails to wake up properly. Or, more precisely, it's a combination of that DSDT and something else. I ended up using Jake Lo's setup with OC 0.6.2, which for some reason I had to edit manually, because ProperTree always yielded an unbootable config. I added a few things there, completely replaced the kexts because I couldn't get bluetooth working. And I updated my BIOS to A24. Finally everything seems to work and be stable. The only little annoying thing is that Fn+Up/Down is a bit glitchy, but I couldn't care less about that. Here is the end result, I hope it will help someone. OC_E6430_A24_DW1510_1366×768_i5-3320M.zip

Sure, I don't use it anymore. The problem remains though. That DSDT with a PNLF section in it is perfect in terms of stability, and the only thing it lacks is a proper brightness level. Same DSDT without a PNLF section combined with different SSDT-PNLF's gets the brightness right, but is inconsistent in terms of waking up. Either this or that.

Thank you! Perhaps I copied a wrong file. Brightness level certainly got adequate, but there is the same problem as with AppleBacklightInjector.kext: it fails to wake up sometimes. In particular, it never wakes up properly when HDMI is plugged in, always shows black screen with nothing going on (the second screen is also black and unresponsive). The files I posted above didn't have such a problem, I checked it rigorously many times. I wonder, what can be the issue here.

Here. OC.zip

Hi. The problem is that the lowest brightness level is too high. It's adjustable and the controls work fine, but it's just too bright. In Mojave and Clover I used AppleBacklightInjector.kext to solve it. It still works and lowers the minimum brightness, but together with Whatevergreen.kext it causes instability and sometimes prevents the system from waking up. Also overall performance degrades for some reason. So I had to get rid of it. Can't find any viable alternative. I'm using Big Sur, Opencore and SSDT-PNLF provided on Whatevergreen github (although I'm not sure if I'm supposed to modify it; tried both GFX0 and IGPU). I also tried to delete the PNLF section from Hervé's DSDT, didn't help.

I'm using the same DSDT on E6430, and VoodooPS2Controller worked, but poorly. I switched to the attached version, feel free to try it. VoodooPS2Controller-R6B6.kext.zip

It works! Very appreciated, it was almost the last thing that I struggled with. Interestingly enough, the system treats the partitions on that drive as removable.

Thanks for the suggestion, but unfortunately it didn't work for me. I'm actually not sure which of my two drives is in the caddy. It may be the current one.

Thanks, but from what I understand, it simply hides the drive from the system. My drive is perfectly functional and I want to use it. It's located in the caddy, I forgot to mention.

Hi. I've had this exact problem with Mojave, and back then it was enough to replace AppleAHCIPort.kext. This time around I followed the Opencore guide and injected the patched CtlnaAHCIPort.kext (after blocking the original kext in the Kernel section). The kext is loaded, but the problem remains. Does anyone know how to deal with it?

Yay thank! It worked out perfectly! I was serious when I said that I had no clue what I was doing