Contribute
Register

USB in Mojave on HP Spectre 13-v130ng

Status
Not open for further replies.
Joined
Jan 12, 2019
Messages
16
Motherboard
HP Spectre 13-v130ng-Clover
CPU
i7-7500U
Graphics
HD 620, 1920x1080
Mobile Phone
  1. Android
Hello,

first I want to apologize for being a newbie asking (probably) stupid questions. It's my first time doing a Hackintosh. I also never had a Mac. You have been warned :) However I do work in IT and since 1990 work with DOS/Windows and also used Linux for a while so I'm familar with Console, Permissions, etc. but my whole knowledge is in the "Windows world" (You want a Windows 7+8+10 Multi-Edition Multi-Lang ISO with drivers for your specific hardware injected "the Microsoft way"? No problem). I also understand kext and DSDT. But here I kernel panic.

Luckily my laptop is well supported, I only need FakeSMC.kext, VoodooPS2Controller.kext, USBInjectAll.kext and that config.plist pre-made by RehabMan for the Intel HD620 and can install as well as run MacOS Mojave without glitches, lags or panics.

For the last days all USB ports were working fine with just USBInjectAll.kext, even hotplugging. But every time I started creating a correct kext by following "USB Port Patching" at https://www.tonymacx86.com/threads/release-hackintool-v1-7-3.254559/ the ports start to behave weird. Most of the time I couldn't even finish the Guide because the ports stopped working.

What also doesn't help is that this time the ports behaved like never before. This time I do see VEN_8086&DEV_15B6 as the main controller in Hackintool (aka. Intel-FB-Patcher) and it is unknown because it's the Intel Alpine Ridge 2-port Thunderbolt 3 chip. The whole time before VEN_8086&DEV_9D2F was shown as XHC (Intel Series 100 chipset).

As soon as the ports started to work weird I went back to defaults (standard IntelHD620 config.plist, standard kexts, etc.) and one time I even started from scratch (formatting the thumb drive, installing clover, putting Mac OS installer onto it, starting the Mac OS installation, etc.) since going back to defaults wasn't helping. Whenever I did that it helped ... until now.

Before I could boot into MacOS, plug in a thumbdrive and it was shown in Finder (and Hackintool). Doesn't matter if USB2 or USB3. I also could unplug and replug it without issues. When ports started to act weird I didn't saw the drive in Finder (or Hackintool or system report) anymore. If I plugged the same drive into a different port I saw it (everywhere). I unplugged it and whatver I plugged in then wasn't shown anymore. Sometimes rebooting helped, sometimes not. I noticed that the third post was always working.

Before: Ports can be re-used.
After: Ports are one-time-use only.

The attched screenshot_hackintool_USB_coldboot.png shows Hackintool after a coldboot (the Laptop was off for hours). It doesn't show the attached devices. However screenshot_systemreport_USB_coldboot.png does show them. After a reboot Hackintool showed them too.

The really weird thing is that even when USB2 or USB3.0 (3.1 Gen1 = 5 Gbps) or USB3.1 (3.1 Gen2 = 10 Gbps) devices or that USB LAN are NOT working I can plug in a USB-C to HDMI or USB-C to DisplayPort adapter and it works perfectly. Ok, those two adapters use that Alternate Mode (was it DisplayPort or USB-C??).
The laptop has three USB-C ports. Two of these are Thunderbolt 3 (Intel Alpine Ridge VEN_8086&DEV_15B6). The third port is USB 3.1 Gen 1 (5 Gbps).

Looks like those two chips fight each other. When the chipset usb controller wins everything works. When the thunderbolt controller wins everything works just one time.

Yeah, you now may say I write to much and don't know what I'm doing and you're probably right. I already saw there are guides for everything out there. I guess I just need general guidance in terms of what to fix first. Should I ignore kexts and do DSDT patching since I can boot into MacOS without serious issues? Should I disable that Thunderbolt 3 controller so I can create the correct USBPorts.kext or should I get that Thunderbolt 3 controller working first? Or do I have to wait for someone else to update his code and should focus on eg. "get the kexts for battery, display brightness, etc." meanwhile? It's like a big party and I do know that there is alcohol but I just not where.
 

Attachments

  • problem_reporting_data.zip
    3.7 MB · Views: 43
Hello,

first I want to apologize for being a newbie asking (probably) stupid questions. It's my first time doing a Hackintosh. I also never had a Mac. You have been warned :) However I do work in IT and since 1990 work with DOS/Windows and also used Linux for a while so I'm familar with Console, Permissions, etc. but my whole knowledge is in the "Windows world" (You want a Windows 7+8+10 Multi-Edition Multi-Lang ISO with drivers for your specific hardware injected "the Microsoft way"? No problem). I also understand kext and DSDT. But here I kernel panic.

Luckily my laptop is well supported, I only need FakeSMC.kext, VoodooPS2Controller.kext, USBInjectAll.kext and that config.plist pre-made by RehabMan for the Intel HD620 and can install as well as run MacOS Mojave without glitches, lags or panics.

For the last days all USB ports were working fine with just USBInjectAll.kext, even hotplugging. But every time I started creating a correct kext by following "USB Port Patching" at https://www.tonymacx86.com/threads/release-hackintool-v1-7-3.254559/ the ports start to behave weird. Most of the time I couldn't even finish the Guide because the ports stopped working.

What also doesn't help is that this time the ports behaved like never before. This time I do see VEN_8086&DEV_15B6 as the main controller in Hackintool (aka. Intel-FB-Patcher) and it is unknown because it's the Intel Alpine Ridge 2-port Thunderbolt 3 chip. The whole time before VEN_8086&DEV_9D2F was shown as XHC (Intel Series 100 chipset).

As soon as the ports started to work weird I went back to defaults (standard IntelHD620 config.plist, standard kexts, etc.) and one time I even started from scratch (formatting the thumb drive, installing clover, putting Mac OS installer onto it, starting the Mac OS installation, etc.) since going back to defaults wasn't helping. Whenever I did that it helped ... until now.

Before I could boot into MacOS, plug in a thumbdrive and it was shown in Finder (and Hackintool). Doesn't matter if USB2 or USB3. I also could unplug and replug it without issues. When ports started to act weird I didn't saw the drive in Finder (or Hackintool or system report) anymore. If I plugged the same drive into a different port I saw it (everywhere). I unplugged it and whatver I plugged in then wasn't shown anymore. Sometimes rebooting helped, sometimes not. I noticed that the third post was always working.

Before: Ports can be re-used.
After: Ports are one-time-use only.

The attched screenshot_hackintool_USB_coldboot.png shows Hackintool after a coldboot (the Laptop was off for hours). It doesn't show the attached devices. However screenshot_systemreport_USB_coldboot.png does show them. After a reboot Hackintool showed them too.

The really weird thing is that even when USB2 or USB3.0 (3.1 Gen1 = 5 Gbps) or USB3.1 (3.1 Gen2 = 10 Gbps) devices or that USB LAN are NOT working I can plug in a USB-C to HDMI or USB-C to DisplayPort adapter and it works perfectly. Ok, those two adapters use that Alternate Mode (was it DisplayPort or USB-C??).
The laptop has three USB-C ports. Two of these are Thunderbolt 3 (Intel Alpine Ridge VEN_8086&DEV_15B6). The third port is USB 3.1 Gen 1 (5 Gbps).

Looks like those two chips fight each other. When the chipset usb controller wins everything works. When the thunderbolt controller wins everything works just one time.

Yeah, you now may say I write to much and don't know what I'm doing and you're probably right. I already saw there are guides for everything out there. I guess I just need general guidance in terms of what to fix first. Should I ignore kexts and do DSDT patching since I can boot into MacOS without serious issues? Should I disable that Thunderbolt 3 controller so I can create the correct USBPorts.kext or should I get that Thunderbolt 3 controller working first? Or do I have to wait for someone else to update his code and should focus on eg. "get the kexts for battery, display brightness, etc." meanwhile? It's like a big party and I do know that there is alcohol but I just not where.
there is another usb guide here:
https://www.tonymacx86.com/threads/...sdt-for-usbinjectall-kext.211311/post-1405329
 
I know that guide as well but I have the same problem as with Hackintool. The two ports powered by the Alpine Ridge Thunderbolt 3 chip either don't show any devices at all or only the first time a device is plugged in.

Based on Hackintool I know what ports I need but that was without the TXHC Thunderbolt 3 chip suddenly playing games with me.

HS01/SS01 = USB2/USB3 middle port
HS02/SS02 = USB2/USB3 left port
HS03/SS03 = USB2/USB3 right port

However I can't get the left and middle port to work anymore because that Thunderbolt 3 chip is interfering. After three reboots the TXHC hub finally came back again and I was able to plug, unplug and replug devices. It helped me to identify the correct hubs/ports:

TXHC HS01/SS01 = USB2/USB3 middle port
TXHC HS02/SS02 = USB2/USB3 left port
XHC HS03/SS03 = USB2/USB3 right port

TXHC = Intel Alpine Ridge Thunderbolt 3 chip
XHC = Intel series 100 chipset

The problem is that sometimes both TXHC ports don't work at all. Sometimes only when the device was plugged in while booting and then unplugging and replugging doesn't work. Sometimes they work perfectly fine.

Why is that so? Do I have too many ports and sometimes those "unused" ones "overwrite" the ones I need, thus I cannot use them?
 
I followed that guide as far as possible and noticed that even with -uia_exclude_hs the two ports (HS01 and HS02) of the TXHC controller are still shown. However, the problem is that while the controller is always shown in IOReg its ports are not. This time it took fived reboots until they finally appeared.

Do the HS01/HS02/SS01/SS02 ports of the XHC controller "overwrite" the same ports of the TXHC controller and thus while the TXHC controller is alsways shown its ports are not? If so I assume creating an DSDT patch (that removes those unused XHC ports) will fix the whole problem? Or do I need to fix/patch something else and the problem has nothing to do with XHC ports "overwriting" TXHC ports?
 
Status
Not open for further replies.
Back
Top