| Bug ID | 106597 |
|---|---|
| Summary | [vga_switcheroo] commit 07f4f97d7b4bf325d9f558c5b58230387e4e5= 7e0 breaks dpm on Alienware 15R3 |
| Product | DRI |
| Version | DRI git |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | DRM/other |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | taijian@posteo.de |
Over on Bug 104064 Alex Deucher and Harry = Wentland had heroically assisted me in finally fixing dGPU auto-suspend on my HG laptop (Intel iGPU + AMD dGPU)= . I was really looking forward to their work going mainline in 4.16 and me being able to enjoy my newly working system. Unfortunately, some other commit into 4.16 broke things again. After overcoming my initial frustration and doing = some research, I was now able to track this down to the work by Lukas Wunner on vga_switcheroo. I am doing my debugging with drm-next-4.18-wip over at https://cgit.freedesk= top.org/~agd5f/linux because 4.16 & 4.17 have one other bug that 4.18 doesn't (Bug 105760) that prevent me from u= sing those. Simply compiling drm-next-4.18-wip will result in a kernel that cannot dynamically power down the dGPU. It remains up regardless of use status and draws power. Now if I revert commits 07f4f97d7b4bf325d9f558c5b58230387e4e57e0, b67ae78efae0d5be5d9c7a507e67cd02971b32e1 and 2b4f44eec2be2688511c2b617d0e1b4f94c45ba4 and recompile, then the resulting kernel will once again fully power down my dGPU when it is not in use.=20 Now, if I can assist in any way with further debugging or testing patches to figure out what specifically went wrong with those patches, I'd be happy to= do so, just let me know!
Does reverting the ATPX quirk from bug 105760 also fix the issue? I = wonder if Lukas' patch fixed the underlying issue and the ATPX workaround is no longer necessary.
Yeah, I tried that, but unfortunately that did not work.
Pretty sure there's an issue with the HDA controller on the GP= U that prevents the GPU from suspending. Can you attach dmesg output of a drm-next-4.18-wip kernel? There's dmesg output in the bug you've linked but I'm not sure if that's with or without my patches?
What does the following show?
cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_status # GPU
cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_usage # GPU
cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_active_kids # GPU
cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_status # HDA
cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_usage # HDA
cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_active_kids # HDA
Ok I found this dmesg ouput of a 4.17 kernel... https:/= /bugs.freedesktop.org/attachment.cgi?id=3D139668 However the HDA device 0000:01:00.1 is not enumerated! It *is* enumerated in the 4.16 dmesg output you've attached. What gives? We know there are Nvidia GPUs which hide the HDA controller if no external display is attached: https://bugs.freedesktop.org/show_bug.c= gi?id=3D75985 Maybe something like that is going on here despite this being an AMD GPU? Also, there are Dell machines which can be switched to one of two modes in = the BIOS: In one mode, audio is streamed to external displays via the Intel HDA= , in the other mode, it's streamed via the AMD HDA. In the former mode, the AMD = HDA serves no purpose and should thus be hidden as per this patch: https://lkml.org/lkml/2018/= 4/20/244 It's possible that something similar is needed here.
Ah, never mind, the 4.17 output was attached by Thomas Martitz= . So without 4.17 dmesg output of your machine it's pretty hard to tell what's going on.
see also: https://bugzilla.kernel.org/show_bug.cgi?id=3D199693
Created atta=
chment 139673 [details]
dmesg with 4.18-wip 'vanilla-as-is'
OK, here come three dmesg outputs - first one is 'vanilla' drm-next-4.18-wi=
p,
the second one is with the atpx quirk reversed, the third one is with the t=
hree
vga_switcheroo patches I mentioned in the original bug report reversed. That
third one is also the only one where my dGPU properly powers down.
Created [details]
dmesg with 4.18-wip 'atpx-quirk reversed'
Here the second dmesg - forced atpx method quirk reversed.
Created attachment 139675 [details]
dmesg with 4.18-wip 'vga_switcheroo-patches reversed'
Here the third dmesg output - this one with the vga_switcheroo patches reve=
rsed
and working power management.
$ cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_status active $ cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_usage 1 $ cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_active_kids=20 0 $ cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_status active $ cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_usage 0 $ cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_active_kids 0 All of these are with the 'vanilla' kernel.
Hm, the first 4.17 output does not show anything suspicious. C= ould you also post the output of: cat /sys/bus/pci/devices/0000:01:00.0/power/control cat /sys/bus/pci/devices/0000:01:00.1/power/control
$ cat /sys/bus/pci/devices/0000:01:00.0/power/control auto $ cat /sys/bus/pci/devices/0000:01:00.1/power/control auto again, this is with the 'vanilla' kernel.
(In reply to Lukas Wunner from comment #5) > Also, there are Dell machines which can be switc= hed to one of two modes in > the BIOS: In one mode, audio is streamed to external displays via the = Intel > HDA, in the other mode, it's streamed via the AMD HDA. In the former m= ode, > the AMD HDA serves no purpose and should thus be hidden as per this pa= tch: > https://lkml.org/lkml/= 2018/4/20/244 > Well, this is a Dell machine, but there is no BIOS option to switch anything regarding video/audio. However, it is possible that there is something wonky about how the chip is wired, because all other Alienware laptops do sport NVIDIA gpus and it could be that the wiring is the same.
(In reply to Alex Deucher from comment #7) > see also: https://bugzilla.kernel.org/show_bug.cgi?id=3D19= 9693 I tried that patch, but am not seeing any difference.
Created attachme= nt 139688 [details] [review] drm-next-4.18-wip debug patch 1 So, the HDA device's usage counter is 0, it has no active children and runt= ime PM is allowed. Still, it's runtime active. Why is it not suspending? Here's= a little patch which litters relevant code with debug printks, hopefully this will get us closer to the answer. Could you apply this on top of drm-next-4.18-wip and attach the resulting dmesg output? Oh and could you also try: cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_status ... to double check that runtime PM is enabled? Thanks!
Created attachment 139692 [deta=
ils]
dmesg with the debug symbols requested by Lukas
This is the 'vanilla' kernel with the extra patch for the debug symbols add=
ed
in.
Also, as requested:
$ cat /sys/bus/pci/devices/0000:01:00.1/power/runtime_status
active