Created attachment 130304 [details] Log when booted under kernel 4.7.8 I'm running a cutdown Xfce Debian Stretch system on a Dell E6440 laptop. The laptop has an Intel 4th Gen and a Radeon HD 8670A/8670M/8690M / R5 M330 video device. 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). When booting between kernels, no changes are made to laptop config. tlp is being used for power optimisation. tunables in powertop show the same optimisations under each kernel. This was initially reported as a kernel bug (https://bugzilla.kernel.org/show_bug.cgi?id=193521). The response was "please file a bug report at freedesktop.org to get help from the graphics experts". There is information attached to the kernel bug. I've also attached Xorg.O.log from running under kernel 4.7 and under kernel 4.9. I don't have 4.8.5 installed any longer but the problem remains under 4.9.13. This is my first bug report, please advise any further info required.
Created attachment 130305 [details] Log when booted under kernel 4.9.13
If your bisection has gone right, you're looking at either c39b487f195b93235ee76384427467786f7bf29f (if you're running amdgpu) or b817634276f7f68c9d1d6d4a27117ff3c2f16956 (if you're on radeon). lspci should tell you which one, and you should be able to revert either one on top of 4.8.5. Once you confirm the commit causing the issue, please change the component accordingly and CC the author - Alex Deucher.
What is the date on your system bios? The core kernel only enables pcie port pm (d3cold) on systems with a date of 2015 or newer, but there have been systems shipping which use those methods since 2013.
from dmidecode: BIOS Information Vendor: Dell Inc. Version: A10 Release Date: 02/02/2015 I did a "git checkout tags/v4.8-rc3 -b bug" and built the kernel. The increased power usage is present as expected. I'll try the revert next.
(In reply to Emil Velikov from comment #2) > If your bisection has gone right, you're looking at either > c39b487f195b93235ee76384427467786f7bf29f (if you're running amdgpu) or > b817634276f7f68c9d1d6d4a27117ff3c2f16956 (if you're on radeon). > > lspci should tell you which one, and you should be able to revert either one > on top of 4.8.5. Once you confirm the commit causing the issue, please > change the component accordingly and CC the author - Alex Deucher. Following the "git checkout tags/v4.8-rc3 -b bug" I reverted b817634276f7f68c9d1d6d4a27117ff3c2f16956. Power usage dropped by approx 4.5W (measured after login once system had settled, wifi not connected). Changed component to DRM/radeon.
(In reply to brett.hassall from comment #5) > (In reply to Emil Velikov from comment #2) > > If your bisection has gone right, you're looking at either > > c39b487f195b93235ee76384427467786f7bf29f (if you're running amdgpu) or > > b817634276f7f68c9d1d6d4a27117ff3c2f16956 (if you're on radeon). > > > > lspci should tell you which one, and you should be able to revert either one > > on top of 4.8.5. Once you confirm the commit causing the issue, please > > change the component accordingly and CC the author - Alex Deucher. > > Following the "git checkout tags/v4.8-rc3 -b bug" I reverted > b817634276f7f68c9d1d6d4a27117ff3c2f16956. Power usage dropped by approx 4.5W > (measured after login once system had settled, wifi not connected). So apparently your system claims to support pcie pm (d3cold), but either doesn't or it's disabled for some reason.
(In reply to Alex Deucher from comment #6) > (In reply to brett.hassall from comment #5) > > (In reply to Emil Velikov from comment #2) > > > If your bisection has gone right, you're looking at either > > > c39b487f195b93235ee76384427467786f7bf29f (if you're running amdgpu) or > > > b817634276f7f68c9d1d6d4a27117ff3c2f16956 (if you're on radeon). > > > > > > lspci should tell you which one, and you should be able to revert either one > > > on top of 4.8.5. Once you confirm the commit causing the issue, please > > > change the component accordingly and CC the author - Alex Deucher. > > > > Following the "git checkout tags/v4.8-rc3 -b bug" I reverted > > b817634276f7f68c9d1d6d4a27117ff3c2f16956. Power usage dropped by approx 4.5W > > (measured after login once system had settled, wifi not connected). > > So apparently your system claims to support pcie pm (d3cold), but either > doesn't or it's disabled for some reason. I've taken a look in the BIOS and there doesn't appear to be any settings under Power Management related to pcie. I've also checked in /etc/default/grub, there is only 'quiet' on the CMDLINE settings. Booted under kernel 4.9, sudo lspci -vv for the radeon card shows: Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-) Status: D3 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Under kernel 4.4 and 4.7 with the lower power consumption, sudo lspci -vv shows "Unknown header type 7f". Booted under kernel 4.9, sudo dmesg | grep 01:00.0 shows: [ 0.515468] pci 0000:01:00.0: [1002:6660] type 00 class 0x038000 [ 0.515480] pci 0000:01:00.0: reg 0x10: [mem 0xe0000000-0xefffffff 64bit pref] [ 0.515489] pci 0000:01:00.0: reg 0x18: [mem 0xf7c00000-0xf7c3ffff 64bit] [ 0.515495] pci 0000:01:00.0: reg 0x20: [io 0xe000-0xe0ff] [ 0.515506] pci 0000:01:00.0: reg 0x30: [mem 0xf7c40000-0xf7c5ffff pref] [ 0.515545] pci 0000:01:00.0: supports D1 D2 [ 0.515545] pci 0000:01:00.0: PME# supported from D1 D2 D3hot [ 0.515566] pci 0000:01:00.0: System wakeup disabled by ACPI [ 2.950049] radeon 0000:01:00.0: VRAM: 2048M 0x0000000000000000 - 0x000000007FFFFFFF (2048M used) [ 2.950051] radeon 0000:01:00.0: GTT: 2048M 0x0000000080000000 - 0x00000000FFFFFFFF [ 2.952510] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/hainan_pfp.bin [ 2.952800] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/hainan_me.bin [ 2.953657] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/hainan_ce.bin [ 2.954265] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/hainan_rlc.bin [ 2.955119] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/hainan_mc.bin [ 2.955430] radeon 0000:01:00.0: firmware: direct-loading firmware radeon/hainan_smc.bin [ 2.989489] radeon 0000:01:00.0: WB enabled [ 2.989491] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000080000c00 and cpu addr 0xffff9e4896928c00 [ 2.989493] radeon 0000:01:00.0: fence driver on ring 1 use gpu addr 0x0000000080000c04 and cpu addr 0xffff9e4896928c04 [ 2.989494] radeon 0000:01:00.0: fence driver on ring 2 use gpu addr 0x0000000080000c08 and cpu addr 0xffff9e4896928c08 [ 2.989495] radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000080000c0c and cpu addr 0xffff9e4896928c0c [ 2.989496] radeon 0000:01:00.0: fence driver on ring 4 use gpu addr 0x0000000080000c10 and cpu addr 0xffff9e4896928c10 [ 2.989498] radeon 0000:01:00.0: radeon: MSI limited to 32-bit [ 2.989561] radeon 0000:01:00.0: radeon: using MSI. [ 3.229692] [drm] Initialized radeon 2.48.0 20080528 for 0000:01:00.0 on minor 1 There is no mention of D3cold for the radeon card. Comparing lspci and dmesg output, the pattern seems to be D3cold+ in the device capabilities results in "PME# supported from D0 D3hot D3cold" in dmesg. I need the longer battery life for travelling and can cope easily without the radeon card being used. Is there a workaround, perhaps something in the modprobe.d, to make the radeon driver revert to old behaviour ie behave as if there was no d3cold support on the system?
As a workaround: install acpi-call-dkms run - echo "\_SB.PCI0.PEG0.PEGP.SGOF" | sudo dd of=/proc/acpi/call Power consumption once settled after login (no wifi connection) drops to previous 4.7 kernel levels (ie from approx 11,1W to 6.5W)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/785.
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.