Contribute
Register

CustoMac Desktop USB Fixes - 10.11+ Reference

So how is my Audio working? it works after updates OOB also.

Either InjectKexts=Yes, or FakeSMC.kext is not in kernel cache. Or you have the patched AppleHDA files installed to the system volume. Or you're using ForceKextsToLoad.

It is bit off-topic at this point, but if you want analysis regarding what you're actually doing...

Attach ioreg as ZIP: http://www.tonymacx86.com/audio/58368-guide-how-make-copy-ioreg.html. Please, use the IORegistryExplorer v2.1 attached to the post! DO NOT reply with an ioreg from any other version of IORegistryExplorer.app.

Provide output (in Terminal):
Code:
kextstat|grep -y acpiplat
kextstat|grep -y appleintelcpu
kextstat|grep -y applelpc
kextstat|grep -y applehda

Attach EFI/Clover folder as ZIP (press F4 at main Clover screen before collecting). Please eliminate 'themes' directory. Provide only EFI/Clover, not the entire EFI folder.

Attach output of (in Terminal):
Code:
sudo touch /System/Library/Extensions && sudo kextcache -u /

Compress all files as ZIP. Do not use external links. Attach all files using site attachments only.
 
I wrote "from".



The patches you have are still wrong. It is clear you're not using a plist editor.

I'd copied and pasted the text directly into the xml pairs in Plist Editor Pro. Didn't realise I could copy and paste as children directly from config_patches.plist.

All sort now. Thank you for your help RehabMan.

I have an IOGEAR USB Bluetooth adapter that has never worked since upgrading to 10.11.* on any USB port. Is this likely related?
 
I have an IOGEAR USB Bluetooth adapter that has never worked since upgrading to 10.11.* on any USB port. Is this likely related?

If the port is working with other devices, and the device is detected (look at ioreg or System Information->USB), then the problem is a device specific one, not a USB problem.

Does the device need a firmware uploader? Did you install one? (BrcmPatchRAM has support for many Broadcom BT devices).
 
My mastake RehabMan. I do indeed have inject kext set to yes not detect. Couldn't remember as I haven't been in my config since god knows how long I guess it's set to yes for the purpose of Clover Audio Injection. Kexts are in L/E removed them from S/L/E and FakeSMC and ALXEthernet is in both L/E and 10.11. Realtek ALC is in 10.11 I'd rather leave it in there because after updates my audio still works without having to boot without cache. If I'm correct in saying kexts isn't cached in EFI/Clover/kexts/10.11 like they are in L/E & S/L/E

my machine just works without any problems what ever have been since 10.8.2 lol.
 
I do indeed have inject kext set to yes not detect.

..
Kexts are in L/E removed them from S/L/E and FakeSMC and ALXEthernet is in both L/E and 10.11.

That is a bad combination. It causes kexts which are already in kernel cache to *also* be injected. So... you end up with two FakeSMC.kext and ALXEthernet.kext, potentially different versions.

The correct configuration:
- InjectKexts=Detect
- all kexts you need installed to the system volume (/L/E or /S/L/E, your choice on 10.11; /S/L/E only on other versions)
- essential kexts in EFI/Clover/kexts (your choice on version specific directory[10.11] or 'Other').

Realtek ALC is in 10.11 I'd rather leave it in there because after updates my audio still works without having to boot without cache.

If you want to do it that way:
- InjectKexts=Detect
- all kexts you need installed to the system volume, except RealtekALC
- realtekALC.kext named in KernelAndKextPatches/ForceKextsToLoad (installed to some directory on the system volume, for example in /ForcedKexts). Note: ForceKextsToLoad uses backslashes, so to force a kext named realtekALC, the ForceKextsToLoad entry would be: \ForcedKexts\realtekALC.kext.
- essential kexts in EFI/Clover/kexts

How it should work (not tested):
- When booting recovery and the installer, since FakeSMC isn't in cache, EFI kexts will be injected. So will realtekALC.kext. I wouldn't want to inject the audio kext when booting the installer or recovery, but you're already doing that now, so no change...
- When booting your system partition, since FakeSMC is in the cache, EFI kexts are not injected. But realtekALC.kext is since it is listed in ForceKextsToLoad.
 
I did a little test awhile ago. I removed FakeSMC.kext and ALXEthernet.kext from L/E and just had them in EFI/Clover/kexts/10.11 just have inject kexts to Yes and I could boot without any issues I don't believe it's got to be in L/E or S/L/E because if they have to he then why would it boot into OS X normally with just FakeSMC in EFI not L/E?
 
Here are those files you've requested Rehab Man I'm pretty sure there isn't duplicates of FakeSMC & AlXEthernet.kext
 

Attachments

  • Jack’s iMac.ioreg
    4.6 MB · Views: 191
  • kextstat.txt
    1.2 KB · Views: 202
  • Terminal Saved Output.txt
    1.9 KB · Views: 211
  • EFI.zip
    21.3 MB · Views: 102
I'm pretty sure there isn't duplicates of FakeSMC & AlXEthernet.kext

You're injecting duplicates of the following kexts:
LPCSensors.kext
GPUSensors.kext
CPUSensors.kext
ACPISensors.kext
FakeSMC.kext
ALXEthernet.kext

Why do I say that?

You have InjectKexts=Yes, these kexts all exist in EFI/Clover/kexts/10.11, and they are also installed to the system volume and included in kernel cache as shown by your kextcache output.

Resulting kernel image is injected kexts + kernel cache since that is what you have asked Clover to do.
 
If that's the case. Then I'll remove them from from L/E because the machine will boot fine and work fine with FakeSMC and ALXEthernet in just EFI. By any chance did you happen to look at USB in ioreg?
 
If that's the case. Then I'll remove them from from L/E because the machine will boot fine and work fine with FakeSMC and ALXEthernet in just EFI.

Not very "native". Your choice.

By any chance did you happen to look at USB in ioreg?

What would I be looking for?
 
Back
Top