Bug 106182 - [Intel NUC] HDMI1 sometimes stops working after resuming from s3 (a single monitor setup)
Summary: [Intel NUC] HDMI1 sometimes stops working after resuming from s3 (a single mo...
Status: CLOSED WONTFIX
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: highest blocker
Assignee: Imre Deak
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2018-04-23 06:25 UTC by Wen-chien Jesse Sung
Modified: 2018-05-20 10:40 UTC (History)
6 users (show)

See Also:
i915 platform: GLK
i915 features: power/runtime PM


Attachments
kernel log of commit 1c7ccd (6.00 MB, text/x-log)
2018-04-23 08:44 UTC, Robert Liu
no flags Details
dmesg output of booting (244.25 KB, text/x-log)
2018-05-09 01:42 UTC, Robert Liu
no flags Details
This is the dmesg output of the failure run (38.43 KB, text/x-log)
2018-05-09 01:43 UTC, Robert Liu
no flags Details
dmesg for outb and inb commands (149.94 KB, text/x-log)
2018-05-10 08:04 UTC, Robert Liu
no flags Details
dmesg for outb and inb commands #2 (169.77 KB, text/x-log)
2018-05-10 08:47 UTC, Robert Liu
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Wen-chien Jesse Sung 2018-04-23 06:25:01 UTC
Sometimes HDMI1 would stop working after suspend/resume.
* By switching the cable to HDMI2 we can see that HDMI2 still works.
* A reboot is required to make HDMI1 work again.
* This issue cannot be reproduce if the monitor is connected to HDMI2 in the first place.

This issue can be reproduced with 4.17-rc1, and also drm-tip/2018-04-19 (1c7ccdf37b04bedb10e2191d34dfbba62beb79ea).

BIOS version: JYGLKCPX.86A.0020.2017.1205.1459
DMI board name: NUC7CJYH
DMI product_name: NUC7JYB

cpuinfo:
vendor_id	: GenuineIntel
cpu family	: 6
model		: 122
model name	: Intel(R) Celeron(R) J4005 CPU @ 2.00GHz
stepping	: 1
microcode	: 0x16

VGA controller:
00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:3185] (rev 03) (prog-if 00 [VGA controller])
	DeviceName:  Onboard IGD
	Subsystem: Intel Corporation Device [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 343
	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] #1b
	Capabilities: [200 v1] Address Translation Service (ATS)
		ATSCap:	Invalidate Queue Depth: 00
		ATSCtl:	Enable-, Smallest Translation Unit: 00
	Capabilities: [300 v1] #13
	Kernel driver in use: i915
	Kernel modules: i915
Comment 1 Jani Saarinen 2018-04-23 06:43:14 UTC
Hi,
What are options set in BIOS for operating system. There should be two options, please use default (Windows). 

+ Imre.
Comment 2 Robert Liu 2018-04-23 06:59:16 UTC
The OS setting in BIOS is set to Windows originally. We do not change it.
Comment 3 qwang13 2018-04-23 07:12:11 UTC
The platform is June-Canyon (GLK-NUC).
This issue could be always reproduced in Ubuntu 18.04(no success). Kernel version is 4.15.

The appearance is like GPU hang. S3 could be invoked, but hang there. And then black screen, ssh failed and no any response.

http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/2018-04-14/
doesn't work.
Comment 4 Jani Saarinen 2018-04-23 07:40:16 UTC
Have you tried latest drm-tip? https://cgit.freedesktop.org/drm-tip.
Also attach the “dmesg” output taken with “drm.debug=0xe” and “log-buf-len=2M”
Comment 5 Jani Saarinen 2018-04-23 07:41:32 UTC
Also report DMC you use.

Latest for GLK is https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915 => glk_dmc_ver1_04.bin
Comment 6 Jani Saarinen 2018-04-23 07:45:42 UTC
Please note that same model in CI too: https://intel-gfx-ci.01.org/hardware.html =>
shard-glk	Intel NUC7CJYH	Gemini Lake J4005		HDMI2.0 (HDMI2.0)
Comment 7 Robert Liu 2018-04-23 08:34:46 UTC
My result is not the same with what the comment 3 described.

When the HDMI output is blank, I can still ssh the target machine.

I have more description for the symptoms:
  * Sometimes switching HDMI cable to HDMI2 port and HDMI output will return normal.
  * Sometimes I need to reboot system to make HDMI1 port to be usable again
  * Sometime switching to HDMI2 does not work, and have to poweroff system to make the HDMI ports return normal.
Comment 8 Robert Liu 2018-04-23 08:44:23 UTC
Created attachment 138993 [details]
kernel log of commit 1c7ccd

drm-tip/2018-04-19 (1c7ccdf37b04bedb10e2191d34dfbba62beb79ea)
Comment 9 Robert Liu 2018-04-23 09:07:10 UTC
DMC info:
$ md5sum /lib/firmware/i915/glk_dmc_ver1_04.bin
72d01d9f8887793ac0787f19206a74fc  /lib/firmware/i915/glk_dmc_ver1_04.bin
Comment 10 Jani Saarinen 2018-04-25 14:44:48 UTC
Imre, any idea from you?
Comment 11 Imre Deak 2018-04-26 16:34:42 UTC
Did you try if turning off/on the monitor helps?

Could you try the latest drm-tip, I'm interested if the following makes a difference:

commit 6de3b1f26d1e8adb53d97835400c541ce50155e5
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date:   Mon Apr 23 14:37:53 2018 +0300

    drm/i915: Use ktime on wait_for
Comment 12 Robert Liu 2018-04-27 01:10:21 UTC
Hi @Imre,

Yesterday, I tested this version: http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-tip/2018-04-26/ (92a39635c2eca4dfe1c8c1673e0c606a720746e5) which includes the commit you mentioned. It also has the same issue.

I'll verify if the on/off the monitor does the magic.
Comment 13 Robert Liu 2018-04-27 03:40:11 UTC
On/off the monitor does not recover the display.

when on/off the monitor, dmesg shows:
[  302.208516] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00000010, dig 0x1000181a, pins 0x00000020
[  302.208621] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 5 - cnt: 0
[  302.208923] [drm:i915_hotplug_work_func [i915]] running encoder hotplug functions
[  302.209029] [drm:i915_hotplug_work_func [i915]] Connector HDMI-A-1 (pin 5) received hotplug event.
[  302.209143] [drm:intel_hdmi_detect [i915]] [CONNECTOR:101:HDMI-A-1]
[  302.236583] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0040 w(1)
[  302.236677] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK on first message, retry
[  302.236939] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0040 w(1)
[  302.236971] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] DP dual mode HDMI ID:  (err -6)
[  302.237024] [drm:drm_detect_monitor_audio [drm]] Monitor has basic audio support
[  302.610630] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00000010, dig 0x1000181a, pins 0x00000020
[  302.610736] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 5 - cnt: 1
[  302.611024] [drm:i915_hotplug_work_func [i915]] running encoder hotplug functions
[  302.611130] [drm:i915_hotplug_work_func [i915]] Connector HDMI-A-1 (pin 5) received hotplug event.
[  302.611246] [drm:intel_hdmi_detect [i915]] [CONNECTOR:101:HDMI-A-1]
[  302.612275] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0050 w(1)
[  302.612369] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK on first message, retry
[  302.627367] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0050 w(1)
[  302.627452] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK on first message, retry
[  302.642317] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0040 w(1)
[  302.642413] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK on first message, retry
[  302.642676] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0040 w(1)
[  302.642708] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] DP dual mode HDMI ID:  (err -6)
[  302.642760] [drm:drm_detect_monitor_audio [drm]] Monitor has basic audio support
[  310.899258] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00000010, dig 0x1000181a, pins 0x00000020
[  310.899362] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 5 - cnt: 0
[  310.899633] [drm:i915_hotplug_work_func [i915]] running encoder hotplug functions
[  310.899740] [drm:i915_hotplug_work_func [i915]] Connector HDMI-A-1 (pin 5) received hotplug event.
[  310.899852] [drm:intel_hdmi_detect [i915]] [CONNECTOR:101:HDMI-A-1]
[  310.929297] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0040 w(1)
[  310.929392] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK on first message, retry
[  310.929654] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0040 w(1)
[  310.929686] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] DP dual mode HDMI ID:  (err -6)
[  310.929738] [drm:drm_detect_monitor_audio [drm]] Monitor has basic audio support
[  311.301426] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00000010, dig 0x1000181a, pins 0x00000020
[  311.301531] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 5 - cnt: 1
[  311.301819] [drm:i915_hotplug_work_func [i915]] running encoder hotplug functions
[  311.301925] [drm:i915_hotplug_work_func [i915]] Connector HDMI-A-1 (pin 5) received hotplug event.
[  311.302071] [drm:intel_hdmi_detect [i915]] [CONNECTOR:101:HDMI-A-1]
[  311.332464] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0040 w(1)
[  311.332561] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK on first message, retry
[  311.332823] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0040 w(1)
[  311.332854] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] DP dual mode HDMI ID:  (err -6)
[  311.332907] [drm:drm_detect_monitor_audio [drm]] Monitor has basic audio support
Comment 14 Imre Deak 2018-05-02 12:40:42 UTC
I could reproduce this on my GLK. The HDMI output seems to be correctly programmed and enabled from the CPU's side, but the display doesn't receive any valid HDMI signal. I tried this with multiple displays. After this stuck state disabling/re-enabling the output doesn't help, neither help further suspend/resume cycles or even warm reboot. After warm reboot the BIOS GOP normally shows a greeting screen, but after warm reboot from the stuck state this greeting screen isn't shown either. Only a power off/on recovers the output. This matches with Robert Liu's report, at least when he has to power off/on the machine to fix things.

Robert could you confirm that from the cases where warm reboot doesn't help, the BIOS GOP screen (showing "Intel (c) NUC" at the middle of the screen) doesn't show up either during booting?

One thing I noticed is that you're using an older BIOS, but upgrading to the latest one didn't help for me at least (JYGLKCPX.86A.0037.2018.0423.1539).
Comment 15 Robert Liu 2018-05-03 01:48:25 UTC
Imre, that situation is exactly the same with mine. When the issue happens, either in BIOS stage or in OS stage, both the HDMI outputs are blank.

I have another SKU with the latest BIOS, and it also has the same symptom.
Comment 16 Robert Liu 2018-05-04 09:50:43 UTC
I set /sys/power/pm_test to devices, platform, processors, core and none to verify the stage of the failure.
With the first four modes (devices, platform, processors and core), I ran rtcwake 100 times and cannot reproduce this issue.
When pm_test is 'none', the issue happened.
I am wondering if it could be a BIOS-related issue.
Comment 17 shashank.sharma@intel.com 2018-05-08 07:42:22 UTC
Hi, 
I have analyzed the logs for HDMI modeset, and it doesn't look like there is anything wrong there, detection looks proper. Can I please see the logs of failure case (only) ?

- Shashank
Comment 18 Robert Liu 2018-05-09 01:42:44 UTC
Created attachment 139434 [details]
dmesg output of booting

Kernel: drm-tip/2018-05-08 (06e15c0f055b8b8e326bb65fa83f69b1b7391e51)
OS: Ubuntu 18.04
Parameters: drm.debug=0x0e

This attachment is the dmesg output of booting
Comment 19 Robert Liu 2018-05-09 01:43:35 UTC
Created attachment 139435 [details]
This is the dmesg output of the failure run

This is the dmesg output of the failure run
Comment 20 Imre Deak 2018-05-09 21:42:16 UTC
Looks like the HDMI retimer chip is in a weird state when the problem happens. To test that theory could you see if the following brings back the output on the HDMI-A-1 connector from the bad state? It resets the chip and forces a detect cycle. It needs the ioport Ubuntu package and you need to run it as root:

v=$(outb 0x66 0x80; outb 0x62 0x1a; inb 0x62)
outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v | 8 ))
sleep 0.1
outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v & ~8 ))

echo detect > /sys/class/drm/card0-HDMI-A-1/status

Please provide a dmesg log after running the above in any case.
Comment 21 Robert Liu 2018-05-10 01:16:43 UTC
The commands did not help. The screen is still blank after I executed the commands.

[  734.977041] [drm:drm_mode_addfb2 [drm]] [FB:109]
[  736.855922] [drm:status_store [drm]] [CONNECTOR:101:HDMI-A-1] force updated from 0 to 0 or reprobing
[  736.855945] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:101:HDMI-A-1]
[  736.856033] [drm:intel_hdmi_detect [i915]] [CONNECTOR:101:HDMI-A-1]
[  736.884363] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0040 w(1)
[  736.884477] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK on first message, retry
[  736.884729] [drm:do_gmbus_xfer [i915]] GMBUS [i915 gmbus dpb] NAK for addr: 0040 w(1)
[  736.884758] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] DP dual mode HDMI ID:  (err -6)
[  736.884806] [drm:drm_detect_monitor_audio [drm]] Monitor has basic audio support
[  736.884847] [drm:drm_add_display_info [drm]] non_desktop set to 0
[  736.884881] [drm:drm_add_display_info [drm]] HDMI: DVI dual 0, max TMDS clock 0 kHz
[  736.884930] [drm:drm_add_edid_modes.part.32 [drm]] ELD monitor VX239
[  736.884964] [drm:drm_add_edid_modes.part.32 [drm]] HDMI: latency present 0 0, video latency 0 0, audio latency 0 0
[  736.884996] [drm:drm_add_edid_modes.part.32 [drm]] ELD size 28, SAD count 1
[  736.885027] [drm:drm_add_display_info [drm]] non_desktop set to 0
[  736.885057] [drm:drm_add_display_info [drm]] HDMI: DVI dual 0, max TMDS clock 0 kHz
[  736.886031] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:101:HDMI-A-1] probed modes :
[  736.886071] [drm:drm_mode_debug_printmodeline [drm]] Modeline 112:"1920x1080" 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5
[  736.886107] [drm:drm_mode_debug_printmodeline [drm]] Modeline 147:"1920x1080" 60 148352 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5
[  736.886143] [drm:drm_mode_debug_printmodeline [drm]] Modeline 114:"1920x1080i" 60 74250 1920 2008 2052 2200 1080 1084 1094 1125 0x40 0x15
[  736.886178] [drm:drm_mode_debug_printmodeline [drm]] Modeline 149:"1920x1080i" 60 74176 1920 2008 2052 2200 1080 1084 1094 1125 0x40 0x15
[  736.886212] [drm:drm_mode_debug_printmodeline [drm]] Modeline 144:"1920x1080" 50 148500 1920 2448 2492 2640 1080 1084 1089 1125 0x40 0x5
[  736.886247] [drm:drm_mode_debug_printmodeline [drm]] Modeline 141:"1920x1080i" 50 74250 1920 2448 2492 2640 1080 1084 1094 1125 0x40 0x15
[  736.886281] [drm:drm_mode_debug_printmodeline [drm]] Modeline 154:"1600x1200" 60 162000 1600 1664 1856 2160 1200 1201 1204 1250 0x40 0x5
[  736.886315] [drm:drm_mode_debug_printmodeline [drm]] Modeline 120:"1680x1050" 60 119000 1680 1728 1760 1840 1050 1053 1059 1080 0x40 0x9
[  736.886349] [drm:drm_mode_debug_printmodeline [drm]] Modeline 119:"1280x1024" 75 135000 1280 1296 1440 1688 1024 1025 1028 1066 0x40 0x5
[  736.886383] [drm:drm_mode_debug_printmodeline [drm]] Modeline 118:"1280x1024" 60 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x40 0x5
[  736.886418] [drm:drm_mode_debug_printmodeline [drm]] Modeline 122:"1440x900" 60 88750 1440 1488 1520 1600 900 903 909 926 0x40 0x9
[  736.886452] [drm:drm_mode_debug_printmodeline [drm]] Modeline 121:"1280x960" 60 108000 1280 1376 1488 1800 960 961 964 1000 0x40 0x5
[  736.886486] [drm:drm_mode_debug_printmodeline [drm]] Modeline 117:"1152x864" 75 108000 1152 1216 1344 1600 864 865 868 900 0x40 0x5
[  736.886520] [drm:drm_mode_debug_printmodeline [drm]] Modeline 115:"1280x720" 60 74250 1280 1390 1430 1650 720 725 730 750 0x40 0x5
[  736.886554] [drm:drm_mode_debug_printmodeline [drm]] Modeline 150:"1280x720" 60 74176 1280 1390 1430 1650 720 725 730 750 0x40 0x5
[  736.886589] [drm:drm_mode_debug_printmodeline [drm]] Modeline 146:"1280x720" 50 74250 1280 1720 1760 1980 720 725 730 750 0x40 0x5
[  736.886623] [drm:drm_mode_debug_printmodeline [drm]] Modeline 131:"1024x768" 75 78750 1024 1040 1136 1312 768 769 772 800 0x40 0x5
[  736.886657] [drm:drm_mode_debug_printmodeline [drm]] Modeline 132:"1024x768" 70 75000 1024 1048 1184 1328 768 771 777 806 0x40 0xa
[  736.886691] [drm:drm_mode_debug_printmodeline [drm]] Modeline 133:"1024x768" 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
[  736.886725] [drm:drm_mode_debug_printmodeline [drm]] Modeline 134:"800x600" 75 49500 800 816 896 1056 600 601 604 625 0x40 0x5
[  736.886760] [drm:drm_mode_debug_printmodeline [drm]] Modeline 135:"800x600" 72 50000 800 856 976 1040 600 637 643 666 0x40 0x5
[  736.886794] [drm:drm_mode_debug_printmodeline [drm]] Modeline 124:"800x600" 60 40000 800 840 968 1056 600 601 605 628 0x40 0x5
[  736.886828] [drm:drm_mode_debug_printmodeline [drm]] Modeline 125:"800x600" 56 36000 800 824 896 1024 600 601 603 625 0x40 0x5
[  736.886862] [drm:drm_mode_debug_printmodeline [drm]] Modeline 142:"720x576" 50 27000 720 732 796 864 576 581 586 625 0x40 0xa
[  736.886896] [drm:drm_mode_debug_printmodeline [drm]] Modeline 151:"720x480" 60 27027 720 736 798 858 480 489 495 525 0x40 0xa
[  736.886930] [drm:drm_mode_debug_printmodeline [drm]] Modeline 116:"720x480" 60 27000 720 736 798 858 480 489 495 525 0x40 0xa
[  736.886965] [drm:drm_mode_debug_printmodeline [drm]] Modeline 126:"640x480" 75 31500 640 656 720 840 480 481 484 500 0x40 0xa
[  736.886999] [drm:drm_mode_debug_printmodeline [drm]] Modeline 127:"640x480" 73 31500 640 664 704 832 480 489 492 520 0x40 0xa
[  736.887033] [drm:drm_mode_debug_printmodeline [drm]] Modeline 152:"640x480" 60 25200 640 656 752 800 480 490 492 525 0x40 0xa
[  736.887067] [drm:drm_mode_debug_printmodeline [drm]] Modeline 128:"640x480" 60 25175 640 656 752 800 480 490 492 525 0x40 0xa
[  736.887101] [drm:drm_mode_debug_printmodeline [drm]] Modeline 129:"720x400" 70 28320 720 738 846 900 400 412 414 449 0x40 0x6
Comment 22 Imre Deak 2018-05-10 07:56:05 UTC
(In reply to Robert Liu from comment #21)
> The commands did not help. The screen is still blank after I executed the
> commands.

Could you check the output of the following when the display is properly enabled, let's say right after powering on/booting:

v=$(outb 0x66 0x80; outb 0x62 0x1a; inb 0x62)
echo $v
outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v | 8 ))
outb 0x66 0x80; outb 0x62 0x1a; inb 0x62

Is the display still enabled? Could you attach the full dmesg log after this?
Comment 23 Robert Liu 2018-05-10 08:03:54 UTC
(In reply to Imre Deak from comment #22)
> v=$(outb 0x66 0x80; outb 0x62 0x1a; inb 0x62)
> echo $v
> outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v | 8 ))
> outb 0x66 0x80; outb 0x62 0x1a; inb 0x62
root@u-NUC7PJYH:~# v=$(outb 0x66 0x80; outb 0x62 0x1a; inb 0x62)
root@u-NUC7PJYH:~# echo $v
0
root@u-NUC7PJYH:~# outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v | 8 ))
root@u-NUC7PJYH:~# outb 0x66 0x80; outb 0x62 0x1a; inb 0x62
8

> 
> Is the display still enabled? Could you attach the full dmesg log after this?

Yes, the display is still enabled. Check the next attachment.
Comment 24 Robert Liu 2018-05-10 08:04:40 UTC
Created attachment 139457 [details]
dmesg for outb and inb commands
Comment 25 Imre Deak 2018-05-10 08:30:08 UTC
(In reply to Robert Liu from comment #23)
> Yes, the display is still enabled. Check the next attachment.

Hm, then the chip isn't reset for some reason.

(In reply to Robert Liu from comment #24)
> Created attachment 139457 [details]
> dmesg for outb and inb commands

Ok, how about the following sequence (setting also bit 0 in the EC register):

v=$(outb 0x66 0x80; outb 0x62 0x1a; inb 0x62)
echo $v
outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v | 9 ))
outb 0x66 0x80; outb 0x62 0x1a; inb 0x62

Is the display still enabled?
Comment 26 Robert Liu 2018-05-10 08:47:07 UTC
Created attachment 139458 [details]
dmesg for outb and inb commands #2

Well, the screen now is off. However, I cannot recover it by poweroff. A removal of the adapter is required to make the screen back.

It looks to me the behavior is slightly different from the issue has.
Comment 27 Imre Deak 2018-05-10 08:59:50 UTC
(In reply to Robert Liu from comment #26)
> Created attachment 139458 [details]
> dmesg for outb and inb commands #2
> 
> Well, the screen now is off. However, I cannot recover it by poweroff.
> A removal of the adapter is required to make the screen back.
> 
> It looks to me the behavior is slightly different from the issue has.

Yes, the sequence you tried just keeps the chip in reset you also need to remove the reset condition to re-enable the display. If the following blanks and unblanks the display for you when it's enabled properly, could you try it again from the stuck state?

v=$(outb 0x66 0x80; outb 0x62 0x1a; inb 0x62)
echo $v
outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v | 9 ))
outb 0x66 0x80; outb 0x62 0x1a; inb 0x62

sleep 0.1

outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v & ~8 ))
outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $v
Comment 28 Robert Liu 2018-05-10 09:09:25 UTC
There commands didn't bring the screen back.

root@u-NUC7PJYH:~# v=$(outb 0x66 0x80; outb 0x62 0x1a; inb 0x62)
root@u-NUC7PJYH:~# echo $v
0
root@u-NUC7PJYH:~# outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v | 9 ))
root@u-NUC7PJYH:~# outb 0x66 0x80; outb 0x62 0x1a; inb 0x62
11
(screen becomes blank)
root@u-NUC7PJYH:~# v=$(outb 0x66 0x80; outb 0x62 0x1a; inb 0x62)
root@u-NUC7PJYH:~# echo $v
11
root@u-NUC7PJYH:~# outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v | 9 ))
root@u-NUC7PJYH:~# outb 0x66 0x80; outb 0x62 0x1a; inb 0x62
11
root@u-NUC7PJYH:~# 
root@u-NUC7PJYH:~# sleep 0.1
root@u-NUC7PJYH:~# 
root@u-NUC7PJYH:~# outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v & ~8 ))
root@u-NUC7PJYH:~# outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $v
(screen is blank)
root@u-NUC7PJYH:~# reboot

root@u-NUC7PJYH:~# v=$(outb 0x66 0x80; outb 0x62 0x1a; inb 0x62)
root@u-NUC7PJYH:~# echo $v
11
root@u-NUC7PJYH:~# outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v | 9 ))
root@u-NUC7PJYH:~# outb 0x66 0x80; outb 0x62 0x1a; inb 0x62
11
root@u-NUC7PJYH:~# 
root@u-NUC7PJYH:~# sleep 0.1
root@u-NUC7PJYH:~# 
root@u-NUC7PJYH:~# outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v & ~8 ))
root@u-NUC7PJYH:~# outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $v
(screen is still blank)
Comment 29 Imre Deak 2018-05-10 09:10:08 UTC
(In reply to Imre Deak from comment #27)
> (In reply to Robert Liu from comment #26)
> > Created attachment 139458 [details]
> > dmesg for outb and inb commands #2
> > 
> > Well, the screen now is off. However, I cannot recover it by poweroff.
> > A removal of the adapter is required to make the screen back.
> > 
> > It looks to me the behavior is slightly different from the issue has.
> 
> Yes, the sequence you tried just keeps the chip in reset you also need to
> remove the reset condition to re-enable the display. If the following blanks
> and unblanks the display for you when it's enabled properly, could you try
> it again from the stuck state?
>
> v=$(outb 0x66 0x80; outb 0x62 0x1a; inb 0x62)
> echo $v
> outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v | 9 ))
> outb 0x66 0x80; outb 0x62 0x1a; inb 0x62
> 
> sleep 0.1
>
> outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v & ))


> outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v | 1 ))


> outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $v

Err, sorry made a mistake the sequence correctly:

v=$(outb 0x66 0x80; outb 0x62 0x1a; inb 0x62)
echo $v
outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v | 9 ))
outb 0x66 0x80; outb 0x62 0x1a; inb 0x62
 
sleep 0.1

outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v | 1 ))
outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $v
Comment 30 Imre Deak 2018-05-10 09:15:15 UTC
(In reply to Imre Deak from comment #29)
> (In reply to Imre Deak from comment #27)
> > (In reply to Robert Liu from comment #26)
> > > Created attachment 139458 [details]
> > > dmesg for outb and inb commands #2
> > > 
> > > Well, the screen now is off. However, I cannot recover it by poweroff.
> > > A removal of the adapter is required to make the screen back.
> > > 
> > > It looks to me the behavior is slightly different from the issue has.
> > 
> > Yes, the sequence you tried just keeps the chip in reset you also need to
> > remove the reset condition to re-enable the display. If the following blanks
> > and unblanks the display for you when it's enabled properly, could you try
> > it again from the stuck state?
> >
> > v=$(outb 0x66 0x80; outb 0x62 0x1a; inb 0x62)
> > echo $v
> > outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v | 9 ))
> > outb 0x66 0x80; outb 0x62 0x1a; inb 0x62
> > 
> > sleep 0.1
> >
> > outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v & ))
> 
> 
> > outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v | 1 ))
> 
> 
> > outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $v
> 
> Err, sorry made a mistake the sequence correctly:
> 
> v=$(outb 0x66 0x80; outb 0x62 0x1a; inb 0x62)
> echo $v
> outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v | 9 ))
> outb 0x66 0x80; outb 0x62 0x1a; inb 0x62
>  
> sleep 0.1
> 
> outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v | 1 ))
> outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $v

But please run the above after powering off/on the machine, reboot is not enough.
Comment 31 Robert Liu 2018-05-10 09:42:05 UTC
After power off/on and run the commands, the screen is still blank.

root@u-NUC7PJYH:~# v=$(outb 0x66 0x80; outb 0x62 0x1a; inb 0x62)
root@u-NUC7PJYH:~# echo $v
11
root@u-NUC7PJYH:~# outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v | 9 ))
root@u-NUC7PJYH:~# outb 0x66 0x80; outb 0x62 0x1a; inb 0x62
11
root@u-NUC7PJYH:~#  
root@u-NUC7PJYH:~# sleep 0.1
root@u-NUC7PJYH:~# 
root@u-NUC7PJYH:~# outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v | 1 ))
root@u-NUC7PJYH:~# outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $v
Comment 32 Robert Liu 2018-05-10 11:00:09 UTC
Re-run the stress test and make the issue happens.
Then use the commands in the comment #29.
The commands bring the screen back.

root@u-NUC7PJYH:~# v=$(outb 0x66 0x80; outb 0x62 0x1a; inb 0x62)
root@u-NUC7PJYH:~# echo $v
3
root@u-NUC7PJYH:~# outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v | 9 ))
root@u-NUC7PJYH:~# outb 0x66 0x80; outb 0x62 0x1a; inb 0x62
11
root@u-NUC7PJYH:~#  
root@u-NUC7PJYH:~# sleep 0.1
root@u-NUC7PJYH:~# 
root@u-NUC7PJYH:~# outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v | 1 ))
root@u-NUC7PJYH:~# outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $v
(screen is on)
Comment 33 Imre Deak 2018-05-10 11:45:19 UTC
(In reply to Robert Liu from comment #32)
> Re-run the stress test and make the issue happens.
> Then use the commands in the comment #29.
> The commands bring the screen back.

Ok, thanks for trying. So it looks like we're seeing the same issue and we have atm one way to recover from the stuck state. This tells me that the source DDI port is outputting a proper video signal, but the retimer chip doesn't forward it to the connector in the stuck state.

For a proper solution (also one that works for the second HDMI port) I'd still like to find the root cause for how the chip gets to the stuck state in the first place. I'll follow up if I find out anything.

> 
> root@u-NUC7PJYH:~# v=$(outb 0x66 0x80; outb 0x62 0x1a; inb 0x62)
> root@u-NUC7PJYH:~# echo $v
> 3
> root@u-NUC7PJYH:~# outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v | 9 ))
> root@u-NUC7PJYH:~# outb 0x66 0x80; outb 0x62 0x1a; inb 0x62
> 11
> root@u-NUC7PJYH:~#  
> root@u-NUC7PJYH:~# sleep 0.1
> root@u-NUC7PJYH:~# 
> root@u-NUC7PJYH:~# outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $(( v | 1 ))
> root@u-NUC7PJYH:~# outb 0x66 0x81; outb 0x62 0x1a; outb 0x62 $v
> (screen is on)
Comment 34 Imre Deak 2018-05-16 08:50:19 UTC
Could you all please provide the 'Project Code' on the back of your NUC. Thanks.
Comment 35 Robert Liu 2018-05-16 09:54:24 UTC
(In reply to Imre Deak from comment #34)
> Could you all please provide the 'Project Code' on the back of your NUC.
We have two models: PPNUC7PJYH and PPNUC7CJYH here.
> Thanks.
Comment 36 Imre Deak 2018-05-18 09:02:58 UTC
(In reply to Robert Liu from comment #35)
> (In reply to Imre Deak from comment #34)
> > Could you all please provide the 'Project Code' on the back of your NUC.
> We have two models: PPNUC7PJYH and PPNUC7CJYH here.

Thanks. These are both pre-production systems and the problem is specific to these (I also had one of these). Closing this ticket now, since we only support production systems where the problem shouldn't happen (without 'Project code' or without 'PP' in the 'Project code').

Thanks for your time reporting the problem and trying the workaround steps.
Comment 37 Jani Saarinen 2018-05-18 12:04:18 UTC
Closing, thank you all effort done.
Comment 38 Piotr Kasp. 2018-05-19 14:37:32 UTC
what ?? issue is not depended of hardware - as same issue exist on asrock and msi mainboard
Comment 39 Imre Deak 2018-05-20 10:40:04 UTC
(In reply to Piotr Kasp. from comment #38)
> what ?? issue is not depended of hardware - as same issue exist on asrock
> and msi mainboard

The problem reported on this ticket is specific to the pre-production version of the Intel GLK NUC hardware. It is fixed by a specific hardware change in the production version and accordingly on those the problem can't be reproduced.

If you see a problem on MSI and ASRock machines those need to be handled separately, so I suggest that you open a new ticket for those.


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.