Created attachment 129243 [details] X log since starting the X server - includes episodes of blanking due to openarena and google maps (under chrome) As Paulo requested on https://bugs.freedesktop.org/show_bug.cgi?id=94605, I'm opening a new bug to help collect information about the "screen blanking 2 seconds" when NUC6i5SYB connected via displayport to a monitor. I'm sorry that I didn't see Eero Tamminen's (2016-08-22 14:30:37 UTC comment #49) comment until now: > This sounds more like the X issues with DRI3 than kernel issue. > Could you try both Intel DDX &modesetting X drivers and with > Intel DDX both DRI3 and DRI2? Yes, I certainly can. But I need specific instructions on where to get the binaries or how to compile and install them locally. I'll try to follow the "HOW TO FILE A BUG REPORT" instructions linked in the "component description" field. I do NOT see an "i915 platform" information field (as described by the HOW-TO). > If it's indeed X issue, please file separate bug about it. I believe he is correct. Last year I reverted to older kernels (4.1 and 4.0) that did not previously exhibit this symptom and the symptom persisted. I believe this issue is rooted in user space and might be related to the display port output. I'll also note that my NUC died late last year and was replaced under warranty by Intel (while there were issues with the return instructions and it took 6+ weeks to resolve everything, it was taken care of - kudos to Intel support for their honest help with this). I'm reproducing the issue with the brand spank'n new HW just as frequently. I do not see any GPU hangs, FIFO overruns, or other symptoms in my dmesg or /var/log/messages output. I don't recall exactly when this symptom started but it was NOT occurring when I first purchased and used the NUC6i5SYB in Feb and March, 2016. I believe it started after May, 2016 (ie showed up in Debian testing - so bug could have been introduced earlier into dev source tree). How to reproduce: 1) run openarena in 2560x1440 2) chrome browser: zoom/pan in Google maps when in "earth" mode (and HW accel is enabled) [262565.324] (==) ModulePath set to "/usr/lib/xorg/modules" [262565.324] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [262565.324] (II) Loader magic: 0x55ac0d3d0e00 [262565.324] (II) Module ABI versions: [262565.324] X.Org ANSI C Emulation: 0.4 [262565.324] X.Org Video Driver: 23.0 [262565.324] X.Org XInput driver : 24.1 [262565.324] X.Org Server Extension : 10.0 [262565.325] (++) using VT number 7 ... [262565.325] (II) xfree86: Adding drm device (/dev/dri/card0) [262565.337] (--) PCI:*(0:0:2:0) 8086:1926:8086:2063 rev 10, Mem @ 0xde000000/16777216, 0xc0000000/268435456, I/O @ 0x0000f000/64, BIOS @ 0x????????/131072 (and I've attached the /var/log/Xorg.0.log from this sign in session) The monitor in my case is Samsung U28D590D (28", 4J UHD): http://www.samsung.com/levant/consumer/it/monitor/uhd-monitor/LU28D590DS/ZN/ The NUC is connected via mini-displayport since AFAIK, displayport is the only link that will support 4K output. I will test with HDMI port (at a lower resolution) and report later (since i'm afraid switching video input might crash or force restarting graphics server). I'm running Debian "testing" (freshly updated) Linux gggnuc6 4.9.0-1-amd64 #1 SMP Debian 4.9.2-2 (2017-01-12) x86_64 GNU/Linux I will add "drm.debug=0x1e log_buf_len=1M" and attach the dmesg buffer once I have that. # dpkg -l | fgrep -i drm ii libdrm-amdgpu1:amd64 2.4.74-1 amd64 Userspace interface to amdgpu-specific kernel DRM services -- runtime ii libdrm-intel1:amd64 2.4.74-1 amd64 Userspace interface to intel-specific kernel DRM services -- runtime ii libdrm-nouveau2:amd64 2.4.74-1 amd64 Userspace interface to nouveau-specific kernel DRM services -- runtime ii libdrm-radeon1:amd64 2.4.74-1 amd64 Userspace interface to radeon-specific kernel DRM services -- runtime ii libdrm2:amd64 2.4.74-1 amd64 Userspace interface to kernel DRM services -- runtime ii libva-drm1:amd64 1.7.3-2 amd64 Video Acceleration (VA) API for Linux -- DRM runtime # dpkg -l | fgrep -i dri ... ii i965-va-driver:amd64 1.7.3-1 amd64 VAAPI driver for Intel G45 & HD Graphics family ... ii libgl1-mesa-dri:amd64 13.0.3-1 amd64 free implementation of the OpenGL API -- DRI modules ... ii libvdpau-va-gl1:amd64 0.4.2-1 amd64 VDPAU driver with OpenGL/VAAPI backend ii libxcb-dri2-0:amd64 1.12-1 amd64 X C Binding, dri2 extension ii libxcb-dri3-0:amd64 1.12-1 amd64 X C Binding, dri3 extension ... ii va-driver-all:amd64 1.7.3-2 amd64 Video Acceleration (VA) API -- driver metapackage ii vdpau-va-driver:amd64 0.7.4-6 amd64 VDPAU-based backend for VA API ... ii xserver-xorg-video-intel 2:2.99.917+git20161206-1 amd64 X.Org X server -- Intel i8xx, i9xx display driver
I've switch to HDMI port and I'm getting 3840x2160 (same) resolution. But "black screen for 2 seconds" symptom is not reproducible. :/ It was very reproducible with DisplayPort. It's possible the frame rate is slower with HDMI; I don't know how to check that. The mini-to-normal DisplayPort cable is 1.8m length and not branded (AFAICT) on the connectors. The cable has : "DisplayPort cable E342987 AWM style 20276 80c 30v VW-1" printed on the cable. I don't think the DisplayPort cable is defective since I've been using the same cable all along and it's not been abused. I just want to include this info in case someone thinks it's a problem with the cable. [comments on about clock speed follows - seems like a red herring though] The Xorg.0.log (this boot) has the following info: [ 5.018] (II) modeset(0): Supported detailed timing: [ 5.018] (II) modeset(0): clock: 297.0 MHz Image Size: 608 x 345 mm [ 5.018] (II) modeset(0): h_active: 3840 h_sync: 4016 h_sync_end 4104 h_blank_end 4400 h_border: 0 [ 5.018] (II) modeset(0): v_active: 2160 v_sync: 2168 v_sync_end 2178 v_blanking: 2250 v_border: 0 [ 5.018] (II) modeset(0): Ranges: V min: 24 V max: 75 Hz, H min: 30 H max: 90 kHz, PixClock max 305 MHz [ 5.018] (II) modeset(0): Monitor name: U28D590 [ 5.018] (II) modeset(0): Serial No: HCPGxxxxxx In the previous Xorg.0.log using DisplayPort, I see the corresponding lines for the 3840x2160 output: [262565.377] (II) modeset(0): Supported detailed timing: [262565.377] (II) modeset(0): clock: 533.2 MHz Image Size: 607 x 345 mm [262565.377] (II) modeset(0): h_active: 3840 h_sync: 3888 h_sync_end 3920 h_blank_end 4000 h_border: 0 [262565.377] (II) modeset(0): v_active: 2160 v_sync: 2163 v_sync_end 2168 v_blanking: 2222 v_border: 0 So it looks like DisplayPort is running a much higher clock frequency than with HDMI. Is that expected/correct? The 2560x1440 output (openarena switches to this): [262565.377] (II) modeset(0): Supported detailed timing: [262565.377] (II) modeset(0): clock: 241.5 MHz Image Size: 607 x 345 mm [262565.377] (II) modeset(0): h_active: 2560 h_sync: 2608 h_sync_end 2640 h_blank_end 2720 h_border: 0 [262565.377] (II) modeset(0): v_active: 1440 v_sync: 1443 v_sync_end 1448 v_blanking: 1481 v_border: 0 [262565.377] (II) modeset(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 134 kHz, PixClock max 545 MHz [262565.377] (II) modeset(0): Monitor name: U28D590 So I'm not convinced this is related to cable or clock speed since the symptom was occurring with 241.5 Mhz clock speed as well. grundler@gggnuc6:~$ xdriinfo Screen 0: i965 grundler@gggnuc6:~$ xdpyinfo name of display: :0.0 version number: 11.0 vendor string: The X.Org Foundation vendor release number: 11900000 X.Org version: 1.19.0 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range: minimum 8, maximum 255 focus: window 0x380000f, revert to PointerRoot number of extensions: 29 BIG-REQUESTS Composite DAMAGE DOUBLE-BUFFER DPMS DRI2 DRI3 GLX Generic Event Extension MIT-SCREEN-SAVER MIT-SHM Present RANDR RECORD RENDER SECURITY SGI-GLX SHAPE SYNC X-Resource XC-MISC XFIXES XFree86-DGA XFree86-VidModeExtension XINERAMA XInputExtension XKEYBOARD XTEST XVideo default screen number: 0 number of screens: 1 screen #0: dimensions: 3840x2160 pixels (1016x571 millimeters) resolution: 96x96 dots per inch depths (7): 24, 1, 4, 8, 15, 16, 32 root window id: 0xe8 depth of root window: 24 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x20 default number of colormap cells: 256 preallocated pixels: black 0, white 16777215 options: backing-store WHEN MAPPED, save-unders NO largest cursor: 256x256 current input event mask: 0xfa803f KeyPressMask KeyReleaseMask ButtonPressMask ButtonReleaseMask EnterWindowMask LeaveWindowMask ExposureMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask ColormapChangeMask number of visuals: 40 default visual id: 0x21 visual: visual id: 0x21 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x22 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits ...
Dear ggg - I'm really sorry about this loooonnng delay until getting back to you. Are you sill having this problem? If yes then please change status REOPENED, if no then please mark bug as resolved. How to documents related building and filing can be found from 01.org. See https://01.org/linuxgraphics/documentation/build-guide-0 and https://01.org/linuxgraphics/documentation/how-report-bugs.
(In reply to Jari Tahvanainen from comment #2) > Dear ggg - I'm really sorry about this loooonnng delay until getting back to > you. Are you sill having this problem? If yes then please change status > REOPENED, if no then please mark bug as resolved. > How to documents related building and filing can be found from 01.org. See > https://01.org/linuxgraphics/documentation/build-guide-0 and > https://01.org/linuxgraphics/documentation/how-report-bugs. Hello ggg, Were you able to replicate this bug? Thank you.
Hi Elizabeth, Sorry - I switch to HDMI port (and lower refresh rates) and everthing is working. So I've not tried displayport since then. If it still doesn't work, what's the plan? thanks, grant
Hello, There is a know issue with openarena in Ubuntu 16.04 and Ubuntu 17.04, I was unable to test this issue in openarena, but, I could try with google maps and it is working find. I use the following configuration: ====================================== Graphic stack ====================================== ====================================== Software ====================================== kernel version : 4.12.0-rc3-drm-tip-ww22-commit-187376e+ architecture : x86_64 os version : Ubuntu 17.04 os codename : zesty kernel driver : i915 bios revision : 5.12 bios release date : 09/12/2016 ====================================== Graphic drivers ====================================== mesa : 17.0.3 modesetting : modesetting_drv.so xorg-xserver : 1.19.3 libdrm : 2.4.81 cairo : 1.14.8 xserver : X.Org X Server 1.19.99.1 intel-gpu-tools (tag) : intel-gpu-tools-1.18-211-g00ce341b intel-gpu-tools (commit) : 00ce341b ====================================== Hardware ====================================== platform : KBL-Nuc motherboard model : MS-B142 motherboard id : MS-B1421 form factor : Desktop manufacturer : Micro-StarInternationalCo.,Ltd. cpu family : Core i7 cpu family id : 6 cpu information : Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz gpu card : Intel Corporation Device 5916 (rev 02) (prog-if 00 [VGA controller]) memory ram : 7.65 GB max memory ram : 64 GB display resolution : 1600x900 cpu thread : 4 cpu core : 2 cpu model : 142 cpu stepping : 9 socket : Other signature : Type 0, Family 6, Model 142, Stepping 9 hard drive : 111GiB (120GB) current cd clock frequency : 540000 kHz maximum cd clock frequency : 675000 kHz displays connected : DP-1 ====================================== Firmware ====================================== dmc fw loaded : yes dmc version : 1.1 guc fw loaded : NONE guc version wanted : 0.0 guc version found : 0.0 ====================================== kernel parameters ====================================== quiet splash fastboot drm.debug=0xe I don't know if you could try with a similar configuration, (xserver and kernel) Regards.
Armando Antonio, Your display resolution is no where near 4K. Can you retest with at least 2560x1440 as was originally reported? Can you share the script that was used to collect the package version info? I'm willing to try any Debian Testing (buster) kernel or package. I'm currently still running "stretch" release but am happy to migrate to buster. Buster currently has 4.11.0-1 kernel: https://packages.debian.org/buster/linux-image-4.11.0-1-686
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.