Created attachment 126824 [details] dmesg output of loop (drm.debug=255) Sometimes, after it had worked fine for hours, my Intel Skylake graphics starts to loop between HDMI connect and disconnect events. (Of course the TV actually stays connected, although switched off.) The corresponding drm.debug=255 messages are attached as dmesg-drm-debug.log. This results in udev events, which cause the X-Server to log the output shown in Xorg.0.log Interestingly, the loop can be interrupted by calling env DISPLAY=:0 xrandr --output HDMI1 After that command, the events stop again and the HDMI output correctly shows as connected. I am using kernel 4.7.3-200.fc24.x86_64 (Fedora 24).
Created attachment 126825 [details] Xorg.0.log of X startup and while looping
Created attachment 126826 [details] dmesg output while booting
Created attachment 126827 [details] lspci output
# while true; do echo "$(date) $(cat /sys/class/drm/card0-HDMI-A-1/status)"; usleep 500000; done Sat Oct 22 21:57:30 CEST 2016 connected Sat Oct 22 21:57:30 CEST 2016 connected Sat Oct 22 21:57:31 CEST 2016 disconnected Sat Oct 22 21:57:32 CEST 2016 disconnected Sat Oct 22 21:57:32 CEST 2016 connected Sat Oct 22 21:57:33 CEST 2016 connected Sat Oct 22 21:57:33 CEST 2016 connected Sat Oct 22 21:57:34 CEST 2016 connected Sat Oct 22 21:57:34 CEST 2016 connected Sat Oct 22 21:57:35 CEST 2016 connected Sat Oct 22 21:57:35 CEST 2016 disconnected Sat Oct 22 21:57:36 CEST 2016 connected
I tried to force the output to connected using the kernel option video=HDMI-A-1:D and a saved EDID block: drm_kms_helper.edid_firmware=HDMI-A-1:edid/leo-samsung.bin. Unfortunately this doesn't work. After the TV had been switched off, the loop starts again. Oct 29 00:07:40 apu kernel: [drm] Got external EDID base block and 1 extension from "edid/leo-samsung.bin" for connector "HDMI-A-1" Oct 29 00:07:40 apu kernel: [drm] Got external EDID base block and 1 extension from "edid/leo-samsung.bin" for connector "HDMI-A-1" Oct 29 00:07:44 apu kernel: [drm] Got external EDID base block and 1 extension from "edid/leo-samsung.bin" for connector "HDMI-A-1" Oct 29 00:07:44 apu kernel: [drm] Got external EDID base block and 1 extension from "edid/leo-samsung.bin" for connector "HDMI-A-1" Oct 29 00:07:47 apu kernel: [drm] Got external EDID base block and 1 extension from "edid/leo-samsung.bin" for connector "HDMI-A-1" Oct 29 00:07:48 apu kernel: [drm] Got external EDID base block and 1 extension from "edid/leo-samsung.bin" for connector "HDMI-A-1" udevadm monitor: ---------------- KERNEL[44410.060085] change /devices/pci0000:00/0000:00:02.0/drm/card0 (drm) UDEV [44410.060848] change /devices/pci0000:00/0000:00:02.0/drm/card0 (drm) KERNEL[44410.062016] add /devices/platform/HDMI-A-1 (platform) KERNEL[44410.062049] remove /devices/platform/HDMI-A-1 (platform) UDEV [44410.062335] add /devices/platform/HDMI-A-1 (platform) UDEV [44410.062484] remove /devices/platform/HDMI-A-1 (platform) KERNEL[44410.150245] change /devices/pci0000:00/0000:00:02.0/drm/card0 (drm) UDEV [44410.150613] change /devices/pci0000:00/0000:00:02.0/drm/card0 (drm) KERNEL[44410.151704] add /devices/platform/HDMI-A-1 (platform) KERNEL[44410.151831] remove /devices/platform/HDMI-A-1 (platform) UDEV [44410.151955] add /devices/platform/HDMI-A-1 (platform) UDEV [44410.152184] remove /devices/platform/HDMI-A-1 (platform) KERNEL[44413.899164] change /devices/pci0000:00/0000:00:02.0/drm/card0 (drm) UDEV [44413.899883] change /devices/pci0000:00/0000:00:02.0/drm/card0 (drm) KERNEL[44413.900998] add /devices/platform/HDMI-A-1 (platform) KERNEL[44413.901355] remove /devices/platform/HDMI-A-1 (platform) UDEV [44413.901372] add /devices/platform/HDMI-A-1 (platform) UDEV [44413.901532] remove /devices/platform/HDMI-A-1 (platform) KERNEL[44413.989166] change /devices/pci0000:00/0000:00:02.0/drm/card0 (drm) UDEV [44413.989547] change /devices/pci0000:00/0000:00:02.0/drm/card0 (drm) KERNEL[44413.990630] add /devices/platform/HDMI-A-1 (platform) KERNEL[44413.990698] remove /devices/platform/HDMI-A-1 (platform) UDEV [44413.990981] add /devices/platform/HDMI-A-1 (platform) UDEV [44413.991154] remove /devices/platform/HDMI-A-1 (platform) KERNEL[44417.779197] change /devices/pci0000:00/0000:00:02.0/drm/card0 (drm) UDEV [44417.779935] change /devices/pci0000:00/0000:00:02.0/drm/card0 (drm) KERNEL[44417.781040] add /devices/platform/HDMI-A-1 (platform) KERNEL[44417.781140] remove /devices/platform/HDMI-A-1 (platform) UDEV [44417.781318] add /devices/platform/HDMI-A-1 (platform) UDEV [44417.781514] remove /devices/platform/HDMI-A-1 (platform) KERNEL[44417.869207] change /devices/pci0000:00/0000:00:02.0/drm/card0 (drm) UDEV [44417.869561] change /devices/pci0000:00/0000:00:02.0/drm/card0 (drm) KERNEL[44417.870613] add /devices/platform/HDMI-A-1 (platform) KERNEL[44417.870649] remove /devices/platform/HDMI-A-1 (platform) UDEV [44417.871309] add /devices/platform/HDMI-A-1 (platform) UDEV [44417.871503] remove /devices/platform/HDMI-A-1 (platform)
(In reply to Leo Bergolth from comment #0) > Interestingly, the loop can be interrupted by calling > env DISPLAY=:0 xrandr --output HDMI1 > > After that command, the events stop again and the HDMI output correctly > shows as connected. This worked only once. :-(
Created attachment 127601 [details] dmesg output of loop with kernel 4.7.9 and force-options
(In reply to Leo Bergolth from comment #5) > I tried to force the output to connected using the kernel option > video=HDMI-A-1:D and a saved EDID block: > drm_kms_helper.edid_firmware=HDMI-A-1:edid/leo-samsung.bin. > > Unfortunately this doesn't work. Is there any other switch that disables those hotplug events and forces the output to connected?
Leo - I'm sorry about this delay on getting back to you. Are you still having this problem, with preferable newer kernel from drm-tip?
No thanks! The problem was caused by a HDMI audio-extractor. I replaced the HDMI audio-extractor with another model (different chipset) and the problem went away. So I blamed the wrong part. Sorry.
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.