OpenCore bootloader. Contribute to acidanthera/OpenCorePkg development by creating an account on GitHub.

github.com

If you cannot enable the legacy RTC in BIOS, and until macOS supports AWAC, try this SSDT.
The _OSI check there isn't relevant for you, as Clover only patches ACPI under macOS, but it doesn't hurt so you may keep it as-is.
If you have no RTC enable BIOS option, try adding that SSDT and disabling your patch, hopefully it works.
Probably that option is hidden and special setup is necessary to enable it, so if it's not in the BIOS GUI, try the SSDT.

Overview One of the serious issues most users will face with 10.11.x (and later, including 10.12.x) is the new USB stack in OS X/macOS. It has a much heavier reliance on ACPI, and as a result is much more likely to expose bugs in your ACPI implementation of _PLD, and _UPC. It is covered in...

www.tonymacx86.com

Once you're done, you can use Hackintool to create a code-less USBPorts.kext instead, and remove USBInjectAll.kext + SSDT-UIAC.aml.

Attached another build, please try it. When attaching the new archive, mention the time of the panic when booted with that kext, as you have many panic logs there. Don't want to see a panic log of the older build and refer it to the new one

I took it for granted that you had looked for the one with the latest time. Anyway I've leaved only the latest panic to do things more simple. That panic is still there, maybe when it is no there, we will miss it
I just want to say that I am infinitely grateful for your help.

I took it for granted that you had looked for the one with the latest time. Anyway I've leaved only the latest panic to do things more simple. That panic is still there, maybe when it is no there, we will miss it
I just want to say that I am infinitely grateful for your help.

Yeah, I did. Just don't want to accidentally have a missing/multiple panics, to be accidentally confused.

A simple workaround for now would probably be polling mode instead of GPIO interrupts. Patch your trackpad's _CRS method to only have this inside:

C-like:

Return (I2CM (I2CX, BADR, SPED))

For now I'm out of ideas besides that workaround. Please open a new issue in the VoodooGPIO repository, attach a panic log/troubleshooting archive made with latest release (2.2) of VoodooI2C, not one of the builds I sent.
Remove old panics to avoid confusion, mention it's a panic upon boot with 2.2, frequency, etc.
Hopefully someone, maybe I, will figure this one soon. Polling is not the best solution, but it's a good replacement when GPIO cannot be used. When it's fixed (or there's a build you can test), revert the _CRS patch.
Not sure if I already suggested it, but do update your BIOS and re-extract/re-patch DSDT.

For now I'm out of ideas besides that workaround. Please open a new issue in the VoodooGPIO repository, attach a panic log/troubleshooting archive made with latest release (2.2) of VoodooI2C, not one of the builds I sent.
Remove old panics to avoid confusion, mention it's a panic upon boot with 2.2, frequency, etc.
Hopefully someone, maybe I, will figure this one soon. Polling is not the best solution, but it's a good replacement when GPIO cannot be used. When it's fixed (or there's a build you can test), revert the _CRS patch.
Not sure if I already suggested it, but do update your BIOS and re-extract/re-patch DSDT.

Sure
Your panic is within VoodooGPIO, in the method that handles interrupts (intel_gpio_community_irq_handler, called via interruptOccurredGated).
Returning what I suggested includes just your I2C bus declaration, without the GPIO pin (SBFG).
In such condition, VoodooI2CHID falls back to polling mode. In polling mode, the driver polls the device for new data, every specified time interval (5ms in VoodooI2CHID, IIRC).
Polling is less efficient than interrupts (With interrupts the device notifies the driver when there's new data available), but it's useful in cases where APIC interrupts are unusable (As almost every time on SKL+ APIC pin is higher than the macOS limit of 0x2F) and GPIO interrupts fail (Usually due to buggy GPIO implementation of the device, but I guess your VoodooGPIO panic is a good reason too).

Sure
Your panic is within VoodooGPIO, in the method that handles interrupts (intel_gpio_community_irq_handler, called via interruptOccurredGated).
Returning what I suggested includes just your I2C bus declaration, without the GPIO pin (SBFG).
In such condition, VoodooI2CHID falls back to polling mode. In polling mode, the driver polls the device for new data, every specified time interval (5ms in VoodooI2CHID, IIRC).
Polling is less efficient than interrupts (With interrupts the device notifies the driver when there's new data available), but it's useful in cases where APIC interrupts are unusable (As almost every time on SKL+ APIC pin is higher than the macOS limit of 0x2F) and GPIO interrupts fail (Usually due to buggy GPIO implementation of the device, but I guess your VoodooGPIO panic is a good reason too).

Many thanks, voodoogpio it's from coolstar? Opened issue on both Coolstar and Alexandred.
I don't know if i've understand good, for me english it's a new thing for now. Have you said that there is a workaround to get rid of this panic? even if not i'm grateful and i will wait for a next release with that panic fixed

Many thanks, voodoogpio it's from coolstar? Opened issue on both Coolstar and Alexandred.
I don't know if i've understand good, for me english it's a new thing for now. Have you said that there is a workaround to get rid of this panic? even if not i'm grateful and i will wait for a next release with that panic fixed

Yes, CoolStar developed it as part of the VoodooI2C development, it's included as a PlugIn is VoodooI2C releases.
Make sure you only attach panic logs made with release version of VoodooI2C. Remove any panic log generated when using the custom builds I made, if you attached such logs.

There is a workaround, as I said. Patch your trackpad's _CRS method in your DSDT, so you only has the return line I suggested a couple of posts above within.

Yes, CoolStar developed it as part of the VoodooI2C development, it's included as a PlugIn is VoodooI2C releases.
Make sure you only attach panic logs made with release version of VoodooI2C. Remove any panic log generated when using the custom builds I made, if you attached such logs.

There is a workaround, as I said. Patch your trackpad's _CRS method in your DSDT, so you only has the return line I suggested a couple of posts above within.

Remove the whole content of _CRS and put just that one line I suggested inside.
Alternatively, you can keep just the last line in _CRS (With SBFI in the end). VoodooI2C will fallback to polling that way as well.

Remove the whole content of _CRS and put just that one line I suggested inside.
Alternatively, you can keep just the last line in _CRS (With SBFI in the end). VoodooI2C will fallback to polling that way as well.