Hi Im owner of NUC Gemini Lake - NUC7CJY Im used latest dam-tip kernel, mesa 18.0 and xorg rc1.19.99.903 My and others users problem is when I play some movies at 1080p@23.98 then stop and picture will back to default 1080p@50 or 2180@50 then i experienced no signal and TV or monitor :( Here log just after boot system http://ix.io/16yg Here after play movie at 1080p@23.98 and stop (after that no signal at TV) http://ix.io/16yk
Created attachment 138595 [details] drm-Print-HDMI-2.0-support-from-monitor
Created attachment 138597 [details] drm-i915-debug-Allow-4-2-0-also-modes-too
I attached 2 patches from shashank.sharma which I got and applied for this kernel
after some investigation, same issue exist on both port HDMI1, HDMI2 what is discovered - when signal gone after switch framerate - enough unplug HDMI cable and connect back - then signal/picture BACK please fix that ASAP - now GEMINI lake NUC is on market and more and more people struggling with this issue which is very annoying (same issue still exist on latest drm-tip kernel from yesterday)
here latest log - what is interesting HDMI on boot is probing couple of times somewhere on start showing _add_display_info] *ERROR* YCBCR420 (also) supported =N [ 1.278596] [drm:drm_add_display_info] *ERROR* YCBCR420 (only) supported =N [ 1.278600] [drm:drm_add_display_info] *ERROR* YCBCR420 dc support =N later [ 88.809058] [drm:drm_add_display_info] *ERROR* ======== Shashank: Monitor 420 ============= [ 88.809059] [drm:drm_add_display_info] *ERROR* YCBCR420 (also) supported =Y [ 88.809061] [drm:drm_add_display_info] *ERROR* YCBCR420 (only) supported =Y [ 88.809062] [drm:drm_add_display_info] *ERROR* YCBCR420 dc support =N i dont know if that help here fresh log just after boot http://ix.io/18qB here after play file with refreshrate 23.98 and stop - signal gone http://ix.io/18qE andf here after reconnect HDMI cable - signal back http://ix.io/18qF if you neeed any more test, logs etc let me know.
Shashank, Ville, any commments?
So was this series tested on top of drm-tip? https://patchwork.freedesktop.org/series/36068/
that for LSPCON - Gemini has native HDMI 2.0 ;) and i did tested this also nothing help.
I have the same issue.
(In reply to Jani Saarinen from comment #6) > Shashank, Ville, any commments? There is something fishy with the EDID's extension blocks for this monitor. first probe, EDID says neither 420_only nor 420_also supported: ============= [ 1.278592] [drm:drm_add_display_info] *ERROR* YCBCR420 (also) supported =N [ 1.278596] [drm:drm_add_display_info] *ERROR* YCBCR420 (only) supported =N [ 1.278600] [drm:drm_add_display_info] *ERROR* YCBCR420 dc support =N [ 1.278604] [drm:drm_add_display_info] *ERROR* ======== ==================================== second probe says 420_also modes supported but no 420_only mode: ============= [ 1.278673] [drm:drm_add_display_info] *ERROR* YCBCR420 (also) supported =Y [ 1.278678] [drm:drm_add_display_info] *ERROR* YCBCR420 (only) supported =N [ 1.278682] [drm:drm_add_display_info] *ERROR* YCBCR420 dc support =N [ 1.278686] [drm:drm_add_display_info] *ERROR* ======== ==================================== and the third probe says both 420_also as well as 420_only supported: ============= [ 1.460456] [drm:drm_add_display_info] *ERROR* YCBCR420 (also) supported =Y [ 1.460564] [drm:drm_add_display_info] *ERROR* YCBCR420 (only) supported =Y [ 1.460566] [drm:drm_add_display_info] *ERROR* YCBCR420 dc support =N [ 1.460567] [drm:drm_add_display_info] *ERROR* ======== ==================================== I am not sure how HF-VSDB block is changing every probe, that to in an incremental supported way :) - Shashank
yeah but when you look closer to logs only first probing is wrong - next few are correct. but question is why during boot probing HDMI 3-4 or more times until system start ? and second, why after switch refreshrate signal gone ? after reconnect HDMI cable back. Compare to kaby lake - I saw in logs HDMI is probing only once .... and everything is good, also on AMLogic box - all good - same TV ... And same problems with gemini lake has a lot people on forum kodi/Ubuntu
Can you please share your KBL logs, with these two patches and same monitor ? - Shashank
here log http://ix.io/18OA and yes probing also few times, but at least after swithing framerate, no any issue. Only Kaby lake is affected
And here more - slighty older kernel but also with your 2 patches Diffrent 4K TV (OLED) and also one more log connected over AVR (tested on kaby lake) here connected direcly to TV http://ix.io/WHa here to AVR http://ix.io/WH8 Also EDID changing on fly - at least on first probing so 2 different vendors of TV: Samsung, LG and same problem over AVR same story
For me it is also a problem on gemini lake. I loose HDMI output while switching back to full HD at 60HZ from various frequencies. I have an Asrock J4105-ITX and at the moment it is not really usable.
I have this issue on my NUC7PJYH (Gemini Lake Pentium J5005) with a completely stock Ubuntu 18.04 Server installation using a Samsung 22" 1080p TV (I'll come back with the exact model number). Here's what happens: 1. When you boot the system, the boot screen ("Intel NUC") is shown, as it should be. 2. Ubuntu starts to boot up and you get to see the first lines of console print-outs. 3. However, as soon as the system loads i915 and switches mode the screen goes black. The TV reports HDMI signal lost. 4. There are two ways to recover: disconnect and reconnect the HDMI plug OR power off and then on the TV. This TV has no such issues with the following hardware: - Apollo Lake Pentium J4205 (using the native HDMI 1.4 output), running Ubuntu 16.10 Server or 17.10 Server - Skylake Core i3-6100U (NUC6i3SYK) running Ubuntu 17.10 (desktop) - Raspberry Pi 3 running Raspbian The fact that this issue seems to be a more general one (one which you'll be able to run into just booting one of the most popular Linux distributions) makes it pretty severe. Check the comments on this article for more people reporting this issue: http://nucblog.net/2018/04/first-major-bios-update-for-nuc7cjyh-gemini-lake-nuc/ Running DVI, i.e. a HDMI to DVI cable, to a computer monitor seems to work fine. I've not run into any black screen issues with the DVI monitors I've tried.
I should add that this issue occurs during almost 100% of boot attempts (at least on this TV). I've booted the system many times during the past week and I believe that HDMI was lost during all boots except one.
Same issue here ! Xorg Log : http://paste.ubuntu.com/p/nvBJwBp3cN/ dmesg Log : http://paste.ubuntu.com/p/Yd9crdcznH/ It is an NUCP7PJYH(2) connected to an Onkyo TX-NR676E If i Switch from htpc to tv and from tv to HTPC i lost the signal. is there a solutions?
Same problem for me on Ubuntu 18.04. Signal lost when xorg is loading driver. However I was able to get the signal back by running "xset s off -dpms", not been able to reproduce that though. Messed around a bit with xrandr and sometimes got signal back by lowering resolution and framerate but not consistently.
guys, I installed the kernel 4.17-rc3 and "seems" to keep the signal. Can you give me some feedback?
I spoke too soon ... not working ...
latest drm-tip even worst no signal at all !
Ville, Imre, any help here?
Reporters, please send also dmesg with drm.debug=0x1e log_buf_len=4M?
Created attachment 139404 [details] dmesg log booting Ubuntu 18.04 Server Log taken after booting Ubuntu 18.04 Server on NUC7PJYH using Samsung UE22H5005 (22" 1080p TV) as monitor. The HDMI signal was lost very shortly (1-2 seconds) after the Ubuntu boot process started (I get to see a few of the boot log printouts before the screen goes black). Note: I turned the TV off and then on again to regain the picture after Ubuntu had booted.
Ville, Shashank, Imre, anything obvious from log provided?
on latest drm-tip from yesterday http://ix.io/19FW here when i tried inject EDID http://ix.io/19FZ in both case no picture at all :( NUC updated to latest bios from 30/04/2018 and connected to TV QLED SAMSUNG 55` 4K Q7
maybe here is problem ? [ 6.777476] [drm:drm_scdc_set_high_tmds_clock_ratio] Failed to set TMDS clock ratio: -6 [ 6.777483] [drm:intel_enable_ddi] *ERROR* [CONNECTOR:101:HDMI-A-1] Failed to configure sink scrambling/TMDS bit clock ratio [ 6.777507] [drm:intel_audio_codec_enable] ELD on [CONNECTOR:101:HDMI-A-1], [ENCODER:100:DDI B] [ 6.777511] [drm:hsw_audio_codec_enable] Enable audio codec on pipe A, 40 bytes ELD [ 6.777520] [drm:audio_config_hdmi_pixel_clock] HDMI audio pixel clock setting for 594000 not found, falling back to defaults [ 6.777523] [drm:audio_config_hdmi_pixel_clock] Configuring HDMI audio for pixel clock 25200 (0x00010000)
Please look bug: https://bugs.freedesktop.org/show_bug.cgi?id=105655 as it was fixed on drm-tip already. Please try to use drm-tip.
so not fully ;) that from log when I tried inject EDID just to check if there is any difference ... that issue not appear when I just normal boot without injecting EDID
(In reply to Jani Saarinen from comment #29) > Please look bug: https://bugs.freedesktop.org/show_bug.cgi?id=105655 as it > was fixed on drm-tip already. Please try to use drm-tip. drm-tip from yesterday 52cc80146d935aa902a3e0fc54268a99fcf68ccf
Please _attach_ the logs to the bug. Otherwise we're likely to lose them at some point.
how can i do this : dmesg with drm.debug=0x1e log_buf_len=4M? ? it's a grub parameter?
fatez: For some reason, I could not get to the Grub menu on my installation. So, here's what I did: 1. sudo nano /etc/default/grub 2. Find the line that says GRUB_CMDLINE_LINUX="". Add the following between the quotes: drm.debug=0x1e log_buf_len=4M NOTE: If there's already text between the quotation marks, just add the text at the end of the quote, with a space separating it from the existing text. 3. sudo update-grub 4. Reboot and dump log to file: dmesg > dmesg.txt
(In reply to Brunnis from comment #34) > fatez: For some reason, I could not get to the Grub menu on my installation. > So, here's what I did: > > 1. sudo nano /etc/default/grub > 2. Find the line that says GRUB_CMDLINE_LINUX="". Add the following between > the quotes: drm.debug=0x1e log_buf_len=4M > NOTE: If there's already text between the quotation marks, just add the > text at the end of the quote, with a space separating it from the existing > text. > 3. sudo update-grub > 4. Reboot and dump log to file: dmesg > dmesg.txt Here the log's whit the latest kernel (4.17-rc4) Dmesg log : http://paste.ubuntu.com/p/HCwbkXMC42/ Xorg.0.log http://paste.ubuntu.com/p/zgQH5hKcXt/ syslog http://paste.ubuntu.com/p/ngm7Dsnkjq/
(In reply to fatez from comment #35) > (In reply to Brunnis from comment #34) > > fatez: For some reason, I could not get to the Grub menu on my installation. > > So, here's what I did: > > > > 1. sudo nano /etc/default/grub > > 2. Find the line that says GRUB_CMDLINE_LINUX="". Add the following between > > the quotes: drm.debug=0x1e log_buf_len=4M > > NOTE: If there's already text between the quotation marks, just add the > > text at the end of the quote, with a space separating it from the existing > > text. > > 3. sudo update-grub > > 4. Reboot and dump log to file: dmesg > dmesg.txt > > Here the log's whit the latest kernel (4.17-rc4) > > Dmesg log : http://paste.ubuntu.com/p/HCwbkXMC42/ > Xorg.0.log http://paste.ubuntu.com/p/zgQH5hKcXt/ > syslog http://paste.ubuntu.com/p/ngm7Dsnkjq/ just to be clear : I have an NUC7PJHH(2) with 2 hdmi port; The first HDMI is connected directly to my Samsung KS8000 (4K) The second HDMI is connected into an SyntoAV (Onkyo that) just only for audio reason (kodi htpc)
Created attachment 139432 [details] Ubuntu 18.04 Linux kodi 4.17.0-994-generic #201805072200 SMP
Created attachment 139433 [details] Log when TV is switched off and on Signal returns when switching on/off the TV.
Any news? ;)
If it helps I can try to provide more info too. But I would need some explanation how to do this, since I am a noob regarding this logs. Again I am using an Asrock J4105-ITX with libreELEC. It is an custom build with latest Kernel by the opener Piotr Kasp.
Hi, Another NUC7CJYH buyer/user here. I'm having the same issue as the rest of you, but I experience it somewhat different. My setup: NUC7CJYH, Ubuntu 18.04 (up-to-date), Kodi 17.6. In my case it somehow seems related to the skin: Default skin (estuary); switching back from 24hz back to 60hz => OK! Aeon Nox or Arctic; switching back from 24hz back to 60hz => NOT OK! And the video type (HD/SD): Aeon Nox or Arctic & SD content; switching back from 24hz to 60 => OK! Maybe I somehow got lucky in those 'okay' situations, but who knows. It might be something to go on. I'll do some more testing as soon as I can (hopefully somewhere next week)
(In reply to Lourens from comment #41) > Hi, > Another NUC7CJYH buyer/user here. > > I'm having the same issue as the rest of you, but I experience it somewhat > different. > > My setup: > NUC7CJYH, Ubuntu 18.04 (up-to-date), Kodi 17.6. > > In my case it somehow seems related to the skin: > Default skin (estuary); switching back from 24hz back to 60hz => OK! > Aeon Nox or Arctic; switching back from 24hz back to 60hz => NOT OK! > > And the video type (HD/SD): > Aeon Nox or Arctic & SD content; switching back from 24hz to 60 => OK! > > > Maybe I somehow got lucky in those 'okay' situations, but who knows. It > might be something to go on. > > I'll do some more testing as soon as I can (hopefully somewhere next week) I have the nuc7pjyh and this problem does me every time I step from HDM1 (Kodi) to HDM2 (Sky) then go back to Kodi It's not the skin, it goes even if I stay in bash
(In reply to fatez from comment #42) > (In reply to Lourens from comment #41) > > Hi, > > Another NUC7CJYH buyer/user here. > > > > I'm having the same issue as the rest of you, but I experience it somewhat > > different. > > > > My setup: > > NUC7CJYH, Ubuntu 18.04 (up-to-date), Kodi 17.6. > > > > In my case it somehow seems related to the skin: > > Default skin (estuary); switching back from 24hz back to 60hz => OK! > > Aeon Nox or Arctic; switching back from 24hz back to 60hz => NOT OK! > > > > And the video type (HD/SD): > > Aeon Nox or Arctic & SD content; switching back from 24hz to 60 => OK! > > > > > > Maybe I somehow got lucky in those 'okay' situations, but who knows. It > > might be something to go on. > > > > I'll do some more testing as soon as I can (hopefully somewhere next week) > > I have the nuc7pjyh and this problem does me every time I step from HDM1 > (Kodi) to HDM2 (Sky) then go back to Kodi > It's not the skin, it goes even if I stay in bash Also here, your problem and mine (if I understand correctly) are different. Your switching HDMI ports, again of I understand correctly, I am not switching from HDMI 1 to HDMI 2 and back. My issue is that the TV blanks when the output goes from 24hz back to 60hz.
@dev Do you have any news for us? :)
Could you all provide the followings found on the back of NUC (some may be missing): - Product code - Project code - Date of manufacture Thanks.
Product Code: BOXNUC7PJYH Regulatory model: NUC7JY Date of Manufacture: 03/18 (no project code)
Notes from debug: Issue appears to occur anytime the display switches from a 74.xxx MHz mode (23.98, 24, 29.97, 30 Hz) to a higher clock frequency (148 Mhz and 296 Mhz at 50, 59.94, and 60 Hz). Long HPD pulse restores output at the selected resolution. PLL programming during failure is correct based on dpll_hw_state in the logs during success and failure. CDCLK remains constant at 316MHz. i915_power_domain_info shows identical "Use counts" during working and non-working cases. Reviewed GLK workaround database for similar issue. Nothing Found.
Product Code: BOXNUC7CJYH1 Regulatory model: NUC7JY Date of Manufacture: 02/18 (no project code) but i think doesn't matter same problem is on asrock, MSI etc. its looks like mess arround HDMI 2.0, i tested coffe Lake with LSPCON and there is eveything perfect.
(In reply to Piotr Kasp. from comment #48) > Product Code: BOXNUC7CJYH1 > Regulatory model: NUC7JY > Date of Manufacture: 02/18 > (no project code) > > > but i think doesn't matter same problem is on asrock, MSI etc. > its looks like mess arround HDMI 2.0, i tested coffe Lake with LSPCON and > there is eveything perfect. CoffeeLake and GeminiLake use a different clock implementation. This issue appears to be a PLL enable sequence issue when switching for lower to higher clock rates. Issue does not occur if I disable 12 bpc support in the driver. For a quick test: In intel_hdmi.c mothod hdmi_12bpc_possible() add return false;
(In reply to Clinton Taylor from comment #49) > (In reply to Piotr Kasp. from comment #48) > > Product Code: BOXNUC7CJYH1 > > Regulatory model: NUC7JY > > Date of Manufacture: 02/18 > > (no project code) > > > > > > but i think doesn't matter same problem is on asrock, MSI etc. > > its looks like mess arround HDMI 2.0, i tested coffe Lake with LSPCON and > > there is eveything perfect. > > CoffeeLake and GeminiLake use a different clock implementation. This issue Correction, both CoffeeLake and GeminiLake use the BXT PLL code. > appears to be a PLL enable sequence issue when switching for lower to higher > clock rates. > > Issue does not occur if I disable 12 bpc support in the driver. > > For a quick test: > > In intel_hdmi.c mothod hdmi_12bpc_possible() > > add > return false;
(In reply to Clinton Taylor from comment #49) > Issue does not occur if I disable 12 bpc support in the driver. > > For a quick test: > > In intel_hdmi.c mothod hdmi_12bpc_possible() > > add > return false; Using an ASRock J5005-ITX on stock Ubuntu 18.04 w/Kernel 4.15, connected to an Onkyo TX-NR509 AV receiver, which shows similar sympthoms (ie. if the resolution goes up (pixel clock rate increases) from the boot res to 1080p50 or 1080p60, the TV picture goes away/blue and the receiver says "No signal". The receiver must be power-cycled to get a picture again). Tried the above (modified Ubuntu kernel sources accordingly, repackaged, installed and booted) - makes the issue go away with this workaround, switching from 50p/60p to 24p and back works, no "No signal". Everything else video-related remains working normally.
(In reply to Daniel Scheller from comment #51) > (In reply to Clinton Taylor from comment #49) > > > Issue does not occur if I disable 12 bpc support in the driver. > > > > For a quick test: > > > > In intel_hdmi.c mothod hdmi_12bpc_possible() > > > > add > > return false; > > Using an ASRock J5005-ITX on stock Ubuntu 18.04 w/Kernel 4.15, connected to > an Onkyo TX-NR509 AV receiver, which shows similar sympthoms (ie. if the > resolution goes up (pixel clock rate increases) from the boot res to 1080p50 > or 1080p60, the TV picture goes away/blue and the receiver says "No signal". > The receiver must be power-cycled to get a picture again). > > Tried the above (modified Ubuntu kernel sources accordingly, repackaged, > installed and booted) - makes the issue go away with this workaround, > switching from 50p/60p to 24p and back works, no "No signal". Everything > else video-related remains working normally. Could you explain exactly how to do it? Also I use Ubuntu 18.04
static bool hdmi_12bpc_possible(const struct intel_crtc_state *crtc_state) { struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev); struct drm_atomic_state *state = crtc_state->base.state; struct drm_connector_state *connector_state; struct drm_connector *connector; int i; return false; if (HAS_GMCH_DISPLAY(dev_priv)) return false; Is this correct?
(In reply to Daniel Scheller from comment #51) I managed to compile from 0 kernel, can I ask you just the courtesy to attach here your intel_hdmi.c patched?
(In reply to fatez from comment #52) > Could you explain exactly how to do it? Also I use Ubuntu 18.04 As I've been asked by a few people, I've put the repo up at GitHub. The exact change I applied to intel_hdmi.c is at [1], and you can build a kernel image right from the 4.15.0-21.22-glktesting branch (see [2]). NB: Whenever something gets added to this issue, I'll keep on adding that to that branch for testing purposes. [1] https://github.com/herrnst/ubuntu-bionic-kernel/commit/3d664ae3c8831a51139efbb5298fc27a1bee4950 [2] https://github.com/herrnst/ubuntu-bionic-kernel/commits/4.15.0-21.22-glktesting
(In reply to Daniel Scheller from comment #55) > (In reply to fatez from comment #52) > > > Could you explain exactly how to do it? Also I use Ubuntu 18.04 > > As I've been asked by a few people, I've put the repo up at GitHub. The > exact change I applied to intel_hdmi.c is at [1], and you can build a kernel > image right from the 4.15.0-21.22-glktesting branch (see [2]). > > NB: Whenever something gets added to this issue, I'll keep on adding that to > that branch for testing purposes. > > [1] > https://github.com/herrnst/ubuntu-bionic-kernel/commit/ > 3d664ae3c8831a51139efbb5298fc27a1bee4950 > [2] > https://github.com/herrnst/ubuntu-bionic-kernel/commits/4.15.0-21.22- > glktesting Hello, I asked you exactly how to do to see if I was wrong something, unfortunately for me does not go I leave the logs of DMESG and Xorg and the compiled kernel (4.16.10) dmesg -> http://paste.ubuntu.com/p/9CKhZbCMhK/ Xorg.0.log -> http://paste.ubuntu.com/p/QHmWjTTZmN/ Kernel 4.16.10 -> https://mega.nz/#!8tRHnYKY!-y4jc8-mpwe1vVqG5JmRjva6m9RX4j88q8h4bGmIhks At this point I don't know what to do anymore!
For convenience, installable kernel-image/headers et al debs at [1] (clone the repo, checkout the branch and then just do "dpkg -i <package>.deb", install whatever is needed). No responsibility of any kind, use at your own risk etc. [1] https://github.com/herrnst/ubuntu-bionic-kernel/tree/4.15.0-21.22-glktesting-deb
I tried your but from me it does not work. I compiled the kernel 4.17-rc5 manually inserting the fix and not even this works, here are the logs and the kernel .deb dmesg -> http://paste.ubuntu.com/p/VBnyzYzC7d/ Xorg.0.log -> http://paste.ubuntu.com/p/67gnqNvZ9H/ Kernel 4.17-rc5 -> https://mega.nz/#!skh0SCzS!QqS4u6k_I5X0n8F0h8vd3HqVgczYSm4iWXNOcb1VHgY
(In reply to Daniel Scheller from comment #57) > For convenience, installable kernel-image/headers et al debs at [1] (clone > the repo, checkout the branch and then just do "dpkg -i <package>.deb", > install whatever is needed). No responsibility of any kind, use at your own > risk etc. > > [1] > https://github.com/herrnst/ubuntu-bionic-kernel/tree/4.15.0-21.22-glktesting- > deb Thanks, works great!
@Erik Sandlund @Daniel Scheller But the signal keeps it even if you change from Hdmi1 to Hdmi2 and then return to HDMI1? Can you try the kernel I compiled myself and see if it works for you? Kernel 4.17-rc5 -> https://mega.nz/#!skh0SCzS!QqS4u6k_I5X0n8F0h8vd3HqVgczYSm4iWXNOcb1VHgY
(In reply to Daniel Scheller from comment #51) > (In reply to Clinton Taylor from comment #49) > > > Issue does not occur if I disable 12 bpc support in the driver. > > > > For a quick test: > > > > In intel_hdmi.c mothod hdmi_12bpc_possible() > > > > add > > return false; > > Using an ASRock J5005-ITX on stock Ubuntu 18.04 w/Kernel 4.15, connected to > an Onkyo TX-NR509 AV receiver, which shows similar sympthoms (ie. if the > resolution goes up (pixel clock rate increases) from the boot res to 1080p50 > or 1080p60, the TV picture goes away/blue and the receiver says "No signal". > The receiver must be power-cycled to get a picture again). > > Tried the above (modified Ubuntu kernel sources accordingly, repackaged, > installed and booted) - makes the issue go away with this workaround, > switching from 50p/60p to 24p and back works, no "No signal". Everything > else video-related remains working normally. Thanks for testing the workaround. We will work on the permanent fix for the upstream driver.
(In reply to fatez from comment #60) > @Erik Sandlund @Daniel Scheller > But the signal keeps it even if you change from Hdmi1 to Hdmi2 and then > return to HDMI1? > > Can you try the kernel I compiled myself and see if it works for you? > > Kernel 4.17-rc5 -> > https://mega.nz/#!skh0SCzS!QqS4u6k_I5X0n8F0h8vd3HqVgczYSm4iWXNOcb1VHgY @fatez; I still believe your issue is different than the one that this bug report is about. Therefore the work-around presented above will not fix your HDMI switching issue. Maybe you should create a new (if it's not already there) bug report about it?
(In reply to Lourens from comment #62) > (In reply to fatez from comment #60) > > @Erik Sandlund @Daniel Scheller > > But the signal keeps it even if you change from Hdmi1 to Hdmi2 and then > > return to HDMI1? > > > > Can you try the kernel I compiled myself and see if it works for you? > > > > Kernel 4.17-rc5 -> > > https://mega.nz/#!skh0SCzS!QqS4u6k_I5X0n8F0h8vd3HqVgczYSm4iWXNOcb1VHgY > > @fatez; > I still believe your issue is different than the one that this bug report is > about. > Therefore the work-around presented above will not fix your HDMI switching > issue. > > Maybe you should create a new (if it's not already there) bug report about > it? You're right! For me it is the first time, can you help me in what section should I write?
> I have this issue on my NUC7PJYH (Gemini Lake Pentium J5005) with a > completely stock Ubuntu 18.04 Server installation using a Samsung 22" 1080p > TV (I'll come back with the exact model number). Here's what happens: > > 1. When you boot the system, the boot screen ("Intel NUC") is shown, as it > should be. > 2. Ubuntu starts to boot up and you get to see the first lines of console > print-outs. > 3. However, as soon as the system loads i915 and switches mode the screen > goes black. The TV reports HDMI signal lost. > 4. There are two ways to recover: disconnect and reconnect the HDMI plug OR > power off and then on the TV. My experience is identical to the above. I also have a NUC7PJYH with HDMI1 plugged into a Sony STR-DH810, which is plugged into a Panasonic VIERA TC-P54V10 plasma TV. I'm running Debian sid/unstable. This problem only happens with the NUC. If I swap out the NUC with any of my other boxes, it's fine. I can confirm that applying https://github.com/herrnst/ubuntu-bionic-kernel/commit/3d664ae3c8831a51139efbb5298fc27a1bee4950 "i915/glk: effectively disable hdmi_12bps_possible()" does in fact solve the problem for me. It's my understanding this is a workaround rather than a proper fix. If I can supply logging, edid, or something that would be helpful towards a proper fix, please let me know. Considering this problem does seem to be wide-spread, thank you to everyone contributing to get it resolved! I just got this NUC and was really disappointed to find this kind of bug.
> I can confirm that applying > https://github.com/herrnst/ubuntu-bionic-kernel/commit/ > 3d664ae3c8831a51139efbb5298fc27a1bee4950 "i915/glk: effectively disable > hdmi_12bps_possible()" does in fact solve the problem for me. It's my > understanding this is a workaround rather than a proper fix. If I can supply > logging, edid, or something that would be helpful towards a proper fix, > please let me know. > Thanks for the offer, however the failure doesn't actually show up in the logs. This appears to be a transcoder disable sequencing issue. The driver sequence has been confirmed as correct according to the Gemini Lake documentation. Why this happens only at 12bpc is still a mystery. 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.
(In reply to fatez from comment #63) > (In reply to Lourens from comment #62) > > (In reply to fatez from comment #60) > > > @Erik Sandlund @Daniel Scheller > > > But the signal keeps it even if you change from Hdmi1 to Hdmi2 and then > > > return to HDMI1? > > > > > > Can you try the kernel I compiled myself and see if it works for you? > > > > > > Kernel 4.17-rc5 -> > > > https://mega.nz/#!skh0SCzS!QqS4u6k_I5X0n8F0h8vd3HqVgczYSm4iWXNOcb1VHgY > > > > @fatez; > > I still believe your issue is different than the one that this bug report is > > about. > > Therefore the work-around presented above will not fix your HDMI switching > > issue. > > > > Maybe you should create a new (if it's not already there) bug report about > > it? > > You're right! For me it is the first time, can you help me in what section > should I write? bump
Created attachment 139778 [details] Scope shot of input and output of level shifter
After bashing my head against he wall for several days I have finally determined that the issue is caused by the HDMI level shifter on the board and not a driver issue. After changing the mode from 1080p24 to 1080p50 the scope shows a valid clock into the level shifter and a very low amplitude clock on the output to the connector. Adding a short delay after the Transcoder is disabled appears to solve the issue with the level shifter. I have attached a scope shot of the waveform into the level shifter (yellow trace) and the output to the connector (blue trace).
(In reply to Clinton Taylor from comment #68) > After bashing my head against he wall for several days I have finally > determined that the issue is caused by the HDMI level shifter on the board > and not a driver issue. > > After changing the mode from 1080p24 to 1080p50 the scope shows a valid > clock into the level shifter and a very low amplitude clock on the output to > the connector. Adding a short delay after the Transcoder is disabled appears > to solve the issue with the level shifter. > > I have attached a scope shot of the waveform into the level shifter (yellow > trace) and the output to the connector (blue trace). Thanks for investigating this further and even finding a "proper" driver workaround for this hardware problem. I did a test with msleep(50) at the end of intel_ddi.c:intel_ddi_disable_transcoder_func() (see [1]) on the ASRock board, and this helps the "No signal" issue aswell. I went a bit further and added a modparam to switch between different GLK tests, which by now are "no 12bpc" and "msleep(50)" ([2] is what everything looks like right now, esp. re patches/tests) :-) If anyone else likes to do some testing: I've put installable kernel .debs up at [3] for easy install (Ubuntu Bionic 4.15.0-23.25 proposed, with the patches ontop). To enable any of the workarounds, use the parameter glkhdmi (set to 1 for the 12bit disable hack, set to 2 for the msleep test). Easiest is to add i915.glkhdmi=X (replace X with 1 or 2) to /etc/default/grub into GRUB_CMDLINE_LINUX_DEFAULT, then update-grub, then reboot. Note if you don't set the option or set it to zero, you'll get stock behaviour and the "No signal" issue back. [1] https://github.com/herrnst/ubuntu-bionic-kernel/commit/f0503e843b8223a2a4572c573a120cd49a8e7134 [2] https://github.com/herrnst/ubuntu-bionic-kernel/compare/Ubuntu-4.15.0-23.25...4.15.0-23.25-glktesting [3] https://github.com/herrnst/ubuntu-bionic-kernel/tree/4.15.0-23.25-glktesting-deb
I'll test these workarounds over the next couple days. So far the `disable 12bpc` has worked good here - no problems. I also modified the patch a little so you can select what you want the default setting to be in menuconfig (I prefer that over using custom grub commands). Is either of these workarounds more preferable over the other? Any potential negative impacts or drawbacks each may have? Thanks!
Guys I ask you a favor, I opened a ticket here https://bugs.freedesktop.org/show_bug.cgi?id=106659 but no one probably has my same problem. After applying the two "fix" from Clinton Taylor (msleep(50); and return false;) if i set 3840x2160@24p in kodi and shift from hdmi1 (kodi) to hdmi2 (sky) and return in hdmi i never lost the signal BUT if i in kodi set 3840x2160@60p and shift from hdmi1 to 2 and return in hdmi1 i lost the signal. Is there a similar solution for 24p even for 60p?
(In reply to Clinton Taylor from comment #68) > After bashing my head against he wall for several days I have finally > determined that the issue is caused by the HDMI level shifter on the board > and not a driver issue. > > After changing the mode from 1080p24 to 1080p50 the scope shows a valid > clock into the level shifter and a very low amplitude clock on the output to > the connector. Adding a short delay after the Transcoder is disabled appears > to solve the issue with the level shifter. > > I have attached a scope shot of the waveform into the level shifter (yellow > trace) and the output to the connector (blue trace). Hello Clinton, What kind of level shifter is this ? Is it DP -> HDMI passive LS or something else ? Do you have any information about it ? - Shashank
> Hello Clinton, > What kind of level shifter is this ? Is it DP -> HDMI passive LS or > something else ? Do you have any information about it ? > The component is a HDMI 2.0 retiming buffer. The data sheet was sent to you on 5/8 by Imre for the following issue. https://bugs.freedesktop.org/show_bug.cgi?id=106182. I can't attach a third party's datasheet to this issue.
Well, I could not relate that, as there are few parallel thread. Also I don't understand why we need a HDMI 2.0 retimer on GLK as it already has a HDMI 2.0 native controller, unless someone needs 2 or 3 HDMI 2.0 sources coming out of GLK NUC, and NUC was short of it, and some platform team decided to use some Paradetech dongle to convert DP 1.2 -> HDMI 2.0. As I don't know anything about this parade chip PS176, and also its been diagnosed that the dongle is causing low amplitude outputs on particular frequencies, I guess we should escalate to Paradetech team. - Shashank
(In reply to shashank.sharma@intel.com from comment #74) > Well, I could not relate that, as there are few parallel thread. Also I > don't understand why we need a HDMI 2.0 retimer on GLK as it already has a > HDMI 2.0 native controller, unless someone needs 2 or 3 HDMI 2.0 sources > coming out of GLK NUC, and NUC was short of it, and some platform team > decided to use some Paradetech dongle to convert DP 1.2 -> HDMI 2.0. > The ITE66317 retimer implementation does seem to be causing the Linux driver some difficulty. Based on what I have seen so far, the Linux driver doesn't wait long enough during mode changes for the retimer to sync correctly to the new faster clock.
(In reply to Clinton Taylor from comment #75) > (In reply to shashank.sharma@intel.com from comment #74) > > Well, I could not relate that, as there are few parallel thread. Also I > > don't understand why we need a HDMI 2.0 retimer on GLK as it already has a > > HDMI 2.0 native controller, unless someone needs 2 or 3 HDMI 2.0 sources > > coming out of GLK NUC, and NUC was short of it, and some platform team > > decided to use some Paradetech dongle to convert DP 1.2 -> HDMI 2.0. > > > > The ITE66317 retimer implementation does seem to be causing the Linux driver > some difficulty. Based on what I have seen so far, the Linux driver doesn't > wait long enough during mode changes for the retimer to sync correctly to > the new faster clock. If that's the case, in order to upstream this kind of solution in driver, we need to: - detect if this is the specific device with re-timer, because a general purpose wait in encoder path wont be acceptable, in driver. - we need the official sepc indicating this encoder needs this range of timing delay for these pixel clock rates. - Shashank
Could this issue affect Windows as well? Interesting comment from Intel’s support forums: https://communities.intel.com/message/546381#546381 ”Sometimes changing the refresh rate or resolution in Windows results in a black screen as well and only pulling out and plugging back the HDMI cable resets the state and gets me picture.” I remember getting a black screen once when I initially ran Win 10 on my NUC7PJYH and ran Passmark’s GPU tests. Anyway, I know this bug tracker doesn’t concern itself with Windows issues, but could be interesting to sync this between the driver teams (if that hasn’t already been done).
For anyone interested, this is the patch I've been using - patch from Daniel Scheller modified to allow setting the default workaround behavior via Kconfig/menuconfig in case you don't want to bother with the grub command line. Patch is here: https://pastebin.com/rimPf2x1
Just thought I'd mention that the 50 ms sleep workaround is effective on my system as well, using the Samsung UE22H5005 1080p TV.
reference: https://patchwork.freedesktop.org/series/44446/
(In reply to Jani Saarinen from comment #80) > reference: https://patchwork.freedesktop.org/series/44446/ Can I apply this patch to the 4.17 kernel or i must have DRM-tip?
It will probably apply to 4.17. It's not much different than the 50ms wait you were using before. The patch just detects a GLK NUC before waiting 42ms. I would like some tests to make sure a 42ms delay is enough. I probably ran 200 cycles in testing, but would really like more to confirm the workaround.
(In reply to Clinton Taylor from comment #82) > It will probably apply to 4.17. It's not much different than the 50ms wait > you were using before. The patch just detects a GLK NUC before waiting 42ms. > > I would like some tests to make sure a 42ms delay is enough. I probably ran > 200 cycles in testing, but would really like more to confirm the workaround. The good news is your patch applies to 4.17. The bad news is it doesn't work here going from a NUC7PJYH -> Sony surround receiver -> Panasonic TV.
(In reply to user.forums from comment #83) > (In reply to Clinton Taylor from comment #82) > > It will probably apply to 4.17. It's not much different than the 50ms wait > > you were using before. The patch just detects a GLK NUC before waiting 42ms. > > > > I would like some tests to make sure a 42ms delay is enough. I probably ran > > 200 cycles in testing, but would really like more to confirm the workaround. > > The good news is your patch applies to 4.17. The bad news is it doesn't work > here going from a NUC7PJYH -> Sony surround receiver -> Panasonic TV. I tried increasing the 42 value to 45, 50, 100, 150. Nothing works. Additional, I noticed that with this patch I don't even see any of the systemd stuff pass by as I do with no patch applied.
(In reply to Jani Saarinen from comment #80) > reference: https://patchwork.freedesktop.org/series/44446/ This patch (backported to the Ubuntu 4.15.0 kernel sources as a replacement for the "hack selection", see above) doesn't work on my J5005-ITX either. Upon boot, the "No signal" issue is back, reverting to the previous kernel with the plain 50ms wait makes it work again.
(In reply to Daniel Scheller from comment #85) > (In reply to Jani Saarinen from comment #80) > > reference: https://patchwork.freedesktop.org/series/44446/ > > This patch (backported to the Ubuntu 4.15.0 kernel sources as a replacement > for the "hack selection", see above) doesn't work on my J5005-ITX either. > Upon boot, the "No signal" issue is back, reverting to the previous kernel > with the plain 50ms wait makes it work again. Sadly can't just edit the comment. For reference, the hardware IDs for the GLK GPU on this board (lspci -vvn): 00:02.0 0300: 8086:3184 (rev 03) (prog-if 00 [VGA controller]) Subsystem: 1849:2212 Again, unconditionally waiting 50ms at the end of intel_ddi_disable_transcoder_func() works, so I suspect all GLK hardware needs this, not only the NUCs.
(In reply to Clinton Taylor from comment #82) > It will probably apply to 4.17. It's not much different than the 50ms wait > you were using before. The patch just detects a GLK NUC before waiting 42ms. > > I would like some tests to make sure a 42ms delay is enough. I probably ran > 200 cycles in testing, but would really like more to confirm the workaround. I confirm that you have applied the patch to the kernel 4.17 but on 10 times 4 times does not work
(In reply to fatez from comment #87) > (In reply to Clinton Taylor from comment #82) > > It will probably apply to 4.17. It's not much different than the 50ms wait > > you were using before. The patch just detects a GLK NUC before waiting 42ms. > > > > I would like some tests to make sure a 42ms delay is enough. I probably ran > > 200 cycles in testing, but would really like more to confirm the workaround. > > I confirm that you have applied the patch to the kernel 4.17 but on 10 times > 4 times does not work I mean "I have applied..."
> > Sadly can't just edit the comment. For reference, the hardware IDs for the > GLK GPU on this board (lspci -vvn): > > 00:02.0 0300: 8086:3184 (rev 03) (prog-if 00 [VGA controller]) > Subsystem: 1849:2212 > > Again, unconditionally waiting 50ms at the end of > intel_ddi_disable_transcoder_func() works, so I suspect all GLK hardware > needs this, not only the NUCs. Daniel, Could you add the following to to intel_quirks[] in intel_display.c { 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time }, I really don't want to add the delay to all GLK's, but even the ASrock photo's show the ITE chip in use on the board. I don't have a guaranteed way to detect the ITE chip on the boards. Thanks, Clint
(In reply to user.forums from comment #84) > (In reply to user.forums from comment #83) > > (In reply to Clinton Taylor from comment #82) > > > It will probably apply to 4.17. It's not much different than the 50ms wait > > > you were using before. The patch just detects a GLK NUC before waiting 42ms. > > > > > > I would like some tests to make sure a 42ms delay is enough. I probably ran > > > 200 cycles in testing, but would really like more to confirm the workaround. > > > > The good news is your patch applies to 4.17. The bad news is it doesn't work > > here going from a NUC7PJYH -> Sony surround receiver -> Panasonic TV. > Could you run lspci -vvn -s00:02.0 from a console prompt and post the results? Thanks, Clint
(In reply to Clinton Taylor from comment #90) > (In reply to user.forums from comment #84) > > (In reply to user.forums from comment #83) > > > (In reply to Clinton Taylor from comment #82) > > > > It will probably apply to 4.17. It's not much different than the 50ms wait > > > > you were using before. The patch just detects a GLK NUC before waiting 42ms. > > > > > > > > I would like some tests to make sure a 42ms delay is enough. I probably ran > > > > 200 cycles in testing, but would really like more to confirm the workaround. > > > > > > The good news is your patch applies to 4.17. The bad news is it doesn't work > > > here going from a NUC7PJYH -> Sony surround receiver -> Panasonic TV. > > > > Could you run lspci -vvn -s00:02.0 from a console prompt and post the > results? > > Thanks, > Clint Sure thing.. ~$ lspci -vvn -s00:02.0 00:02.0 0300: 8086:3184 (rev 03) (prog-if 00 [VGA controller]) Subsystem: 8086:2072 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 124 Region 0: Memory at a0000000 (64-bit, non-prefetchable) [size=16M] Region 2: Memory at 90000000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at f000 [size=64] [virtual] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: <access denied> Kernel driver in use: i915 Kernel modules: i915
(In reply to Clinton Taylor from comment #90) > (In reply to user.forums from comment #84) > > (In reply to user.forums from comment #83) > > > (In reply to Clinton Taylor from comment #82) > > > > It will probably apply to 4.17. It's not much different than the 50ms wait > > > > you were using before. The patch just detects a GLK NUC before waiting 42ms. > > > > > > > > I would like some tests to make sure a 42ms delay is enough. I probably ran > > > > 200 cycles in testing, but would really like more to confirm the workaround. > > > > > > The good news is your patch applies to 4.17. The bad news is it doesn't work > > > here going from a NUC7PJYH -> Sony surround receiver -> Panasonic TV. > > > > Could you run lspci -vvn -s00:02.0 from a console prompt and post the > results? > > Thanks, > Clint Whit ur patch and kernel 4.17 : sudo lspci -vvn -s00:02.0 00:02.0 0300: 8086:3184 (rev 03) (prog-if 00 [VGA controller]) Subsystem: 8086:2072 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 128 Region 0: Memory at a0000000 (64-bit, non-prefetchable) [size=16M] Region 2: Memory at 90000000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at f000 [size=64] [virtual] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: [40] Vendor Specific Information: Len=0c <?> Capabilities: [70] Express (v2) Root Complex Integrated Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0 ExtTag- RBE+ DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, OBFF Not Supported DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee00018 Data: 0000 Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [100 v1] Process Address Space ID (PASID) PASIDCap: Exec- Priv-, Max PASID Width: 14 PASIDCtl: Enable- Exec- Priv- Capabilities: [200 v1] Address Translation Service (ATS) ATSCap: Invalidate Queue Depth: 00 ATSCtl: Enable-, Smallest Translation Unit: 00 Capabilities: [300 v1] Page Request Interface (PRI) PRICtl: Enable- Reset- PRISta: RF- UPRGI- Stopped+ Page Request Capacity: 00008000, Page Request Allocation: 00000000 Kernel driver in use: i915 Kernel modules: i915 If I step from HDMI 1 (kodi) to HDMI 2 (Sky) and go back to Kodi, I lose the signal. If I kill Kodi and raise him, after 8-9 times he returns to live but I lose the audio
And again the audio lost : [ 4122.063172] snd_hda_intel 0000:00:0e.0: azx_get_response timeout, switching to polling mode: last cmd=0x20bf8100 [ 4123.075186] snd_hda_intel 0000:00:0e.0: No response from codec, disabling MSI: last cmd=0x20bf8100 [ 4124.087207] snd_hda_intel 0000:00:0e.0: azx_get_response timeout, switching to single_cmd mode: last cmd=0x20bf8100 [ 4124.371430] snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f0d00. -5
(In reply to Clinton Taylor from comment #89) Hi Clint, > > Sadly can't just edit the comment. For reference, the hardware IDs for the > > GLK GPU on this board (lspci -vvn): > > > > 00:02.0 0300: 8086:3184 (rev 03) (prog-if 00 [VGA controller]) > > Subsystem: 1849:2212 > > > > Again, unconditionally waiting 50ms at the end of > > intel_ddi_disable_transcoder_func() works, so I suspect all GLK hardware > > needs this, not only the NUCs. > > Daniel, > Could you add the following to to intel_quirks[] in intel_display.c > > { 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time }, Done (could have tried that myself though already since it's obvious it won't do anything without matching hardware IDs). With that, your patch works well, just like with the 50ms unconditional delay. My i915.ko now carries [1] (your original patch plus unrelated fixups for the 4.15 backport) and [2] (with additional hardware IDs), please ignore any debian changelog changes. > I really don't want to add the delay to all GLK's, but even the ASrock > photo's show the ITE chip in use on the board. I don't have a guaranteed way > to detect the ITE chip on the boards. The list of hardware IDs might get long though. On another forum, one user has the same HDMI issue with an ASRock J4105-ITX with the "slower" (compared to J5005) GLK iGPU, that one identifies with 00:02.0 0300: 8086:3185 (rev 03) (prog-if 00 [VGA controller]) Subsystem: 1849:2212 So, same subsys vendor+id, but different PCI ID. Thats why I added more IDs in [2], the two mentioned by fatez and user.forums@gmail.com are in there aswell. For anyone who wants to test: Ubuntu Kernel debs at [3]. [1] https://github.com/herrnst/ubuntu-bionic-kernel/commit/92f7740df31c5c920d217db210594b4cd9e45413 [2] https://github.com/herrnst/ubuntu-bionic-kernel/commit/b8c66deb38c5b8020b50bfb44c71e06a0275bba3 [3] https://github.com/herrnst/ubuntu-bionic-kernel/tree/4.15.0-23.25-glktesting3-deb
(In reply to Daniel Scheller from comment #94) > For anyone who wants to test: Ubuntu Kernel debs at [3]. > > [1] > https://github.com/herrnst/ubuntu-bionic-kernel/commit/ > 92f7740df31c5c920d217db210594b4cd9e45413 > [2] > https://github.com/herrnst/ubuntu-bionic-kernel/commit/ > b8c66deb38c5b8020b50bfb44c71e06a0275bba3 > [3] > https://github.com/herrnst/ubuntu-bionic-kernel/tree/4.15.0-23.25- > glktesting3-deb Whit Your kernel i can switch from hdmi1 to hdmi2 and return in kodi without losing signal BUT i have lost audio : Jun 12 21:00:19 NucBox kernel: [ 746.347626] snd_hda_intel 0000:00:0e.0: azx_get_response timeout, switching to polling mode: last cmd=0x20bf8100 Jun 12 21:00:20 NucBox kernel: [ 747.359663] snd_hda_intel 0000:00:0e.0: No response from codec, disabling MSI: last cmd=0x20bf8100 Jun 12 21:00:21 NucBox kernel: [ 748.371690] snd_hda_intel 0000:00:0e.0: azx_get_response timeout, switching to single_cmd mode: last cmd=0x20bf8100 Jun 12 21:00:21 NucBox kernel: [ 748.391945] snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f0d00. -5 Jun 12 21:19:30 NucBox kernel: [ 1896.982135] azx_single_send_cmd: 246 callbacks suppressed Jun 12 21:19:30 NucBox kernel: [ 1897.038596] snd_hda_codec_hdmi hdaudioC0D2: Unable to sync register 0x2f0d00. -5
My apoligies. Was a pulse problem. Whit ur latest kernel all works fine. Now is time to watch some video and test it
I spoke too soon... I came home from work and I turned on the TV to watch Kodi and guess what? Lost Signal
Version 2 of the upstream patch has been posted: https://patchwork.freedesktop.org/patch/229363/
(In reply to Clinton Taylor from comment #98) > Version 2 of the upstream patch has been posted: > > https://patchwork.freedesktop.org/patch/229363/ Tested & working here now. Thank you Clinton, and all who contributed!
(In reply to Clinton Taylor from comment #98) > Version 2 of the upstream patch has been posted: > > https://patchwork.freedesktop.org/patch/229363/ Many thanks from me for taking care of this aswell!
I came here with the same problem (J5005 ASRock board, occasional HDMI connection problems with Ubuntu 18.04) but little to no knowhow about kernel-patching but I thought it might be a good place to start diving a bit deeper. Can someone explain to me how I can apply the patch from from https://patchwork.freedesktop.org/patch/229363/ right now on an up-to-date Ubuntu 18.04 system? How can I follow progress to see when the patch will be merged into mainline (will it be merged?)?
(In reply to Ingo Fischer from comment #101) > I came here with the same problem (J5005 ASRock board, occasional HDMI > connection problems with Ubuntu 18.04) but little to no knowhow about > kernel-patching but I thought it might be a good place to start diving a bit > deeper. > > Can someone explain to me how I can apply the patch from from > https://patchwork.freedesktop.org/patch/229363/ right now on an up-to-date > Ubuntu 18.04 system? > How can I follow progress to see when the patch will be merged into mainline > (will it be merged?)? Although it is not the correct place to ask for a guide, I do so (If it's just the first time you have to install some things): - sudo apt install git flex bison bc libssl-dev gawk libudev-dev ocl-icd-opencl-dev libpci-dev libelf-dev python2.7 libncurses-dev fakeroot kernel-wedge binfmt-support ksh lsscsi binfmt-support libpcre16-3 libpcre3-dev libpcre32-3 libpcrecpp0v5 libsepol1-dev libattr1-dev libblkid-dev libpcre16-3 libpcre3-dev libpcre32-3 libpcrecpp0v5 libselinux1-dev libsepol1-dev uuid-dev debugedit libarchive13 libdw1 liblua5.2-0 liblzo2-2 libnspr4 libnss3 librpm8 librpmbuild8 librpmio8 librpmsign8 rpm rpm-common rpm2cpio spl-dkms - sudo git clone --depth 1 --single-branch --branch v4.17.2 git://git.launchpad.net/~ubuntu-kernel-test/ubuntu/+source/linux/+git/mainline-crack v4.17.2 - cd v4.17.2 - sudo wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.2/0001-base-packaging.patch - sudo wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.2/0002-UBUNTU-SAUCE-add-vmlinux.strip-to-BOOT_TARGETS1-on-p.patch - sudo wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.2/0003-UBUNTU-SAUCE-tools-hv-lsvmbus-add-manual-page.patch - sudo wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.2/0004-UBUNTU-SAUCE-no-up-disable-pie-when-gcc-has-it-enabl.patch - sudo wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.2/0005-debian-changelog.patch - sudo wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17.2/0006-configs-based-on-Ubuntu-4.17.0-3.4.patch - Download the patch from https://patchwork.freedesktop.org/patch/229363/ and rename in i915.patch - sudo patch -p1 < 0001-base-packaging.patch - sudo patch -p1 < 0002-UBUNTU-SAUCE-add-vmlinux.strip-to-BOOT_TARGETS1-on-p.patch - sudo patch -p1 < 0003-UBUNTU-SAUCE-tools-hv-lsvmbus-add-manual-page.patch - sudo patch -p1 < 0004-UBUNTU-SAUCE-no-up-disable-pie-when-gcc-has-it-enabl.patch - sudo patch -p1 < 0005-debian-changelog.patch - sudo patch -p1 < 0006-configs-based-on-Ubuntu-4.17.0-3.4.patch - sudo patch -p1 < i915.patch - sudo chmod a+x debian/rules - sudo chmod a+x debian/scripts/* - sudo chmod a+x debian/scripts/misc/* - sudo fakeroot debian/rules clean set do_zfs = false in debian.master/rules.d/amd64.mk, - sudo fakeroot debian/rules binary-headers binary-generic binary-perarch
Version 3 of the patch has been sent to the intel-gfx mail list. Changes: Delay increased to 100ms based on review feedback. Confirm crtc_state->type is HDMI, so we don't delay for other output types. https://patchwork.freedesktop.org/patch/233505/
(In reply to Clinton Taylor from comment #103) > Version 3 of the patch has been sent to the intel-gfx mail list. > > Changes: > Delay increased to 100ms based on review feedback. > Confirm crtc_state->type is HDMI, so we don't delay for other output types. > > https://patchwork.freedesktop.org/patch/233505/ I have the same issue; I tried several kernels (4.15.0-23; 4.17.0-041700; 4.17.1-041701; 4.17.2-041702; 4.18.0-041800rc1; 4.18.0-041800rc2) - and even the last available [ 2.744531] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 2.745155] [drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin (v1.4) [ 2.745628] [drm] Applying Increase DDI Disabled quirk [ 2.748345] [drm] Initialized i915 1.6.0 20180514 for 0000:00:02.0 on minor 0 [ 2.749844] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) See here the NO SIGNAL : https://i.imgur.com/eawe700.jpg
Please test patch that is not yet merged but today got rb from Imre.
(In reply to Jani Saarinen from comment #105) > Please test patch that is not yet merged but today got rb from Imre. What patch are you talking about exactly?
(In reply to Clinton Taylor from comment #103) > Version 3 of the patch has been sent to the intel-gfx mail list. > > Changes: > Delay increased to 100ms based on review feedback. > Confirm crtc_state->type is HDMI, so we don't delay for other output types. > > https://patchwork.freedesktop.org/patch/233505/ Thanks for the updated patch. Though, this iteration brings the issue back at least during boot when i915.ko is loaded: My J5005-ITX prints it's boot messages after powering on the system. Then, when i915 first initialises the hardware and switches the FB to 1080p50 (forced via "video=HDMI-A-1:1920x1080@50" on the kernel command line), I get the "No signal" problem. Shortly after, when X and Kodi are started, the picture returns due to some "xset" commands that are run. From within Kodi, playing a 23.976p movie and stopping (thus switching to 1080p50 again), picture remains and there are no more issues. Maybe the connector check causes the initial issue here? For reference, the backported patch is at [1] and kernel debs at [2]. [1] https://github.com/herrnst/ubuntu-bionic-kernel/commits/4.15.0-24-26-glktesting4 [2] https://github.com/herrnst/ubuntu-bionic-kernel/tree/4.15.0-24.26-glktesting4-deb
> Thanks for the updated patch. Though, this iteration brings the issue back > at least during boot when i915.ko is loaded: My J5005-ITX prints it's boot > messages after powering on the system. Then, when i915 first initialises the > hardware and switches the FB to 1080p50 (forced via > "video=HDMI-A-1:1920x1080@50" on the kernel command line), I get the "No > signal" problem. Shortly after, when X and Kodi are started, the picture > returns due to some "xset" commands that are run. From within Kodi, playing > a 23.976p movie and stopping (thus switching to 1080p50 again), picture > remains and there are no more issues. Maybe the connector check causes the > initial issue here? Thanks for the test. Glad we found this early. Let me see what other connector type checks I need to add. My guess is INTEL_OUTPUT_UNUSED for the first boot issue.
> Maybe the connector check causes the > initial issue here? Daniel, Using the v3 patch could you apply the following diff? Thanks,-Clint diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index 89bb5ce..b2ff394 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -1818,15 +1818,16 @@ void intel_ddi_disable_transcoder_func(const struct inte i915_reg_t reg = TRANS_DDI_FUNC_CTL(cpu_transcoder); uint32_t val = I915_READ(reg); - val &= ~(TRANS_DDI_FUNC_ENABLE | TRANS_DDI_PORT_MASK | TRANS_DDI_DP_VC_P val |= TRANS_DDI_PORT_NONE; I915_WRITE(reg, val); + DRM_ERROR(" *** connector type = %d\n", crtc_state->output_types); if (dev_priv->quirks & QUIRK_INCREASE_DDI_DISABLED_TIME && - intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) { - msleep(DDI_DISABLED_QUIRK_TIME); + (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI) || + intel_crtc_has_type(crtc_state, INTEL_OUTPUT_UNUSED))) { DRM_DEBUG_KMS("Quirk Increase DDI disabled time\n"); + msleep(DDI_DISABLED_QUIRK_TIME); } } diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d index ff42268..d3ad9c1 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -14956,7 +14956,6 @@ static int intel_dmi_reverse_brightness(const struct dmi /* ASRock ITX*/ { 0x3185, 0x1849, 0x2212, quirk_increase_ddi_disabled_time }, { 0x3184, 0x1849, 0x2212, quirk_increase_ddi_disabled_time }, - }; static void intel_init_quirks(struct drm_device *dev)
(In reply to Clinton Taylor from comment #109) > > Maybe the connector check causes the > > initial issue here? > > Daniel, > Using the v3 patch could you apply the following diff? Did that (exact diff looks like [1] now, please ignore the debchangelog stuff). Packaged ([2]), installed, rebooted, issue still remains. The DRM_ERROR(connector_type) reveals why, though: # dmesg | grep disable_transcoder [ 2.998161] [drm:intel_ddi_disable_transcoder_func [i915]] *ERROR* *** connector type = 1024 [ 11.002233] [drm:intel_ddi_disable_transcoder_func [i915]] *ERROR* *** connector type = 64 [ 373.751818] [drm:intel_ddi_disable_transcoder_func [i915]] *ERROR* *** connector type = 64 [ 380.119446] [drm:intel_ddi_disable_transcoder_func [i915]] *ERROR* *** connector type = 64 [ 383.988156] [drm:intel_ddi_disable_transcoder_func [i915]] *ERROR* *** connector type = 64 [ 389.564144] [drm:intel_ddi_disable_transcoder_func [i915]] *ERROR* *** connector type = 64 [ 406.176236] [drm:intel_ddi_disable_transcoder_func [i915]] *ERROR* *** connector type = 64 [ 415.329143] [drm:intel_ddi_disable_transcoder_func [i915]] *ERROR* *** connector type = 64 So, right after boot, connector type is INTEL_OUTPUT_UNKNOWN, and in all following cases it's INTEL_OUTPUT_HDMI. I did not test this yet, but adding _UNKNOWN to the if() should finally do the trick (will eventually add that somewhen today and retest). [1] https://github.com/herrnst/ubuntu-bionic-kernel/commit/38ecb48f10b4dfedc1dd190d42749cb0d93b6886 [2] https://github.com/herrnst/ubuntu-bionic-kernel/tree/4.15.0-24.26-glktesting5-deb
(In reply to Daniel Scheller from comment #110) > (In reply to Clinton Taylor from comment #109) > > > Maybe the connector check causes the > > > initial issue here? > > > > Daniel, > > Using the v3 patch could you apply the following diff? > > [...] I did not test this yet, but adding > _UNKNOWN to the if() should finally do the trick (will eventually add that > somewhen today and retest). Clint, just tested exactly that (see [1]) - with that, no "No signal" on the AV and/or TV. Installable images at [2]. Thanks, Daniel [1] https://github.com/herrnst/ubuntu-bionic-kernel/commit/25276f577b3b1193a57a2a729d2bb8ad86b964c2 [2] https://github.com/herrnst/ubuntu-bionic-kernel/tree/4.15.0-24.26-glktesting6-deb
Current upstream code has changed INTEL_OUTPUT_UNKNOWN to INTEL_OUTPUT_DDI, and there has been a slight logic change around it. I will add INTEL_OUTPUT_DDI to the patch and submit a new version.
https://patchwork.freedesktop.org/patch/236192/ V4 of the patch has been submitted upstream. This patch will not apply cleanly to the 4.15 kernel. To apply to 4.15 change INTEL_OUTPUT_DDI to INTEL_OUTPUT_UNKNOWN
(In reply to Clinton Taylor from comment #113) > https://patchwork.freedesktop.org/patch/236192/ > > V4 of the patch has been submitted upstream. This patch will not apply > cleanly to the 4.15 kernel. To apply to 4.15 change INTEL_OUTPUT_DDI to > INTEL_OUTPUT_UNKNOWN Clint, first up, sorry for the hassle regarding OUTPUT_UNKNOWN and OUTPUT_DDI with more current kernels in mind. I applied your latest patch to 4.17.4 sources (slight conflict fixups required, see [1] for the result) and put the DRM_ERROR() back in which prints the current connector type ([2]). On 4.17, the check for _UNKNOWN or _DDI even doesn't seem to be needed anymore, the debug print will always report connector type 64, even directly after boot/hwinit/i915 load. Long story short, the patch still works well. Test debs based on 4.17.4 at [3]. Will keep the latest 4.15 patches/branches around though, as they eventually are candidates for a possible "Ubuntu stable kernel" inclusion when your fix is merged into some linux/drm kernel tree. [1] https://github.com/herrnst/ubuntu-bionic-kernel/commit/c514d34616e9c54fa07efb316019d0c5fc410cf2 [2] https://github.com/herrnst/ubuntu-bionic-kernel/commit/2c00ac7bb2208f29573d6e7455126f744536d2a6 [3] https://github.com/herrnst/ubuntu-bionic-kernel/tree/4.17.4-ubuntu-glktesting7-deb
(In reply to Clinton Taylor from comment #113) > https://patchwork.freedesktop.org/patch/236192/ > > V4 of the patch has been submitted upstream. This patch will not apply > cleanly to the 4.15 kernel. To apply to 4.15 change INTEL_OUTPUT_DDI to > INTEL_OUTPUT_UNKNOWN v4 on kernel 4.18-rc3 full log in attachments [42751.866605] [drm:i915_hotplug_work_func [i915]] Connector HDMI-A-1 (pin 5) received hotplug event. [42751.866716] [drm:intel_hdmi_detect [i915]] [CONNECTOR:101:HDMI-A-1] [42751.867000] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0050 w(1) [42751.867084] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK on first message, retry [42751.867348] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0050 w(1) [42751.867402] [drm:drm_do_probe_ddc_edid [drm]] drm: skipping non-existent adapter i915 gmbus dpb [42751.867491] [drm:intel_hdmi_set_edid [i915]] HDMI GMBUS EDID read failed, retry using GPIO bit-banging [42751.867575] [drm:intel_gmbus_force_bit [i915]] enabling bit-banging on i915 gmbus dpb. force bit now 1 [42751.868256] [drm:drm_do_probe_ddc_edid [drm]] drm: skipping non-existent adapter i915 gmbus dpb [42751.868342] [drm:intel_gmbus_force_bit [i915]] disabling bit-banging on i915 gmbus dpb. force bit now 0 [42751.868609] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0040 w(1) [42751.868693] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK on first message, retry [42751.868947] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0040 w(1) [42751.868978] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] DP dual mode HDMI ID: (err -6) [42751.869069] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:101:HDMI-A-1] status updated from connected to disconnected [42751.872045] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:101:HDMI-A-1] [42751.872092] [drm:intel_hdmi_detect [i915]] [CONNECTOR:101:HDMI-A-1] [42751.872280] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0050 w(1) [42751.872306] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK on first message, retry [42751.872490] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0050 w(1) [42751.872511] [drm:drm_do_probe_ddc_edid [drm]] drm: skipping non-existent adapter i915 gmbus dpb [42751.872537] [drm:intel_hdmi_set_edid [i915]] HDMI GMBUS EDID read failed, retry using GPIO bit-banging [42751.872562] [drm:intel_gmbus_force_bit [i915]] enabling bit-banging on i915 gmbus dpb. force bit now 1 [42751.873124] [drm:drm_do_probe_ddc_edid [drm]] drm: skipping non-existent adapter i915 gmbus dpb [42751.873149] [drm:intel_gmbus_force_bit [i915]] disabling bit-banging on i915 gmbus dpb. force bit now 0 [42751.873333] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0040 w(1) [42751.873357] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK on first message, retry [42751.873539] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0040 w(1) [42751.873550] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] DP dual mode HDMI ID: (err -6) [42751.873557] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:101:HDMI-A-1] disconnected [42751.873658] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:107:HDMI-A-2] [42751.873683] [drm:intel_hdmi_detect [i915]] [CONNECTOR:107:HDMI-A-2] [42751.873868] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpc] NAK for addr: 0050 w(1) [42751.873891] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpc] NAK on first message, retry [42751.874073] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpc] NAK for addr: 0050 w(1) [42751.874086] [drm:drm_do_probe_ddc_edid [drm]] drm: skipping non-existent adapter i915 gmbus dpc [42751.874109] [drm:intel_hdmi_set_edid [i915]] HDMI GMBUS EDID read failed, retry using GPIO bit-banging [42751.874134] [drm:intel_gmbus_force_bit [i915]] enabling bit-banging on i915 gmbus dpc. force bit now 1 [42751.874693] [drm:drm_do_probe_ddc_edid [drm]] drm: skipping non-existent adapter i915 gmbus dpc [42751.874717] [drm:intel_gmbus_force_bit [i915]] disabling bit-banging on i915 gmbus dpc. force bit now 0 [42751.874901] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpc] NAK for addr: 0040 w(1) [42751.874924] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpc] NAK on first message, retry [42751.875106] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpc] NAK for addr: 0040 w(1) [42751.875113] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] DP dual mode HDMI ID: (err -6) [42751.875120] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:107:HDMI-A-2] disconnected
Created attachment 140467 [details] kern.log_Patch_v4_Kernel_v4.18-rc3
Created attachment 140468 [details] syslog_Patch_v4_Kernel_v4.18-rc3
Hey, do you guys have any news?
The quirk patch got merged onto drm-tip. So I believe that the issue is resolved. 90c3e2198777 drm/i915/glk: Add Quirk for GLK NUC HDMI port issues.
(In reply to fatez from comment #118) > Hey, do you guys have any news? (In reply to Radhakrishna Sripada from comment #119) > The quirk patch got merged onto drm-tip. So I believe that the issue is > resolved. > > 90c3e2198777 drm/i915/glk: Add Quirk for GLK NUC HDMI port issues. Yep, sorry for not updating the bug, it can be closed now that the patch is merged. Daniel, the patch will be backported to stable kernel releases (4.14 and 4.17), but users of 4.15 need to do the backporting/maintenance of the fix on their own.
But only I still have the problem with no signal every time I change from hdmi1 to hdmi2 and back in hdmi1?
(In reply to fatez from comment #121) > But only I still have the problem with no signal every time I change from > hdmi1 to hdmi2 and back in hdmi1? That sounds like a different issue from the one originally reported in this bug. I see you already opened a new bug [1], so let's handle it there. [1] https://bugs.freedesktop.org/show_bug.cgi?id=106659
Closing this as the related but different issue of HDMI1 to HDMI2 switching is tracked under https://bugs.freedesktop.org/show_bug.cgi?id=106659. And the merged patch has a Tested-By from Daniel Scheller.
Good morning, I would like to know, how much time would you pass before the drm-tip patches are even put to the "normal kernel? Thank you
(In reply to fatez from comment #124) > Good morning, I would like to know, how much time would you pass before the > drm-tip patches are even put to the "normal kernel? Thank you It's now in the latest v4.14 and v4.17 stable releases at least.
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.