Jump to content

WhatEverGreen Support Topic


MattsCreative
1,503 posts in this topic

Recommended Posts

 

4 minutes ago, TheBloke said:

WEG not supported in Clover?  What does that mean exactly?

image.thumb.png.5c17d0001c02e57403064291c1240768.png

this a message i got

 

8 minutes ago, Andrey1970 said:

 

We didn't test WEG on 5700, but we will carry out the test soon.
On previous generation AMD everything is good.
Kexts don't depend on the bootloader.

ok will be great to see some progress to use clover for the 5700
https://github.com/acidanthera/bugtracker/issues/528

Link to comment
Share on other sites

Let me clarify the situation regarding Clover support. Starting September 1, 2019, all Acidanthera projects are tested only with OpenCore.

  • We no longer do testing with Clover. 
  • We will not intentionally break anything that currently works and our code remains fully opensource and available for external contribution.
  • We will no longer perform Clover compatibility release validation for our products, but we will fix our own bugs upon request.
  • With future releases we may abandon select products, hacks specific to Clover, and Clover patch contribution to ease maintenance burden.

 

 

 

Thanks for understanding

Acidanthera team 

Edited by vandroiy2012
  • Like 1
  • Sad 3
Link to comment
Share on other sites

2 minutes ago, vandroiy2012 said:

Let me clarify the situation regarding Clover support. Starting September 1, 2019, all Acidanthera projects are tested only with OpenCore.

 

Understood.  Thanks very much for clarifying that.

 

I was already planning to start learning and testing OC, but now I have learnt this, I think I will definitely try to move over to OC for the future.

 

Thanks again.

  • Like 1
Link to comment
Share on other sites

19 minutes ago, vandroiy2012 said:

Let me clarify the situation regarding Clover support. Starting September 1, 2019, all Acidanthera projects are tested only with OpenCore.

  • We no longer do testing with Clover. 
  • We will not intentionally break anything that currently works and our code remains fully opensource and available for external contribution.
  • We will no longer perform Clover compatibility release validation for our products, but we will fix our own bugs upon request.
  • With future releases we may abandon select products, hacks specific to Clover, and Clover patch contribution to ease maintenance burden.

 

 

 

Thanks for understanding

Acidanthera team 

okie dokie ill bug clover for it lol but also with my 5700 xt i dont need to use weg in Opencore an its working great the only issue with Opencore was the positioning of the display port as its the farthest to the right an as there is only 1 HDMi an that works as i have dual monitors

Link to comment
Share on other sites

Hello! I don´t know if this post really belongs here, however if a WhatEverGreen developer can take a quick look at this and provide any pointers i´d be grateful forever. Been fighting with this issue for weeks and it is frustrating I can´t solve it. 

 

Computer: HP Probook 450G4 (KabyLake / Intel HD620 + replaced ips panel, B156HN01.1).

 

The problem is brightness control does not work until a sleep/wake cycle.

Before then, any level below the maximum show a black screen, or sometimes a low-brightness and heavily flickering image.

 

I have installed RehabMan´s ACPIPoller + ACPIDebug extensions to trace around the SSDT-PNLF patch and found out interesting things:


- Code in SSDT-PNLF is failing, I think, because all variables in the OperationRegion return 0xffffffff and seem not writable. You can see the traces on the _INI method: BAR1 is detected, KabyLake PWM chosen, but writing to LEV*not work 

    { "PNLF/I", "BAR1", 0xf0000004, "GDID", 0x5916, "MAX", 0x56c, }
    { "PNLF/I", "INIT", 0x1, }
    { "PNLF/I", "SET LEVW TO", 0x80000000, "result", 0xffffffff, }
    { "PNLF/I", "LEVX", 0xffffffff, "LEVW", 0xffffffff, "GRAN", 0xffffffff, }
    

I have defined a method POLL to be called by ACPIPoller and use brightness controls, but the polling shows no change

    { "PNLF/P", "----------", 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff, }
    { "PNLF/P", "POLL LEVX", 0xffffffff, "LEVW", 0xffffffff, "GRAN", 0xffffffff, }
    { "PNLF/P", "POLL LEVD", 0xffffffff, "LEV2", 0xffffffff, "LEVL", 0xffffffff, }
    { "PNLF/P", "----------", 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff, }    

 

- If I just replace SSDT-PNLF with a dummy one that just defines the Device, the Brightness behaviuour is the same! (so it confirms SSDT-PNLF was doing nothing)

 

Other things:

    - I found the methods _BCL, _BQC defined in my original DSDT, on device GFX0/DD1F

    - Please find attached DSDT and IOREG.log

 

These are the WhateverGreen traces:

Lilu:     api @ (DBG) got load request from WhateverGreen (133)
WhateverGreen:    init @ (DBG) WhateverGreen bootstrap DBG-133-2019-10-08
WhateverGreen:     rad @ (DBG) not enabling CAIL_DisableDrmdmaPowerGating
WhateverGreen:     rad @ (DBG) not enabling CAIL_DisableGfxCGPowerGating
WhateverGreen:     rad @ (DBG) not enabling CAIL_DisableUVDPowerGating
WhateverGreen:     rad @ (DBG) not enabling CAIL_DisableVCEPowerGating
WhateverGreen:     rad @ (DBG) not enabling CAIL_DisableDynamicGfxMGPowerGating
WhateverGreen:     rad @ (DBG) not enabling CAIL_DisableGmcPowerGating
WhateverGreen:     rad @ (DBG) not enabling CAIL_DisableAcpPowerGating
WhateverGreen:     rad @ (DBG) not enabling CAIL_DisableSAMUPowerGating
WhateverGreen:   shiki @ (DBG) will autodetect autodetect GPU 0 whitelist 0
WhateverGreen:   shiki @ (DBG) pre-config: online 0, bgra 0, compat 0, whitelist 0, id 0, stream 0
WhateverGreen:    igfx @ (DBG) platform is snb 0 and list 0xFFFFFF7F8A3FA940
WhateverGreen:     weg @ (DBG) applying backlight patch
WhateverGreen:    igfx @ dumping framebuffer information to /AppleIntelFramebuffer_9_18.7
WhateverGreen:    igfx @ (DBG) patching framebufferId 0x591B0000 connector [1] busId: 0x05, pipe: 10, type: 0x00000800, flags: 0x00000187
WhateverGreen:    igfx @ (DBG) patching framebufferId 0x591B0000 connector [2] busId: 0x04, pipe: 10, type: 0x00000010, flags: 0x00000187
WhateverGreen:    igfx @ (DBG) patching framebufferId 0x591B0000 successful
WhateverGreen:     weg @ (DBG) panel display set returned 1
WhateverGreen:     weg @ (DBG) failed to obtain display mode
WhateverGreen:     weg @ (DBG) failed to obtain display mode
WhateverGreen:     weg @ (DBG) failed to obtain display mode
WhateverGreen:     weg @ (DBG) fb info 1: -2147479552:0 7680:0:32
WhateverGreen:     weg @ (DBG) fb info 2: 3:8 --------RRRRRRRRGGGGGGGGBBBBBBBB 0:1920:1080
WhateverGreen:     weg @ (DBG) attempting to copy...

 

 

I´d appreciate any suggestions. 

 

 

 

 

DSDT.aml

 

SSDT-PNLF-NULL.dsl

SSDT-PNLF-DEBUG.dsl

P0SiTR0NK.ioreg.zip

 

SSDT-PNLF-NEW.dsl

Edited by rlp
Link to comment
Share on other sites

Not quite sure this is a WEG issue.

 

Running a KBL i5-7400 with SMBIOS iMac18,1 on a GA-H270M-DS3H, iGPU only, no dGPU, 96MB DVMT, Windows 8 mode with CSM disabled.

 

X86PlatformPlugin and AGPM are loaded.

 

Using platform 0x59120000, HDMI on AppleIntelFramebuffer@0 with connector-type 00080000

 

 

System sleeps, but restarts on wake

 

I received the following error in system logs.

 

terminating with uncaught exception of type std::runtime_error: Unable to obtain display pipe for display device: 0x0745e6d04. Service: 0x04c03. DP count: 0
Error Code:      0x00000000

 

Edited by REKTIMU2
Link to comment
Share on other sites

On 10/23/2019 at 10:57 PM, vandroiy2012 said:

Let me clarify the situation regarding Clover support. Starting September 1, 2019, all Acidanthera projects are tested only with OpenCore.

  • We no longer do testing with Clover. 
  • We will not intentionally break anything that currently works and our code remains fully opensource and available for external contribution.
  • We will no longer perform Clover compatibility release validation for our products, but we will fix our own bugs upon request.
  • With future releases we may abandon select products, hacks specific to Clover, and Clover patch contribution to ease maintenance burden.

 

 

 

Thanks for understanding

Acidanthera team 

 

Understood.

 

But what about Clover users? They trust in Acidanthera kexts, plugins and drivers for their Hacks for long time. There aren't some alternative to remplace your great tools (WEG for example).

 

I was already start learning and testing OC, but now I wait for Public Release (not published at this time). In this moment, I will try to move over to OC for the future. 

 

  • Like 2
Link to comment
Share on other sites


  localhost kernel[0]: calling mpo_policy_init for Lilu
 localhost kernel[0]: Security policy loaded: Lilu Kernel Extension 1.3.8 (Lilu)
 localhost kernel[0]: (kernel) WhateverGreen:     weg @ failed to apply agdp Piker-Alpha's patch 7

  localhost kernel[0]: calling mpo_policy_init for Lilu
localhost kernel[0]: Security policy loaded: Lilu Kernel Extension 1.3.8 (Lilu)
localhost kernel[0]: (kernel) WhateverGreen:     weg @ failed to apply agdp Piker-Alpha's patch 7
 

i get this on mojave (18G1012) on RX480 and CM Z170-UD5-TH

Link to comment
Share on other sites

Just wonder is it supposed to be so. I've got a rx560 with 5k monitor @dp and 4kuhd monitor @hdmi, after boot only hdmi is working, dp is black. But, after I accidentally found the freesync settings in the hdmi monitor and set it to the "middle" value (whatever it means) both started to work properly. Latest weg+lilu, checked on several boots.

2019-11-03 03:42:58.489517+0200  localhost kernel[0]: (kernel) Lilu:     api @ (DBG) got load request from WhateverGreen (134)
2019-11-03 03:42:58.489520+0200  localhost kernel[0]: (kernel) WhateverGreen:    init @ (DBG) WhateverGreen bootstrap DBG-134-2019-10-30
2019-11-03 03:42:58.489527+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) not enabling CAIL_DisableDrmdmaPowerGating
2019-11-03 03:42:58.489529+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) not enabling CAIL_DisableGfxCGPowerGating
2019-11-03 03:42:58.489531+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) not enabling CAIL_DisableUVDPowerGating
2019-11-03 03:42:58.489533+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) not enabling CAIL_DisableVCEPowerGating
2019-11-03 03:42:58.489535+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) not enabling CAIL_DisableDynamicGfxMGPowerGating
2019-11-03 03:42:58.489537+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) not enabling CAIL_DisableGmcPowerGating
2019-11-03 03:42:58.489539+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) not enabling CAIL_DisableAcpPowerGating
2019-11-03 03:42:58.489541+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) not enabling CAIL_DisableSAMUPowerGating
2019-11-03 03:42:58.489544+0200  localhost kernel[0]: (kernel) WhateverGreen:   shiki @ (DBG) will autodetect autodetect GPU 0 whitelist 0
2019-11-03 03:42:58.489546+0200  localhost kernel[0]: (kernel) WhateverGreen:   shiki @ (DBG) pre-config: online 0, bgra 0, compat 0, whitelist 0, id 0, stream 0
2019-11-03 03:43:19.679593+0200  localhost kernel[0]: (kernel) WhateverGreen:    igfx @ (DBG) found GuC accel config at 0xFFFFFF7FA2D61324
2019-11-03 03:43:19.700308+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) starting controller 0xFFFFFF8067194530
2019-11-03 03:43:19.700326+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) GetProperty discovered property merge request for aty_properties
2019-11-03 03:43:19.700344+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) GetProperty discovered property merge request for aty_config
2019-11-03 03:43:19.830012+0200  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) invoked at kext loading/unloading
2019-11-03 03:43:19.973655+0200  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) invoked at kext loading/unloading
2019-11-03 03:43:19.974601+0200  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) invoked at kext loading/unloading
2019-11-03 03:43:19.975704+0200  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) invoked at kext loading/unloading
2019-11-03 03:43:20.266740+0200  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) invoked at kext loading/unloading
2019-11-03 03:43:20.267272+0200  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) invoked at kext loading/unloading
2019-11-03 03:43:20.437299+0200  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) invoked at kext loading/unloading
2019-11-03 03:43:20.595898+0200  localhost kernel[0]: (kernel) WhateverGreen:     con @ (DBG) 0 is type 00000400 (DP  ) flags 00000304 feat 0100 pri 0000 txmit 11 enc 02 hotplug 02 sense 01
2019-11-03 03:43:20.595902+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) translateAtomConnectorInfoV1 got sense id 01
2019-11-03 03:43:20.595905+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) translateAtomConnectorInfoV1 checking 2120 object id
2019-11-03 03:43:20.595907+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) autocorrectConnector found unsupported connector type 13
2019-11-03 03:43:20.595911+0200  localhost kernel[0]: (kernel) WhateverGreen:     con @ (DBG) 0 is type 00000800 (HDMI) flags 00000204 feat 0100 pri 0000 txmit 21 enc 03 hotplug 05 sense 04
2019-11-03 03:43:20.595914+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) translateAtomConnectorInfoV1 got sense id 04
2019-11-03 03:43:20.595916+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) translateAtomConnectorInfoV1 checking 2220 object id
2019-11-03 03:43:20.595919+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) autocorrectConnector found unsupported connector type 0C
2019-11-03 03:43:20.595922+0200  localhost kernel[0]: (kernel) WhateverGreen:     con @ (DBG) 0 is type 00000004 (DVI ) flags 00000004 feat 0100 pri 0000 txmit 00 enc 00 hotplug 03 sense 05
2019-11-03 03:43:20.595925+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) translateAtomConnectorInfoV1 got sense id 05
2019-11-03 03:43:20.595927+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) translateAtomConnectorInfoV1 checking 211E object id
2019-11-03 03:43:20.595930+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) autocorrectConnector replacing txmit 00 with 10 for 0 connector sense 05
2019-11-03 03:43:20.595934+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) setting fb limit to 3
2019-11-03 03:43:20.595938+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) getConnectorInfo found 3 senses in connector-priority
2019-11-03 03:43:20.595941+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) reprioritiseConnectors setting priority of sense 01 to 1 by sense
2019-11-03 03:43:20.595944+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) reprioritiseConnectors setting priority of sense 04 to 2 by sense
2019-11-03 03:43:20.595947+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) reprioritiseConnectors setting priority of sense 05 to 3 by sense
2019-11-03 03:43:20.595953+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) getConnectorsInfo resulting 3 connectors follow
2019-11-03 03:43:20.595956+0200  localhost kernel[0]: (kernel) WhateverGreen:     con @ (DBG) 0 is type 00000400 (DP  ) flags 00000304 feat 0100 pri 0001 txmit 11 enc 02 hotplug 02 sense 01
2019-11-03 03:43:20.595961+0200  localhost kernel[0]: (kernel) WhateverGreen:     con @ (DBG) 1 is type 00000800 (HDMI) flags 00000204 feat 0100 pri 0002 txmit 21 enc 03 hotplug 05 sense 04
2019-11-03 03:43:20.595965+0200  localhost kernel[0]: (kernel) WhateverGreen:     con @ (DBG) 2 is type 00000004 (DVI ) flags 00000004 feat 0100 pri 0003 txmit 10 enc 00 hotplug 03 sense 05
2019-11-03 03:43:20.595974+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) SetProperty caught model 14 (Radeon RX 560)
2019-11-03 03:43:20.595977+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) SetProperty ignored setting model to Radeon RX 560
2019-11-03 03:43:20.597081+0200  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) invoked at kext loading/unloading
2019-11-03 03:43:20.598097+0200  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) invoked at kext loading/unloading
2019-11-03 03:43:20.598566+0200  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) invoked at kext loading/unloading
2019-11-03 03:43:20.599041+0200  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) invoked at kext loading/unloading
2019-11-03 03:43:20.599524+0200  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) invoked at kext loading/unloading
2019-11-03 03:43:20.600720+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) starting controller done 1 0xFFFFFF8067194530
2019-11-03 03:43:20.601146+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) GetProperty discovered property merge request for cail_properties
2019-11-03 03:43:20.965518+0200  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) invoked at kext loading/unloading
2019-11-03 03:43:21.497599+0200  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) invoked at kext loading/unloading
2019-11-03 03:43:21.498429+0200  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) invoked at kext loading/unloading
2019-11-03 03:43:21.522761+0200  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) invoked at kext loading/unloading
2019-11-03 03:43:21.523995+0200  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) invoked at kext loading/unloading
2019-11-03 03:43:21.524678+0200  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) invoked at kext loading/unloading
2019-11-03 03:43:21.691355+0200  localhost kernel[0]: (kernel) WhateverGreen:     weg @ (DBG) fb info 1: -5:1 15360:0:32
2019-11-03 03:43:21.691361+0200  localhost kernel[0]: (kernel) WhateverGreen:     weg @ (DBG) fb info 2: 3:8 --------RRRRRRRRGGGGGGGGBBBBBBBB 2740474080:3840:2160
2019-11-03 03:43:21.691378+0200  localhost kernel[0]: (kernel) WhateverGreen:     weg @ (DBG) fb info 1: 12288:1 0:0:32
2019-11-03 03:43:21.691382+0200  localhost kernel[0]: (kernel) WhateverGreen:     weg @ (DBG) fb info 2: 3:8 --------RRRRRRRRGGGGGGGGBBBBBBBB 2740474080:0:0
2019-11-03 03:43:21.691386+0200  localhost kernel[0]: (kernel) WhateverGreen:     weg @ (DBG) this display has different mode
2019-11-03 03:43:21.691395+0200  localhost kernel[0]: (kernel) WhateverGreen:     weg @ (DBG) fb info 1: 12288:1 0:0:32
2019-11-03 03:43:21.691399+0200  localhost kernel[0]: (kernel) WhateverGreen:     weg @ (DBG) fb info 2: 3:8 --------RRRRRRRRGGGGGGGGBBBBBBBB 2740474080:0:0
2019-11-03 03:43:21.691403+0200  localhost kernel[0]: (kernel) WhateverGreen:     weg @ (DBG) this display has different mode
2019-11-03 03:43:21.717735+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) AGDCValidateDetailedTiming 0 -> 1 (0)
2019-11-03 03:43:21.717824+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) AGDCValidateDetailedTiming 0 -> 1 (0)
2019-11-03 03:43:21.720000+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) AGDCValidateDetailedTiming 0 -> 1 (0)
2019-11-03 03:43:21.720052+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) AGDCValidateDetailedTiming 0 -> 1 (0)
2019-11-03 03:43:21.720099+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) AGDCValidateDetailedTiming 0 -> 1 (0)
2019-11-03 03:43:24.900618+0200  localhost kernel[0]: (kernel) Lilu: patcher @ (DBG) invoked at kext loading/unloading
2019-11-03 03:43:28.647743+0200  localhost kernel[0]: (kernel) WhateverGreen:     weg @ (DBG) fb info 1: -2147479519:1 20480:0:32
2019-11-03 03:43:28.647773+0200  localhost kernel[0]: (kernel) WhateverGreen:     weg @ (DBG) fb info 2: 3:8 --------RRRRRRRRGGGGGGGGBBBBBBBB 1:5120:2880
2019-11-03 03:43:28.647776+0200  localhost kernel[0]: (kernel) WhateverGreen:     weg @ (DBG) this display has different mode
2019-11-03 03:43:28.702073+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) AGDCValidateDetailedTiming 0 -> 1 (0)
2019-11-03 03:46:48.621919+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) AGDCValidateDetailedTiming 0 -> 1 (0)
2019-11-03 03:46:48.621945+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) AGDCValidateDetailedTiming 0 -> 1 (0)
2019-11-03 03:46:48.621969+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) AGDCValidateDetailedTiming 0 -> 1 (0)
2019-11-03 03:46:48.621992+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) AGDCValidateDetailedTiming 0 -> 1 (0)
2019-11-03 03:46:48.622012+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) AGDCValidateDetailedTiming 0 -> 1 (0)
2019-11-03 03:46:48.622032+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) AGDCValidateDetailedTiming 0 -> 1 (0)
2019-11-03 03:46:48.622058+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) AGDCValidateDetailedTiming 0 -> 1 (0)
2019-11-03 03:46:48.700776+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) AGDCValidateDetailedTiming 2 -> 1 (0)
2019-11-03 03:46:48.700820+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) AGDCValidateDetailedTiming 2 -> 1 (0)
2019-11-03 03:46:48.700855+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) AGDCValidateDetailedTiming 2 -> 1 (0)
2019-11-03 03:46:48.700887+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) AGDCValidateDetailedTiming 2 -> 1 (0)
2019-11-03 03:46:48.700919+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) AGDCValidateDetailedTiming 2 -> 1 (0)
2019-11-03 03:46:48.700972+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) AGDCValidateDetailedTiming 2 -> 1 (0)

 

Skipped a lot of 

2019-11-03 03:46:48.622058+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) AGDCValidateDetailedTiming 0 -> 1 (0)
2019-11-03 03:46:48.700776+0200  localhost kernel[0]: (kernel) WhateverGreen:     rad @ (DBG) AGDCValidateDetailedTiming 2 -> 1 (0)

messages (there are really many of them)

Edited by viktr
Link to comment
Share on other sites

On 2019/11/2 at AM12点19分, maclinuxG4 said:


  localhost内核[0]:为Lilu调用mpo_policy_init
 localhost内核[0]:已加载安全策略:Lilu内核扩展1.3.8(Lilu)
 localhost内核[0] :(内核)WhateverGreen:weg @无法应用agdp Piker-Alpha补丁7

  本地主机内核[0]:为Lilu
本地主机内核调用[mpo_policy_init]:[0]已加载安全策略:Lilu内核扩展1.3.8(Lilu)
本地主机内核[0] :(内核)WhateverGreen:weg @无法应用agdp Piker-Alpha的补丁7
 

我在RX480和CM Z170-UD5-TH的莫哈韦沙漠(18G1012)上得到了这个

https://github.com/acidanthera/Lilu/releases

 

https://github.com/acidanthera/WhateverGreen/releases

Link to comment
Share on other sites

Sign me up for the issues with 5700 XT cards. Without agdpmod=pikera, black screen. But I want to extend it for Recovery mode as well: it is unusable as the screen is garbled. -radvesa does not help in here either.

 

Also, I can only get DisplayPort if I have a HDMI connected. Even while BIOS/kernel loading prefers the DP, without a HDMI connected device, black screen with all possible combinations.

 

Timestamp                       (process)[PID]    


2019-11-03 15:30:30.789993-0500  localhost kernel[0]: (Lilu) Lilu:     api @ (DBG) got load request from WhateverGreen (134)
2019-11-03 15:30:30.791577-0500  localhost kernel[0]: (Lilu) WhateverGreen:    init @ (DBG) WhateverGreen bootstrap DBG-134-2019-11-03
2019-11-03 15:30:30.793407-0500  localhost kernel[0]: (Lilu) WhateverGreen:     weg @ (DBG) agdpmod using config pikera
2019-11-03 15:30:30.794871-0500  localhost kernel[0]: (Lilu) WhateverGreen:     rad @ (DBG) not enabling CAIL_DisableDrmdmaPowerGating
2019-11-03 15:30:30.806973-0500  localhost kernel[0]: (Lilu) WhateverGreen:     rad @ (DBG) not enabling CAIL_DisableGfxCGPowerGating
2019-11-03 15:30:30.808778-0500  localhost kernel[0]: (Lilu) WhateverGreen:     rad @ (DBG) not enabling CAIL_DisableUVDPowerGating
2019-11-03 15:30:30.810533-0500  localhost kernel[0]: (Lilu) WhateverGreen:     rad @ (DBG) not enabling CAIL_DisableVCEPowerGating
2019-11-03 15:30:30.812289-0500  localhost kernel[0]: (Lilu) WhateverGreen:     rad @ (DBG) not enabling CAIL_DisableDynamicGfxMGPowerGating
2019-11-03 15:30:30.814266-0500  localhost kernel[0]: (Lilu) WhateverGreen:     rad @ (DBG) not enabling CAIL_DisableGmcPowerGating
2019-11-03 15:30:30.825777-0500  localhost kernel[0]: (Lilu) WhateverGreen:     rad @ (DBG) not enabling CAIL_DisableAcpPowerGating
2019-11-03 15:30:30.827532-0500  localhost kernel[0]: (Lilu) WhateverGreen:     rad @ (DBG) not enabling CAIL_DisableSAMUPowerGating
2019-11-03 15:30:30.829314-0500  localhost kernel[0]: (Lilu) WhateverGreen:   shiki @ (DBG) will autodetect autodetect GPU 0 whitelist 0
2019-11-03 15:30:30.831192-0500  localhost kernel[0]: (Lilu) WhateverGreen:   shiki @ (DBG) pre-config: online 0, bgra 0, compat 0, whitelist 0, id 0, stream 0
2019-11-03 15:30:46.303782-0500  localhost kernel[0]: (Lilu) WhateverGreen:    igfx @ (DBG) found GuC accel config at 0xFFFFFF7F94EF039E
2019-11-03 15:30:47.449193-0500  localhost kernel[0]: (Lilu) WhateverGreen:     rad @ (DBG) GetProperty discovered property merge request for aty_config
2019-11-03 15:30:47.460652-0500  localhost kernel[0]: (Lilu) WhateverGreen:     rad @ (DBG) GetProperty discovered property merge request for aty_properties
2019-11-03 15:30:47.502909-0500  localhost kernel[0]: (Lilu) WhateverGreen:     rad @ (DBG) SetProperty caught model 18 (Radeon RX 5700 XT)
2019-11-03 15:30:47.512797-0500  localhost kernel[0]: (Lilu) WhateverGreen:     rad @ (DBG) SetProperty missing model, fallback to Radeon RX 5700 XT
2019-11-03 15:30:47.544394-0500  localhost kernel[0]: (Lilu) WhateverGreen:     rad @ (DBG) GetProperty discovered property merge request for cail_properties
2019-11-03 15:30:49.976693-0500  localhost kernel[0]: (Lilu) WhateverGreen:     weg @ (DBG) fb info 1: 12288:1 0:4294967168:32
2019-11-03 15:30:49.976697-0500  localhost kernel[0]: (Lilu) WhateverGreen:     weg @ (DBG) fb info 2: 3:8 --------RRRRRRRRGGGGGGGGBBBBBBBB 2503288568:0:0
2019-11-03 15:30:49.976700-0500  localhost kernel[0]: (Lilu) WhateverGreen:     weg @ (DBG) this display has different mode
2019-11-03 15:30:49.976707-0500  localhost kernel[0]: (Lilu) WhateverGreen:     weg @ (DBG) fb info 1: 12288:1 0:4294967168:32
2019-11-03 15:30:49.976710-0500  localhost kernel[0]: (Lilu) WhateverGreen:     weg @ (DBG) fb info 2: 3:8 --------RRRRRRRRGGGGGGGGBBBBBBBB 2503288568:0:0
2019-11-03 15:30:49.976718-0500  localhost kernel[0]: (Lilu) WhateverGreen:     weg @ (DBG) this display has different mode
2019-11-03 15:30:49.976723-0500  localhost kernel[0]: (Lilu) WhateverGreen:     weg @ (DBG) fb info 1: 12288:1 0:4294967168:32
2019-11-03 15:30:49.976726-0500  localhost kernel[0]: (Lilu) WhateverGreen:     weg @ (DBG) fb info 2: 3:8 --------RRRRRRRRGGGGGGGGBBBBBBBB 2503288568:0:0
2019-11-03 15:30:49.976729-0500  localhost kernel[0]: (Lilu) WhateverGreen:     weg @ (DBG) this display has different mode
2019-11-03 15:30:49.976733-0500  localhost kernel[0]: (Lilu) WhateverGreen:     weg @ (DBG) fb info 1: 12288:1 0:4294967168:32
2019-11-03 15:30:49.976736-0500  localhost kernel[0]: (Lilu) WhateverGreen:     weg @ (DBG) fb info 2: 3:8 --------RRRRRRRRGGGGGGGGBBBBB

2019-11-03 15:30:49.976739-0500  localhost kernel[0]: (Lilu) WhateverGreen:     weg @ (DBG) this display has different mode

Edited by Alex HQuest
added WEG log output
Link to comment
Share on other sites

50 minutes ago, Alex HQuest said:

Sign me up for the issues with 5700 XT cards. Without agdpmod=pikera, black screen. But I want to extend it for Recovery mode as well: it is unusable as the screen is garbled. -radvesa does not help in here either.

 

Also, I can only get DisplayPort if I have a HDMI connected. Even while BIOS/kernel loading prefers the DP, without a HDMI connected device, black screen with all possible combinations.

Did you try to explicitly define connectors priority?

Link to comment
Share on other sites

2 hours ago, Alex HQuest said:




 

 

2 hours ago, Alex HQuest said:
Nope. How do I do it?

 


Via custom ssdt or device properties. It is in the docs. Download debug versions of liku and weg, provide debug boot parameters for both liku and weg (it is something like -liludbg and -wegdbg), reboot, then find your connectors numbers in the log.

Then you need to find the pci three path to your gpu, for example with https://github.com/acidanthera/gfxutil

After you’ve got connectors numbers and device pci path, you can define their priorities for weg, either with connector priority under your device’s properties in devices or with custom ssdt

Fir device properties just list your connectors, for example you found in logs that 3 is dp, 0 is hdmi and 5 is dvi and you'd like to set the priorities as hdmi (highest), dp, dvi. So your connector-priority property shall look like 0x000305. Here's an example how it could be lookinlg like:
 

<key>Devices</key>
        <dict>
                <key>Properties</key>
                <dict>
                        <key>PciRoot(0x0)/Pci(0x1,0x0)/Pci(0x0,0x0)</key>
                        <dict>
                                <key>connector-priority</key>
                                <data>AQQF</data>
                        </dict>
                </dict>

SSDT example is here
 

 

Edited by viktr
Link to comment
Share on other sites

Did the connectors priority change via OC injection. Changed DP over HDMI and HDMI over DP as well. No changes whatsoever. HDMI is still the first display to change to graphics mode after kernel finishes load, and I still have to use a HDMI unit in order to get DP output - a pure DP setup gives black screen, and a HDMI with DP gives me multi monitor setup. DP continues to be the default output for BIOS and kernel loading screens.

 

Worth a shot though, thanks.

Screen Shot 2019-11-03 at 4.47.06 PM.png

Screen Shot 2019-11-03 at 4.54.31 PM.png

Edited by Alex HQuest
Link to comment
Share on other sites

13 minutes ago, Alex HQuest said:

Did the connectors priority change via OC injection. Changed DP over HDMI and HDMI over DP as well. No changes whatsoever. HDMI is still the first display to change to graphics mode after kernel finishes load, and I still have to use a HDMI unit in order to get DP output - a pure DP setup gives black screen, and a HDMI with DP gives me multi monitor setup. DP continues to be the default output for BIOS and kernel loading screens.

 

Worth a shot though, thanks.

Screen Shot 2019-11-03 at 4.47.06 PM.png

 

I have completely opposite situation - my dp is set as the first in the bios, connector-priority and ssdt, my system starts to boot with dp as main but when it is switching to gui, it switchs output to the hdmi monitor. Maybe it depends on mac model used, have no idea. Btw, is there a setting for that in your mobo? Mine gb z270 has it for the egpu although it's not so easy to find )

 

 

Edited by viktr
Link to comment
Share on other sites

Hi everyone,

 

I have Asus RX 470 Mining Edition (only a single DVI connector). 

 

Upgrade to 10.15.1 resulted as boot to black screen (but I can still open a VNC remote connection). I was NOT using WEG before upgrade and everything worked OK. I was getting black screen with WEG already with 10.15.0 so I chose not to use it before. 

 

I see that WEG has a fix for black screen in 10.15.1, but for me the screen stays black even with latest release. I have tried different options e.g. -rad24, -raddvi, different agdpmod-choices.

 

With my limited experience I can't see anything obvious in WEG logs:

WEG-debug log: https://pastebin.com/h6yi7GfG
Clover config.plist: https://pastebin.com/KJui9F6x

 

Any ideas what to try next to get WEG working with this single DVI-port RX 470 & 10.15.1?

Thanks!
 

Link to comment
Share on other sites

Guys I have randomly screen loss problem. When screen loss everything works, fans are working lights are on no trace. And I cant trace it what the hack is my problem? I almost upgrade all of my parts even bought a new 4K monitor but still getting this problem. I used debug version of WEG and Lilu and take the output text but I don't now how read this debug logs; Could you please someone check my logs and tell me is there any problem?

 

Terminal Saved Output

 

 

Edited by telepati
Link to comment
Share on other sites

On 9/21/2019 at 3:19 PM, TheBloke said:

@dragonmel I've just realised you must be the duece guy I've been speaking to on mald0n's forum? :)

 

When you mentioned your mobo and CPU I thought it was a coincidence, especially when you say here you'd love to use iMacPro SMBIOS, and over there you said you wanted MP 5.1.  But you've just written about the speed x12 multiplier on both forums, so, must be you.

 

Anyway, yes I have the same problem with iMacPro 1.1 and x12 multiplier.  But it is resolved by sleep & wake.   Given I have to sleep & wake anyway to use more than one port, this is not the end of the world.

 

So right now I am still in iMacPro 1.1.  From boot I get a picture on DP1, then I put the system to sleep, plug in the other monitors, then wake.  At that point I will have all monitors detected, and proper power management, with x12 - x24 multipliers and normal benchmark scores.

 

However, my 4K @ 60 monitor often will show no picture. It's detected at 4K@60, and shows in Displays, but it's just black.   I have to unplug/replug it a couple of times, and/or power it on and off, before eventually it shows a picture.   This is a big improvement on the MacPro 5.1 SMBIOS, where it normally only connects at 2084x1080, or sometimes at 4K@30, but almost never at 4K@60.

 

I noted that in Windows 10 I also had a black screen issue with the 4K monitor, so I figure this issue is not specific to macOS.  Though it is definitely worse in macOS - on Windows 10, I've had the black screen on the 4K monitor a couple of times, and it's always gone away after I've replugged the monitor once.   In macOS, I get it every single boot, and it usually takes 2, 3 or even 4 attempts before I get a picture on it.

 

I have working h264 and h265 HW accel with iMacPro 1.1, except I have been getting regular crashes when I try to use it.   In particular, trying to export a Premiere Pro project with HW h264 encoding will seem to run fine for 4-5 minutes, then suddenly all displays stop updating, and if I SSH in and check the logs, I will see many instances of:

 

kernel[0:472] (IOAcceleratorFamily2) void IOAccelFenceMachine::fence_timeout(IOTimerEventSource *): AMDRadeonAccelerator prodding blockFenceInterrupt

 

As well as errors about GPU hang.

 

However, I also had a crash a couple of times in Windows 10 when trying some HW h264 encoding, so I am not 100% sure if this is specific to macOS.  But, again, if it's not specific, it's certainly worse. 

 

I have been playing around in the BIOS with my OC settings to see if the issue will go away with different settings.  But I don't hold out a huge amount of hope.

 

I tried the shikivga line with MP 5.1 SMBIOS, and this gave me h264 encode/decode, but not h265.  And as mentioned, I could never get my 4K monitor to reliably connect at 4K@60, so this made MP 5.1 a bit of a non-starter for me.  So I never bothered testing if HW h264 encode would crash in MP5.1 like it currently is with iMacPro 1.1.

 

So right now it's all a bit of a mess, but I do have a somewhat usable system.  Yesterday I actually got a whole day of useful work out of it!  Although there are still weird issues; like yesterday I did a lot of After Effects work, and video previews felt really slow, slower than I remember from using my R9 280X.  Then at the end of the night I ran a Geekbench 4 test, and only got 150k on the Metal Compute test, where it should be 200k. 

 

I'd be very interested if Slice had anything to say about the errors.

 

 

 

Hi all,

 

after a long journey I finally found this thread, what should I say, I experienced the same issues:

 

X58A-UD3R / i7 950

AMD Radeon Vega 56 (Sapphire Nitro+ 56 LE)

 

After upgrading to Mojave (from HS), there was no chance to get something different than a blank screen on my LG UW Monitor 2560 x 1080.

I was on MacPro5,1 and the only way I could get something on the screen, was to add a second channel on the monitor or to force it to 1080p(Cinema)

I tested a whole bunch of stuff in clover and weg, like EDID injections, VRAM bios load, use "Kamarang" as framebuffer (note: main display port will change to the 1 left, after that),but nothing seemed to work.

I switched to iMacPro1,1 and fortunately I got a screen and a noticeable good GPU performance and compatibility.

The downside of that, as you all experienced as well, is that the CPU stick to mulitplier x12 which is in my case 1,91GHz, and no chance to get it changed no mater what I tried (options in BIOS, and various clover settings)

Also the sleep and wake technique does not solve the port issue nor does it solve the CPU stepping issue on my setup, any advise?

 

So now I can choose to have either CPU handling working with MacPro5,1 but no screen, or ,stellar GPU performance with screen but half of the CPU performance !?

I really regret of having upgraded to Mojave :-/

 

thanks,

nean

Link to comment
Share on other sites

@nean Hmm that's odd.  I had completely forgotten about that x12 issue.  I always have to sleep & wake on boot in order to be able to use more than one GPU port, and I always get x24 after that.  I have been running the Vega 64 in my X58 for the last month or so, and it is mostly rock solid.  The main problem is that I have to disconnect all but one monitor each time I reboot, as the system will fail to boot if more than one port is connected.  Booting with one monitor connected gives me a working picture on that monitor, then I put the system to sleep, then wake it, and after that I can plug in all monitors, and they all work.   I also solved my issue with regular freezes when using HW accelerated encode/decode, which I planned to post about soon (short explanation: it required disabling HDMI and DP sound by stopping AppleGFXHDA.kext from loading.)

 

I see you have the GX-X58A-UDR3, same mobo as me.  At least, it is the same if you are running version 2.0 and FH BIOS?  If you are, I will give you all my files - Clover, DSDT, etc - and I would assume you would then get the same results as me.  Only difference is I have a Xeon X5670 instead of i7 950, but I didn't have to change my DSDT or config when I changed to this CPU, so hopefully that won't affect anything.

 

By the way, the X5670 is really cheap on eBay now and is a great upgrade over a 7xx CPU - two extra cores, and OCs really nicely. 

 

Anyway, let me know what revision mobo you have and if it matches, I will send you my files tomorrow.

Link to comment
Share on other sites

8 hours ago, TheBloke said:

@nean Hmm that's odd.  I had completely forgotten about that x12 issue.  I always have to sleep & wake on boot in order to be able to use more than one GPU port, and I always get x24 after that.  I have been running the Vega 64 in my X58 for the last month or so, and it is mostly rock solid.  The main problem is that I have to disconnect all but one monitor each time I reboot, as the system will fail to boot if more than one port is connected.  Booting with one monitor connected gives me a working picture on that monitor, then I put the system to sleep, then wake it, and after that I can plug in all monitors, and they all work.   I also solved my issue with regular freezes when using HW accelerated encode/decode, which I planned to post about soon (short explanation: it required disabling HDMI and DP sound by stopping AppleGFXHDA.kext from loading.)

  

I see you have the GX-X58A-UDR3, same mobo as me.  At least, it is the same if you are running version 2.0 and FH BIOS?  If you are, I will give you all my files - Clover, DSDT, etc - and I would assume you would then get the same results as me.  Only difference is I have a Xeon X5670 instead of i7 950, but I didn't have to change my DSDT or config when I changed to this CPU, so hopefully that won't affect anything.

  

By the way, the X5670 is really cheap on eBay now and is a great upgrade over a 7xx CPU - two extra cores, and OCs really nicely. 

 

Anyway, let me know what revision mobo you have and if it matches, I will send you my files tomorrow.

 

@TheBloke

yes its the same mobo, v2 and bios on FH, that is kind, and I'd be more to than happy to test your bundle, we can exchange if you're interested in my approach.

thanks for the hint about the cpu, switching CPU could be an option, Xeon X5670 sounds a bit like it is a server cpu?

however, I already invested in vega to get to mojave, and if it comes to HW I'm almost thinking about switching the mobo/cpu/ram to a X99 or X299 architecture.

this particular X58 mobo was always a bit of a pain especially as the chipsets (other than the ICH9) was not really performing at all (not even under windows)

but other than that I have to admit it was/is rocket solid.

Lets find out what we can still get out of this grandfather hackintosh ;-)

 

would any of the 1366 cpus work? eg.: https://www.servershop24.de/en/components/cpu-heat-sink/intel/socket-1366/

 

thanks

 

Edited by nean
Link to comment
Share on other sites

×
×
  • Create New...