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@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
