Created attachment 69006 [details] dmesg acquired when the monitor was flickering External monitor connected to VGA1 port of a laptop sometimes starts flickering with red stripes, when it is supposed to be in power saving mode. I have not found a short way to reproduce the issue, but I have seen it almost every time last time. Many bugs that manifested themselves after switches between LVDS1 and VGA1 screens where fixed last months. That is why a dozen of [Fn+F8] become a usual test of new kernels on my laptop. Ubuntu Unity desktop + extreme tux racer or Google Earth usually makes a problem apparent. The attached files were gathered after an unsuccessful attempt to reproduce the issue with xrandr command in X started by "startx /usr/bin/xterm" command. After that I disconnected the external monitor, started lightdm, logged in, connected the monitor again and pressed [Fn+F8] several times. At certain moment the desktop switched to built-in screen LVDS1, VGA1 should be off and xrandr reported that VGA1 was disabled, but there were flashes with red stripe at random position approximately one per second on the monitor. The following commands xrandr --output VGA1 --auto xrandr --output VGA1 --off put the monitor to power saving mode. lspci: 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 03) 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) (rev 03) i386 system and kernel is installed Versions of graphics-related packages: xserver-xorg-video-intel Version: 2:2.20.9-0ubuntu2 xserver-xorg-core Version: 2:1.13.0-0ubuntu6 libgl1-mesa-dri Version: 9.0-0ubuntu1 libdrm-intel1 Version: 2.4.39-0ubuntu1 Kernel: 3.7.0-994-generic #201210230423 SMP Tue Oct 23 08:32:20 UTC 2012 i686 i686 i686 GNU/Linux from http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-experimental/2012-10-23-raring/ Just installed Ubuntu 12.10 Asus F80L laptop External monitor (LG L2000CP) connected through VGA connector
Created attachment 69007 [details] Xorg.0.log
Created attachment 69008 [details] intel_reg_dumper, monitor flickering
Created attachment 69009 [details] intel_reg_dumper, monitor in power saving regime, after xrandr
Created attachment 69010 [details] intel_reg_dumper, xterm-only session, monitor in power saving mode This intel_reg_dumper was taken as a reference before others in startx /usr/bin/xterm session. The monitor is in power saving mode as expected. Note the following line at the end of the file SDVO phase shift 5 out of range -- probobly not an issue. At least the spelling "probobly" is an issue There are some not so good lines in dmesg [ 19.728105] [drm:intel_panel_setup_backlight] *ERROR* Failed to get maximum backlight value [ 20.484043] i915: fixme: max PWM is zero
(In reply to comment #4) > There are some not so good lines in dmesg > [ 19.728105] [drm:intel_panel_setup_backlight] *ERROR* Failed to get > maximum backlight value I wonder what kernel you're really running. That message has been demoted to debug level since v3.7. Please try with a "real" v3.7 or v3.8-rc2 or later, and if you can, reproduce the original problem with the drm.debug=0xe module parameter, and attach the dmesg. > [ 20.484043] i915: fixme: max PWM is zero I realize that we don't properly handle this case. We no longer create a userspace backlight interface in this case, but we still try to handle ACPI backlight methods, which is bound to be buggy. However, the two messages you see above are not related to any of the reported external monitor issues at all. If you have any LVDS backlight issues, that's another story - and another bug should be filed for that. Please check the reported problem with a new kernel.
A quick test shows that linux-image-3.8.0-999-generic_3.8.0-999.201301090432_i386.deb (mainline 2013-01-09) is affected by this bug, but with linux-image-3.8.0-994-generic_3.8.0-994.201301090406_i386.deb (drm-intel-nightly) external monitor correctly switches to stand-by regime. I should check it more carefully. Previously posted logs were taken with the kernel built from commit 397fe15715ef1457d89f52666d0e249eb5eae64c
(In reply to comment #6) > A quick test shows that > linux-image-3.8.0-999-generic_3.8.0-999.201301090432_i386.deb > (mainline 2013-01-09) is affected by this bug, but > with > linux-image-3.8.0-994-generic_3.8.0-994.201301090406_i386.deb > (drm-intel-nightly) external monitor correctly switches to stand-by regime. > I should check it more carefully. Please do, thanks.
Terrible, fresh kernels crash with no messages in logs when I plug AC adapter... Ok, It is not connected to i915. Two consequent cold boots of 3.8.0-994-generic #201301090406 SMP Wed Jan 9 09:18:02 UTC 2013 i686 i686 i686 GNU/Linux kernel (drm-intel-nightly) lead to different results. Sometimes cycle with [Fn+F8] hotkey goes through the state when external monitor is in standby regime. But when external monitor "duplicates" laptop screen (neglecting 800-768 bottom pixels that are absent on the external monitor) there is no Unity launchbar (left panel) on both screens. Another variant is that after several press of [Fn+F8] hotkey narrow stripes flashing on the external monitor when it must be in standby state. However in this case Unity launchbar does not disappear from the "duplicated" screens. intel_reg_dumper files have not so much common lines. When external monitor is in the power saving regime Xorg.0.log contains the following lines: [ 128.469] (II) intel(0): EDID vendor "GSM", prod id 20025 [ 128.469] (II) intel(0): Using hsync ranges from config file [ 128.469] (II) intel(0): Using vrefresh ranges from config file [ 128.469] (II) intel(0): Printing DDC gathered Modelines: [ 128.469] (II) intel(0): Modeline "1600x1200"x0.0 130.00 1600 1648 1680 1760 1200 1203 1207 1235 +hsync +vsync (73.9 kHz eP) [ 128.469] (II) intel(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) [ 128.469] (II) intel(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz e) [ 128.470] (II) intel(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e) [ 128.470] (II) intel(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz e) [ 128.470] (II) intel(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz e) [ 128.470] (II) intel(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz e) [ 128.470] (II) intel(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) [ 128.470] (II) intel(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz e) [ 128.470] (II) intel(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz e) [ 128.470] (II) intel(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz e) [ 128.470] (II) intel(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz e) [ 128.470] (II) intel(0): Modeline "1024x768"x0.0 94.50 1024 1072 1168 1376 768 769 772 808 +hsync +vsync (68.7 kHz e) [ 128.470] (II) intel(0): Modeline "800x600"x0.0 56.25 800 832 896 1048 600 601 604 631 +hsync +vsync (53.7 kHz e) [ 128.470] (II) intel(0): Modeline "1600x1200"x0.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz e) [ 128.492] (II) intel(0): Allocated new frame buffer 2880x1200 stride 11776, tiled [ 132.783] (II) intel(0): EDID vendor "AUO", prod id 17476 [ 132.783] (II) intel(0): Printing DDC gathered Modelines: [ 132.783] (II) intel(0): Modeline "1280x800"x0.0 68.94 1280 1301 1333 1408 800 803 808 816 -hsync -vsync (49.0 kHz eP) [ 132.935] (II) intel(0): Allocated new frame buffer 1280x800 stride 5120, tiled Only the following lines (repeated several times) are in Xorg.0.log when the external monitor is flashing with stripes [ 125.348] (II) intel(0): EDID vendor "AUO", prod id 17476 [ 125.348] (II) intel(0): Printing DDC gathered Modelines: [ 125.348] (II) intel(0): Modeline "1280x800"x0.0 68.94 1280 1301 1333 1408 800 803 808 816 -hsync -vsync (49.0 kHz eP) [ 125.426] (II) intel(0): Allocated new frame buffer 1280x800 stride 5120, tiled Which logs (dmesg, Xorg.0.log, intel_reg_dumper) would you like to have?
I have some test results with recent drm-intel-nightly kernel (as a general impression, it works well enough): 3.8.0-994-generic #201302150406 SMP Fri Feb 15 09:16:52 UTC 2013 i686 i686 i686 GNU/Linux commit 2f5d6b55e082078d554f96f699243f65af719e68 http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2013-02-15-raring/ It seems that the bug is reproducible in Unity session with switching displays by the [Fn+F8] keystroke. I changed wallpaper and the color of the flashing stripe sometimes looks similar to the new background. If I switch to vt and back by [Ctrl+Alt+F1], [Alt+F7] when the external display is flashing, the monitor correctly goes to power saving regime. Unfortunately, only till the next cycle with [Fn+F8] hotkey. If I stop X server and start it again (stop lightdm; start lightdm) then the external monitor switches to the power saving regime as it should.
Can you also reproduce this when changing the monitor configuration with xrandr instead of [Fn+F8]? It could be that the BIOS intercepts this and creates complete havoc with the display configuration the kernel has set up.
On second thought, your SDVO output issue was probably fixed in commit afcac370645d78b3b2457f62c5a0f621324a141f Author: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Date: Wed Feb 13 22:20:22 2013 +0100 drm/i915: Set i9xx sdvo clock limits according to specifications
The patch is in the drm-intel-nightly ppa, isn't it? 3.8.0-994-generic #201302180405 SMP Mon Feb 18 09:15:43 UTC 2013 i686 i686 i686 GNU/Linux 4e5f64bc1d21abbce9ed70d929e553c11f47e912 With xrandr I hit the Bug 49688. I do not feel any difference with the latest kernel. Concerning whether the bug is reproducible. I realized that the order, in which the display switches, varies from time to time. (Unity saves something?) The external monitor does not go to power saving regime if previous state was VGA1 only and the new state is LVDS1 only. It seems that both displays or "cropped" mirror regime do not cause the problem. To avoid possible hassle with BIOS, I have tried to switch displays from the GUI (System settings -> Displays). The external monitor do not want to sleep if I switch display from VGA1 to LVDS1. Ignoring dark screen state, the bug can be reproduced with xrandr too. So it does not matter how I switch displays, the point is the certain order, namely VGA1 only -> LVDS1 only.
A patch referencing this bug report has been merged in Linux v3.9-rc1: commit 4f7dfb6788dd022446847fbbfbe45e13bedb5be2 Author: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Date: Wed Feb 13 22:20:22 2013 +0100 drm/i915: Set i9xx sdvo clock limits according to specifications
Not sure, but are we really doing VGA over SDVO here or could it be ADPA? If so, ADPA is bound to the wrong pipe when the problem occurs and thus never turns HSYNC or VSYNC off. I have no idea why the pipe changes yet but it wouldn't hurt setting it again in intel_crt_set_dpms(). Would you like a patch for this or am I way off?
(In reply to comment #14) > Not sure, but are we really doing VGA over SDVO here or could it be ADPA? If > so, ADPA is bound to the wrong pipe when the problem occurs and thus never > turns HSYNC or VSYNC off. There should be special bits for the VGA dpms state to turn of h/vsync. See intel_crt_set_dpms > I have no idea why the pipe changes yet but it wouldn't hurt setting it > again in intel_crt_set_dpms(). Would you like a patch for this or am I way > off? As long as ADPA is disabled, we should be fine (bit31) and the selected pipe (bit30) shouldn't affect anything ... I'm still confused what's going on here. The SDVO issue was a red herring, it doesn't look like it's used on your system. Another thing to try is to enable debug output with drm.debug=0xe and then grab a dmesg both when the mode switching works and when it doesn't. I suspect something in the exact ordering is slightly different, which then brings up a bug somewhere.
Created attachment 75954 [details] dmesg, drm.debug=0xe, red stripes 3.8.0-994-generic #201303050407 SMP Tue Mar 5 09:20:15 UTC 2013 i686 i686 i686 GNU/Linux (drm-intel-nightly kernel) echo 0xe > /sys/module/drm/parameters/debug and switch from VGA1 only to LVDS1 only from Display settings GUI
Created attachment 75956 [details] dmesg, drm.debug=0xe, external monitor in power saving mode echo 0xe > /sys/module/drm/parameters/debug and switch from LVDS1 auto (1280x800) + VGA1 auto (1600x1200) to LVDS1 only using Display Settings GUI
Created attachment 75962 [details] [review] [PATCH] drm/i915: Turn off hsync and vsync on ADPA when disabling crt Max, could you please try the following patch? Thanks
Dear Patrik, I can not reproduce the bug if your patch is applied. It seems it works. I wonder if it can be safely applied to the stable kernel (3.8.2)?
Patch merged to drm-intel-fixes with cc:stable as commit f40ebd6bcbbd0d30591f42dc16be52b5086a366b Author: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Date: Tue Mar 5 14:24:48 2013 +0100 drm/i915: Turn off hsync and vsync on ADPA when disabling crt Unfortunately git fdo is down, so you can't (yet) see the commit. Should show up in a stable release as soon as the patch trickled through all the different trees. Thanks for reporting this bug, I think we now have them all fixed.
A short test have shown that the patch applied to 3.8.2 fixes the issue as well. Thank you for working on this bug.
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.