Bug 97471

Summary: kworker consumes 100% of a cpu core when screen sleeps with amdgpu kernel driver.
Product: DRI Reporter: Malcolm Lewis <malcolmlewis>
Component: DRM/AMDgpuAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: jano.vesely, striker, tiwai
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
System information and perf data
none
Ourput from dmesg
none
possible fix none

Description Malcolm Lewis 2016-08-24 15:06:20 UTC
Created attachment 126008 [details]
System information and perf data

Hi
I have configured my system to use the amdgpu kernel driver (note no experimental support activated) on openSUSE Tumbleweed and running 4.8.0-rc2-3.gda13dfd-default. I did have to re-build the xf86-video-amdgpu to add my Mullins R5 PCI-IDs. I don't see this when running the radeon driver.

Reproducible: Always

Steps to Reproduce:
1. Boot to Gnome desktop.
2. Set timeout for screen saver 1-15 minutes doesn't matter.
3. From a remote ssh session monitor via top and observe one cpu at ~100% when screen save activates.

Actual Results:  
I ran the following perf command to capture some data which will add as an attachment;

perf record -F 250 -g -a sleep 10
perf report

Expected Results:  
Not consume cpu when idle/screensaver mode.

Attachment includes;
20-amdgpu.conf, dmidecode.txt, perf_data_summary.txt, 4.8.rc3.perf.data, os-release and Xorg.0.log
Comment 1 Michel Dänzer 2016-08-30 00:29:10 UTC
Please attach the corresponding dmesg output.
Comment 2 Malcolm Lewis 2016-08-30 01:16:25 UTC
Created attachment 126111 [details]
Ourput from dmesg
Comment 3 bugs.freedesktop.org 2016-09-08 17:20:09 UTC
I am hitting this bug on Carrizo as well.
In particular, it only takes effect if the disabled output is the integrated screen (eDP-1). Disabling the DP-1 output (which is actually an HDMI port) connected to an external screen has no visible effects.

My system is Arch Linux, with the default kernel (Vanilla Linux 4.7.2 with a one-line patch changing the default log level).

I can provide additional information about my system if necessary.
I can also try out kernel patches if that will help.
Comment 4 Alex Deucher 2016-09-27 21:08:11 UTC
*** Bug 97849 has been marked as a duplicate of this bug. ***
Comment 5 Alex Deucher 2016-09-27 21:11:10 UTC
For some reason the eDP panel is causing an hotplug interrupt storm when the panel is disabled.  I'm not sure why radeon is behaving differently off hand.
Comment 6 Alex Deucher 2016-09-27 21:56:07 UTC
Does this only happen after a suspend/resume cycle?
Comment 7 Striker Leggette 2016-09-27 21:59:23 UTC
Fresh boot.  This happens as soon as you change the display to _only_ push HDMI.
Comment 8 Alex Deucher 2016-09-27 23:01:56 UTC
Created attachment 126818 [details] [review]
possible fix

Does this patch help?
Comment 9 Jan Vesely 2016-09-28 15:56:17 UTC
(In reply to Alex Deucher from comment #8)
> Created attachment 126818 [details] [review] [review]
> possible fix
> 
> Does this patch help?

modified version of the patch helps on my setup. (patch modified to apply on top of ROCK kernel)
Comment 10 Malcolm Lewis 2016-09-28 22:42:16 UTC
(In reply to Alex Deucher from comment #8)
> Created attachment 126818 [details] [review] [review]
> possible fix
> 
> Does this patch help?
Hi
I can confirm the patch also works for me, both with the Laptop screen, laptop and HDMI attached screen and just the HDMI screen.

Kernel used: 4.8.0-rc8-2.g991ee60-default
OS: openSUSE Tumbleweed 20160927
Note, there is no dce_v6_0.c file, so had to tweak your patch.
Comment 11 Malcolm Lewis 2016-09-30 15:20:35 UTC
Hi
I would also like to confirm the patch works with the 4.4.21-3-default in openSUSE Leap 42.2 currently in beta.

I also expect it to work with SLED 12 SP2 when released since they are running the same kernel, just need to update xf86-video-amdgpu to 1.1.2 for support of my GPU.

Many thanks :)

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.