I've been tracking down why my Thinkpad x201 laptop with Arrandale graphics uses considerably more power under Linux than under Windows. I found where most of the difference comes from. If I boot the laptop unplugged, using LVDS display only, it uses about 8-9W according to Powertop. If I connect an external display through the VGA connector and activate it ("xrandr --output VGA1 --auto"), the laptop uses about 2W more (11-12W). So far so good. However, after I deactivate the external display ("xrandr --output VGA1 --off") and disconnect it, the power usage *stays* at the high level of 11-12W. Restarting the Xserver does not help. However, a suspend (S3) and resume cycle does bring it back to the low power level. I'm getting the same problem when using the DisplayPort connector on the docking station with a DP to DVI-D converter cable (the output is then called HDMI1 for some reason, BTW). I noticed this on Gentoo x86_64 with xorg-server-1.9.5, xf86-video-intel-2.15.0, libdrm-2.4.25, mesa-7.10.2, and kernel 2.6.38(.4). However, I was also able to reproduce it using live USB keys with Ubuntu 11.04 and Fedora 15 beta. The problem occurs every time. I saw the same problem on an older Thinkpad t61 with GM965, so it doesn't appear to be Arrandale-specific.
What's the contents of /sys/kernel/debug/dri/0/i915_fbc_status before/during/after the external display is connected? And a corresponding intel_reg_dumper would be useful. [A guide is available at http://intellinuxgraphics.org/how_to_report_bug.html]
It may not be arrandale specific, but it helps to grab our attention...
(In reply to comment #1) > What's the contents of /sys/kernel/debug/dri/0/i915_fbc_status > before/during/after the external display is connected? Not exactly informative: "FBC unsupported on this chipset" This is with with xorg-server-1.10.2, xf86-video-intel-2.15.0, libdrm-2.4.25, mesa-7.10.2, and kernel 2.6.39.1. > And a corresponding > intel_reg_dumper would be useful. I'll attach four versions: 01afterboot: straight after boot, no external display connected, LVDS1 only. 02connect: with VGA1 connected and configured (xrandr --output VGA1 --auto). 03disconnect: with VGA1 disabled (xrandr --output VGA1 --off) and physically disconnected (buggy configuration with high power usage). 04aftersuspend: like 03disconnect, but after an S3 suspend/resume cycle (power usage goes back to low).
Created attachment 48494 [details] straight after boot, no external display connected, LVDS1 only
Created attachment 48495 [details] with VGA1 connected and configured (xrandr --output VGA1 --auto)
Created attachment 48496 [details] with VGA1 disabled (xrandr --output VGA1 --off) and physically disconnected (buggy configuration with high power usage)
Created attachment 48497 [details] like 03disconnect, but after an S3 suspend/resume cycle (power usage goes back to low)
I think we finally found this bug. Please test the current drm-intel-fixes tree (git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6, drm-intel-fixes branch) and make sure it's fixed.
I'm sorry to report that I see no improvement with intel-drm-fixes (last commit cda2bb78c24de7674eafa3210314dc75bed344a6). Reopening... Let me know what debug info you need, if any.
Can you attach register dumps from before connecting the external display, then after connecting it, configuring it, and disconnecting it with the latest code?
Created attachment 49808 [details] intel-drm-fixes, before connect
Created attachment 49809 [details] intel-drm-fixes, after connect
Created attachment 49810 [details] intel-drm-fixes, after configure
Created attachment 49811 [details] intel-drm-fixes, after disconnect
Ok let's see... here's the diff between the fresh boot 9which has low power right?) and after an external display has been configured then disconnected (which has high power): --- intel_reg_dumper.01afterboot 2011-08-02 09:32:31.000000000 -0700 +++ intel_reg_dumper.04afterdisconnect 2011-08-02 09:32:21.000000000 -0700 @@ -1,6 +1,6 @@ PGETBL_CTL: 0x00000008 - GEN6_INSTDONE_1: 0xfffffffe - GEN6_INSTDONE_2: 0xffffffff + GEN6_INSTDONE_1: 0x0008817f + GEN6_INSTDONE_2: 0x89155c0e CPU_VGACNTRL: 0x80000000 (disabled) DIGITAL_PORT_HOTPLUG_CNTRL: 0x00000000 RR_HW_CTL: 0x00000000 (low 0, high 0) @@ -34,25 +34,25 @@ These indicate something is keeping the GPU busy... do you have rendering going on maybe? DSPASURF: 0x0142b000 DSPATILEOFF: 0x00000000 (0, 0) PIPEBCONF: 0x00000000 (disabled, inactive, 8bpc) - HTOTAL_B: 0x00000000 (1 active, 1 total) - HBLANK_B: 0x00000000 (1 start, 1 end) - HSYNC_B: 0x00000000 (1 start, 1 end) - VTOTAL_B: 0x00000000 (1 active, 1 total) - VBLANK_B: 0x00000000 (1 start, 1 end) - VSYNC_B: 0x00000000 (1 start, 1 end) + HTOTAL_B: 0x053f03ff (1024 active, 1344 total) + HBLANK_B: 0x053f03ff (1024 start, 1344 end) + HSYNC_B: 0x049f0417 (1048 start, 1184 end) + VTOTAL_B: 0x032502ff (768 active, 806 total) + VBLANK_B: 0x032502ff (768 start, 806 end) + VSYNC_B: 0x03080302 (771 start, 777 end) Leftover mode timing regs, should be harmless. VSYNCSHIFT_B: 0x00000000 - DSPBCNTR: 0x00000000 (disabled) + DSPBCNTR: 0x58004400 (disabled) Plane B was previously enabled but is now disabled, that should befine. DSPBBASE: 0x00000000 - DSPBSTRIDE: 0x00000000 (0) - DSPBSURF: 0x00000000 + DSPBSTRIDE: 0x00001400 (80) + DSPBSURF: 0x0142b000 Stale addresses from the previous plane enable, should be harmless. DSPBTILEOFF: 0x00000000 (0, 0) - PIPEBSRC: 0x00000000 (1, 1) - PIPEB_DATA_M1: 0x00000000 (TU 1, val 0x0 0) - PIPEB_DATA_N1: 0x00000000 (val 0x0 0) + PIPEBSRC: 0x03ff02ff (1024, 768) + PIPEB_DATA_M1: 0x7e17cdc0 (TU 64, val 0x17cdc0 1560000) + PIPEB_DATA_N1: 0x0020f580 (val 0x20f580 2160000) PIPEB_DATA_M2: 0x00000000 (TU 1, val 0x0 0) PIPEB_DATA_N2: 0x00000000 (val 0x0 0) - PIPEB_LINK_M1: 0x00000000 (val 0x0 0) - PIPEB_LINK_N1: 0x00000000 (val 0x0 0) + PIPEB_LINK_M1: 0x0000fde8 (val 0xfde8 65000) + PIPEB_LINK_N1: 0x00041eb0 (val 0x41eb0 270000) PIPEB_LINK_M2: 0x00000000 (val 0x0 0) PIPEB_LINK_N2: 0x00000000 (val 0x0 0) PFA_CTL_1: 0x00000000 (disable, auto_scale yes, auto_scale_cal no, v_filter enable, vadapt disable, mode least, filter_sel programmed,chroma pre-filter disable, vert3tap auto, v_inter_invert field 1) @@ -62,9 +62,9 @@ Stale timings from the last mode set, should be harmless. PFA_WIN_POS: 0x00000000 (0, 0) PFA_WIN_SIZE: 0x00000000 (0, 0) PFB_CTL_1: 0x00000000 (disable, auto_scale yes, auto_scale_cal no, v_filter enable, vadapt disable, mode least, filter_sel programmed,chroma pre-filter disable, vert3tap auto, v_inter_invert field 1) - PFB_CTL_2: 0x00000000 (vscale 0.000000) - PFB_CTL_3: 0x00000000 (vscale initial phase 0.000000) - PFB_CTL_4: 0x00000000 (hscale 0.000000) + PFB_CTL_2: 0x00007e80 (vscale 0.988281) + PFB_CTL_3: 0x00003f40 (vscale initial phase 0.494141) + PFB_CTL_4: 0x00007e00 (hscale 0.984375) Panel fitter changed config? This was probably enabled on the pipe B mode set... if we don't disable this after the pipe it may keep the pipe alive... but the code says we disable it after, so it should be safe. PFB_WIN_POS: 0x00000000 (0, 0) PFB_WIN_SIZE: 0x00000000 (0, 0) PCH_DREF_CONTROL: 0x00001402 (cpu source disable, ssc_source enable, nonspread_source enable, superspread_source disable, ssc4_mode downspread, ssc1 enable, ssc4 disable) @@ -75,11 +75,11 @@ PCH_DPLL_SEL: 0x00000000 (FDL_TP1 timer 0.5us, FDL_TP2 timer 1.5us, freq 125) PCH_DPLL_ANALOG_CTL: 0x00008000 PCH_DPLL_A: 0x88046004 (enable, sdvo high speed no, mode LVDS, p2 Div 14, FPA0 P1 3, FPA1 P1 3, refclk SSC, sdvo/hdmi mul 1) - PCH_DPLL_B: 0x04800080 (disable, sdvo high speed no, mode (null), p2 (null), FPA0 P1 8, FPA1 P1 8, refclk default 120Mhz, sdvo/hdmi mul 1) + PCH_DPLL_B: 0x04100010 (disable, sdvo high speed no, mode (null), p2 (null), FPA0 P1 5, FPA1 P1 5, refclk default 120Mhz, sdvo/hdmi mul 1) PCH_FPA0: 0x00021005 (n = 2, m1 = 16, m2 = 5) PCH_FPA1: 0x00021005 (n = 2, m1 = 16, m2 = 5) - PCH_FPB0: 0x00030d07 (n = 3, m1 = 13, m2 = 7) - PCH_FPB1: 0x00030d07 (n = 3, m1 = 13, m2 = 7) + PCH_FPB0: 0x00010c09 (n = 1, m1 = 12, m2 = 9) + PCH_FPB1: 0x00010c09 (n = 1, m1 = 12, m2 = 9) More stale timing bits, should be harmless. TRANS_HTOTAL_A: 0x057f04ff (1280 active, 1408 total) TRANS_HBLANK_A: 0x057f04ff (1280 start, 1408 end) TRANS_HSYNC_A: 0x05370517 (1304 start, 1336 end) @@ -94,12 +94,12 @@ TRANSA_DP_LINK_N1: 0x00000000 (val 0x0 0) TRANSA_DP_LINK_M2: 0x00000000 (val 0x0 0) TRANSA_DP_LINK_N2: 0x00000000 (val 0x0 0) - TRANS_HTOTAL_B: 0x00000000 (1 active, 1 total) - TRANS_HBLANK_B: 0x00000000 (1 start, 1 end) - TRANS_HSYNC_B: 0x00000000 (1 start, 1 end) - TRANS_VTOTAL_B: 0x00000000 (1 active, 1 total) - TRANS_VBLANK_B: 0x00000000 (1 start, 1 end) - TRANS_VSYNC_B: 0x00000000 (1 start, 1 end) + TRANS_HTOTAL_B: 0x053f03ff (1024 active, 1344 total) + TRANS_HBLANK_B: 0x053f03ff (1024 start, 1344 end) + TRANS_HSYNC_B: 0x049f0417 (1048 start, 1184 end) + TRANS_VTOTAL_B: 0x032502ff (768 active, 806 total) + TRANS_VBLANK_B: 0x032502ff (768 start, 806 end) + TRANS_VSYNC_B: 0x03080302 (771 start, 777 end) Ditto. TRANSB_DATA_M1: 0x00000000 (TU 1, val 0x0 0) TRANSB_DATA_N1: 0x00000000 (val 0x0 0) TRANSB_DATA_M2: 0x00000000 (TU 1, val 0x0 0) @@ -145,7 +145,7 @@ FDI_RXA_IMR: 0x000000ff FDI_RXB_IIR: 0x00000000 FDI_RXB_IMR: 0x000000ff - PCH_ADPA: 0x00f40000 (disabled, transcoder A, -hsync, -vsync) + PCH_ADPA: 0x40f40000 (disabled, transcoder B, -hsync, -vsync) VGA port is off, that's good. HDMIB: 0x00000018 (disabled pipe A 8bpc SDVO DVI audio disabled +vsync +hsync non-detected) HDMIC: 0x0000001c (disabled pipe A 8bpc SDVO DVI audio disabled +vsync +hsync detected) HDMID: 0x00000018 (disabled pipe A 8bpc SDVO DVI audio disabled +vsync +hsync non-detected) @@ -162,7 +162,7 @@ BLC_PWM_PCH_CTL1: 0x80000000 BLC_PWM_PCH_CTL2: 0x061a061a PCH_PP_STATUS: 0xc0000008 (on, ready, sequencing idle) - PCH_PP_CONTROL: 0x00000003 (blacklight disabled, power down on reset, panel on) + PCH_PP_CONTROL: 0xabcd0003 (blacklight disabled, power down on reset, panel on) Looks fine, we left it unlocked. PCH_PP_ON_DELAYS: 0x00fa09c4 PCH_PP_OFF_DELAYS: 0x00fa09c4 PCH_PP_DIVISOR: 0x00186903 Based on this, the most obvious thing would be to check that nothing is rendering in the background and taking extra power that way. If you're sure the GPU is idle (i.e. you can reproduce this with a plain X session + xterm, no fancy desktop stuff, using just xrandr to disable the display after disconnect) then we'll have to look at our disable ordering to make sure things are correct.
Created attachment 49859 [details] intel-drm-fixes, no KDE, before
Created attachment 49860 [details] intel-drm-fixes, no KDE, after
I'm guessing the "busy" GPU is due to compositing window manager (kwin)? Nothing was *really* busy there, it was an idle desktop. Anyway, as requested, I reproduced it without a WM, with just xterm windows. I attach the before/after register dumps. Comparing to the older ones though, the only difference I see is the GPU no longer being kept busy. I still see a power difference before and after of about 1W, if ACPI is to be believed.
Ok can you try drm-intel-next again? Maybe the panel lock was biting us.
Still about 1W difference before and after. There are some small differences in reg dumps. Here are diffs compared to older dumps from 3.0-based intel-drm-fixes: Before connecting: - PCH_PP_CONTROL: 0x00000003 (blacklight disabled, power down on reset, panel on) + PCH_PP_CONTROL: 0xabcd0003 (blacklight disabled, power down on reset, panel on) After disconnecting: - PIPEBCONF: 0x00000000 (disabled, inactive, 8bpc) + PIPEBCONF: 0x00000014 (disabled, inactive, 8bpc)
Ouping, is this something you can reproduce on any platform (ILK, SNB, or IVB)?
I reproduced this issue on IVB and SNB, there is similar issue, but isn't the same one. I have filed the bug 48902. deactivate the external display ("xrandr --output VGA1 --off") and disconnect it, the power usage falls down but never falls to the level of boot. (In reply to comment #21) > Ouping, is this something you can reproduce on any platform (ILK, SNB, or IVB)?
Timeout. Please do reopen if you can still reproduce the issue and help us diagnose the problem, thanks.
with the latest Kernel and Mesa, the bug has been fixed on SNB and IVB. (In reply to comment #23) > Timeout. Please do reopen if you can still reproduce the issue and help us > diagnose the problem, thanks.
(In reply to comment #24) > with the latest Kernel and Mesa, the bug has been fixed on SNB and IVB. > (In reply to comment #23) I don't know, I'm still seeing about 1W difference on SNB (which I think is better than it used to be -- thanks for your efforts, guys -- but I wouldn't call it fully resolved). Ouping, what kernel version/Mesa do I need? I'm running: kernel 3.6.6 xorg-server 1.12.4 xf86-video-intel 2.20.12 mesa 8.0.4 libdrm 2.4.37
with the following environment, Kernel_version: 3.1.0-7.fc16.i686.PAE Libdrm: (master)libdrm-2.4.40-1-g7d42b49c0cf19dbb4531cd84efae51f95db2eea1 Mesa: (master)1665af3066f3d58c42e9d5b13098f13615a7672c Xserver: (master)xorg-server-1.13.0-143-g6a6c3afe71ac82a93d9fd0034dd5bbdcf0eae1ea Xf86_video_intel: (master)2.20.13-9-g866ed4a26cbbb29ef3845b0aa56383c4d951c65a Cairo: (master)62b795fe52c73ad58101c101aa77449f4b61a576 Libva: (staging)38c94cd922473095814ed9a9f99ad98fcc9c285d Libva_intel_driver: (staging)e30019e8b90e67fb7599c27b94c30ae644f2ff07 Kernel_unstable: (drm-intel-nightly)628302221814f3c00858b5fcbc11df8f0c6f60d2 this issue can be reproduced again, Start X : 11.9 w connect VGA: 13.3 w xrandr --output VGA1 off: 12.5 w disconnect VGA, the power usage falls down but never falls to the level of boot. (In reply to comment #25) > (In reply to comment #24) > with the latest Kernel and Mesa, the bug has > been fixed on SNB and IVB. > (In reply to comment #23) I don't know, I'm > still seeing about 1W difference on SNB (which I think is better than it > used to be -- thanks for your efforts, guys -- but I wouldn't call it fully > resolved). Ouping, what kernel version/Mesa do I need? I'm running: > kernel 3.6.6 xorg-server 1.12.4 xf86-video-intel 2.20.12 mesa 8.0.4 libdrm > 2.4.37
This hasn't been tested in a long time. Can we either close, or retest with a more recent software stack? Ouping?
with the environment: Libdrm: (master)libdrm-2.4.45-4-g8a88e349975a64676f143183e835e6d296f29627 Mesa: (master)7bafd88c153e395274b632e7eae4bc9fc3aec1d2 Xserver: (master)xorg-server-1.14.99.1-119-gc21344add2fc589df83b29be5831c36a372201bd Xf86_video_intel: (master)2.21.8-19-g6dacaddb6a28670a52cead4b62c056a8acde8f3a Cairo: (master)85c2a0d76ab109f2bec8f7dccab577033e6d37b0 Libva: (staging)ef53340b19746589079d7ed5f9c67970fcc40401 Libva_intel_driver: (staging)9c698455fec340ced7dbf93cc5be004bb4a1eb22 Kernel_unstable: (drm-intel-nightly)62a719f8197badfb40dec7ab5da07974401eadac this issue can't be reproduced. xrandr --output VGA1 --auto 29.1w xrandr --output VGA1 --off 28.2w xinit X 28.2 the power usage falls down but never falls to the level of boot. (In reply to comment #27) > This hasn't been tested in a long time. Can we either close, or retest with > a more recent software stack? Ouping?
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.