Comme=
nt # 29
on bug 10406=
4
from taijian@posteo.d=
e
Created attachment 137979 [details]
dmesg with 4.17-wip-d1eeebbd78fd and dc=3D1
OK, I've gotten around to doing some more testing and playing around with s=
ome
more kcl setting, in order to better debug my crashing issues. Here's what I
found.
1) I believe that the crashing issues I kept having with force_atpx=3D1 and=
dc=3D1
after repeated or longer lasting invocations of the dGPU might have been
because of the shitty ACPI/UEFI implementation of my laptop vendor. I have =
now
tried setting acpi.osi=3D!* acpi.osi=3D'Windos 2015' and voil=C3=A1, the cr=
ashing has
vanished. So that seems to be a problem on that end, unfortunately improbab=
le
to ever get properly fixed... But at least there is a workaround and the
problem does not appear to be with your code!
2) The inconsistend dpm behaviour between dc=3D1 and dc=3D0 is still a thin=
g.
force_atpx=3D1 plus dc=3D1 gives me wonderful dpm with the dGPU fully power=
ing down
between uses. force_atpx=3D1 plus dc=3D0 does not. No idea what's up with t=
hat.
3) There is a new bug, probably introduced by this commit:
https://cgit.freedesktop.org/~agd5f/linux/p=
atch/?id=3D7c8c32854566dd9fb2ad4108029670604bc77b19.
On hybrid gpu laptops amdgpu does not actually control the brightness of the
internal screen, because that is controlled by the iGPU. So amdgpu should
probably not try. Maybe put a check in there? There is a crash referenced
related to this issue in the attached dmesg output, look starting at
[10.234751].
I hope this helps and isn't too late for a last minute pull to drm-next for
4.17, because I'd really like to see the force_atpx option in there!