Opencore hangs chain loaded trough RefindPlus with UGA cards

[startergo]

There has been recent change which closed this issue:
#1498
After that, certain configurations with UGA/EFI cards on cMP5,1 prevent the OC from booting. This is the behavior:

• OC and RP boot independently.
• OC does not boot chain loaded from RP
  
  If it is a GOP card there is no problem.
  067 GT630 UGA MVC OC hung.zip

[vit9696]

Please provide the exact commit causing this as well as the configuration file.

[startergo]

Not sure about the exact commit, but I opened an issue dakanji/RefindPlus#24
So it must be around this time. Config file will follow when I have access to my machine.

[vit9696]

Please find it via https://dortania.github.io/builds/?product=OpenCorePkg&viewall=true

[startergo]

Ok I will find the working snapshot when I get back home (1-2) days.

[dakanji]

Wonder why all those debug log items are sent to screen instead of to the log file.
Happens on all boots of v0.6.7, when chain loaded at least, not just those that crash.

[dakanji]

Also worth noting that this issue only appears to affect the MacPro5,1 (No UGA on ConsoleOut) and not the MacPro3,1 (UGA on ConsoleOut ... MacPro version involved in #1498).

Other point of note is that the screen is already in graphics mode when RP calls OC.
Could be set to text mode beforehand if it will make a difference.

[vit9696]

@dakanji basically all log sent before OC logging protocol is initialised has to go onscreen currently.

• Does the issue happen exclusively with RP? I believe Mac EFI also starts OpenCore in graphics mode, so I do not expect any problem here.
• I saw something about NVIDIA hacks in the issue. What is it about?

[startergo]

• I saw something about NVIDIA hacks in the issue. What is it about?

This is the EFI version spoofing to allow the NVIDIA GOP to initialize. This is currently implemented in RP, but not yet in OC, so if someone wants to use OC with NVIDIA, the EFI version has to be spoofed to version 2 early in the booting sequence.
But that was something else. During those tests when I removed the driver spoofing in the EFI firmware I noticed this odd behavior for chain loading. It was just coincidence for this matter so is not relevant for this issue.
RP also uses some of the OC libraries. Could it be that OC hangs because those protocols have been already initialized in RP?

[dakanji]

To clarify things.

There are two overlapping issues as follows:

1. RefindPlus not booting
2. OpenCore not booting when chain loaded

Issue 1 was the subject of the bug report @startergo raised in the RP repo. This was shut down as invalid because it turned out to be related to the fix from #1280 where he injected the drivers into his firmware (The Nvidia Hack).

Issue 1 is not relevant to this issue except that he mentioned Issue 2 in passing in the report.

@startergo had been moaning to me recently that OpenCore not booting when chain loaded from RP. I couldn't replicate his problem and others i asked to test could not either so I put it all down to his exotic setup (manifested in Issue 1) and ignored him 😉

However, someone else I ask to test stuff, who has a basic setup, mentioned the same issue so I finally started to take @startergo serious.

After a few tests, the following same to light:

1. The issue only affects GPUs with UGA (GPUs with GOP are not affected).
2. The Issue only affects cMP 5,1 (cMP 3,1 is not affected regardless of whether the GPU has GOP or UGA).

It might be related to RP only. Needs reconfirmation.

[vit9696]

Can we provide a quirk for NVIDIA inside OC to avoid potential collision between RP and OC at least for the test case? I remember the driver submitted, but no interest in upstreaming the patch.

[dakanji]

It looked like it will be a headache to incorporate but obviously not impossible.
Can have that as a separate target as the issue here seems unrelated.

[vit9696]

Can have that as a separate target as the issue here seems unrelated.

Yes, that would do.

[startergo]

I just had a chance to do some testing. I tested the latest commits as of the time of writing this in a hope something might have changed, but the hang is still there. If I only have a GOP card connected to a display and the UGA card disconnected from the display( but still inside) the system boots. Attached are both config files.
config.conf.zip
config.plist.zip

[vit9696]

Please do #1542 (comment).
The builds are here: https://dortania.github.io/builds/?product=OpenCorePkg&viewall=true
More you postpone this, more builds you have to test.

[startergo]

I went back and tested 0.66 and 0.65. Still the same hang. I think it is safe to conclude that the problem is within RP as it used to work before.
Archive.zip
Archive1.zip

[vit9696]

Right, I guess in this case I am closing this, but I will provide any help if necessary. Just respond as needed.

[dakanji]

IIRC, this was said to also be manifested while chain loading from rEFInd.
Seems best to investigate that angle.

[dakanji]

@startergo ... Try this OC 0.6.8 build which has additional debug prints added and share the log.
Should help reveal exactly where the crash is happening.

DBG-OpenCore-068[PreRelease].zip

[startergo]

opencore-2021-03-06-201648.txt

[dakanji]

it is crashing on this ifstatement: https://github.com/acidanthera/OpenCorePkg/blob/e54b600945606d6f21909519aa43dd1b262e44fd/Library/OcDriverConnectionLib/OcDriverConnectionLib.c#L266

The TRACER 02 c 01 a 01 a 01 a 01 print out is immediately above this after the for statement.
Can't say that sheds much light so far.

[startergo]

rEFInd chainloading:
opencore-2021-03-06-205228.txt

[dakanji]

That one crashes after this line: https://github.com/acidanthera/OpenCorePkg/blob/e54b600945606d6f21909519aa43dd1b262e44fd/Library/OcDriverConnectionLib/OcDriverConnectionLib.c#L275

I think it is most likely a memory allocation issue in rEFInd that has carried over into RP. Initially seemed it might be the ReloadGOP thing but obviously not the case since this is not in rEFInd.

Solution is not here in OpenCore and the breaking commit needs to be found in rEFInd.

[startergo]

That one crashes after this line: https://github.com/acidanthera/OpenCorePkg/blob/e54b600945606d6f21909519aa43dd1b262e44fd/Library/OcDriverConnectionLib/OcDriverConnectionLib.c#L275

I think it is most likely a memory allocation issue in rEFInd that has carried over into RP. Initially seemed it might be the ReloadGOP thing but obviously not the case since this is not in rEFInd.

Solution is not here in OpenCore and the breaking commit needs to be found in rEFInd.

Something is still very inexplicable. rEFInd 0.13.1 does not boot at all (grey screen). All other before up to 0.11.4 need APFS.efi and HFS_x64.efi to display the boot partitions. Without them only tools are seen, but even then the hang is still there, whereas RP actually had a working snapshot as you can see in the other issue.

[startergo]

So commit 90a1dbd8282b814486f8b292e3c03a9a577ee45b of OC allows rEFINd 0.13.0 to chainload OC.
0.13.1 and RP still hang. So @dakanji apparently a new memory leak has been introduced between 0.13.0 and 0.13.1 ( I guess one commit), which is preventing RP and rEFInd from chainloading OC.

[dakanji]

Can you raise an issue on the RP Repo to track finding this?