Don't enable ACPI patches for OSes other than macOS #147

hasashin · 2020-10-28T20:57:27Z

There is no need to patch ACPI on operating systems as Windows or Linux so this mod disable acpi support when selected entry is not any of macOS entries.

stevezhengshiqi · 2020-10-28T21:02:38Z

ACPI patches are meant to be compatible with multiple operating systems. If your ACPI breaks the OS, then it's not well written. Before OpenCore version v0.0.3, it had a quirk called IgnoreWindows that would ignore ACPI patches on other OSs. However, it is deprecated because users need to adjust their SSDTs to support multiple systems.

ACPI tables must be compatible with any operating system regardless of the changes.

Quote from ACDT team.

hasashin · 2020-10-28T21:27:53Z

I see. I don't have enough knowledge about ACPI in general. Of course correctly done patches shouldn't break anything but SSDTs for EC e.x. create dummy controller which isn't going to break anything in Windows but isn't necessary I think.

Thanks for reply

vit9696 · 2020-10-28T21:53:48Z

You could disable that dummy controller with _STA method on anything but Darwin. The issue with this patch is that it does not work when chainloading operating systems, when running operating systems from Shell, and that it breaks the ability to inject custom tables into Windows and and the ability to apply quirks that are relevant for Windows as well (like ResetLogoStatus).

hasashin · 2020-10-28T22:27:51Z

Ok, Thanks for your help.

Lavmint · 2020-12-10T11:39:47Z

Bump
It seems that many users having issue with booting windows from OC causing blue/black repair screen

I faced the same problem and tried this:

Install new OC with only Vault Optional plist modification - same repair screen
Disable all ACPI patches in working OC with bootable Mac OS - same repair screen
Any other 2 days hacks to do the dumbest thing ever - load another working EFI

Why don't you just give user the ability to load other EFI without a headache?
It may not be directly referencing to this issue, idk, but many people think that this is due to OC ACPI magic

roddy20 · 2020-12-10T16:13:36Z

There is no problem to boot Windows. OC is not responsible if your DSDT patches are incorrect

Lavmint · 2020-12-10T16:25:33Z

There is no problem to boot Windows. OC is not responsible if your DSDT patches are incorrect

I can boot Windows from firmware
I can't boot Windows when using OC
@
OC is not responsible

Okay, I suppose I'm responsible

roddy20 · 2020-12-10T16:34:11Z

There is no problem to boot Windows. OC is not responsible if your DSDT patches are incorrect

I can boot Windows from firmware
I can't boot Windows when using OC

I can boot both :)

Lavmint · 2020-12-10T16:40:51Z

I can boot both :)

I can boot both (+ linux) on HP laptop from OC without any problems (except strange behavior with some intel software)
but I can't boot to Windows on my Desktop from OC at all

stevezhengshiqi · 2020-12-10T18:19:02Z

There is no problem to boot Windows. OC is not responsible if your DSDT patches are incorrect

I can boot Windows from firmware
I can't boot Windows when using OC
@
OC is not responsible

Okay, I suppose I'm responsible

Yes, you are right. You are responsible since ACPI pathes will effect Windows. You have to add operating system patch (IF Darwin...) to SSDTs

Lavmint · 2020-12-10T18:26:57Z

Yes, you are right. You are responsible since ACPI pathes will effect Windows. You have to add operating system patch (IF Darwin...) to SSDTs

I can't boot even if I disable all patches, I've already wrote this in the first message.
Even with the vanilla OC with only one single Vault Optional modification

stevezhengshiqi · 2020-12-10T19:27:45Z

@Lavmint Then you can try to play with SyncRuntimePermissions, ProtectUefiServices, and ProtectMemoryRegions. You might need https://dortania.github.io/OpenCore-Post-Install/multiboot/bootcamp.html#booting-windows-results-in-bluescreen-or-linux-crashes. Again, please don't blame OC as it's your configuration problem.

Lavmint · 2020-12-10T19:44:53Z

@stevezhengshiqi god bless you, it was SyncRuntimePermissions.
I din't even look in BootCamp troubleshooting since I was not intereted in BootCamp at all
Maybe platform specific issues should be separated from BootCamp, because it's mac platform specific tool
Thanks a lot and have a nice day

djdexter84 · 2020-12-12T05:33:26Z

@stevezhengshiqi god bless you, it was SyncRuntimePermissions.
I din't even look in BootCamp troubleshooting since I was not intereted in BootCamp at all
Maybe platform specific issues should be separated from BootCamp, because it's mac platform specific tool
Thanks a lot and have a nice day

More than anything I think you do not respect at all the titanic work done by the whole team and the whole community, coming with a childish and unproven observation.
If you had appreciated the work done, you would have read the OpenCore manual that is included in absolutely every release as well as the very well built and elaborate Dortania guide. The problem is strictly yours and the people in the community who do the same as you: they do not read carefully and enough.

Lavmint · 2020-12-12T10:38:19Z

@djdexter84 I know that this is a titanic black voodoo magic work trust me.

Unproven

I searched for the solution of this issue for 2 days there are many topics for the query "opencore repair windows blue screen", many of them were using Clover before without any issues so am I. Some of them were referencing to ACPI "if Darwin" case, some of them just suggested to use refind to boot into another systems. But it is a very strange situation when you spending 2 days (like for battery patching) to find out why windows not booting when you've got only 2 patches applied and even with disabling them you can't boot. What else should I think?

I red Dortania guide and googled for this issue over and over again and ended up here searching some closed issues that may be pointing to my problem.

Maybe I was a little bit overreacting

I suggest devs to move Windows specific issue in Dortania outside of Bootcamp guide, I was not going to "Install bootcamp", in fact I hate Bootcamp so I would never find this troubleshooting note for windows that was covered there. All OSs on PC are installed without any Bootcamps for ages, it is again a mac specific tool that has nothing to do with PC

If you are thinking that I'm a childish idiot - so be it, you are not the last who would call me like that.

vit9696 · 2020-12-12T12:28:06Z

Booting any operating system from a new environment is indeed a terrible task due to numerous bugs that firmware vendors leave us with. Like this. And yes, when I say any, I mean Windows and Linux as well. We need to make a new environment to let all the operating systems to coexist with each other, support smooth rebooting from one to another (not necessarily through BootCamp, but possibly with other tools), smooth updating, hibernation waking, and so on.

As a result, it does become more complex in general, and some issues cannot be easily diagnosed by checking that macOS boots. What we tried to do in this regard is to create a spec, then collaborate with more people to create the guides, and furthermore reply on the issues like this one to help to clarify problematic places. Perhaps, what is needed is a checklist allowing one to grade the system to be compatible, but so far we had no resources to create one.

Perhaps the community could help us with this initiative.

beeaniebee · 2020-12-23T09:16:40Z

bringing this up again, just for a quick question/statement: I have a Gentoo Linux install beside my macOS Big Sur install. An ACPI patch I'm using changes the top row of function keys to different keys so that macOS can utilize them for actions like brightness. Is there any way to add an option to boot entries (just a suggestion of how) that would disable ACPI, kext, etc. injection, basically just allowing OpenCore to boot a Linux or windows operating system as it would natively on the system? I would really like to be able to use my brightness, playback, and insert/delete keys in Linux/Windows without having to manually open the bios boot selector each time (as I'm sure all y'all devs know that's always more of a pain than it should be lol)

stevezhengshiqi · 2020-12-23T10:04:21Z

@BeanieBen9990 It has nothing to do with OpenCore but your way to write an ACPI path. You should put all your changes that specific to macOS under If (_OSI ("Darwin")) to avoid affecting other operating systems. For example

Method (_QXX)
{
  If (_OSI ("Darwin"))
  {
    Notify(\_SB.PCI0.LPCB.PS2K, 0x046c) // Your macOS patch here
  }
  Else
  {
    Return (Zero) // Original DSDT implementation
  }
}

RGarrido03 · 2020-12-23T10:08:30Z

Hi! About ACPI patches I've done this already. However, things like SMBios are still being applied. If I want to remove macOS and maintain Windows, I have to reinstall Windows, as booting without OpenCore leads to a different SMBios. (Personal experience. I have some software that's tied to my SMBios)
My suggestion is for something like Clover. Apply all these patches only on macOS, and use it as a simple bootloader for other OSes.
Thanks!

stevezhengshiqi · 2020-12-23T10:18:42Z

@RGarrido03 Hi, actually, OpenCore Configuration has clearly mentioned how to avoid SMBIOS changes on other OS. What you need to do is to:

PlatformInfo - UpdateSMBIOSMode -> Custom
PlatformInfo - SpoofVendor -> false
Kernel - Quirks - CustomSMBIOSGuid -> true

Please check OpenCore documents carefully.

roddy20 · 2020-12-23T10:20:04Z

My suggestion is for something like Clover.

My suggestion is for reading the manual: 6. UpdateSMBIOSMode
Type: plist string
Failsafe: Create
Description: Update SMBIOS fields approach:
• TryOverwrite — Overwrite if new size is <= than the page-aligned original and there are no issues with legacy region unlock. Create otherwise. Has issues on some types of firmware.
• Create — Replace the tables with newly allocated EfiReservedMemoryType at AllocateMaxAddress without any fallbacks.
• Overwrite — Overwrite existing gEfiSmbiosTableGuid and gEfiSmbiosTable3Guid data if it fits new size. Abort with unspecified state otherwise.
• Custom—WriteSMBIOStables(gEfiSmbios(3)TableGuid)togOcCustomSmbios(3)TableGuidtoworkaround firmware overwriting SMBIOS contents at ExitBootServices. Otherwise equivalent to Create. Requires patch- ing AppleSmbios.kext and AppleACPIPlatform.kext to read from another GUID: "EB9D2D31" - "EB9D2D35"
(in ASCII), done automatically by CustomSMBIOSGuid quirk.
Note: A side effect of using Custom approach is making SMBIOS updates exclusive to macOS, avoiding a collision
with existing Windows activation and custom OEM software but potentially breaking Apple-specific tools.

beeaniebee · 2020-12-24T00:23:45Z

@BeanieBen9990 It has nothing to do with OpenCore but your way to write an ACPI path. You should put all your changes that specific to macOS under If (_OSI ("Darwin")) to avoid affecting other operating systems. For example
Method (_QXX)
{
  If (_OSI ("Darwin"))
  {
    Notify(\_SB.PCI0.LPCB.PS2K, 0x046c) // Your macOS patch here
  }
  Else
  {
    Return (Zero) // Original DSDT implementation
  }
}

This might be the solution to my problem! I am using ACPI patches written by another person for my machine, as he has done some very good and hard work on making hackintoshing our model of laptop very easy! The ACPI patch for making the brightness keys work on it may not have this in it. Thank you!

beeaniebee · 2020-12-24T05:35:41Z

@BeanieBen9990 It has nothing to do with OpenCore but your way to write an ACPI path. You should put all your changes that specific to macOS under If (_OSI ("Darwin")) to avoid affecting other operating systems. For example
Method (_QXX)
{
  If (_OSI ("Darwin"))
  {
    Notify(\_SB.PCI0.LPCB.PS2K, 0x046c) // Your macOS patch here
  }
  Else
  {
    Return (Zero) // Original DSDT implementation
  }
}

I gave it a try but it actually isn't an .aml file that is causing the problem. It's a "patch" under the ACPI/patch in Config.plist. I'm a huge noob on AML and ACPI patching. Is there a way to either tell OpenCore not to inject these patches into a linux operating system, or port this "patch" to a .aml file where I can add the If statement that would prevent it from running the patch if the operating system is not Darwin? I would love some feedback on what I could do. Thank you!

stevezhengshiqi · 2020-12-24T05:49:22Z

@BeanieBen9990 Your brightness patch is in SSDT-BRT6.aml. ACPI-Patch patches always pair with SSDTs. I suggest reading https://dortania.github.io/Getting-Started-With-ACPI/#a-quick-explainer-on-acpi to have a basic idea about ACPI patches. Further discussions should place in a support forum, not here.

beeaniebee · 2020-12-24T06:55:05Z

Alright thanks. I was just asking because only when the patch in the config was disabled was the problem fixed. Disabling the ACPI patch or adding the If statement didn't fix the problem. I have given up on trying anything other than bringing the issue up with the person who wrote/gathered the ACPI patches I use, disabling the patch, and just remapping the keys on macOS since I use linux more and would rather the functionality be good on linux and ok on macOS than good on macOS and impossible on linux. Thanks though!

Drovosek01 · 2022-12-07T22:34:13Z

I came across a situation where the fixed DSDT (I removed the extra cores and sockets so that macOS would start the first time) negatively affected Windows. In the ways known to me, I was unable to isolate this fix from Windows.

acidanthera/bugtracker#2168

As a result, I had to use a modified OpenCore to prevent ACPI changes from penetrating Windows

https://www.insanelymac.com/forum/topic/341402-customized-opencore-with-additional-features/
https://gitee.com/btwise/OpenCore_NO_ACPI
https://github.com/wjz304/OpenCore_NO_ACPI_Build

abbasabidi85 · 2024-02-05T22:54:31Z

I have the same issue, where even after adding _OSI condition in SSDTs, the patches inside ACPI are still in effect and Windows somehow even draws same amount of power as macOS i.e 1.5 watts but if I boot Windows from firmware aka windows boot manager by pressing f12 key at boot, Windows idle draw is 0.7 watts.

I have followed Dortania Guide to install but still the issue is same.

Is there anything that I can look into to solve this issue other than using rEFInd.

Don't enable ACPI patches for other OSes than macOS

87a4785

Andrey1970AppleLife closed this Oct 28, 2020

beeaniebee mentioned this pull request Dec 24, 2020

ACPI Patches being applied in other operating systems Mateo1234454545/DELL-5570-Hackintosh#5

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Don't enable ACPI patches for OSes other than macOS #147

Don't enable ACPI patches for OSes other than macOS #147

hasashin commented Oct 28, 2020

stevezhengshiqi commented Oct 28, 2020 •

edited

hasashin commented Oct 28, 2020

vit9696 commented Oct 28, 2020

hasashin commented Oct 28, 2020

Lavmint commented Dec 10, 2020 •

edited

roddy20 commented Dec 10, 2020

Lavmint commented Dec 10, 2020

roddy20 commented Dec 10, 2020

Lavmint commented Dec 10, 2020

stevezhengshiqi commented Dec 10, 2020

Lavmint commented Dec 10, 2020

stevezhengshiqi commented Dec 10, 2020 •

edited

Lavmint commented Dec 10, 2020

djdexter84 commented Dec 12, 2020

Lavmint commented Dec 12, 2020 •

edited

vit9696 commented Dec 12, 2020

beeaniebee commented Dec 23, 2020

stevezhengshiqi commented Dec 23, 2020

RGarrido03 commented Dec 23, 2020 •

edited

stevezhengshiqi commented Dec 23, 2020 •

edited

roddy20 commented Dec 23, 2020 •

edited

beeaniebee commented Dec 24, 2020

beeaniebee commented Dec 24, 2020 •

edited

stevezhengshiqi commented Dec 24, 2020 •

edited

beeaniebee commented Dec 24, 2020

Drovosek01 commented Dec 7, 2022

abbasabidi85 commented Feb 5, 2024

Don't enable ACPI patches for OSes other than macOS #147

Don't enable ACPI patches for OSes other than macOS #147

Conversation

hasashin commented Oct 28, 2020

stevezhengshiqi commented Oct 28, 2020 • edited

hasashin commented Oct 28, 2020

vit9696 commented Oct 28, 2020

hasashin commented Oct 28, 2020

Lavmint commented Dec 10, 2020 • edited

roddy20 commented Dec 10, 2020

Lavmint commented Dec 10, 2020

roddy20 commented Dec 10, 2020

Lavmint commented Dec 10, 2020

stevezhengshiqi commented Dec 10, 2020

Lavmint commented Dec 10, 2020

stevezhengshiqi commented Dec 10, 2020 • edited

Lavmint commented Dec 10, 2020

djdexter84 commented Dec 12, 2020

Lavmint commented Dec 12, 2020 • edited

vit9696 commented Dec 12, 2020

beeaniebee commented Dec 23, 2020

stevezhengshiqi commented Dec 23, 2020

RGarrido03 commented Dec 23, 2020 • edited

stevezhengshiqi commented Dec 23, 2020 • edited

roddy20 commented Dec 23, 2020 • edited

beeaniebee commented Dec 24, 2020

beeaniebee commented Dec 24, 2020 • edited

stevezhengshiqi commented Dec 24, 2020 • edited

beeaniebee commented Dec 24, 2020

Drovosek01 commented Dec 7, 2022

abbasabidi85 commented Feb 5, 2024

stevezhengshiqi commented Oct 28, 2020 •

edited

Lavmint commented Dec 10, 2020 •

edited

stevezhengshiqi commented Dec 10, 2020 •

edited

Lavmint commented Dec 12, 2020 •

edited

RGarrido03 commented Dec 23, 2020 •

edited

stevezhengshiqi commented Dec 23, 2020 •

edited

roddy20 commented Dec 23, 2020 •

edited

beeaniebee commented Dec 24, 2020 •

edited

stevezhengshiqi commented Dec 24, 2020 •

edited