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]

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

[Adriannho]