Bug 193521

Summary: Linux-4.8-rc3 - power usage increase by approx 4W - Dell E6440
Product: Power Management Reporter: Brett Hassall (brett.hassall)
Component: Run-Time-PMAssignee: Zhang Rui (rui.zhang)
Status: CLOSED MOVED    
Severity: normal CC: brett.hassall, lenb, rui.zhang
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 4.8-rc3 Subsystem:
Regression: No Bisected commit-id:
Attachments: output from lspci to show laptop hardware
powertop screenshot booted with 4.8-rc2
powertop screenshot booted with 4.8-rc3
pictorial view of bisect result

Description Brett Hassall 2017-01-29 11:02:13 UTC
Created attachment 253451 [details]
output from lspci to show laptop hardware

I'm running a cutdown Xfce Debian Stretch system on a Dell E6440 laptop.

I've noticed an increase in power consumption between kernel 4.7.8 and kernel 4.8.5 of >4W.

Investigating further the increase seems to have been introduced between 4.8-rc2 and 4.8-rc3 (tested using binary mainline kernels from the Ubuntu Kernel PPA).

I've attached powertop output from rc2 & rc3. Also attached is the output of lspci.

other than booting the different kernel, no other changes have been made.

tlp is being used for power optimisation. tunables in powertop show the same optimisations under each kernel.

This is my first bug report, please advise any further info required.
Comment 1 Brett Hassall 2017-01-29 11:04:03 UTC
Created attachment 253461 [details]
powertop screenshot booted with 4.8-rc2
Comment 2 Brett Hassall 2017-01-29 11:04:50 UTC
Created attachment 253471 [details]
powertop screenshot booted with 4.8-rc3
Comment 3 Zhang Rui 2017-02-06 02:03:53 UTC
please confirm if the problem is fixed in latest upstream kernel, say, 4.10-rc7
Comment 4 Zhang Rui 2017-02-06 02:04:23 UTC
If not, please use git bisect to find out which commit introduces the problem.
Comment 5 Brett Hassall 2017-02-06 23:43:38 UTC
The problem is not fixed in 4.10-rc7.

I have not built a kernel from source before so it might take me a while to figure out the git bisect thing.

thanks
Comment 6 Len Brown 2017-02-07 00:35:44 UTC
Looks like powertop is claiming the backlight and the wireless radio went up by 2 watts each.  The display backlight is using much more power in the failing case.  Please do an apples/apples comparison with the screen in 3 states:

1. off
2. minimum brightness
3. maximum brightness

What do you see with the wireless radio enabled vs disabled?

Are you able to observe a symptom via a means other than using powertop -- ie with a battery monitor or actual battery life?
Comment 7 Brett Hassall 2017-02-08 10:13:08 UTC
I have written a little utility program to get battery data from /sys/class/power_supply/BAT0. The utility calculates power draw and time remaining. I use it with the xfce genmon plugin so if I hover the mouse over the plugin icon I can get power updates every n sec (configured for n=5).

The results I am seeing are consistent with powertop. The time it takes for the battery to discharge is consistent with the time remaining values reported in powertop and my utility.

The powertop snaps for both rc2 and rc3 were taken with these settings:
1) backlight brightness set to 500 (out of 5273) - set by writing to /sys/class/backlight/intel_backlight/brightness
2) the wifi radio on but not connected to an access point. i control wifi connections manually via a shell script.

When the display blanks after the laptop is idle and I wake the display, powertop has some latency before it updates and shows approx 4W less power usage than with the screen on.

Questions:
1) 4W for the backlight seems high when it is set to 500 out of 5273 ? 
2) Does radio device: dell-laptop represent the wifi radio and network interface: wlp3s0 represent the driver? I've google'd for explanations of the powertop output and not found specific info like that.
Comment 8 Brett Hassall 2017-02-14 10:35:50 UTC
I've worked on the git bisect and found the last good commit to be 184ca823481c99dadd7d946e5afd4bb921eab30d and the last bad commit to be 76dcd9392af63ef8a1801ca727c20b3ccd1bff96.

There are 9 commits remaining. I did a build on 4 of them:
93b1f14553a5f48104b639d28e41c2bb73c0dc37 - Merge tag 'mediatek-drm-fixes-2016-08-12'
c3beef5e14f938070d64a02c762171003018937b - Merge branch 'drm-fixes-4.8'
b817634276f7f68c9d1d6d4a27117ff3c2f16956 - Revert "drm/radeon: work around lack of upstream ACPI support for D3cold
b5db361eb7746cc9ada51554a6b996170c439f0b - drm/mediatek: add CONFIG_OF dependency

All 4 resulted in a kernel panic immediately after the grub screen. These builds all resulted in "rc1" in the linux-image name (instead of rc2 for the kernels that booted). I also saw a kernel panic when I tried 4.8-rc1 from the Ubuntu kernel PPA so that seems consistent.

I've attached a screen shot from qgit to show the commit situation pictorially.

BTW, I was building the kernels with CC=gcc-5 as a workaround for the GCC 6 stack protection bug. Results seem consistent so I think it is ok.

Does this give you enough to work with? 

The laptop has a radeon HD8690M card which is rarely used if ever. 

Thanks
Comment 9 Brett Hassall 2017-02-14 10:38:17 UTC
Created attachment 254747 [details]
pictorial view of bisect result
Comment 10 Brett Hassall 2017-03-03 20:32:39 UTC
do i need to change the status from needinfo?
Comment 11 Zhang Rui 2017-03-14 07:19:52 UTC
this sounds like a graphics issue to me.
please file a bug report at freedesktop.org to get help from the graphics experts.
You can also update the URL information here.
I will mark this one as closed.
Comment 12 Brett Hassall 2017-03-18 22:07:07 UTC
Bug raised with freedesktop.org - https://bugs.freedesktop.org/show_bug.cgi?id=100270