|
Description
max
2012-05-09 05:58:14 UTC
Created attachment 61283 [details]
dmesg with drm.debug=0x06
Created attachment 61284 [details]
xrandr --verbose
Created attachment 61285 [details]
intel_reg_dumper
Created attachment 61286 [details]
VBIOS dump
Created attachment 61287 [details]
reg_dump after LVDS1->VGA1, [Ctrl+Alt+F1], [Alt+F7]
Created attachment 61288 [details]
reg_dump, back to LVDS1, again [Ctrl+Alt+F1], [Alt+F7]
Can you please clarify the status of the outputs when you took the regdumps? The issue sounds like inconsistent DPMS tracking as X switches outputs, but both the regdumps have the corresponding pipes enabled. Sorry, it was my fault. I took that regdumps after I restored image on the screen by pressing [Ctrl+Alt+F1], [Alt+F7]. A computer with blank screens is like a darkroom. I am adding two more regdumps when both displays was really blank, one after xrandr --output LVDS1 --off --output VGA1 --auto and after xrandr --output VGA1 --off --output LVDS1 --auto this time before [Ctrl+Alt+F1]... kernel 3.4.0-999-generic #201205110427 SMP i686 xserver-xorg-video-intel Version: 2:2.19.0+git20120509.a83d90ee-0ubuntu0sarvatt~precise xserver-xorg-core Version: 2:1.12.1.901+git20120510+server-1.12-branch.58dfb139-0ubuntu0ricotz~precise libgl1-mesa-dri Version: 8.1~git20120509.788fd04d-0ubuntu0sarvatt~precise libdrm-intel1 Version: 2.4.33+git20120504.d72a44c7-0ubuntu0ricotz~precise Created attachment 61459 [details]
regdump after LVDS1->VGA1, expected image on VGA1, actually both blank
Created attachment 61461 [details]
regdump after VGA1->LVDS1, expected image on LVDS1, actually both blank
Ok, to make our jobs a bit easier, can you also attach register dumps when VGA1 (respectively LVDS1) work, i.e. after you've restored the screen with a vt change? This way we can hunt for differences. Created attachment 61497 [details]
regdump after LVDS1->VGA1 and Ctrl+Alt..., as expected image on VGA1
Created attachment 61498 [details]
regdump after VGA1->LVDS1 and Ctrl+Alt..., as expected image on LVDS1
Sequence of regdumps xrandr --output LVDS1 --off --output VGA1 --auto both displays are blank https://bugs.freedesktop.org/attachment.cgi?id=61459 [Ctrl+Alt+F1], [Alt+F7], VGA1 works https://bugs.freedesktop.org/attachment.cgi?id=61497 xrandr --output VGA1 --off --output LVDS1 --auto both displays are blank https://bugs.freedesktop.org/attachment.cgi?id=61461 [Ctrl+Alt+F1], [Alt+F7], LVDS1 works https://bugs.freedesktop.org/attachment.cgi?id=61498 Should I add more info? I see that the bug still has NEEDINFO status. I think I should add some new regdumps. For the xserver-xorg-video-intel from ppa:intel-sna I noticed the following. 1. Switching to VGA1 usually works, but sometimes the external monitor remains dark 2. Switching to LVDS1 usually leads to dark screen. 3. Sometimes after switching to LVDS1 the screen is dim. I can restore brightness by pressing [Ctrl+Alt+F1] [Alt+F7] I launch X server by startx /usr/bin/xterm To switch between internal and external screen I use xrandr --output LVDS1 --off --output VGA1 --auto xrandr --output VGA1 --off --output LVDS1 --auto The kernel is from drm-intel-experimental: 3.4.0-994-generic #201206050409 SMP Tue Jun 5 08:17:32 UTC 2012 i686 i686 i386 GNU/Linux xserver-xorg-video-intel Version: 2:2.19.0+git20120521.afdaf184-0ubuntu0sarvatt2~sna~precise xserver-xorg-core Version: 2:1.12.2+git20120605+server-1.12-branch.aaf48906-0ubuntu0ricotz~precise libgl1-mesa-dri Version: 8.1~git20120529.f92b2e5e-0ubuntu0sarvatt~precise libdrm-intel1 Version: 2.4.34+git20120520.481234f2-0ubuntu0ricotz~precise Created attachment 62636 [details]
dmesg
Created attachment 62637 [details]
Xorg.0.log
Created attachment 62639 [details]
reg_dump after LVDS1->VGA1 (VGA1 dark)
Created attachment 62640 [details]
reg_dump after LVDS1->VGA1, vt7<->vt1 (normal image on VGA1)
Created attachment 62641 [details]
reg_dump VGA1->LVDS1 (no image on LVDS1)
Created attachment 62642 [details]
reg_dump after VGA1->LVDS1 vt7<->vt1 (normal image on LVDS1)
Hm, gen4 plus switching LVDS around causes a dim screen ... can you please try my backlight confusion branch from my personal git repo at http://cgit.freedesktop.org/~danvet/drm Created attachment 62644 [details]
reg_dump after VGA1->LVDS1 (dark image on LVDS1, low backlight)
Created attachment 62645 [details]
reg_dump after VGA1->LVDS1 and vt7<->vt1 (normal image on LVDS1, restored backlight)
I've updated my backlight-confusion branch with patches for gen4, can you please retest? Daniel, I am sorry for the delay. At first, please, check that I have grabbed the correct branch: commit d1f990f09d798c3ec040a73eb5eebcebaac665b0 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Jun 11 09:39:32 2012 +0200 debug patch: stop special-casing combination mode I have noticed no difference in behavior with this kernel. However intel_reg_dumps are not identical. I can post them if you are interested in them: blank VGA1 (and after restore), blank LVDS1 (and after restore), and dim LVDS1 (and after restore). Sometimes I see a a short blink of xterm image when I press [Ctrl+Alt+F1] and before the text at the console appears. (both #201206050409 and d1f990f kernels) In addition there are two different states of "black LVDS1". 1. Really black, no reaction on [Fn+F6] key (increase brightness) 2. Brightness can be increased to noticeable level (usual glow of black TN LCD screen), although no traces of image. If I press [Ctrl+Alt+F1] [Alt+F7], brightness switched to the previous dimmer level (as it was when I saw the xterm on LVDS1 last time). I can add that if I run not just an xterm but rather full ubuntu unity session, I get black screen after xrandr only in less than 1/3 cases. If xterm is the single xsrever client, screen remains black, until I press [Ctrl+Alt+F1] [Alt+F7], almost every time with current versions of the packages. xorg-edgers + drm-intel-experimental xserver-xorg-video-intel Version: 2:2.19.0+git20120613.0db789e1-0ubuntu0sarvatt~precise xserver-xorg-core Version: 2:1.12.2+git20120605+server-1.12-branch.aaf48906-0ubuntu0ricotz~precise libgl1-mesa-dri Version: 8.1~git20120529.f92b2e5e-0ubuntu0sarvatt~precise libdrm-intel1 Version: 2.4.35+git20120613.d1fcfb17-0ubuntu0sarvatt~precise kernel 3.4.0-994-generic #201206130406 SMP Wed Jun 13 08:15:01 UTC 2012 i686 i686 i386 GNU/Linux The bug still persists with xterm only session and Ubuntu drm-intel experimental kernel linux-image-3.5.0-994-generic 3.5.0-994.201207060407 (In reply to comment #29) > The bug still persists with xterm only session and Ubuntu drm-intel > experimental kernel linux-image-3.5.0-994-generic 3.5.0-994.201207060407 This has a massive chance of having been fixed int the modeset rework merged into 3.7. Please test with the latest 3.7-rc kernel and report back, thanks. Created attachment 70130 [details] dmesg, drm-intel-next/2012-11-14-raring Switching to LVDS1 works fine. Switching to VGA1 wakes up the external monitor, but no image appears before [Ctrl+Alt+F1], [Alt+F7] I hope, http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/2012-11-14-raring/ is new enough Commit: d640c4b09a5d83a8167eb09d22bd89d9fa7e3b91 Should I try mainline or drm-intel-nightly? Created attachment 70131 [details]
Xorg.0.log, 3.7.0-997-generic #201211140424
Created attachment 70132 [details]
intel_reg_dumper just after xrandr --output VGA1 --auto --output LVDS1 --off
Created attachment 70133 [details]
intel_reg_dumper with image on VGA1 (after [Ctrl+Alt+F1], [Alt+F7])
Difference of intel_reg_dumper reports just after xrandr and when image appeared on the external monitor after switching to vt and back. I do not like black screen after xrandr invocation.
@@ -26,9 +26,9 @@
SDVOC: 0x00080018 (disabled, pipe A, stall disabled, not detected)
SDVOUDI: 0x00000000
DSPARB: 0x00001d9c
- DSPFW1: 0xce080808
+ DSPFW1: 0x00880808
DSPFW2: 0x00000808
- DSPFW3: 0x20000000
+ DSPFW3: 0x10000000
ADPA: 0xc0000018 (enabled, pipe B, +hsync, +vsync)
LVDS: 0x02308300 (disabled, pipe A, 18 bit, 1 channel)
DVOA: 0x00000000 (disabled, pipe A, no stall, -hsync, -vsync)
@@ -48,12 +48,12 @@
PFIT_PGM_RATIOS: 0x08000800
PORT_HOTPLUG_EN: 0x00000220
PORT_HOTPLUG_STAT: 0x00000300
- DSPACNTR: 0x58000400 (disabled, pipe A)
+ DSPACNTR: 0x58000000 (disabled, pipe A)
DSPASTRIDE: 0x00001400 (5120 bytes)
DSPAPOS: 0x00000000 (0, 0)
DSPASIZE: 0x00000000 (1, 1)
DSPABASE: 0x00000000
- DSPASURF: 0x00428000
+ DSPASURF: 0x00040000
DSPATILEOFF: 0x00000000
PIPEACONF: 0x00000000 (disabled, inactive, progressive)
PIPEASRC: 0x04ff031f (1280, 800)
@@ -92,8 +92,8 @@
PIPEB_DP_LINK_M: 0x00000000
PIPEB_DP_LINK_N: 0x00000000
CURSOR_B_BASE: 0x00000000
- CURSOR_B_CONTROL: 0x00000000
- CURSOR_B_POSITION: 0x00000000
+ CURSOR_B_CONTROL: 0x10000000
+ CURSOR_B_POSITION: 0x0120005c
FPB0: 0x00010c09 (n = 1, m1 = 12, m2 = 9)
FPB1: 0x00010c09 (n = 1, m1 = 12, m2 = 9)
DPLL_B: 0x94020c00 (enabled, non-dvo, default clock, DAC/serial mode, p1 = 2, p2 = 10)
To clarify: With the new kernel LVDS1 works now, but VGA1 still (sometimes) has problems? Also, does the vt switch still resurrect it correctly? I did not test too much this time. The kernel was booted a couple of times. Two cycles LVDS1<->VGA1 each time. VGA1->LVDS1 was always fine, LVDS1->VGA1 always resulted in black screen (monitor on). Each time switching to vt and back restored the image. In regards to previous kernel versions, for some builds LVDS1 worked better, sometimes VGA1. Can you please retest with latest drm-intel-nightly from http://cgit.freedesktop.org/~danvet/drm-intel I've just merged two patches to adjust the pll limits for sdvo/lvds on gen3/4. 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/ X session launched with startx /usr/bin/xterm Switching to external display always results in dark screen, however the monitor is not in power saving regime. intel_reg_dumper before and after [Ctrl+Alt+F1] [Alt+F7] (dark screen vs. correct image with the xterm window) PFIT_PGM_RATIOS: 0x08000800 PORT_HOTPLUG_EN: 0x00000220 PORT_HOTPLUG_STAT: 0x00000300 - DSPACNTR: 0x58000400 (disabled, pipe A) + DSPACNTR: 0x58000000 (disabled, pipe A) DSPASTRIDE: 0x00001400 (5120 bytes) DSPAPOS: 0x00000000 (0, 0) DSPASIZE: 0x00000000 (1, 1) DSPABASE: 0x00000000 - DSPASURF: 0x00428000 + DSPASURF: 0x00040000 DSPATILEOFF: 0x00000000 PIPEACONF: 0x00000000 (disabled, inactive, progressive) PIPEASRC: 0x04ff031f (1280, 800) Switching to LVDS1 sometimes works correctly. Sorry, by I do not see any progress, probably some regress. Created attachment 76343 [details]
dmesg, drm.debug=0xe, black LVDS1
drm-intel-nightly kernel 2013-03-07
3.8.0-994-generic #201303070438 SMP Thu Mar 7 09:47:22 UTC 2013 i686 i686 i686 GNU/Linux
As usual, no problem in Ubuntu Unity session.
With "startx /usr/bin/xterm" external monitor (VGA1) is always dark
after switching, however it is waked up from power saving mode.
First switching back to internal screen (LVDS1) leads to dark screen,
after next one normal picture is shown.
The only difference in dmesg with drm.debug=0x0e just after switching
to LVDS1 is the following line
dark screen:
[ 165.792214] [drm:i9xx_update_plane], Writing base 00832000 00000000 0 0 5120
normal image:
[ 372.664238] [drm:i9xx_update_plane], Writing base 01042000 00000000 0 0 5120
Note 00832000 vs. 01042000
As usual, I have to press [Ctrl+Alt+F1], [Alt+F7] to bring the image back.
Is this still an issue on latest kernels? 3.12.0-994-generic #201311210459 SMP Thu Nov 21 10:09:54 UTC 2013 i686 i686 i686 GNU/Linux (ubuntu mainline drm-intel-nightly) [ 3.917667] [drm] initialized overlay support [ 4.085004] fbcon: inteldrmfb (fb0) is primary device [ 4.108135] ------------[ cut here ]------------ [ 4.108208] WARNING: CPU: 0 PID: 204 at /home/apw/COD/linux/drivers/gpu/drm/i 915/intel_panel.c:792 intel_panel_enable_backlight+0xca/0xd0 [i915]() [ 4.108223] Modules linked in: hid_a4tech ahci(+) r8169 libahci i915(+) usbhi d mii i2c_algo_bit hid drm_kms_helper video drm [ 4.108229] CPU: 0 PID: 204 Comm: modprobe Not tainted 3.12.0-994-generic #20 1311210459 [ 4.108230] Hardware name: ASUSTeK Computer Inc. F80L /F80L , BIOS 206 08/06/2008 [ 4.108240] 00000000 00000000 f5d6b884 c1675822 f8af35fc f5d6b8b4 c1056804 c 1876a24 [ 4.108247] 00000000 000000cc f8af35fc 00000318 f8abefda f8abefda f5f29800 f 54f0000 [ 4.108255] f54f13dc f5d6b8c4 c1056842 00000009 00000000 f5d6b8f0 f8abefda 0 0000004 [ 4.108256] Call Trace: [ 4.108266] [<c1675822>] dump_stack+0x41/0x52 [ 4.108273] [<c1056804>] warn_slowpath_common+0x84/0xa0 [ 4.108334] [<f8abefda>] ? intel_panel_enable_backlight+0xca/0xd0 [i915] ... [ 4.109022] [<c113f4ab>] ? vm_mmap_pgoff+0x8b/0xb0 [ 4.109027] [<c168854d>] sysenter_do_call+0x12/0x28 [ 4.109029] ---[ end trace 457ad49306518c8d ]--- [ 4.109031] ------------[ cut here ]------------ [ 4.109067] WARNING: CPU: 0 PID: 204 at /home/apw/COD/linux/drivers/gpu/drm/i915/intel_panel.c:342 intel_panel_compute_brightness+0x6a/0x70 [i915]() [ 4.109074] Modules linked in: hid_a4tech ahci(+) r8169 libahci i915(+) usbhid mii i2c_algo_bit hid drm_kms_helper video drm [ 4.109077] CPU: 0 PID: 204 Comm: modprobe Tainted: G W 3.12.0-994-generic #201311210459 ... [ 4.109932] WARNING: CPU: 0 PID: 204 at /home/apw/COD/linux/drivers/gpu/drm/i915/intel_panel.c:450 i9xx_set_backlight+0xe4/0xf0 [i915]() ... [ 4.110815] WARNING: CPU: 0 PID: 204 at /home/apw/COD/linux/drivers/gpu/drm/i915/intel_display.c:9460 check_crtc_state+0x285/0x360 [i915]() [ 4.110816] pipe state doesn't match! So I did not tested VGA/LVDS switching with this kernel 3.12.0-994-generic #201311220431 SMP Fri Nov 22 09:32:00 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux (ubuntu mainline drm-intel-nightly *x86_64*) Ubuntu-13.10 The problem with dark screen persists. Many warning in dmesg [ 22.266431] [drm] initialized overlay support [ 22.293106] fbcon: inteldrmfb (fb0) is primary device [ 22.316061] ------------[ cut here ]------------ [ 22.316120] WARNING: CPU: 0 PID: 363 at /home/apw/COD/linux/drivers/gpu/drm/i 915/intel_panel.c:792 intel_panel_enable_backlight+0xe0/0xf0 [i915]() [ 22.316145] Modules linked in: ath9k_hw snd_seq_device bnep snd_timer rfcomm ath microcode(+) snd mac80211 i915(+) btusb cfg80211 drm_kms_helper bluetooth ps mouse drm serio_raw soundcore lp parport asus_laptop lpc_ich i2c_algo_bit sparse _keymap input_polldev mac_hid video hid_a4tech usbhid hid ahci libahci r8169 mii [ 22.316149] CPU: 0 PID: 363 Comm: systemd-udevd Not tainted 3.12.0-994-generi c #201311220431 [ 22.316151] Hardware name: ASUSTeK Computer Inc. F80L /F80L , BIOS 206 08/06/2008 [ 22.316155] 0000000000000318 ffff88007a0bd468 ffffffff81742f52 0000000000000 086 [ 22.316158] 0000000000000000 ffff88007a0bd4a8 ffffffff8106783c 0000000000000 282 [ 22.316160] ffff880078d41800 ffff88007b238000 ffff88007b23a19c 0000000000000 246 [ 22.316161] Call Trace: [ 22.316171] [<ffffffff81742f52>] dump_stack+0x46/0x58 [ 22.316175] [<ffffffff8106783c>] warn_slowpath_common+0x8c/0xc0 http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/2013-11-16-trusty/ *i386* + kubuntu 13.04 The problem with dark screen persists (mainly with VGA1) Many warnings with call traces in dmesg. After several switches LVDS1<->VGA1 X server failed, image in text console did not update (frozen). So the bug has not been fixed. The recent kernel have serious problems with GM965/GL960. Unfortunately it is unlikely that I will be able to file bugs and test fixes in the near future. Hm, that WARN is actually fairly interesting, we seem to be unable to get a sane backlight value. It's been a recently added sanity check. Can you please upload a new drm.debug=0xe dmesg with the latest drm-intel-experimental build? Adding Jani (although he's on vacation right now), our residential backlight expert. Created attachment 89995 [details]
dmesg with drm-intel-nightly 2013-11-29 x86_64
Warnings in dmesg likely originate from another bug to be filed,
but I upload the requested log. It is just boot, no start of the xserver.
(In reply to comment #45) > Created attachment 89995 [details] > dmesg with drm-intel-nightly 2013-11-29 x86_64 > > Warnings in dmesg likely originate from another bug to be filed, > but I upload the requested log. It is just boot, no start of the xserver. The updated drm-intel-nightly should now have fixes for the warnings; please retry that and attach dmesg. Neither warnings nor blank screen after LVDS1<->VGA1 switching has gone away. I have filed Bug #74081 for the following message [drm:intel_pipe_config_compare] *ERROR* mismatch in gmch_pfit.lvds_border_bits (expected 32768, found 0) Sorry to say, I can only ask to please try current drm-intel-nightly from http://cgit.freedesktop.org/drm-intel and attach dmesg with drm.debug=0xe. We have fixed plenty of related bugs; not sure if this one is among them. Created attachment 98980 [details] dmesg with drm-intel-nightly 2014-05-13 x86_64 I am sorry, but the problem persists. I have got dark VGA1 screen 3 times. Last time I have switched to vt and back by [Ctrl+Alt+F1], [Alt+F7] to restore the image. Picture on the LVDS1 display has normally appeared all three times with no additional kicks. I downloaded generic x86_64 kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2014-05-13-utopic/ I am attaching the kernel dmesg log taken with drm.debug=0x0e. Display manager was disabled. Ping for a retest on current drm-intel-nightly. Surprisingly yesterday's drm-intel-nightly ubuntu build works correctly. I have tested x86_64 kernel. I have not seen dark screen neither on LVDS1 not VGA1. The only issue is that if X server is stopped when only VGA1 is active (LVDS1 is switched off), backlight level of LVDS1 gets lowest value so the image is very dim. Before the start of X server and during the test LVDS1 has normal brightness if it is active. I have to restore brightness by Fn+F6 hotkey. However it is not related to this bug. I think now the bug may be closed since the original problem has gone away. As regards the backlight bug, all I can suggest is trying different versions of the kernel and ddx. It's likely just that no one resets the backlight after turning it off for a modeset on vt switch. |
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.