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
Hi, What are options set in BIOS for operating system. There should be two options, please use default (Windows). + Imre.
The OS setting in BIOS is set to Windows originally. We do not change it.
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.
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”
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
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)
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.
Created attachment 138993 [details] kernel log of commit 1c7ccd drm-tip/2018-04-19 (1c7ccdf37b04bedb10e2191d34dfbba62beb79ea)
DMC info: $ md5sum /lib/firmware/i915/glk_dmc_ver1_04.bin 72d01d9f8887793ac0787f19206a74fc /lib/firmware/i915/glk_dmc_ver1_04.bin
Imre, any idea from you?
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
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.
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
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).
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.
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.
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
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
Created attachment 139435 [details] This is the dmesg output of the failure run This is the dmesg output of the failure run
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.
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
(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?
(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.
Created attachment 139457 [details] dmesg for outb and inb commands
(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?
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.
(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
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)
(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
(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.
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
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)
(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)
Could you all please provide the 'Project Code' on the back of your NUC. Thanks.
(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.
(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.
Closing, thank you all effort done.
what ?? issue is not depended of hardware - as same issue exist on asrock and msi mainboard
(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.