We would like to see a dmesg from boot and from after connecting (but not even enabling) the VGA monitor with drm.debug=6 on the kernel commandline.

Created attachment 94603 [details]
dmesg after boot  drm.debug=6

attached is dmesg after boot  drm.debug=6

Created attachment 94604 [details]
dmesg after vga connect (then disconnect)

attached is dmesg after vga connected (screen goes black), then disconnected

For my sanity, please add i915.enable_fbc=0 to your boot commandline.

Created attachment 94610 [details]
dmesg after boot  drm.debug=6 i915.enable_fbc=0

dmesg after boot  drm.debug=6  i915.enable_fbc=0  (not sure this reduced the output significantly)

Created attachment 94611 [details]
dmesg after vga connect (then disconnect)  drm.debug=6  i915.enable_fbc=0

dmesg after connect vga (monitor off) then disconnect

Right, it didn't actually disable FBC. Using i915.ko as a module? I guess you will need to add i915.enable_fbc as a module parameter then - e.g.
echo "options i915 enable_fbc=0" >> /etc/modprobe.d/i915.conf

And you may also need to rebuild any initramfs.

I did this

echo "options i915 enable_fbc=0" >> /etc/modprobe.d/i915.conf

and rebooted, but output of dmesg looks very similar.  How can I tell if fbc has been disabled?

> And you may also need to rebuild any initramfs.

I'm not quite sure how to do this with Mageia 3.  Doesn't dracut take care of this automagically?

(In reply to comment #8)
> I did this
> 
> echo "options i915 enable_fbc=0" >> /etc/modprobe.d/i915.conf

We've renamed the parameter for consistency. It's still i915_enable_fbc in Linus' tree, but enable_fbc in -nightly. See 'modinfo i915 | grep enable_fbc' or 'ls /sys/module/i915/parameters/*enable_fbc' for which one you have.

> and rebooted, but output of dmesg looks very similar.  How can I tell if fbc
> has been disabled?

'cat /sys/module/i915/parameters/*enable_fbc'

'modinfo i915 | grep enable_fbc' or 'ls /sys/module/i915/parameters/*enable_fbc' yields  

/sys/module/i915/parameters/i915_enable_fbc

so I put

options i915_enable_fbc=0

into /etc/modprobe.d/i915.conf

After a reboot, cat /sys/module/i915/parameters/*enable_fbc  yields  -1.

which I assume means it is not disabled.  What else must I do?

Created attachment 95217 [details]
dmesg after boot  drm.debug=6 i915.i915_enable_fbc=0

Adding the kernel option   i915.i915_enable_fbc=0 seems to have worked.

Created attachment 95219 [details]
dmesg after vga connect (then disconnect)  drm.debug=6  i915.i915_enable_fbc=0

Attached is the dmesg  right after connecting to the vga monitor (laptop screen and external monitor both go black), then disconnect (laptop screen comes back)

Looks like userspace is switching off the eDP when the external monitor is plugged in.

Can you check the output of "xrandr"?

Here is the output of xrandr

Screen 0: minimum 320 x 200, current 1366 x 768, maximum 32767 x 32767
eDP1 connected primary 1366x768+0+0 (normal left inverted right x axis y axis) 309mm x 174mm
   1366x768       60.0*+
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        59.9  
DP1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)




Do you need xrandr when the vga monitor is connected?  Since the screen goes black then, and response to the keyboard is unknown, this might be difficult.

(In reply to comment #14)
> Do you need xrandr when the vga monitor is connected?  Since the screen goes
> black then, and response to the keyboard is unknown, this might be difficult.

Yes. If you have trouble, try using ssh to remotely login.

I expect that with the monitor connected, you will see that eDP is registered as connected by has no mode set.

I connect the vga monitor to my laptop, then my laptop and external monitor (turned on) go blank.  I log in remotely via ssh to my laptop from another machine, then when I issue  "xrandr -q --display :0.0", nothing happens for about 30 seconds, then I receive

Screen 0: minimum 320 x 200, current 2646 x 1024, maximum 32767 x 32767
eDP1 connected primary 1366x768+0+0 (normal left inverted right x axis y axis) 309mm x 174mm
   1366x768       60.0*+
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        59.9  
DP1 connected 1280x1024+1366+0 (normal left inverted right x axis y axis) 376mm x 301mm
   1280x1024      60.0*+   75.0  
   1152x864       75.0  
   1024x768       75.1     60.0  
   800x600        75.0     60.3  
   640x480        75.0     60.0  
   720x400        70.1  
HDMI1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)

and both the monitor and laptop screen come alive!  Only there is a horizontal shift of the picture on both screens.

Created attachment 95719 [details]
udevadm monitor --property

FYI, when I issue  udevadm  monitor --property

and then connect and disconnect the VGA monitor, the output is attached.  I wonder if the backlight/acpi_video0  has something to do with the problem?

Please boot with drm.debug=0xe, repeat exactly what you have done in comment #16 and then immediately grab dmesg and attach it here. Hopefully the debug logs will shed a light on what exact funny thing is going on in your box in those 30s.

OK, I'll try this when I get back to my office.  

Additional remark:  I made a udev rule that runs a script which basically sleeps for a while when the kernel detects a drm change.  Now when I plug in an external monitor, that script runs, so I can still use the laptop.   With the external monitor plugged in and my sleeping script running,  I issue an "xrandr -q" command from a terminal window, and the screen goes blank.  Why should a mere query do this?  Hopefully this provides additional info to figure out the problem.

The query probes the hw, and that's where something seems to go wrong. That's why we need to the logfiles to see what exactly is going on, where the huge delay happens and what could be the cause. Behavioral descriptions without logs to correlate aren't too telling.

Created attachment 96464 [details]
dmesg from xrandr logged in from other machine

booted with drm.debug=0xe i915.i915_enable_fbc=0    logged in from other machine,  plugged in monitor (screens blank),  issued   xrandr -q --display :0.0 ,  nothing happens for more than 2 minutes (could not reproduce previous behavior), hit ctrl-C,  dmesg > file,   file attached

Created attachment 96465 [details]
dmesg after xrandr -q  (again)

I put back in my udev rule,  connected the monitor (nothing happens),  then issued the "xrandr -q" command on the laptop.  screens go black,  then from other machine I did a dmesg.   Probably redundant info, but here it is anyways.

Created attachment 96466 [details]
dmesg after remove monitor connection...laptop screen comes back

I unplugged monitor,  laptop screen comes back,  dmesg attached (FYI)

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.

Very frustrating.  When I connect a monitor with HDMI,  I can get at least one screen working and I am able to F8 between the monitor and my laptop screen.  I can't get both screens simultaneously working.   xrandr with the VGA monitor always causes both screens to go black.  What a pain.

Is there another video driver I could try?  This linux intel driver does not seem to work with my machine.  I don't know if this is a driver bug, or the mageia people did not compile it so that it works with a dell laptop.

Well, at least I can make my presentations using linux, copy to a flash drive, and boot into Windows 8 for connecting to a projector. The Windows OS works fine for connecting to external monitors.  Thanks for your help.

Found some time to get back to this.  With udev rules preventing immediate blanking when the external monitor is plugged in, might be able to track down source of problem.  Compiled xrandr source to try to locate what part of code is blanking the screen.   Blanking occurs in the call to  XRRGetScreenInfo.
Only a problem when a VGA monitor is plugged in.  HDMI connection works okay.  Since I know nothing about X11 and the i915, I guess I'll just swim upstream through the code until I arrive at the problem.  Next, I'll try to locate where in XRRGetScreenInfo things are going awry.

The blanking occurs in a call to  _XReply (dpy, (xReply *) &rep, 0, xFalse).  Not sure this is helping, but this takes me into the x11 extensions.  Hopefully will soon get into the driver.

RESOLVED!  Updating to the kernel 3.12.18  Mageia 4 seems to have solved this problem!  Yeah!  Hurray!  Or perhaps one of the other updated packages solved the problem.  Good bye and thanks for your help.

(In reply to comment #28)
> RESOLVED!  Updating to the kernel 3.12.18  Mageia 4 seems to have solved
> this problem!  Yeah!  Hurray!  Or perhaps one of the other updated packages
> solved the problem.  Good bye and thanks for your help.

Thanks for the report; I'm glad it works for you now. Would be nice to know what fixed it eventually, but I guess we can't have everything, every time.