Bug 92685 - [i915 Skylake] HDMI output does not work with some adapters
Summary: [i915 Skylake] HDMI output does not work with some adapters
Status: CLOSED WORKSFORME
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: XOrg git
Hardware: Other All
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-27 01:43 UTC by ebiggers3
Modified: 2018-04-22 15:43 UTC (History)
12 users (show)

See Also:
i915 platform: I965GM, SKL
i915 features: display/HDMI


Attachments
dmesg.gz (23.89 KB, application/x-gzip)
2015-10-27 01:43 UTC, ebiggers3
no flags Details
Fix SKL DP AUX CH clock divider (913 bytes, patch)
2015-11-13 14:24 UTC, Ander Conselvan de Oliveira
no flags Details | Splinter Review
Fix SKL DP AUX CH clock divider (914 bytes, patch)
2015-11-13 14:35 UTC, Ander Conselvan de Oliveira
no flags Details | Splinter Review
dmesg (87.25 KB, text/plain)
2015-11-26 02:47 UTC, ebiggers3
no flags Details
i915_display_info on k501ux (1.83 KB, application/x-info)
2017-04-11 10:31 UTC, Marc Neiger
no flags Details
dmesg on k501ux (110.91 KB, text/plain)
2017-04-11 10:31 UTC, Marc Neiger
no flags Details
dmesg drm tip 4.13.0-994 (102.07 KB, text/plain)
2017-08-01 23:48 UTC, Marc Neiger
no flags Details
display_info 4.13.0-994 (1.81 KB, text/plain)
2017-08-01 23:49 UTC, Marc Neiger
no flags Details
Sigrok DDC trace, HW I2C vs bitbanging (3.37 KB, application/vnd.sigrok.session)
2017-12-24 21:53 UTC, Stefan Brüns
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description ebiggers3 2015-10-27 01:43:10 UTC
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.
Comment 1 Timo Aaltonen 2015-10-28 14:30:48 UTC
seeing same on SKL21-SDS, with the added fun that eDP stays blank until drm-intel-next-2015-09-28-merged.
Comment 2 Timo Aaltonen 2015-10-28 14:35:55 UTC
..until the first DPMS cycle, returning from it makes things work
Comment 3 Ander Conselvan de Oliveira 2015-11-13 14:24:56 UTC
Created attachment 119641 [details] [review]
Fix SKL DP AUX CH clock divider

Could you give this patch a try?
Comment 4 Ander Conselvan de Oliveira 2015-11-13 14:35:08 UTC
Created attachment 119642 [details] [review]
Fix SKL DP AUX CH clock divider

There was a typo on the previous patch.
Comment 5 ebiggers3 2015-11-14 01:21:35 UTC
I tested Linux 4.3 with your patch applied, but it did not solve the problem.
Comment 6 ebiggers3 2015-11-23 03:20:49 UTC
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.
Comment 7 ebiggers3 2015-11-25 05:51:20 UTC
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.
Comment 8 Jani Nikula 2015-11-25 08:11:39 UTC
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.
Comment 9 ebiggers3 2015-11-26 02:47:51 UTC
Created attachment 120126 [details]
dmesg
Comment 10 ebiggers3 2015-11-26 02:50:56 UTC
Attached the log as requested.
Comment 11 ebiggers3 2016-01-24 17:16:45 UTC
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.
Comment 12 Jani Nikula 2016-01-25 09:19:37 UTC
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.
Comment 13 Chris Bainbridge 2016-06-07 19:35:04 UTC
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
Comment 14 Jari Tahvanainen 2017-03-13 15:00:52 UTC
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.
Comment 15 Marc Neiger 2017-03-25 16:34:25 UTC
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.
Comment 16 Jani Nikula 2017-03-27 19:12:52 UTC
Please try v4.11-rc4 or drm-tip branch of https://cgit.freedesktop.org/drm-tip
Comment 17 Marc Neiger 2017-03-27 20:33:10 UTC
4.11.rc4 does not solve the issue.
Moreover 4.10.* and 4.11.* don't work with bumblebee on a primus hybrid hardware.
Comment 18 Jari Tahvanainen 2017-04-10 11:41:40 UTC
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.
Comment 19 Marc Neiger 2017-04-11 10:31:08 UTC
Created attachment 130796 [details]
i915_display_info on k501ux
Comment 20 Marc Neiger 2017-04-11 10:31:42 UTC
Created attachment 130797 [details]
dmesg on k501ux
Comment 21 Marc Neiger 2017-05-22 21:07:46 UTC
Currently using kernel 4.11.1 but to no avail.
Comment 22 Marc Neiger 2017-06-19 21:34:10 UTC
Currently using kernel 4.11.5 for no improvement.
Comment 23 Elizabeth 2017-07-28 18:51:02 UTC
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
Comment 24 Marc Neiger 2017-07-29 14:39:05 UTC
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.
Comment 25 Elizabeth 2017-08-01 21:41:40 UTC
(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.
Comment 26 Marc Neiger 2017-08-01 23:48:52 UTC
Created attachment 133185 [details]
dmesg drm tip 4.13.0-994
Comment 27 Marc Neiger 2017-08-01 23:49:23 UTC
Created attachment 133186 [details]
display_info 4.13.0-994
Comment 28 Jim Harvey 2017-11-27 00:49:31 UTC
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.
Comment 29 Jim Harvey 2017-11-28 16:32:58 UTC
(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
Comment 30 Stefan Brüns 2017-12-24 02:31:35 UTC
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.
Comment 31 Stefan Brüns 2017-12-24 21:53:19 UTC
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
Comment 32 Jani Nikula 2018-01-03 07:08:08 UTC
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
Comment 33 Marc Neiger 2018-03-01 22:47:28 UTC
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.
Comment 34 Marc Neiger 2018-03-05 15:04:19 UTC
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
Comment 35 Stefan Brüns 2018-03-05 16:44:38 UTC
Is the KVM switch on the HDMI or on the VGA side?
Comment 36 Marc Neiger 2018-03-06 14:33:27 UTC
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.
Comment 37 Jani Saarinen 2018-03-29 07:10:34 UTC
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.
Comment 38 Jani Saarinen 2018-04-22 15:43:39 UTC
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.