[solved] Mojave 10.14.1 update lost USB 3.0

chiefbeats · Nov 8, 2018

RehabMan said:
Of course there is. If you had read my guide, you would know how.
But why would you modify a system kext when you can do it from outside?
A modified system kext will need to be modified after each update....

I was trying to consider an alternative to the SSDT method since I was having a problem that didn't exist before it. I read your guide, but maybe I don't understand everything to a level to say I recall or know how to accomplish it.

RehabMan said:
No head butting there.

RehabMan said:
Suggestion: Understand fully before criticizing methods that others have worked to produce.

I don't know why you would think I'm criticizing you. Nobody criticized anyone here. I think your beef is with kgp, not me. I never criticized your method. Honestly, if I have to criticize something, I've seen a lot of your responses to people in need of help, and you're very passive and dismissive. I don't get the same vibe from other users that help people on here (failing to recall their names - pastrychef?). I get it. You're probably trying to get people to learn for themselves, etc. I am trying to understand your guide and implement it, but it isn't exactly "USBInJectAll for Dummies." I think you need to take a step back and remember there was a time you didn't know all this either. Don't forget where you came from. Again, I never criticized your method, I simply asked if there were alternatives because you don't describe any other methods besides using the kext and SSDT patch, and that method has caused a few issues that didn't exist before. I've read both your guides and the USBInjectAll.kext readme, and there is conflicting information. Giving credit where credit it due, I think what you, and everyone else, are doing is absolutely amazing. I'm simply asking questions out of curiosity and the passion of doing this stuff. From one geek to another, thank you.

RehabMan said:
What are you referring to?

I'm referring to the port numbers, HS01, SS01 etc. showing up in IOregistry properly.

RehabMan said:
What kind of trackpad?

Apple Magic Trackpad

RehabMan said:
What, specifically, is different?

Differences were described underneath the statement above.

RehabMan said:
You probably have other mistakes. For example, just from looking at your ioreg:
- USB power properties not implemented (not new USBX ones, not legacy either)
- GenericUSBXHCI not recommended (it is buggy and no one is maintaining it)
- Plex Tuner and Chrome hooking various USB ports for some reason...
- forgot SATA-unsupported.kext (for your Intel SATA controller that is missing entries in AppleAHCIPort.kext Info.plist)
- CPU PM not implemented (you need config.plist/ACPI/SSDT/Generate/PluginType=true)
- config.plist/SystemParameters/InjectKexts should be set "Detect"... all "kexts you need" installed to /L/E
- note kextcache output shows clear problem with mismatch between AirportBrcmFixup.kext and Lilu.kext
- also kextcache output shows USBInjectAll.kext not properly installed

I agree. I'm sure there are other problems. This is great information! Now we're getting somewhere as this is the second time I've submitted my "problem report" files. I understand you're not obligated to help, but it's greatly appreciated. For my better understanding, how would I know these issues exist? What files or application are you using to identify these issues?

RehabMan · Nov 8, 2018

chiefbeats said:
I think your beef is with kgp, not me.

I have no "beef" with kgp.

simply asked if there were alternatives because you don't describe any other methods besides using the kext and SSDT patch,

When your ACPI is broken (as is common), somehow you must inject the valid ports.
Apple does the same thing (its computers have broken ACPI too).
Two ways:
- USBInjectAll.kext with custom SSDT
- USB port injector kext

Both do the same thing: Inject a "ports" dictionary with valid ports.

Obviously, you could also fix ACPI. But that is much more difficult, and even Apple decided not to.

I've read both your guides and the USBInjectAll.kext readme, and there is conflicting information.

You will need to provide specifics. No possibility to guess what you're referring to.

Apple Magic Trackpad

I don't have one.
Isn't that bluetooth?

chiefbeats · Nov 8, 2018

RehabMan said:
I have no "beef" with kgp.

As long as you know I'm not criticizing you. I don't know how you came to that assumption.

RehabMan said:
When your ACPI is broken (as is common), somehow you must inject the valid ports.
Apple does the same thing (its computers have broken ACPI too).
Two ways:
- USBInjectAll.kext with custom SSDT
- USB port injector kext

Are the port injector instructions included with your custom SSDT guide? Every time I've read it, I feel it takes me down the path of using the SSDT in conjunction with the USBInjectAll.kext.

RehabMan said:
Both do the same thing: Inject a "ports" dictionary with valid ports.

Which system kext would I edit?

RehabMan said:
You will need to provide specifics. No possibility to guess what you're referring to.

One thing off the top of my head is explaining the USBInjectAll.kext is temporarily used to inject all ports to generate the custom SSDT. I believe that's how its explained in the kext readme file. I'm saying this off the top of my head (not able to verify at the moment). There's a possibility I'm completely wrong.

RehabMan said:
I don't have one.
Isn't that bluetooth?

Yes, but the bluetooth is powered/run off of USB. My HS07 to be exact. When I exclude that port, the trackpad goes down.

RehabMan · Nov 8, 2018

chiefbeats said:
Are the port injector instructions included with your custom SSDT guide?

Ports are injected with USBInjectAll.kext, configuration determined by SSDT-UIAC.aml.

Every time I've read it, I feel it takes me down the path of using the SSDT in conjunction with the USBInjectAll.kext.

As you should expect. That's what the guide is for. Implied quite clearly by the title of the thread, I think.

Which system kext would I edit?

I would not recommend editing system kexts.
But you can read about the kexts involved here:
https://www.tonymacx86.com/threads/guide-10-11-usb-changes-and-solutions.173616/

One thing off the top of my head is explaining the USBInjectAll.kext is temporarily used to inject all ports to generate the custom SSDT.

USBInjectAll.kext is not temporary.
The SSDT-UIAC.aml provides configuration data for USBInjectAll.kext.

From the README, seems quite clear:

Without a custom configuration, it is not intended that this kext be used long term. It is best to create a custom injector containing only the ports that are active on the target machine, or to create an SSDT that customizes the port injection done by USBInjectAll.kext. Customizing USBInjectAll.kext with an SSDT is covered later in this README.

Yes, but the bluetooth is powered/run off of USB. My HS07 to be exact. When I exclude that port, the trackpad goes down.

I'm guessing your trackpad/BT problems are caused by other issues.

chiefbeats · Nov 8, 2018

RehabMan said:
Ports are injected with USBInjectAll.kext, configuration determined by SSDT-UIAC.aml.

As you should expect. That's what the guide is for. Implied quite clearly by the title of the thread, I think.

My comment regarding the readme below clears this up.

RehabMan said:
USBInjectAll.kext is not temporary.
The SSDT-UIAC.aml provides configuration data for USBInjectAll.kext.

From the README, seems quite clear:

From the readme Without a custom configuration, it is not intended that this kext be used long term. It is best to create a custom injector containing only the ports that are active on the target machine, or to create an SSDT that customizes the port injection done by USBInjectAll.kext. Customizing USBInjectAll.kext with an SSDT is covered later in this README.

I think I understand what you are trying to say now, but it reads as if you are differentiating between two different methods. Create a custom injector sounds as if you are referring to some other injector, not USBInjectAll.kext...right? If you're referring to USBInjectAll.kext, I think you could have said, "It is not intended that this kext/port injector be used long term without custom configuration using an SSDT. It is best to create a custom injector, USBInjectAll.kext in this case, containing only the ports that are active on the target machine. We accomplish this by using USBInjectAll.kext (port injector) and customizing its injection by creating an SSDT.

Maybe something to consider in the future when writing guides. It currently sounds like the custom port injector is something separate from the kext + SSDT method, which is why I was asking about a "port injector method" in the first place. I think what it boils down to is the use of the word "or" here. "In other words" would have been better in its place.

RehabMan said:
I'm guessing your trackpad/BT problems are caused by other issues.

Possibly. Maybe trying to fix the issues you listed above may help. Will you answer my question regarding how to know or identify if issues exist, please? You mentioned my IOreg before.

RehabMan said:
Ports are injected with USBInjectAll.kext, configuration determined by SSDT-UIAC.aml.

That's clear. Is it possible to control the ports injected directly from USBInjectAll.kext, by perhaps editing the info.plist or something else within the kext, as opposed to creating an SSDT that changes how it behaves after the fact?

RehabMan · Nov 8, 2018

chiefbeats said:
My comment regarding the readme below clears this up.

...

From the readme Without a custom configuration, it is not intended that this kext be used long term. It is best to create a custom injector containing only the ports that are active on the target machine, or to create an SSDT that customizes the port injection done by USBInjectAll.kext. Customizing USBInjectAll.kext with an SSDT is covered later in this README.

I think I understand what you are trying to say now, but it reads as if you are differentiating between two different methods.

The differentiation is whether you do something to inject valid ports to stay within the 15 port limit or not.
Does not matter how you do it.

Create a custom injector sounds as if you are referring to some other injector, not USBInjectAll.kext...right?

Correct.
No matter how you decide to inject valid ports (staying within the 15 port limit), it is something you must do.

People that apply the port limit patch and USBInjectAll.kext, then stop,... are not using USBInjectAll.kext correctly.

If you're referring to USBInjectAll.kext, I think you could have said, "It is not intended that this kext/port injector be used long term without custom configuration using an SSDT. It is best to create a custom injector, USBInjectAll.kext in this case, containing only the ports that are active on the target machine. We accomplish this by using USBInjectAll.kext (port injector) and customizing its injection by creating an SSDT. Maybe something to consider in the future when writing guides.

To me, it says the same thing.
But ok...

It currently sounds like the custom port injector is something separate from the kext + SSDT method,

A custom port injector kext does the same thing, but in a different way.

which is why I was asking about a "port injector method" in the first place.

I'm pretty sure I suggested that @headkaze has a feature in the Intel FB patcher that can generate the kext for you.
And you can find plenty of examples elsewhere.
And that rundown I wrote for 10.11 actually covers it a bit too (it is obvious if you understand codeless kexts, and injection with AppleUSBMergeNub).

I think what it boils down to is the use of the word "or" here. "In other words" would have been better in its place.

The 'or' refers to the two different methods of injecting select USB ports.

Possibly. Maybe trying to fix the issues you listed above may help. Will you answer my question regarding how to know or identify if issues exist, please? You mentioned my IOreg before.

The issues I listed were identified by analyzing your problem reporting files (ioreg, Clover/drivers64UEFI, Clover/config.plist, kextcache output, Clover/kexts/Other, other output, etc.)

I have considered writing a guide "How to check for common mistakes you probably made", but haven't had the time and am still organizing my thoughts on that one.

That's clear. Is it possible to control the ports injected directly from USBInjectAll.kext, by perhaps editing the info.plist or something else within the kext, as opposed to creating an SSDT that changes how it behaves after the fact?

There is nothing about SSDT-UIAC that is "after the fact". USBInjectAll.kext applies your changes specified in the SSDT to Info.plist data prior to doing anything.

I don't want to encourage people to edit USBInjectAll.kext Info.plist due to the confusion it will cause. Therefore, I will not discuss it.

chiefbeats · Nov 9, 2018

RehabMan said:
The differentiation is whether you do something to inject valid ports to stay within the 15 port limit or not.
Does not matter how you do it.

Moving on. It's fixed. Geez, I thought I was hardheaded. lol! :lol:

RehabMan said:
To me, it says the same thing.
But ok...

That's a rather biased response considering you wrote it. The USB power guide needs a little help as well. Just saying. For instance, there's no clarification for when you find both H_EC and EC in the DSDT. Also, the H_EC had the _STA number 0 listed, but not the EC which made it more confusing. I was expecting to see one or the other, not both. And having seen both, I expected they both would have the _STA number listed. But I was able to figure it out, from reading your responses to others, that I didn't need to rename H_EC to EC. It's not in the guide though. Once I got rid of that, my computer would boot again. Ultimately, I don't think I truly understand what I'm gaining from performing these fixes, but it's comforting to know these things are "done right" and will contribute to a more stable system.

RehabMan said:
You probably have other mistakes. For example, just from looking at your ioreg:
- USB power properties not implemented (not new USBX ones, not legacy either)
- GenericUSBXHCI not recommended (it is buggy and no one is maintaining it)
- Plex Tuner and Chrome hooking various USB ports for some reason...
- forgot SATA-unsupported.kext (for your Intel SATA controller that is missing entries in AppleAHCIPort.kext Info.plist)
- CPU PM not implemented (you need config.plist/ACPI/SSDT/Generate/PluginType=true)
- config.plist/SystemParameters/InjectKexts should be set "Detect"... all "kexts you need" installed to /L/E
- note kextcache output shows clear problem with mismatch between AirportBrcmFixup.kext and Lilu.kext
- also kextcache output shows USBInjectAll.kext not properly installed

I went through and fixed these (that I could take action on), with exception to the SATA-unsupported.kext. I'm a little confused with this one because I could only find SATA-100 or 200 series-unsupported kexts. Nothing for 300 series. Where can I find the applicable kext? Would this be one of the 3rd party SATA kexts in Multibeast? Multibeast installs

Can you also explain the difference between using /L/E vs S/L/E vs Clover/kexts/other, please? This is in regard to your inject kexts comment.

Will you take another look at my debug folder, please, and see if there is anything else I can work on? Or help me with identifying these things myself? Thanks for your help!

Amylowellow · Nov 9, 2018

chiefbeats said:
SATA-100 or 200 series-unsupported kexts. Nothing for 300 series.

https://github.com/RehabMan/hack-tools/blob/master/kexts/SATA-unsupported.kext/Contents/Info.plist.

look at the content. it has all 3.

chiefbeats · Nov 9, 2018

Amylowellow said:
https://github.com/RehabMan/hack-tools/blob/master/kexts/SATA-unsupported.kext/Contents/Info.plist.

look at the content. it has all 3.

When RehabMan mentioned the kext, I had not clue where to go to get it, so I searched for it. I found a different location that only had the 100 and 200 series kexts. Thanks.

RehabMan · Nov 9, 2018

chiefbeats said:
with exception to the SATA-unsupported.kext. I'm a little confused with this one because I could only find SATA-100 or 200 series-unsupported kexts. Nothing for 300 series. Where can I find the applicable kext? Would this be one of the 3rd party SATA kexts in Multibeast? Multibeast installs

Use SATA-unsupported.kext.
The others you mention are deprecated.
Read the laptop guide:
https://www.tonymacx86.com/threads/guide-booting-the-os-x-installer-on-laptops-with-clover.148093/

Can you also explain the difference between using /L/E vs S/L/E vs Clover/kexts/other, please? This is in regard to your inject kexts comment.

Post #2 of the laptop guide explains it.

Search

[solved] Mojave 10.14.1 update lost USB 3.0

chiefbeats

RehabMan

Moderator

chiefbeats

RehabMan

Moderator

chiefbeats

RehabMan

Moderator

chiefbeats

Attachments

Amylowellow

chiefbeats

RehabMan

Moderator

Forum

Guides

Downloads