Created attachment 125267 [details]
dmesg from my latest boot (with some wifi messages at end deleted for priva=
cy)
I have an HP Pavilion 17-g133cl with A10 Carrizo+Topaz. I struggled for
hours/days to get this to actually display anything at all using the amdgpu
driver. In the mean time, efifb works perfectly every time (except of cour=
se
no 3d, no X resolution switching, no brightness control, and slow enough th=
at
video playing is also impossible). Since it seemed like there were just is=
sues
powering up the display controller correctly, I decided at first to add my
notes to h=
ttps://bugzilla.kernel.org/show_bug.cgi?id=3D117591 but my symptoms
(and cures) are, indeed, different. After much blind playing with my syste=
m (I
have no way to ssh in, and the keyboard is flaky as well, so that was a lot=
of
fun), I made the following observations:
- kernel power management options appeared to have no effect
- sometimes (very rarely), it just starts working, regardless
- once it starts working for more than 1 minute, it stays working
- often, it starts partially working, by giving me a flickering display
- often, it starts working with a stable display, only to start flickering
again after a few seconds (very rarely even going completely black gain)
- my first way of fixing it is fairly reliable, but almost always require=
s at
least one blind reboot before it starts giving my a display: xrandr --outp=
ut
eDP --crtc 1 (added to my .xinitrc)
- if, when it finally comes up, it is flickering, it can be cured by
toggling the crtc between 0 and 1 often enough until it remains stable for =
at
least a minute.
- if crtc 1 is enabled when X is killed, the machine goes blank and hangs
hard; switching consoles while X is up works, though (although the consoles
remain black).
- changing the crtc to 1 in X does nothing for the console; only X displ=
ays
anything. I have not tried to write a libdrm program to make the console
switch to crtc 1, nor have I managed to trace where the crtc list comes fro=
m,
or how to force it in the amdgpu driver itself.
- if, instead of playing with the crtc, I play with power management aga=
in,
I seem to be able to get it working by booting once with power management
enabled, then rebooting with it disabled, and then it works (video in conso=
le
as well as X, and no crtc switching necessary). However, that may just have
been how it decides to work today, and tomorrow it will no longer work.
I get identical behavior with kernels 4.6.2, 4.6.3, 4.6.4, 4.7-rc4 (which I
decided to try given the supposed major amdgpu overhaul), 4.4.15 (which I
decided to try given that the poster of the kernel.org bug was using Ubuntu=
's
4.4 kernel) (all on Gentoo; with the exception of 4.7-rc4, this is with
Gentoo's fbdecor patches, but I obviously have that disabled while working
through this problem).
Overall, this is very weird and frustrating. I've had power management iss=
ues
with previous Radeon laptops (all of them), but the gpu pm issue usually
manifested as hard locks while playing games with power management enabled,=
not
this crap. I have a feeling that anything that gets it to work only gets i=
t to
work due to random chance, and it's just that I'm beating at it often enough
that I finally hit the jackpot at some point, and it keeps working correctly
until I power cycle for an extended period again. I also get the feeling t=
hat
I must be a major masochist to keep using ATI/AMD hardware, given that in 1=
5+
years of using it I've never had an experience better than "meh, mostl=
y works".
If I weren't dead broke, I'd have chucked this machine over a freeway over=
pass
and bought something else.