Contribute
Register

Matebook 13 boot every two attempts

Status
Not open for further replies.
Looked at the binary representation of your DSDT, it's patching your RTC's _STA method, apparently it's disabled.
I've seen something related a couple of days ago in OpenCore:
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.
Unfortunately Huawei bios has very few options, so I've used this SSDTs and removed that "ACPI" flag. Works flawlessly
See here:
Once you're done, you can use Hackintool to create a code-less USBPorts.kext instead, and remove USBInjectAll.kext + SSDT-UIAC.aml.
Will do this night

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 :p
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 :lol:
I just want to say that I am infinitely grateful for your help.

Have you seen new update 14.6? should i update?
 

Attachments

  • debug_10304 2.zip
    2.1 MB · Views: 74
Last edited:
Unfortunately Huawei bios has very few options, so I've used this SSDTs and removed that "ACPI" flag. Works flawlessly
...
Will do this night
Great!

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 :lol:
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.

Have you seen new update 14.6? should i update?
No reason to stay behind :p

Why do you have system SSDTs in the patched folder? You don't need to patch them, especially not dynamic ones (SSDT-xN). Remove system SSDTs from there.

What's that SSDT-SBUS? Why do you need it? If there's no reason to have it - remove.
 
Great!


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))
Can you explain more deeply?
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.
Yes you have already said to re extract bios and repatch, but i've already said that i'm already on the latest bios. Will open issue
No reason to stay behind :p

Why do you have system SSDTs in the patched folder? You don't need to patch them, especially not dynamic ones (SSDT-xN). Remove system SSDTs from there.

What's that SSDT-SBUS? Why do you need it? If there's no reason to have it - remove.
Will update, and remove that files, many thanks
 
Can you explain more deeply?
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
 
Last edited:
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.
I have to replace this return statement(selected in screenshot) of both this and the one upper?
 

Attachments

  • screenshot.png
    screenshot.png
    206.7 KB · Views: 78
I have to replace this return statement(selected in screenshot) of both this and the one upper?
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.

Make sure you're patching your trackpad - I2C0.TPD0.
 
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.

Make sure you're patching your trackpad - I2C0.TPD0.
It's to hard to comprend explained in text lol. I've changed both return statements and it worked well. Waiting for update in voodooi2c kext.
 
Status
Not open for further replies.
Back
Top