Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: OCLP 0.2.5 breaks DP video in MP5,1 + AMD7970 #510

Closed
TheWojtek opened this issue Sep 25, 2021 · 3 comments
Closed

[Bug]: OCLP 0.2.5 breaks DP video in MP5,1 + AMD7970 #510

TheWojtek opened this issue Sep 25, 2021 · 3 comments
Labels
bug Something isn't working

Comments

@TheWojtek
Copy link

TheWojtek commented Sep 25, 2021

Machine Model

MacPro5,1

Application Version

Latest Release

Application Variant

TUI (Text User Interface)

What versions of macOS are you seeing the problem on?

macOS 11, Big Sur

Where does this issue happen?

Between booting macOS and Login Screen

What is the Isssue?

MP5,1 with AMD7970 (Windows detects it as R9 280x as it was marketed, 2x DP, 1x HDMI, 1x DVI), running OCLP 0.2.5, 2x DP displays + 1x HDMI display.

  1. During "building OC" phase the text-based OCLP 0.2.5 reports
- Found dGPU (1): 1002:6798
- Failed to find Device path for dGPU 1

which was not an issue in OCLP 0.2.4.

  1. On power on the following sequence happens:
  • all displays wake from standby
  • boot picker displays on DP screen # 1 as in OCLP 0.2.4 (expected)
  • Apple logo and boot progress display on DP screen # 1 (expected)
  • both DP screens go standby, login screen displays on HDMI screen
  1. After login DP screens are not detected in "Displays" prefpane and not listed in "Graphics/Displays" section of System Information.

Neither disconnecting the HDMI display nor running a single DP display from each port of the GPU does not change the above behavior. Manual copy/paste of the relevant section from 0.2.4 config.plist to 0.2.5 config.plist does not change the behavior.

I suspect this may be related to #451

OCLP 0.2.4 (working) and 0.2.5 config.plist attached (with .txt extensions)

0.2.4.config.plist.txt
0.2.5.config.plist.txt

Any Additional Information

Unfortunately cannot check the behavior in Windows, as OCLP 0.2.5 does not boot a previously (0.2.4) working Windows10 installation.

@TheWojtek TheWojtek added the bug Something isn't working label Sep 25, 2021
@khronokernel
Copy link
Member

During "building OC" phase the text-based OCLP 0.2.5 reports

  • Found dGPU (1): 1002:6798
  • Failed to find Device path for dGPU 1
    which was not an issue in OCLP 0.2.4.

This was actually an issue with 0.2.4 and older, they incorrectly generated Device Properties when the device path did not exist in ACPI. The reason you didn't notice this issue before is because of the transition from MacPro7,1 SMBIOS to iMacPro1,1 which has extra display checks.

I am already aware of the first gen GCN issue, however cannot research further myself for some time. I suspect it's either an AGDP or Shiki issue. Feel free to research further.

However I would like more Information on this:

Unfortunately cannot check the behavior in Windows, as OCLP 0.2.5 does not boot a previously (0.2.4) working Windows10 installation.

No one was reported OCLP breaking Windows boot, I'm using it myself right now with a MacPro5,1 and RX470 and many others on our discord as well. Could you elaborate how this broke? ie. ACPI crash, etc. I wonder if this is potentially an issue with OpenCorePkg

@khronokernel
Copy link
Member

Squeezed in a quick test before I leave, threw an AMD 7950 GPU in my MacPro5,1 with OCLP. Have a DisplayPort and DVI display hooked up, both working quite nicely:
Screen Shot 2021-09-25 at 10 15 42 AM

This doesn't mean I believe this issue is non-existent due to the fact I was reported about this yesterday, just very strange a nearly identical setup cannot replicate. As proper testing cannot be done without local reproduction, I'll revert the iMacPro1,1 SMBIOS change and use MacPro7,1. A bit unfortunate as the goal of iMacPro1,1 SMBIOS was to allow for wider OS support, but it seems this configuration is not as universal as I believed

Will close this issue once pushed, appreciate opening the issue

Side note: would very much appreciate more Information on the Windows issue if you can provide, as that's one I've not heard about and would like to resolve

@TheWojtek
Copy link
Author

TheWojtek commented Sep 25, 2021

Thank you for your interest - while I struggle with getting the OCLP 0.2.4 to run again, the Windows issue is hard to trace: it just freezes once the "Windows" flag is displayed. The spinning dot circle does not appear at all. It's on a SATA SSD (contrary to NVMe I run my MacOS from) and the boot used to be quite speedy just days ago.

@khronokernel - all the screens I connect are 4K, does it make a difference? I had several bizarre happenings with this setup, including needing to cycle DP mode 1.2 to 1.1 and back to 1.2 on every boot in order to get 4K on all three screens (but it only worked if screen number 1 was toggled).

Once I get my MacOS install running again I will possibly edit this post with Windows research.

EDIT: I now have no video at all on any port. I suspect a catastrophical hardware (GPU) failure coincided with the update. I don't have any other GPU at hand so it will hang here until I am able to revive the box.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants