On Sun, 2015-11-01 at 12:48 +0100, Maarten Maathuis wrote:
> Hi everyone.
>
> I've been some hardlock problems when switching from the HDMI connection of my
> monitor (connected to another PC) and the displayport (connected to the
> problematic PC), several times a week at least.
>
> In an effort to narrow down the problem I've been tried looking at drm modeset
> debug information, as well try catch something with netconsole. Neither have
> pointed me the root cause yet, but i do have some observations that I cannot
> put into place yet and would like some feedback on prior to opening a bug
> report.
>
> My mainbord is: Asrock Fatal1ty Z170 Gaming-ITX/ac
> My CPU is: Intel i7 6700
> My monitor is: Samsung U24E850, equiped with both displayport 1.2 and HDMI 2.0
>
> Kernel version: 4.3-RC7
>
> The display connections on the mainbord are:
> - DP 1.2
> - HDMI 1.4
> - HDMI 2.0 via DP 1.2 (recognized as DP by driver)
>
> I notice some funny things I would like some feedback on.
>
> 1. The EDID retrieval doesn't always succeed, i've noticed this sometimes by
> running "xrandr" after starting up. I've also noticed it after rebooting from
> a hard lock that it goes into 1024x768 resolution instead of 3840x2160, it
> takes another reboot to get it right. As if it relies on the resolution the
> boot used? How to troubleshoot this?
>
> 2. I notice that the driver thinks there are 3 HDMI connections, 2 of which
> seem to share the same hotplug pin as the 2 DP connections, what is going
> here? Could this cause trouble? The fake HDMI connections seem always to fail
> edid retrieval, but I'm not a 100% sure if this also happens in the hardlock
> situation (no evidence yet).
>
> 3. Switching between HDMI and DP channel on my monitor sometimes results in a
> hotplug event and sometimes it does not? Any idea why this happens? I'm
> curious about this because the hardlocks occur after spending a few hours on
> the HDMI channel typically.
>
> Anything I should be looking for before going down the route of a bug report?
It would be better to file a bug report and attach the output of dmesg from boot
while running with drm.debug=0xe in the kernel command line. Further instruction
s in the link below.
https://01.org/linuxgraphics/documentation/how-report-bugs
Ander
>
> Sincerely,
>
> Maarten.
>
> P.S. I'm not subscribed to this mailinglist, so please CC me.
>
> --
> Far away from the primal instinct, the song seems to fade away, the river get
> wider between your thoughts and the things we do and say.
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
