# Problems with Hybrid Radeon and the latest kernels

## buboleck

Hello,

I have Lenovo G505 with AMD A5000 APU with integrated Radeon GPU plus discrete Radeon GPU. I was using almost without problems (excluding some opengl issues) with the radeonsi and xorg 1.15. With kernel 3.13.6 and below X works fine, with kernels 3.13.7, 3.13.8 and 3.14 X is not loading (well the Xorg.log shows that it starts but the process does not show in the process list.) resulting in blank black screen. I thought that X starts on the discrete GPU (as it proved to be the case in past issues) so I created a xorg.conf specifying that it must use the integrated GPU, but still no go. I assume someone else already experienced that?

----------

## Hu

If this works in 3.13.6 and fails in 3.13.7, could you bisect the changes to identify the specific commit that breaks it?

----------

## buboleck

Unfortunately due to time restrains I'm not able to play much with the kernels. It was a general question, maybe submitting a bug is better idea.

----------

## TomWij

# git shortlog v3.13.6..v3.13.7 | grep radeon

      drm/radeon/atom: select the proper number of lanes in transmitter setup

      drm/radeon/dpm: fix typo in EVERGREEN_SMC_FIRMWARE_HEADER_softRegisters

      drm/radeon: re-order firmware loading in preparation for dpm rework

      drm/radeon: fix runpm disabling on non-PX harder

      drm/radeon/cik: properly set sdma ring status on disable

      drm/radeon/cik: stop the sdma engines in the enable() function

      drm/radeon/cik: properly set compute ring status on disable

      drm/radeon: fix minor typos in si_dpm.c

      drm/radeon/si: fix typo in dpm sq ramping setup

      drm/radeon: TTM must be init with cpu-visible VRAM, v2

Some important commits (re-order firmware, engine and ring internals, DRM memory management, ...) and some less important ones (typo, small fixes, ...); could be in one of those important commits, a bisect restricted to drm/radeon might work out. But before we go down that road, maybe we can get a better idea from the logs as it might bail out and tell us where the issue lies.

Can you share us /var/log/Xorg.0.log, the output of `dmesg` and /var/log/messages (on OpenRC) or the output of `systemctl -rb` (on systemd)?

----------

## buboleck

Hello,

Here are the logs:

From 3.13.6

http://retro-motobg.com/pics/radeon/Xorg.log-3.13.6

http://retro-motobg.com/pics/radeon/dmesg-3.13.6

From 3.14

http://retro-motobg.com/pics/radeon/Xorg.log-3.14

http://retro-motobg.com/pics/radeon/dmesg-3.14

I'm loading both cards firmware, I think I can try without the discrete card loading.

----------

## TomWij

Hmm, most interesting difference when you strip the timestamps of the Xorg logs and do a diff is that instead of loading "EXA" and "shadow" it is now loading "dri2" and "glamor" (aka glamoregl); does that shed any light? Maybe reverting that functionality using the configuration might be a solution? Update: This post mentions that "There is a bug in glamor preventing it from working correctly with xorg-server-1.13 and later. So for now you have to use 1.12.". Later posts mention that disabling the gles USE flag on the x11-libs/glamor package works.

----------

## buboleck

Hello,

The only change in the system is the kernel, gles is not enabled for x11-libs/glamor

----------

## buboleck

Ok, a bit of success... I disabled the loading of the firmware of the discrete GPU and now X starts properly. Any idea how the check why the second GPU prevents the X from stating?

----------

## TomWij

You can check Xorg.0.log for that.

----------

## buboleck

Yes I know that but there are no error messages or any indication that something is wrong.

----------

## TomWij

See my earlier post on this, it is because it loads in a different implementation; comparing a working and a failed log shows you that.

----------

## buboleck

 *TomWij wrote:*   

> See my earlier post on this, it is because it loads in a different implementation; comparing a working and a failed log shows you that.

 

Ok, but why? The only difference is the kernel. X should behave the same as it was not changed.

----------

## TomWij

No, X can behave different as it does auto detection unless you manually specify in its configuration to do something specific.

----------

## Adriannho

 *buboleck wrote:*   

> Hello,
> 
> I have Lenovo G505 with AMD A5000 APU with integrated Radeon GPU plus discrete Radeon GPU. I was using almost without problems (excluding some opengl issues) with the radeonsi and xorg 1.15. With kernel 3.13.6 and below X works fine, with kernels 3.13.7, 3.13.8 and 3.14 X is not loading (well the Xorg.log shows that it starts but the process does not show in the process list.) resulting in blank black screen. I thought that X starts on the discrete GPU (as it proved to be the case in past issues) so I created a xorg.conf specifying that it must use the integrated GPU, but still no go. I assume someone else already experienced that?

 

Please take a look at https://bugs.freedesktop.org/show_bug.cgi?id=77930

It seems to describe your situation as well.

Be sure to check it and apply patches/fixes when/if they arrive.

----------

