Contribute
Register

[Guide] Creating a Custom SSDT for USBInjectAll.kext

@RehabMan - I posted my problem reporting files in #2689. Thank you for any help / suggestions.
 
I have a Thinkpad T61 running High Sierra 10.13.6 with USBInjectAll.kext version 0.6.5 (April 20, 2018) and a custom SSDT-UIAC-ALL. I discovered a compatibility issue with an external USB drive and tried updating USBInjectAll.kext to 0.7.1 (November 8, 2018) to see if that might be the problem. After installing 0.7.1 and rebooting, attached USB devices were not recognized. Reverting to 0.6.5 restored USB operation.

Should I be able to upgrade from USBInjectAll.kext 0.6.5 to 0.7.1 while retaining the same custom SSDT-UIAC-ALL and same DSDT edits? I'll be glad to spend more time on this, but wanted to ask this simple question first.

Thank you.

EDIT: This laptop dual-boots Sierra and High Sierra. I do not have the USB problem in Sierra with USBInjectAll.kext 0.6.5.

EDIT: @RehabMan - Attached are two debug archives. debug_065 is with USBInjectAll.kext 0.6.5 (UIA_065) and debug_071 is with USBInjectAll.kext 0.7.1 (UIA_071). These archives were extracted from my Thinkpad T61 running High Sierra 10.13.6 (in-place upgrade from Sierra). With UIA_065, USB devices that I connect to my USB ports are recognized in High Sierra. With UIA_071, USB devices that I connect to my USB ports are not recognized (and do not appear in IO_Reg_Explorer).

I typically boot this laptop into Sierra, but now I need High Sierra and am only now discovering issues with USB in High Sierra. Specifically, when I try to backup my High Sierra partition to an external USB Drive (using Carbon Copy), the system freezes. I do not experience any USB problems with Sierra (and USBInjectAll.kext 0.6.5).

Any help/suggestions that you can offer would be greatly appreciated. Thank you.

Attach both the USBInjectAll.kext that you're actually using in each scenario.
 
Attach both the USBInjectAll.kext that you're actually using in each scenario.
The problem reporting archives in Post #2689 contain all kexts I'm using (including both versions of the USBINjectAll.kext). If I misunderstood your request, please let me know. Thank you.
 
The problem reporting archives in Post #2689 contain all kexts I'm using (including both versions of the USBINjectAll.kext). If I misunderstood your request, please let me know. Thank you.

No. You did not include a copy of the actual USBInjectAll.kext you're using.
You need to:
- reproduce the exact problem again (for each version of USBInjectAll.kext)
- collect PR files
- in addition, grab the USBInjectAll.kext (as ZIP) from the /L/E folder
 
No. You did not include a copy of the actual USBInjectAll.kext you're using.
You need to:
- reproduce the exact problem again (for each version of USBInjectAll.kext)
- collect PR files
- in addition, grab the USBInjectAll.kext (as ZIP) from the /L/E folder
@RehabMan - The PR files are attached to POST #2689. There are two zip files - one complete set of PR files for version 065 and one complete set of PR files for 071. Attached to this post are the UIA kexts copied from my /L/E folder (identical to the kexts in my CLOVER/kexts folder).

I used gen_debug to produce each complete set of problem reporting files as you instructed.
 

Attachments

  • USBInjectAll.kext.065.zip
    17.4 KB · Views: 51
  • USBInjectAll.kext.071.zip
    16.8 KB · Views: 59
USBinjectall.kext is no longer used (or supposed to be used) once you have a properly configured ssdt-uaic file in your clover folder. Therefore, you can technically remove from both locations. As far as I know, usbinjectall.kext should never be in your clover folder.

Also, the majority of your kexts should all be in the /S/L/E folder on your mac. Technically, the absolute only kext that is required to be in your efi folder is fakesmc.kext. Anything else can once again go in S/L/E. If you want you can put your audio drivers in the efi folder but that is not necessary. The only other exception that I am not sure of is possible the nvidia and lilu kexts that may have to go in your efi folder. However, your computer will still boot without them, it just not may run as it is supposed to.

As for usbinject, clock id, and fix ownership, i have no idea if they are or ever were "supposed" to be checked in cc. What I can say, is that i no longer use usbinjectall.kext and have the ports patch disabled, but still leave these options checked or enabled. That being said, to my knowledge, my hack has absolutely no ill sideffects from this. So i am going to say it is safe to leave them enabled.

As for fixes, im not too sure, but i can say most of them have zero effect on my build, so i just keep them disabled.

Kextdev mode, debug, and nvida disable can all safely be deactivated (about 90% sure on this). Nvida disable=1 is only relative to os's before Sierra I believe. If you have an nivida card, you should be using the enable nvidiaweb under system parameters. Good luck.

I removed USBInjectAll.kext from both locations, installed all kexts in the system, before fully reading your post.. I also installed lilu, and whatevergreeen (which I think is a kext related to graphics?), and now can't seem to uninstall them.. I left a copy of them both on my EFI along with virtualsmc. Will this cause any issues? Or can I remove them from EFI, or how can I remove from system folder if I am getting an error message "Can't remove kext as.vit9696.Lilu; services failed to terminate - 0xdc008018."?

I was able to uncheck all fixes as well, and everything works perfect still.

I also managed to disable all boot flags and so far so good! I am using an AMD GPU, so no need for the Nvidia stuff. :D

Depends on whether you want all your USB ports working when you run the installer or recovery.
That's what the kexts in EFI/Clover/kexts are for (scenarios where you cannot install required kexts, but must rely on kext injection).

@RehabMan Is it then safe to leave my kexts in both locations and set Inject Kext options to detect? I only needed the USBInjectAll, and my ethernet kexts during installation. Would it make sense to leave these two in EFI? I would like to make sure that if I have any issues I can easily get into my recovery drive and do what I need to do to get back up and running.. I am using my bluetooth keyboard and mouse exclusively, which is connected though the USB controller so I would need them to work also (which btw seems to work even in my UEFI perfectly)
 
HS03 may not be correct for your hardware. You need to examine ioreg to determine which port(s) you have connected your keyboard/mouse.

Kernel flags are specified in Clover options, or at config.plist/Boot/Arguments.
I already managed to start with -uia_exclude_hs all right
Now I have a question
the USB 2.0 ports I only have in HS
the 6 USB 3.1 ports I have both in HS01.02.03.04.05.06 and they are the same in SS01.02.03.04.05.06 match

I have to put the HS and SS in the SSDT or which of the two dev's put?
 
@RehabMan - The PR files are attached to POST #2689. There are two zip files - one complete set of PR files for version 065 and one complete set of PR files for 071. Attached to this post are the UIA kexts copied from my /L/E folder (identical to the kexts in my CLOVER/kexts folder).

I used gen_debug to produce each complete set of problem reporting files as you instructed.

The debug_071 files show that USBInjectAll is not even loading under IOResources.
I have no idea why that might happen (especially with no kernel log data).
Not reproducible here.
Try with fresh install.
Note that there are a lot of releases between 0.7.1 and 0.6.5. If you can still repro on a fresh install, try each release to determine when the problem appeared.
 
Last edited:
@RehabMan Is it then safe to leave my kexts in both locations and set Inject Kext options to detect?

Not only is it "safe", but it is also the best/recommended way, IMO.

Would it make sense to leave these two in EFI? I would like to make sure that if I have any issues I can easily get into my recovery drive and do what I need to do to get back up and running.. I am using my bluetooth keyboard and mouse exclusively, which is connected though the USB controller so I would need them to work also (which btw seems to work even in my UEFI perfectly)

You should test your EFI with recovery and installer to determine what is required to use them.
 
Back
Top