<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEEDINFO "
title="NEEDINFO --- - Dell Latitude E5440 screen goes blank when external VGA monitor connected"
href="https://bugs.freedesktop.org/show_bug.cgi?id=75385#c24">Comment # 24</a>
on <a class="bz_bug_link
bz_status_NEEDINFO "
title="NEEDINFO --- - Dell Latitude E5440 screen goes blank when external VGA monitor connected"
href="https://bugs.freedesktop.org/show_bug.cgi?id=75385">bug 75385</a>
from <span class="vcard"><a class="email" href="mailto:daniel@ffwll.ch" title="Daniel Vetter <daniel@ffwll.ch>"> <span class="fn">Daniel Vetter</span></a>
</span></b>
<pre>The logs look pretty sane and not really out of the ordinary. Normal detect
plus then a modeset, all not taking unduly long. But this here in the last file
doesn't look good:
[ 841.799204] INFO: task kworker/0:0:4 blocked for more than 120 seconds.
[ 841.799215] Not tainted 3.12.13-desktop-2.mga4 #1
[ 841.799219] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 841.799224] kworker/0:0 D ffff88011ea13e40 0 4 2 0x00000000
[ 841.799320] Workqueue: events ironlake_panel_vdd_work [i915]
[ 841.799326] ffff880119b2bd80 0000000000000046 ffff880119b2bfd8
0000000000013e40
[ 841.799335] ffff880119b2bfd8 0000000000013e40 ffff880119b0c500
ffff880118c8db30
[ 841.799344] ffff880118c8db34 ffff880119b0c500 00000000ffffffff
ffff880118c8db38
[ 841.799353] Call Trace:
[ 841.799371] [<ffffffff81614e39>] schedule_preempt_disabled+0x29/0x70
[ 841.799381] [<ffffffff81612f62>] __mutex_lock_slowpath+0x132/0x1b0
[ 841.799391] [<ffffffff81612fff>] mutex_lock+0x1f/0x30
[ 841.799444] [<ffffffffa00c81b5>] ironlake_panel_vdd_work+0x25/0x40 [i915]
[ 841.799455] [<ffffffff8107b15c>] process_one_work+0x17c/0x410
[ 841.799463] [<ffffffff8107bd41>] worker_thread+0x121/0x3b0
[ 841.799472] [<ffffffff8107bc20>] ? rescuer_thread+0x320/0x320
[ 841.799481] [<ffffffff81082750>] kthread+0xc0/0xd0
[ 841.799489] [<ffffffff81082690>] ? kthread_create_on_node+0x120/0x120
[ 841.799500] [<ffffffff8161e70c>] ret_from_fork+0x7c/0xb0
[ 841.799508] [<ffffffff81082690>] ? kthread_create_on_node+0x120/0x120
Have you seen that every time it takes forever?
Also can you please build your kernel with CONFIG_PROVE_LOCKING and rehang your
machines. lockdep might be able to shed some lights on what's going on here -
something seems to deadlock, which isn't pretty.
The eDP1 probing also looks sane so eDP1 going off doesn't look like a kernel
issue. And indeed in
[ 55.008400] [drm:intel_crtc_set_config], [CRTC:3] [FB:39] #connectors=1 (x
y) (1366 0)
[ 55.008406] [drm:intel_set_config_compute_mode_changes], modes are
different, full mode set
[ 55.008408] [drm:drm_mode_debug_printmodeline], Modeline 24:"1366x768" 60
76300 1366 1414 1446 1610 768 771 776 790 0x48 0xa
[ 55.008414] [drm:drm_mode_debug_printmodeline], Modeline 40:"" 0 108000 1280
1328 1440 1688 1024 1025 1028 1066 0x0 0x5
[ 55.008420] [drm:intel_set_config_compute_mode_changes], computed changes
for [CRTC:3], mode_changed=1, fb_changed=1
[ 55.008424] [drm:intel_modeset_stage_output_state], [CONNECTOR:10:eDP-1] to
[NOCRTC]
[ 55.008427] [drm:intel_modeset_stage_output_state], encoder changed, full
mode switch
[ 55.008430] [drm:intel_modeset_stage_output_state], encoder changed, full
mode switch
[ 55.008433] [drm:intel_modeset_stage_output_state], [CONNECTOR:19:DP-1] to
[CRTC:3]
[ 55.008435] [drm:intel_modeset_stage_output_state], crtc changed, full mode
switch
[ 55.008437] [drm:intel_modeset_stage_output_state], crtc changed, full mode
switch
we see that userspace asks for DP1 to be used instead of eDP1. No idea why
running xrandr made things work again earlier. I guess you should try to
reproduce that scenario and grab logs for it.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
<li>You are on the CC list for the bug.</li>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>