Created attachment 119210 [details] dmesg.gz Running Linux 4.3-rc7 on a laptop with Intel Skylake integrated graphics, I encountered warnings in the kernel log and a several second hang during boot. Furthermore, an external monitor attached to the HDMI input did not work. The problems occur every boot. The full dmesg output with drm.debug=14 is attached; some highlights are shown below: [ 1.401196] [drm:intel_dp_aux_ch] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [ 1.414508] [drm:intel_dp_aux_ch] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [ 1.427851] [drm:intel_dp_aux_ch] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [ 1.427853] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status 0xad40001f [ 1.447865] ------------[ cut here ]------------ [ 1.447867] WARNING: CPU: 1 PID: 6 at drivers/gpu/drm/i915/intel_dp.c:854 intel_dp_aux_ch+0x10f/0x6a0() [ 1.447867] dp_aux_ch not started status 0xad40001f ... [ 8.043643] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 130 ... [ 32.571277] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 130 ... [ 32.608835] i915 0000:00:02.0: HDMI-A-1: EDID block 0 invalid.
seeing same on SKL21-SDS, with the added fun that eDP stays blank until drm-intel-next-2015-09-28-merged.
..until the first DPMS cycle, returning from it makes things work
Created attachment 119641 [details] [review] Fix SKL DP AUX CH clock divider Could you give this patch a try?
Created attachment 119642 [details] [review] Fix SKL DP AUX CH clock divider There was a typo on the previous patch.
I tested Linux 4.3 with your patch applied, but it did not solve the problem.
Update: with Linux 4.4-rc2, the "dp_aux_ch not started" warning is gone, and there is no longer a several second hang on boot or when changing the screen resolution. However, the HDMI output continues to be broken, and the log messages about the EDID checksum being invalid still appear.
I updated the bug title to reflect the fact that the HDMI output not working (because of the invalid EDID checksum) is now the only problem for me. So there must have been two separate problems originally, one of which was solved by the 4.4 merges. I tried hacking the i915 driver code in a few different ways but none of them solved the problem: - always setting force_bit=1 on the 'struct intel_gmbus' - changing the drm_i915_private hotplug_work to a delayed_work and scheduling it with delay 400 ms - increasing the number of retries in drm_do_get_edid() from 4 to 32 - increasing the number of retries of the "live status" check in intel_hdmi_detect() from 3 to 30 Also, I verified that the same monitor and VGA->HDMI adapter works on a Raspberry Pi. So that leaves the Skylake hardware and/or the i915 driver as the source of the problem.
Please add drm.debug=14 module parameter, and attach dmesg all the way from boot to the problem, running v4.4-rc2 or later. Please attach plain text dmesg only, not compressed.
Created attachment 120126 [details] dmesg
Attached the log as requested.
Update: Using a different cable, which connects the DVI input of the monitor to the HDMI output of the Skylake GPU, everything works as expected. The non-working setup used a different adapter that connected the VGA input of the monitor to the HDMI output of the Skylake GPU. So, the issue manifests itself with particular adapters and not with the HDMI output itself. It's also possible that everything works as intended on the Skylake side and the particular (brand new) adapter I used was "bad". However, I don't currently have any other HDMI->VGA adapters to test. I will leave this bug open for now as several people are watching it, and it's possible they have encountered similar problems.
HDMI->DVI is just wires. HDMI->VGA is an active protocol converter. The more complex stuff always has more ways to go wrong, both in the adapter and in the driver.
I see the "dp aux hw did not signal timeout" error logged on IvyBridge (although the display works ok). Possibly it could have the same root cause, which looks like a race condition in the init code, see bug #96428
Based on the comment 11 and the silence after that I would like propose this to be closed. ebiggers3@gmail.com - if you agree with me then please mark this as resolved+fixed.
I meet the same problem and currently using kernel 4.9.17. All versions I tested until now have the problem. I also bought and tested 3 different adapters. As they all exhibit the same problem and the HDMI output works with regular monitors I now assume there is something specific with HDMI to VGA adapters. I suspect is it related to EID or monitor signaling. Machine is actually ASUS K501UX. I can do some tests within my technical abilities. Thanks.
Please try v4.11-rc4 or drm-tip branch of https://cgit.freedesktop.org/drm-tip
4.11.rc4 does not solve the issue. Moreover 4.10.* and 4.11.* don't work with bumblebee on a primus hybrid hardware.
Mark - can you please attach the dmesg and cat /sys/kernel/debug/dri/0/i915_display_info? Remember to add drm.debug=0xe to your kernel command line.
Created attachment 130796 [details] i915_display_info on k501ux
Created attachment 130797 [details] dmesg on k501ux
Currently using kernel 4.11.1 but to no avail.
Currently using kernel 4.11.5 for no improvement.
Good afternoon Marc, Thanks for the follow up, could you test latest stable and latest drm-tip? Some patches for HDMI have been added. Thank you. https://www.kernel.org/ https://cgit.freedesktop.org/drm-tip
Hi Elizabeth Thank for your reply. I know this is not exactly what you expected, but I don't know how to compile a kernel with patches. Perhaps I could try if you refer me to a proper howto. What I did it instead is to test the kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-tip/2017-07-29/ I assumed it to be very close to the kernel you had in mind. On my PC (ASUS k501X), 4.13 kernel break Bumblebee and NVIDIA proprietary driver (384) support as Bumblebee can't start and the DKMS module can not be compiled. Nevertheless the machine runs normally using the intel graphic support. Unfortunately the HDMI adapater detection does not work any better with this kernel. Perhaps you'd like me to provide some log or other test output.
(In reply to Marc Neiger from comment #24) > Hello Marc, Latest drm-tip is ok, actually last dmesg attached is from 4.9 so a new dmesg could be helpful to compare, and if any other information is needed it will be commented here. Thank you again.
Created attachment 133185 [details] dmesg drm tip 4.13.0-994
Created attachment 133186 [details] display_info 4.13.0-994
I have this exact problem. Old computer used two vga monitors, I just built a new computer and trying to use the old monitors. Mobo is Asus TUF Z270 Mark 2 with an I5 7600K, OS is Ubuntu 16.04 with kernel 4.10.0-40. Gofanco Active DVI-D to VGA Adapter Converter works well but XF TIMES HDMI to VGA will fail on a cold boot. Both screens show the Ubuntu purple for a few seconds then the HDMI shuts down. Reboot does not start the HDMI side but usually a power cycle will. DMESG in the failed HDMI condition has this error: [ 1.668084] [drm] Initialized i915 1.6.0 20161121 for 0000:00:02.0 on minor 0 [ 1.675364] random: fast init done [ 1.809723] i915 0000:00:02.0: HDMI-A-1: EDID is invalid: [ 1.809724] [00] BAD 18 ab 1a 3a 5b 3f d0 19 a4 71 db 8e 55 d8 ce a5 [ 1.809724] [00] BAD f6 73 dd d5 de 24 38 3a 09 05 89 72 f5 67 95 b3 [ 1.809724] [00] BAD 3e ab 0b f4 b1 ae 10 62 63 eb f8 7b 86 1f 4c e5 [ 1.809725] [00] BAD 22 80 86 1c 81 00 1e 7b 12 19 62 d2 5f 79 09 9c [ 1.809725] [00] BAD bc 2d c1 0d 12 32 6b 03 0c 33 21 81 ff 5d a4 50 [ 1.809725] [00] BAD 0e 8b 35 56 ad a8 75 8d a8 e7 31 7e ab 37 35 16 [ 1.809725] [00] BAD b1 0c 10 92 98 74 70 e0 d9 c7 d7 cc 44 e3 bb af [ 1.809726] [00] BAD 38 aa c2 6b 0e d4 e5 a8 0c a0 6d 5f 17 92 01 02 Otherwise DMESG looks the same when it works or not. I built an xorg.conf adding IgnoreEDID but no help, I saw this in Xorg.0.log: [ 12.156] (WW) intel(0): Option "IgnoreEDID" is not used and no other error messages.
(In reply to Jim Harvey from comment #28) > I have this exact problem. Old computer used two vga monitors, I just built > a new computer and trying to use the old monitors. Mobo is Asus TUF Z270 > Mark 2 with an I5 7600K, OS is Ubuntu 16.04 with kernel 4.10.0-40. > > Gofanco Active DVI-D to VGA Adapter Converter works well but XF TIMES HDMI > to VGA > will fail on a cold boot. Both screens show the Ubuntu purple for a few > seconds then the HDMI shuts down. Reboot does not start the HDMI side but > usually a power cycle will. > > DMESG in the failed HDMI condition has this error: > > [ 1.668084] [drm] Initialized i915 1.6.0 20161121 for 0000:00:02.0 on > minor 0 > [ 1.675364] random: fast init done > [ 1.809723] i915 0000:00:02.0: HDMI-A-1: EDID is invalid: > [ 1.809724] [00] BAD 18 ab 1a 3a 5b 3f d0 19 a4 71 db 8e 55 d8 ce a5 > [ 1.809724] [00] BAD f6 73 dd d5 de 24 38 3a 09 05 89 72 f5 67 95 b3 > [ 1.809724] [00] BAD 3e ab 0b f4 b1 ae 10 62 63 eb f8 7b 86 1f 4c e5 > [ 1.809725] [00] BAD 22 80 86 1c 81 00 1e 7b 12 19 62 d2 5f 79 09 9c > [ 1.809725] [00] BAD bc 2d c1 0d 12 32 6b 03 0c 33 21 81 ff 5d a4 50 > [ 1.809725] [00] BAD 0e 8b 35 56 ad a8 75 8d a8 e7 31 7e ab 37 35 16 > [ 1.809725] [00] BAD b1 0c 10 92 98 74 70 e0 d9 c7 d7 cc 44 e3 bb af > [ 1.809726] [00] BAD 38 aa c2 6b 0e d4 e5 a8 0c a0 6d 5f 17 92 01 02 > > Otherwise DMESG looks the same when it works or not. I built an xorg.conf > adding IgnoreEDID but no help, I saw this in Xorg.0.log: > [ 12.156] (WW) intel(0): Option "IgnoreEDID" is not used > and no other error messages. The last thing I see on the screen before the HDMI adapter shuts down is this: Nov 28 10:20:23 junkbox-2 kernel: [ 1.436007] fb: switching to inteldrmfb from EFI VGA
I can see the same issue (HDMI-to-VGA not working) on a Laptop with 965GM (Dell Inspiron 11z). The same adapter works when used behind a DP-to-HDMI adapter, the obvious difference is the AUX-to-I2C bridge in the DP/HDMI adapter. I hooked up a logic analyzer to the HDMI connection (that is, the DDC lines). There is no obvious protocol violation when connected to the 965GM, but there are a few observations: -- using i2c-dev/i2cdump 4 0x50, on 965GM -- - when reading each byte individually (i.e. write offset, read byte), the whole EEPROM is read correctly - when reading in blocks (write offset, read 32 bytes), the first byte is always correct, the second byte occasionally -- comparing 965GM as master and DP adapter as master -- 965GM: releases SDA (ACK) at the exact same time as SCL is pulled down DP: SDA is kept stable for 500ns after SCL is pulled down My current assuption is the HDMI-to-VGA adapter samples the SDA line with the falling edge of SCL, i.e. at a time where the SDA line is already pulled up again. LA traces can be made available.
Created attachment 136385 [details] Sigrok DDC trace, HW I2C vs bitbanging The first transfer (reading 0xff after the first byte) uses the GM965 GMBUS, the second one uses bitbanging
People with the issue on Skylake or generally something other than GM965, please try Stefan's patch http://patchwork.freedesktop.org/patch/msgid/a39f080b-81a5-4c93-b3f7-7cb0a58daca3@rwthex-w2-a.rwth-ad.de
I successfully tested Stephan's patch on my machine Asus k501ux Kernel is 4.14.23 ubuntu mainline with Stephan's patch. Thanks ! I own a couple of other HDMI VGA converters which I'll test soon, but I'm confident.
2 out 3 adapters (all different) do now work with Stefan's patch. Oddly enough the one which does not work directly with the screen does work when used with a KVM (Belkin 2 ports). Thanks a lot
Is the KVM switch on the HDMI or on the VGA side?
KVM and display are VGA. PC is HDMI and connected to KVM through the adapter. The KVM is likely to react differently than the display and use different timings or shift the display timings, whether reception or transmission.
First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Closing, please re-open if still occurs.
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.