Created attachment 62710 [details] dmesg dump I'm seeing this issue with both snb and ivb, my nice Samsung is getting turned off every now and then for no apparent reason. But I did take a debug dump from dmesg, which is attached. According to Chris the monitor doesn't respond to a periodic probe and is declared as disconnected. Currently running 3.4, happens on earlier kernels as well.
Specifically, this output_poll: [923495.437620] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5013003e [923495.444818] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5013003e [923495.452772] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5013003e [923495.460233] [drm:intel_dp_detect], DPCD: 110a840101000100 [923495.460241] [drm:output_poll_execute], [CONNECTOR:13:DP-1] status updated from 1 to 2 So the intel_dp_detect_dpcd() fails to retrieve communicate with the monitor and we give up in a huff.
Created attachment 62715 [details] [review] disable all hdmi connectors Jesse has a system where doing HDMI detection on the same digital port totally confuses the attached DP display. To test whether your system suffers from the same problems, please test with this quick debug patch which disables all HDMI outputs. Note that with this patch only DP monitors will work on external connectors.
Created attachment 62782 [details] another dmesg dump I added that patch, but looks like it didn't work. Attached another dmesg dump with drm.debug=0x06, the interesting bits are towards the end.
also, this time I'm using 3.2.19 + some backport hang fixes, but I doubt it matters here..
Just to check: Does your problem of the dp screen disappearing correlate with: [47766.404715] [drm:intel_dp_check_link_status], TMDS-9: channel EQ not ok, retraining [47766.404927] [drm:intel_dp_start_link_train], training pattern 1 signal levels 00000000 [47766.405653] [drm:intel_dp_start_link_train], training pattern 1 signal levels 02000000 [47766.406376] [drm:intel_dp_start_link_train], training pattern 1 signal levels 06000000 [47766.407098] [drm:intel_dp_start_link_train], training pattern 1 signal levels 00000000 [47766.407820] [drm:intel_dp_start_link_train], training pattern 1 signal levels 06000000 [47766.408541] [drm:intel_dp_start_link_train], training pattern 1 signal levels 00000000 [47766.409263] [drm:intel_dp_start_link_train], training pattern 1 signal levels 06000000 [47766.409985] [drm:intel_dp_start_link_train], training pattern 1 signal levels 00000000 [47766.410707] [drm:intel_dp_start_link_train], training pattern 1 signal levels 06000000 [47766.411428] [drm:intel_dp_start_link_train], training pattern 1 signal levels 00000000 [47766.412150] [drm:intel_dp_start_link_train], clock recovery OK in demsg?
Oh and: Can you please boot with drm.debug=0xe and attach the full dmesg, just so we know what your system looks like? While at it, also please attacht the output of xrandr --verbose, thanks.
Created attachment 62880 [details] xrandr --verbose the system is a Maho-Bay SDP, I'll get the dmesg dump after a fresh boot later. Attached xrandr --verbose output.
The entries you pasted are after I turned the monitor back on. I took another pair of dumps now, one right after it turned off and another one after turning it back on, and the diff shows that the second "PCH HDCP audio interrupt" is output when the monitor has been turned on. The first one is when things start to go wrong. so, soon after this the monitor is shut down [47763.079587] [drm:pch_irq_handler], PCH HDCP audio interrupt [47763.079611] [drm:i915_hotplug_work_func], running encoder hotplug functions . . and this comes after powering it back on (note the couple of seconds gap due to me being slow :) [47766.403771] [drm:pch_irq_handler], PCH HDCP audio interrupt [47766.403785] [drm:i915_hotplug_work_func], running encoder hotplug functions [47766.404715] [drm:intel_dp_check_link_status], TMDS-9: channel EQ not ok, retraining . .
Can you please retest with 3.6-rc kernel? Just to ensure that we're not hunting a duplicate here (since we've fixed quite a few issues around audio support recently).
I'm now running 3.6rc5, and it still has the same issue.
Created attachment 67628 [details] [review] disable all hdmi modes Can you please test this quick debug hack to disable all hdmi modes? I suspect that the hotplug detection we regularly do causes (eventually) some havoc. Or at least we've had similar bugs, so better check this first.
I added the patch to the distro kernel (based on 3.2.29), and then after maybe an hour of uptime I got a full system lockup, and after maybe half a minute the monitor powered off.
(In reply to comment #12) > I added the patch to the distro kernel (based on 3.2.29), and then after > maybe an hour of uptime I got a full system lockup, and after maybe half a > minute the monitor powered off. That's pretty much guaranteed to be a different issue ;-) The question is whether the patch fixes the flicker or not. Also, please don't use a this old kernel as a baseline, since due to the massive amount of changes compared to current upstream it essentially invalidates any testing your doing.
Yeah, I figured as much.. I'll switch to 3.6 sometime soon, when I don't need to build anything (need overlayfs support from the distro kernel :/)
... so it was a bug in the monitor default settings. Samsung is wise enough to have a setting for "off timer" and the timeout of 1h. By default.. I have no idea if it should use some sort of a sensor, I've turned every eco mode setting off since they don't work. Looks like this is related though it's hidden in another menu. Oh well, closing.
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.