Bug 106659 - [hdmi retimer?] No signal after switch from HDM1 to HDM2 and return in HDM1
Summary: [hdmi retimer?] No signal after switch from HDM1 to HDM2 and return in HDM1
Status: CLOSED WORKSFORME
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: All Linux (All)
: medium blocker
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged
Keywords:
Depends on:
Blocks:
 
Reported: 2018-05-25 19:49 UTC by fatez
Modified: 2018-09-21 10:57 UTC (History)
3 users (show)

See Also:
i915 platform: GLK
i915 features: display/HDMI


Attachments
Xorg.log (49.29 KB, text/plain)
2018-05-25 19:49 UTC, fatez
no flags Details
Dmesg (57.07 KB, text/plain)
2018-05-25 19:49 UTC, fatez
no flags Details
Vaainfo (1.87 KB, text/plain)
2018-05-25 19:50 UTC, fatez
no flags Details
Mesa (1.36 KB, text/plain)
2018-05-25 19:50 UTC, fatez
no flags Details
wflinfo (212 bytes, text/plain)
2018-05-25 19:50 UTC, fatez
no flags Details
syslog.i915.glkhdmi=1 (298.98 KB, text/plain)
2018-05-30 11:31 UTC, fatez
no flags Details
dmesg.i915.glkhdmi=1 (194.22 KB, text/plain)
2018-05-30 11:32 UTC, fatez
no flags Details
dmesg.i915.glkhdmi=1.SIGNAL.LOST (218.53 KB, text/plain)
2018-05-30 18:18 UTC, fatez
no flags Details
syslog.i915.glkhdmi=1.SIGNAL.LOST (936.77 KB, text/plain)
2018-05-30 18:18 UTC, fatez
no flags Details
syslog.i915.glkhdmi=2.SIGNAL.LOST (482.98 KB, text/plain)
2018-05-31 19:23 UTC, fatez
no flags Details
dmesg.i915.glkhdmi=2.SIGNAL.LOST (150.60 KB, text/plain)
2018-05-31 19:23 UTC, fatez
no flags Details
Syslog (9.15 MB, application/zip)
2018-06-05 22:02 UTC, fatez
no flags Details
dmesg (326.57 KB, application/zip)
2018-06-05 22:03 UTC, fatez
no flags Details
Syslog (151.28 MB, text/plain)
2018-06-06 10:41 UTC, fatez
no flags Details
dmesg (3.94 MB, text/plain)
2018-06-06 10:43 UTC, fatez
no flags Details
dmesg (3.53 MB, text/plain)
2018-07-18 05:42 UTC, fatez
no flags Details
syslog (314.24 KB, text/plain)
2018-07-18 05:42 UTC, fatez
no flags Details
dmesg (713.66 KB, text/plain)
2018-07-18 13:11 UTC, fatez
no flags Details
syslog (981.66 KB, text/plain)
2018-07-18 13:11 UTC, fatez
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description fatez 2018-05-25 19:49:42 UTC
Created attachment 139768 [details]
Xorg.log

Hi,

...First of all sorry for grammatical errors, I'm using an online translator...

So, I have an NUC7PJYH and have this problem :

When i shift from HDM1 (kodi) to HDM2 (sky) and return to HDM1(kodi) i lost the signal.
To get back the signal I have to restart the system.

I tried any version of the kernel and also the drivers available but I always get the same result: No signal.


Some info in attached files


I also tried the "possible" fix of Clinton Taylor :
"A simple msleep(50); at the end of intel_ddi_disable_transcoder_func() appears to resolve the issue. This is also a W/A and not the final solution."

And 
"In intel_hdmi.c  mothod hdmi_12bpc_possible()add return false;"

But I had no luck
Comment 1 fatez 2018-05-25 19:49:58 UTC
Created attachment 139769 [details]
Dmesg
Comment 2 fatez 2018-05-25 19:50:11 UTC
Created attachment 139770 [details]
Vaainfo
Comment 3 fatez 2018-05-25 19:50:22 UTC
Created attachment 139771 [details]
Mesa
Comment 4 fatez 2018-05-25 19:50:39 UTC
Created attachment 139772 [details]
wflinfo
Comment 5 fatez 2018-05-26 07:39:13 UTC
I forgot to mention that I stay with this risuluzion in Kodi3840x2160@24p then it works but if I leave this 3840x2160@60 does not work
Comment 6 Jani Saarinen 2018-05-28 06:21:10 UTC
Hi, Sounds like https://bugs.freedesktop.org/show_bug.cgi?id=105887.
Agree Clint/reporter as dup?
Comment 7 Jani Nikula 2018-05-29 06:14:59 UTC
(In reply to fatez from comment #1)
> Created attachment 139769 [details]
> Dmesg

Please add drm.debug=14 module parameter, reproduce the problem, and attach dmesg again.
Comment 8 Clinton Taylor 2018-05-29 22:20:18 UTC
(In reply to Jani Saarinen from comment #6)
> Hi, Sounds like https://bugs.freedesktop.org/show_bug.cgi?id=105887.
> Agree Clint/reporter as dup?

No, It's not clear that this is a dup at this time as the 8 bpc fix did not solve the issue.

I am finalizing a patch for https://bugs.freedesktop.org/show_bug.cgi?id=105887 and I would like Fatez to test using this patch on his setup.
Comment 9 fatez 2018-05-30 11:30:55 UTC
(In reply to Clinton Taylor from comment #8)
> (In reply to Jani Saarinen from comment #6)
> > Hi, Sounds like https://bugs.freedesktop.org/show_bug.cgi?id=105887.
> > Agree Clint/reporter as dup?
> 
> No, It's not clear that this is a dup at this time as the 8 bpc fix did not
> solve the issue.
> 
> I am finalizing a patch for
> https://bugs.freedesktop.org/show_bug.cgi?id=105887 and I would like Fatez
> to test using this patch on his setup.

Hey Clinton,

I have tried ur kernel and now seems work fine, i added in grub : 
GRUB_CMDLINE_LINUX_DEFAULT="splash quiet i915.glkhdmi=1 drm.debug=14"

I attached dmesg and syslog
Comment 10 fatez 2018-05-30 11:31:53 UTC
Created attachment 139849 [details]
syslog.i915.glkhdmi=1
Comment 11 fatez 2018-05-30 11:32:08 UTC
Created attachment 139850 [details]
dmesg.i915.glkhdmi=1
Comment 12 fatez 2018-05-30 18:00:35 UTC
I spoke too soon, he redone the same joke
I try to reproduce the bug and I'll attach the log
Comment 13 fatez 2018-05-30 18:18:25 UTC
Created attachment 139868 [details]
dmesg.i915.glkhdmi=1.SIGNAL.LOST
Comment 14 fatez 2018-05-30 18:18:44 UTC
Created attachment 139869 [details]
syslog.i915.glkhdmi=1.SIGNAL.LOST
Comment 15 fatez 2018-05-31 19:23:21 UTC
Created attachment 139893 [details]
syslog.i915.glkhdmi=2.SIGNAL.LOST
Comment 16 fatez 2018-05-31 19:23:34 UTC
Created attachment 139894 [details]
dmesg.i915.glkhdmi=2.SIGNAL.LOST
Comment 17 Jani Nikula 2018-06-05 08:27:20 UTC
When you're not running upstream kernels, please indicate which kernel you're running. Upstream does not and will not have i915.glkhdmi module parameter.
Comment 18 fatez 2018-06-05 10:39:58 UTC
(In reply to Jani Nikula from comment #17)
> When you're not running upstream kernels, please indicate which kernel
> you're running. Upstream does not and will not have i915.glkhdmi module
> parameter.

Hello, tell me which version you want the kernel that I install it and then attack the logs
Comment 19 Jani Saarinen 2018-06-05 18:45:36 UTC
Test with latest drm-tip: https://cgit.freedesktop.org/drm-tip and send dmesg with drm.debug=0x1e log_buf_len=4M?
Comment 20 fatez 2018-06-05 22:02:47 UTC
Created attachment 140037 [details]
Syslog
Comment 21 fatez 2018-06-05 22:03:37 UTC
Created attachment 140038 [details]
dmesg
Comment 22 fatez 2018-06-05 22:04:09 UTC
(In reply to Jani Saarinen from comment #19)
> Test with latest drm-tip: https://cgit.freedesktop.org/drm-tip and send
> dmesg with drm.debug=0x1e log_buf_len=4M?

I did what you requested with latest drm-tip kernel.
Comment 23 Jani Saarinen 2018-06-06 06:09:17 UTC
Can add logs as plain text no zipped files to ease devs efforts.
Comment 24 fatez 2018-06-06 10:41:46 UTC
Created attachment 140050 [details]
Syslog
Comment 25 fatez 2018-06-06 10:43:06 UTC
Created attachment 140051 [details]
dmesg
Comment 26 fatez 2018-06-06 10:48:04 UTC
(In reply to fatez from comment #22)
> (In reply to Jani Saarinen from comment #19)
> > Test with latest drm-tip: https://cgit.freedesktop.org/drm-tip and send
> > dmesg with drm.debug=0x1e log_buf_len=4M?
> 
> I did what you requested with latest drm-tip kernel.

Reput them not zipped
Comment 27 Jani Saarinen 2018-06-06 10:51:44 UTC
Can you also make sure dmesg if from the beginning of system boot to failure not just starting from later phases.
Comment 28 Jani Saarinen 2018-06-06 10:52:00 UTC
(In reply to Jani Saarinen from comment #27)
> Can you also make sure dmesg if from the beginning of system boot to failure
> not just starting from later phases.

I mean is from.
Comment 29 Imre Deak 2018-07-17 10:46:48 UTC
Could you please attach a dmesg log booting a current drm-tip kernel with drm.debug=0x1e kernel parameter? The log should include all the messages starting from bootup up to the point where you observe the error. If necessary you can increase the log buffer size adding something like log_buf_len=4M to the kernel parameters.
Comment 30 fatez 2018-07-18 05:42:07 UTC
(In reply to Imre Deak from comment #29)
> Could you please attach a dmesg log booting a current drm-tip kernel with
> drm.debug=0x1e kernel parameter? The log should include all the messages
> starting from bootup up to the point where you observe the error. If
> necessary you can increase the log buffer size adding something like
> log_buf_len=4M to the kernel parameters.

latest drm-tip 

NucBox:~$ uname -r
4.18.0-rc4+


[26066.771837] [drm:intel_hpd_irq_handler] Received HPD interrupt on PIN 5 - cnt: 0
[26066.771936] [drm:i915_hotplug_work_func] running encoder hotplug functions
[26066.771964] [drm:i915_hotplug_work_func] Connector HDMI-A-1 (pin 5) received hotplug event.
[26066.771978] [drm:intel_hdmi_detect] [CONNECTOR:101:HDMI-A-1]
[26066.798634] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpb] NAK for addr: 0040 w(1)
[26066.798641] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpb] NAK on first message, retry
[26066.798815] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpb] NAK for addr: 0040 w(1)
[26066.798826] [drm:drm_dp_dual_mode_detect] DP dual mode HDMI ID:  (err -6)
[26066.798834] [drm:drm_rgb_quant_range_selectable] CEA VCDB 0x0f
[26066.798839] [drm:drm_detect_monitor_audio] Monitor has basic audio support
[26067.214616] [drm:gen8_de_irq_handler] hotplug event received, stat 0x00000010, dig 0x1000181a, pins 0x00000020, long 0x00000020
[26067.214629] [drm:intel_hpd_irq_handler] Received HPD interrupt on PIN 5 - cnt: 1
[26067.214716] [drm:i915_hotplug_work_func] running encoder hotplug functions
[26067.214728] [drm:i915_hotplug_work_func] Connector HDMI-A-1 (pin 5) received hotplug event.
[26067.214752] [drm:intel_hdmi_detect] [CONNECTOR:101:HDMI-A-1]
[26067.242279] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpb] NAK for addr: 0040 w(1)
[26067.242287] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpb] NAK on first message, retry
[26067.242464] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpb] NAK for addr: 0040 w(1)
[26067.242475] [drm:drm_dp_dual_mode_detect] DP dual mode HDMI ID:  (err -6)
[26067.242484] [drm:drm_rgb_quant_range_selectable] CEA VCDB 0x0f
[26067.242490] [drm:drm_detect_monitor_audio] Monitor has basic audio support
Comment 31 fatez 2018-07-18 05:42:36 UTC
Created attachment 140683 [details]
dmesg
Comment 32 fatez 2018-07-18 05:42:52 UTC
Created attachment 140684 [details]
syslog
Comment 33 Imre Deak 2018-07-18 10:25:26 UTC
(In reply to fatez from comment #31)
> Created attachment 140683 [details]
> dmesg

Hm, this log tells me that HDMI-A-2 is never in a connected state. IIUC, in your bug report the bad sequence is:
1. Display plugged to HDMI-A-1   (works ok)
2. Display unplugged from HDMI-A-1 and plugged to HDMI-A-2 (works ok)
3. Display unplugged from HDMI-A-2 and plugged to HDMI-A-1 (doesn't work)

- So step 2. should be ok, but in your log HDMI-A-2 is never connected. So is 
  HDMI-A-2 working for you? If so could you double check that your log includes 
  the part where HDMI-A-2 is plugged and works ok?

- Could you provide the followings found on the back of the NUC (some may be 
  missing):
  - Product code
  - Project code
  - Date of manufacture

- Does the problem happen all the time?

- After the problem happens, could you do
  # echo detect > /sys/class/drm/card0-HDMI-A-1/status
  and then provide a dmesg log

Thanks.
Comment 34 fatez 2018-07-18 13:10:45 UTC
(In reply to Imre Deak from comment #33)
> (In reply to fatez from comment #31)
> > Created attachment 140683 [details]
> > dmesg
> 
> Hm, this log tells me that HDMI-A-2 is never in a connected state. IIUC, in
> your bug report the bad sequence is:
> 1. Display plugged to HDMI-A-1   (works ok)
> 2. Display unplugged from HDMI-A-1 and plugged to HDMI-A-2 (works ok)
> 3. Display unplugged from HDMI-A-2 and plugged to HDMI-A-1 (doesn't work)
> 
> - So step 2. should be ok, but in your log HDMI-A-2 is never connected. So
> is 
>   HDMI-A-2 working for you? If so could you double check that your log
> includes 
>   the part where HDMI-A-2 is plugged and works ok?
> 
> - Could you provide the followings found on the back of the NUC (some may be 
>   missing):
>   - Product code
>   - Project code
>   - Date of manufacture
> 
> - Does the problem happen all the time?
> 
> - After the problem happens, could you do
>   # echo detect > /sys/class/drm/card0-HDMI-A-1/status
>   and then provide a dmesg log
> 
> Thanks.


Hi,

My system is nuc7pyh and has two native HDMI 2.0 port.
I only use the first HDMI(A-1) port and it is linked to Denon AVR-X2400H; the second HDMI(A-2) port is empty, it is not connected.
When I pass from hdmi1 to hdmi2 and vice versa, I never unplug the cable from the NUC but I use Denon's remote to switch from Sky (hdmi2) to Kofi Nuc (hdmi1).
When I pass from Kodi to Sky and I'll be back in Kodi i lost the signal forever. I have to reboot the Nuc so I can see again.

If it helps, I did a hw-probe of my "clean" system here: https://linux-hardware.org/index.php?probe=a9b6f206ab
And here I did a hw-probe with "drm.debug=0x1e log_buf_len=4M" : https://linux-hardware.org/?probe=94f2aa43b7

so here :
NucBox:/sys/class/drm$ cat card0-HDMI-A-1/status 
connected

NucBox:/sys/class/drm$ cat card0-HDMI-A-2/status 
disconnected

  - Product code = BOXNUC7PJYH2
  - Project code = ??
  - Date of manufacture = 28MAR2018

The problem comes every time I move from hdmi2 to hdmi1 and I go back to hdmi2 (always through Denon, I repeat, I never unplug the Hdmi cable from the Nuc)

And AFTER SIGNAL LOST :

$ sudo cat /sys/class/drm/card0-HDMI-A-1/status
connected

$ sudo cat /sys/class/drm/card0-HDMI-A-2/status
disconnected
Comment 35 fatez 2018-07-18 13:11:01 UTC
Created attachment 140689 [details]
dmesg
Comment 36 fatez 2018-07-18 13:11:18 UTC
Created attachment 140690 [details]
syslog
Comment 37 Imre Deak 2018-07-19 12:19:15 UTC
(In reply to fatez from comment #34)
> (In reply to Imre Deak from comment #33)
> > (In reply to fatez from comment #31)
> [...]
> Hi,
> 
> My system is nuc7pyh and has two native HDMI 2.0 port.
> I only use the first HDMI(A-1) port and it is linked to Denon AVR-X2400H;
> the second HDMI(A-2) port is empty, it is not connected.
> When I pass from hdmi1 to hdmi2 and vice versa, I never unplug the cable
> from the NUC but I use Denon's remote to switch from Sky (hdmi2) to Kofi Nuc
> (hdmi1).
> When I pass from Kodi to Sky and I'll be back in Kodi i lost the signal
> forever. I have to reboot the Nuc so I can see again.

Ah ok, so for reference, IIUC you have (please confirm/correct it):

- Two HDMI sources, one of them is the NUC7PJYH2 GLK NUC. (If so what is the other source?)
- The two sources are connected to the AVRs two HDMI inputs (HDMI1/HDMI2).
- To the AVR there is one HDMI display connected.
- Switching between the two AVR inputs with the AVR's remote causes the problem.

From the log I can see the following sequence:
1. successful modeset on HDMI-A-1                (AVR is switched to HDMI1)
2. hotplug with HDMI-A-1 becoming disconnected   (AVR is switched from HDMI1 to HDMI2)
   There is no modeset at this point, so HDMI-A-1 should continue to output a 
   valid signal.
3. hotplug with HDMI-A-1 becoming connected      (AVR is switched back to HDMI1 from HDMI2)
   Again no modeset, though a few successful detect cycles. HDMI-A-1 should
   still continue to output a valid signal from the mode set at 1.

It's a bit strange that Kodi doesn't disable the output in 2., but in theory things should still work, as the mode remains the same in 3. as what was set in 1. In any case it's possible that we need to force a mode disable/re-enable cycle to make things work.

Could you try finding a way to force Kodi to disable the output after you switched the AVR from HDMI1 to HDMI2 and then make it re-enable it in Kodi after you switched back to HDMI1? (For ex. by setting some video output setup option in Kodi from and back to HDMI-A-1).

If that doesn't fix it, to rule out that this is an AVR/display issue, could you try the following two things in the bad state when you switched the AVR back to HDMI1 (keeping the GLK NUC powered all the time)?:
A.
1. unplug the display from AVR and power cycle the display
2. plug the display directly to the GLK NUC

B.
1. power off both the AVR and the display
2. power on the AVR, make sure it's switched to the HDMI1 input (the GLK NUC)
3. power on the display

Does A. or B. resolve the problem?

Did you try to upgrade the firmware of your AVR [1], and your display?

[1] http://firmware.denon.eu/

> If it helps, I did a hw-probe of my "clean" system here:
> https://linux-hardware.org/index.php?probe=a9b6f206ab
> And here I did a hw-probe with "drm.debug=0x1e log_buf_len=4M" :
> https://linux-hardware.org/?probe=94f2aa43b7
> 
> so here :
> NucBox:/sys/class/drm$ cat card0-HDMI-A-1/status 
> connected
> 
> NucBox:/sys/class/drm$ cat card0-HDMI-A-2/status 
> disconnected
> 
>   - Product code = BOXNUC7PJYH2
>   - Project code = ??
>   - Date of manufacture = 28MAR2018

Thanks, so not a pre-production device.

> 
> The problem comes every time I move from hdmi2 to hdmi1 and I go back to
> hdmi2 (always through Denon, I repeat, I never unplug the Hdmi cable from
> the Nuc)
> 
> And AFTER SIGNAL LOST :
> 
> $ sudo cat /sys/class/drm/card0-HDMI-A-1/status
> connected

Right, this was never a problem then, the output is in the connected state when it's supposed to be.

> 
> $ sudo cat /sys/class/drm/card0-HDMI-A-2/status
> disconnected
Comment 38 fatez 2018-07-19 12:25:40 UTC
nope, i have only one port connected from the nuc to denon avr;
the second port from nuc is unplugged.

Repeat, my nuc has two port but only one is connected to avr.

In AVR i have HDM1 is Kodi (from nuc), HDMI2 is Sky etc.

Whe i shift from kodi to sky and return to kodi WITH AVR i lost signal.
Comment 39 Imre Deak 2018-07-19 12:54:02 UTC
(In reply to fatez from comment #38)
> nope, i have only one port connected from the nuc to denon avr;
> the second port from nuc is unplugged.
> 
> Repeat, my nuc has two port but only one is connected to avr.

Right, that is what I thought too if you read again comment #37. Could you please  re-read that and try the things there?

> 
> In AVR i have HDM1 is Kodi (from nuc), HDMI2 is Sky etc.
> 
> Whe i shift from kodi to sky and return to kodi WITH AVR i lost signal.
Comment 40 fatez 2018-07-21 07:39:40 UTC
(In reply to Imre Deak from comment #39)
> (In reply to fatez from comment #38)
> > nope, i have only one port connected from the nuc to denon avr;
> > the second port from nuc is unplugged.
> > 
> > Repeat, my nuc has two port but only one is connected to avr.
> 
> Right, that is what I thought too if you read again comment #37. Could you
> please  re-read that and try the things there?
> 
> > 
> > In AVR i have HDM1 is Kodi (from nuc), HDMI2 is Sky etc.
> > 
> > Whe i shift from kodi to sky and return to kodi WITH AVR i lost signal.

You are completely right, I apologize for the answer given (in a hurry and without reading well... stress stress..) I asked @fritsch that he is a Dev of Kodi if he can help me. I keep you up to speed as soon as I hear. Sorry again for the Unpolite answer I gave you.
Comment 41 Lakshmi 2018-09-11 07:13:20 UTC
Fatez, any feedback? Do you still have the issue? Instructions given above are tried?
Comment 42 Lakshmi 2018-09-21 10:57:21 UTC
No feedback from two months, closing as resolved works for me.

If the issue appears again, upgrade the AVR firmware to latest and try.

Follow the above instructions to narrow down the debugging of this issue.

Remember to verify the issue with latest drm-tip https://cgit.freedesktop.org/drm-tip and send dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M.

Still if you see the same problem, reopen the issue.


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.