I'm running on a new Intel NUC d54250wyk. If I boot the system with my Dell U3011 plugged in, I see a blank screen instead of X. Switching to a console VT looks fine, and then trying to switch back to X results in me seeing the desktop for a second, then the picture starts flickering and goes blank. The following scenarios work fine: 1) I plug in my U2410 over HDMI and boot with that 2) I boot with no display attached and then plug in the U3011 3) I run with the U2410, then suspend, then resume with the U3011 plugged in. So it seems very specific to this case of booting with the display present.
(In reply to Philip Langdale from comment #0) > I'm running on a new Intel NUC d54250wyk. > > If I boot the system with my Dell U3011 plugged in, I see a blank screen > instead of X. Switching to a console VT looks fine, and then trying to > switch back to X results in me seeing the desktop for a second, then the > picture starts flickering and goes blank. > > The following scenarios work fine: > > 1) I plug in my U2410 over HDMI and boot with that > 2) I boot with no display attached and then plug in the U3011 > 3) I run with the U2410, then suspend, then resume with the U3011 plugged in. > > So it seems very specific to this case of booting with the display present. Please attach dmesgs from early boot, with drm.debug=0xe module parameter set, for both the reported problem *and* the working case #2. Thanks.
Oh, which kernel version are you using? Please try at least 3.12 or later.
Kernel 3.12.5 and also tested with 3.13.rc3. No difference.
Created attachment 119051 [details] Failure when turning on machine with U3011 plugged in
Created attachment 119061 [details] Failure when turning on machine with U3011 not plugged in and plugged in after X starts Turns out that from a cold start, plugging in the display later doesn't help. I have to reboot with the display off and then turn it on after X starts for it to work.
Created attachment 119071 [details] Success when rebooting with U3011 off and turning it on after X starts
Philip, please attach your Xorg.0.log. Chris, please have a look at this. I fail to see anything wrong in the dmesg; I suspect userspace, but I suck at debugging there...
The Xorg.0.log at default logging level trivially doesn't show any errors or warnings, so it'll be a waste of time for me to attach that. What debug level do you need?
Please just attach the Xorg.0.log. Thanks.
Created attachment 121111 [details] Xorg log when things don't work
Created attachment 121121 [details] Xorg log when things do work
Done
Can you please also test latest drm-intel-nightly from http://cgit.freedesktop.org/~danvet/drm-intel/ Might be that we've improved the situation a bit meanwhile - your descriptions sounds an awful lot like there's some underrun. Also, when you restore the display momentarily with a vt switch and the go back to X, are there any underruns reported in dmesg (dmesg | grep underrun, you need drm.debug=0xe enabled)? There's one at boot for the failing case ...
Created attachment 121301 [details] dmesg output with drm-intel-nightly for initial boot with no display
Created attachment 121311 [details] dmesg output with drm-intel-nightly for initial boot with no display after vt switch back and forth
I tried running with drm-intel-nightly and attached dmesg logs for it. No change in the display behaviour. You can see from the logs that there is no additional underrun reported after the VT switch with the brief flickering X display visible. Also, drm-intel-nightly locked up all the time. When I tried to boot it normally with the hdmi display, it locked up after a few seconds at the desktop. In the displayport case it locked up when I tried to reboot - apparentling in the fb panning code. I have panic logs but that's a separate problem and perhaps you know what's going on there already. Do you guys have access to one of these machines? It is an Intel product. :-)
Appears to be fixed in 3.14 final, but I couldn't tell you why.
Hm, I guess we'll take that. Thanks for your report and please reopen if the issue resurfaces.