Contribute
Register

[Release] Hackintool v3.x.x

I asked vit about this and he says it's odd that the wrong kext is being loaded. So we need debug logs. @yobro can you please use debug versions of Lilu + AppleALC along with -liludbgall liludump=60 boot args and then run the gen_debug.sh tool to generate the debug files (please include /var/log/Lilu_* files) and attach here please.

Thanks for giving me a hand with this. I've attached the files.

AppleALC cannot deal with IOKit matching issues. Must be done with device-id injection.

I set the device-id to cJ0AAA== using FB-Patcher and I got my audio working for the first time since High Sierra. Thanks a lot!
 

Attachments

  • Lilu_1.2.8_18.2.txt
    56 KB · Views: 156
  • debug_29565.zip
    2 MB · Views: 87
Last edited:
Could it be possible that too many USB ports can cause sleep issues? I ask because when I followed the USB section it doesn't say anything about HPxx ports and PRxx except that typically PR11 and PR21 are set to internal and to delete anything else unused. I had about 2 or 3 ports active in the HP section and about 1 extra port in the PR section and that put me over the 15 port limit. So not sure what to do about the extra HPxx and PRxx ports. I do have intermittent sleep issues where sleep reboots my Hackintosh described here https://www.tonymacx86.com/threads/sleep-reboots-the-computer.266750/.
 
Could it be possible that too many USB ports can cause sleep issues? I ask because when I followed the USB section it doesn't say anything about HPxx ports and PRxx except that typically PR11 and PR21 are set to internal and to delete anything else unused. I had about 2 or 3 ports active in the HP section and about 1 extra port in the PR section and that put me over the 15 port limit. So not sure what to do about the extra HPxx and PRxx ports. I do have intermittent sleep issues where sleep reboots my Hackintosh described here https://www.tonymacx86.com/threads/sleep-reboots-the-computer.266750/.

The 15-port limit is per controller. Impossible to exceed the port limit on EHCI or the EHCI attached hubs.
Port limit only has an effect on xHCI.

Refer to the guide:
https://www.tonymacx86.com/threads/guide-creating-a-custom-ssdt-for-usbinjectall-kext.211311/
 
AppleALC cannot deal with IOKit matching issues. Must be done with device-id injection.
vit asked me to reply to you:
vit9696 said:
AppleALC intercepts arbitrary kext loading and patches out the :: probe method of AppleGFXHDA. This is obvious from the code below:
https://github.com/acidanthera/AppleALC/blob/c7b0e26/AppleALC/kern_alc.cpp#L238-L254
https://github.com/acidanthera/AppleALC/blob/c7b0e26/AppleALC/kern_alc.cpp#L444-L448
You should use the latest development version (1.3.4) of AppleALC to have everything work out of the box. See:
https://github.com/acidanthera/AppleALC/blob/master/Changelog.md#v134
- Disabled AppleGFXHDA matching onto HDEF to force AppleHDA usage
@yobro can you please remove the device-id injection and update your AppleALC version to 1.3.4+ (your current version is 1.3.3). Please let us know if this solves the problem.
 
vit asked me to reply to you:

vit9696 said:
AppleALC intercepts arbitrary kext loading and patches out the :: probe method of AppleGFXHDA. This is obvious from the code below

It is likely users here are using released kexts only, as most users are not familiar with Lilu/plugin build process (or any kext build process)...
When common problems are addressed in AppleALC, I would suggest builds be made available sooner to address those problems.
(IMO, too much time between AppleALC builds)

Note: FakePCIID_Intel_HDMI_Audio.kext can also be used to cause probe to fail. But it has proven a bit unreliable. Maybe AppleALC/Lilu technique will be more successful.

vit9696 said:
You should use the latest development version (1.3.4) of AppleALC to have everything work out of the box.

Personally, I have no hardware with this particular issue, therefore no ability to test the in-development AppleALC solution.
 
According to post #1, my USB controller (200-series, 8086:A2AF) requires rehabman's XHCI-unsupported.kext. But looking at /System/Library/Extensions/IOUSBHostFamily.kext/Contents/Plugins/AppleUSBXHCIPCI.kext/Contents/Info.plist reveals that my USB controller is natively supported and doesn't need that kext. What's the reason for discrepancy?
 
Last edited:
According to post #1, my USB controller (200-series, 8086:A2AF) requires rehabman's XHCI-unsupported.kext. But looking at /System/Library/Extensions/IOUSBHostFamily.kext/Contents/Plugins/AppleUSBXHCIPCI.kext/Contents/Info.plist reveals that my USB controller is natively supported and doesn't need that kext. What's the reason for disagreement?

I noticed this too recently. Maybe a change with Mojave?
 
According to post #1, my USB controller (200-series, 8086:A2AF) requires rehabman's XHCI-unsupported.kext.
It doesn't actually say that. It says "you may need to install additional kexts". I would try without it first.
 
According to post #1, my USB controller (200-series, 8086:A2AF) requires rehabman's XHCI-unsupported.kext. But looking at /System/Library/Extensions/IOUSBHostFamily.kext/Contents/Plugins/AppleUSBXHCIPCI.kext/Contents/Info.plist reveals that my USB controller is natively supported and doesn't need that kext. What's the reason for discrepancy?

Things change in each version. What was unsupported in a previous macOS/OS X release becomes supported in newer releases. But the IOProbeScore in XHCI-unsupported.kext is carefully chosen such that XHCI-unsupported.kext installed when not actually needed has no effect.
 
Back
Top