[solved] Mojave 10.14.1 update lost USB 3.0

[DimitrisG]

Can I ask something ?
After proper ssdt-usb we should remove usbinjectall.kext or leave it?

 

[RehabMan]

Can I ask something ?
After proper ssdt-usb we should remove usbinjectall.kext or leave it?

I assume you're referring to this guide and the resulting SSDT typically named SSDT-UIAC.aml:
https://www.tonymacx86.com/threads/guide-creating-a-custom-ssdt-for-usbinjectall-kext.211311/

Look at the title of the thread: "[Guide] Creating a Custom SSDT for USBInjectAll.kext"
(emphasis added)

Based on the thread title, what is your best guess?

And if you read the text, do you find anywhere the guide instructs to remove USBInjectAll.kext?

Note: Not trying to be grumpy here, just trying to get people to use the gray matter between their ears.

 

[chiefbeats]

I have rewritten that sentence in the guide. Hope you like it.

I found this in your original guide, which is exactly what I was saying above:
You can use USBInjectAll.kext to inject all ports possible for your USB controllers. With all ports injected, you can determine which ones are already used. There is also a patch available that can increase the port limit. Use only short term for determining which ports need to go into your port injector. Make sure you read the README for USBInjectAll.kext.

Whether it's used in your new guide is irrelevant. We clearly agree on this point, but you refuse to admit it.

That's fine, though. Your opinion about the patch doesn't change the fact the patch actually works, and the bootflag method is unnecessary while the patch is implemented. I bet you and FredWst are enemies!

Just when I thought we were starting to be friends....

 

[chiefbeats]

Can I ask something ?
After proper ssdt-usb we should remove usbinjectall.kext or leave it?

Leave it installed.

 

[RehabMan]

I found this in your original guide, which is exactly what I was saying above:
You can use USBInjectAll.kext to inject all ports possible for your USB controllers. With all ports injected, you can determine which ones are already used. There is also a patch available that can increase the port limit. Use only short term for determining which ports need to go into your port injector. Make sure you read the README for USBInjectAll.kext.

Whether it's used in your new guide is irrelevant. We clearly agree on this point, but you refuse to admit it.

Content of previous versions of the guide is not relevant.

I changed the guide to not depend on the patch because:
- got tired of chasing down (or creating it by disassembly analysis) the patch for each version
- got tired of people applying the wrong patch (eg. wrong version for the version of the system)
- got tired of people not placing the patch correctly in config.plist (I've seen it all)
- got tired of people stopping (not implementing SSDT-UIAC) after they realize the patch fixed their immediate problem (leading to other problems later)

Port limit patch: "good riddance."

That's fine, though. Your opinion about the patch doesn't change the fact the patch actually works, and the bootflag method is unnecessary while the patch is implemented. I bet you and FredWst are enemies!

If people want to use the port limit patch, they are free to do so.
After all, it is their computer, their prerogative.

But I cannot recommend it.

 

[chiefbeats]

Content of previous versions of the guide is not relevant.

I changed the guide to not depend on the patch because:
- got tired of chasing down (or creating it by disassembly analysis) the patch for each version
- got tired of people applying the wrong patch (eg. wrong version for the version of the system)
- got tired of people not placing the patch correctly in config.plist (I've seen it all)
- got tired of people stopping (not implementing SSDT-UIAC) after they realize the patch fixed their immediate problem (leading to other problems later)

Port limit patch: "good riddance."

I can understand that. It makes sense.

Was that list of issues you caught the only things that you identified as a problem? Care to check the debug folder I sent last night, please? I want to confirm I fixed the problems you listed as well as take care of any others that still do. Thanks again.

 

[RehabMan]

Was that list of issues you caught the only things that you identified as a problem? Care to check the debug folder I sent last night, please? I want to confirm I fixed the problems you listed as well as take care of any others that still do. Thanks again.

Looks like you fixed:
- GenericUSBXHCI is gone
- CPU PM implemented (X86PlatformPlugin now loaded)
- InjectKexts=Detect (but kexts not installed, see below)


Problems:
- now your ioreg shows two EC objects (this is obvious stuff... sticks out like a sore thumb when you look at ioreg). No doubt due to renaming EC0 *and* adding SSDT-EC. Those two things are mutually exclusive. You only use SSDT-EC if you don't already have a serviceable EC device.
- SATA-unsupported.kext still not installed
- kexts still not installed properly (expect to see FakeSMC.kext or VirtualSMC.kext and other kexts you need in kextcache output)
- why is AppleHDA.kext patched? (and you have realtekALC.kext?). Onboard audio not working anyway.... Typically, we are using AppleALC.kext now.
- HDAS should be renamed HDEF
- Plex Tuner still installed, still hooking onto USB stuff
- legacy XHC power properties not injected (use config.plist/Devices/USB/Inject=true)

 

[chiefbeats]

Few questions and comments to help solving these issues...

- now your ioreg shows two EC objects (this is obvious stuff... sticks out like a sore thumb when you look at ioreg). No doubt due to renaming EC0 *and* adding SSDT-EC. Those two things are mutually exclusive. You only use SSDT-EC if you don't already have a serviceable EC device.

I was getting unexpected results when following the guide. I removed it and will resubmit debug folder when everything is done.

- SATA-unsupported.kext still not installed

I'm confused by this as usually there is an actual kext. In this case, I only have the info.plist. I realize kexts contain this, but is it as simple as creating the contents folder (with .plist) and naming the folder SATA-unsupported.kext?

- kexts still not installed properly (expect to see FakeSMC.kext or VirtualSMC.kext and other kexts you need in kextcache output)

The current Mojave Install doesn't have any mention of the FakeSMC kexts, etc. I was under the impression this is no longer required.

- why is AppleHDA.kext patched? (and you have realtekALC.kext?). Onboard audio not working anyway.... Typically, we are using AppleALC.kext now.

This was a result of what I selected in Multibeast based on the audio card I have. 1220a I believe.

- HDAS should be renamed HDEF

Done.

- Plex Tuner still installed, still hooking onto USB stuff

- legacy XHC power properties not injected (use config.plist/Devices/USB/Inject=true)

Done.

 

[RehabMan]

I'm confused by this as usually there is an actual kext. In this case, I only have the info.plist. I realize kexts contain this, but is it as simple as creating the contents folder (with .plist) and naming the folder SATA-unsupported.kext?

Kexts are directories (some call them folders) that contain files.
A codeless kext is a kext with only an Info.plist (in the Contents sub-directory).
As per guide, you should download the repo ZIP, then use the kext that is in kexts (directory/folder).

The current Mojave Install doesn't have any mention of the FakeSMC kexts, etc. I was under the impression this is no longer required.

No idea where you got that impression.
You cannot boot macOS without some sort of SMC emulator (FakeSMC.kext or VirtualSMC.kext).
Currently, you're injecting one of them (from EFI/Clover/kexts), otherwise you would not be able to boot.

This was a result of what I selected in Multibeast based on the audio card I have. 1220a I believe.

On Mojave, we use AppleALC.kext.
Multibeast for Mojave has not been released yet, so you need to do such tasks without the help of Multibeast.

 

[spackley]

Few questions and comments to help solving these issues...



I was getting unexpected results when following the guide. I removed it and will resubmit debug folder when everything is done.



I'm confused by this as usually there is an actual kext. In this case, I only have the info.plist. I realize kexts contain this, but is it as simple as creating the contents folder (with .plist) and naming the folder SATA-unsupported.kext?



The current Mojave Install doesn't have any mention of the FakeSMC kexts, etc. I was under the impression this is no longer required.



This was a result of what I selected in Multibeast based on the audio card I have. 1220a I believe.



Done.





Done.

Without trying to upset anyone, any chance of explaining how you did it without boot flags. I have a Skylake H170-DS3H and I can't get it to work at all. It's down to my lack of knowledge/skills more than anything I'm sure, so a really simple idiot guide would be great. I'm sure I'm not the only one who would appreciate it.