Intel NUC Skylake & KabyLake Video Issues

resinos2x

#1

I’ve have project that requires the use of the 7th gen intel NUCs and i’ve stumbled with an issue with the video acceleration on the debian jessie docker image, which makes my app crash whenever the video driver tries to display anything too intensive (a video or any animation in css or even a big image on a 1080p screen).

Steps to reproduce issue

  • Flash the resinOS provided by the resin dashboard (2.0.9+rev1 as the time of this writing) .
  • Using Resin/Electron as a base i make the necessary adjustments in the Dockerfile.template to make video output work :
    • use docker image base resin/intel-nuc-node:8
    • remove the line: xserver-xorg-video-fbdev \
    • add RUN echo deb http://http.debian.net/debian jessie-backports main contrib non-free > /etc/apt/sources.list.d/jessie-backports.list
    • add RUN apt-get update
    • add RUN sudo apt-get install --target-release jessie-backports linux-image-amd64 firmware-misc-nonfree xserver-xorg-video-intel libegl1-mesa libgl1-mesa-glx libgl1-mesa-dri
    • change npm cache clean to npm cache verify
  • Put some CSS 3d animation or video on the electron app for video acceleration testing
  • Push the app to the repo and let the NUC provision itself.

Expected result

  • Webview to start with video acceleration.

Actual result

  • App crashes with different errors, among them some of the like:

[intel_init_bufmgr] Error initializing buffer manager.
xinit: connection to X server lost
[WARNING:audio_manager.cc] Multiple instances ofAudioManager detected

Other information

  • This was just for testing but i also added in one instance intel_iommu=igfx_off in the grub.cfg file. (needless to say it didn’t help).
  • Disabling hardware acceleration & webgl in electron config just makes it so the app is visible until you interact with it and some animation happens then the app crashes.

#3

Do you mind posting a full log from one of the crashes (or as much as you are able to get)? It could be interesting to see what else is happening around that time.

I’m also curious as to whether you have tried this outside of resin.io using the same Debian version and firmware – if so, does that work?

If I understand you correctly, the video is working properly up to the point that a large image or a lot of animation is happening, at which point it crashes. If it were something simple like a driver failing to load I’d expect to see a failure before getting any video at all.

I’ll ask one of my colleagues with a NUC to see if they can reproduce this.


#4

@Victor actually, it seems like the first thing to check is to make sure you are on the latest version of resin-electronjs. There was a pull request about two weeks ago to fix a similar issue: https://github.com/resin-io/resin-electronjs/pull/45

Can you verify that you are on the latest upstream code for resin-electronjs?


#5

Here is a log with the hardware acceleration turned off in electron:

19.07.17 01:50:34 (-0600) Started application 'registry2.resin.io/automata/3a1048e558447753bd8ebc2478540bf437b967af
19.07.17 01:50:34 (-0600) Systemd init system enabled.
19.07.17 01:50:34 (-0600) systemd 215 running in system mode. (+PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP -APPARMOR)
19.07.17 01:50:34 (-0600) Detected virtualization ‘other’.
19.07.17 01:50:34 (-0600) Detected architecture ‘x86-64’.
19.07.17 01:50:34 (-0600) Set hostname to .
19.07.17 01:50:34 (-0600) hostname: No address associated with hostname
19.07.17 01:50:34 (-0600) xauth: file /root/.Xauthority does not exist
19.07.17 01:50:34 (-0600) xauth: (stdin):1: bad display name “a6382a8:0” in “add” command
19.07.17 01:50:34 (-0600)
19.07.17 01:50:34 (-0600)
19.07.17 01:50:34 (-0600) XOrg X Server 1.16.4
19.07.17 01:50:34 (-0600) Release Date: 2014-12-20
19.07.17 01:50:34 (-0600) X Protocol Version 11, Revision 0
19.07.17 01:50:34 (-0600) Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
19.07.17 01:50:34 (-0600) Current Operating System: Linux a6382a8 4.8.17-yocto-standard #2 SMP PREEMPTThu Jul 6 11:57:19 UTC 2017 x86_64
19.07.17 01:50:34 (-0600) Kernel command line: BOOT_IMAGE=/vmlinuz root=LABEL=resin-rootA rootwait intel_iommu=igfx_off
19.07.17 01:50:34 (-0600) Build Date: 06 July 2017 10:44:53PM
19.07.17 01:50:34 (-0600) xorg-server 2:1.16.4-1+deb8u1
19.07.17 01:50:34 (-0600) Current version of pixman: 0.32.6
19.07.17 01:50:34 (-0600) Markers: (–) probed, (**) from config file, (==) default setting,
19.07.17 01:50:34 (-0600) (++) from command line, (!!) notice, (II) informational,
19.07.17 01:50:34 (-0600) (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
19.07.17 01:50:34 (-0600) (==) Log file: “/var/log/Xorg.0.log”, Time: Wed Jul 19 07:50:34 2017
19.07.17 01:50:34 (-0600) (==) Using system config directory "/usr/share/X11/xorg.conf.d"
19.07.17 01:50:34 (-0600) [intel_init_bufmgr:1190] Error initializing buffer manager.
19.07.17 01:50:35 (-0600) [191:0719/075035.787492:WARNING:audio_manager.cc(317)] Multiple instances ofAudioManager detected
19.07.17 01:50:35 (-0600) [191:0719/075035.787575:WARNING:audio_manager.cc(278)] Multiple instances ofAudioManager detected
19.07.17 01:50:35 (-0600) App Ready
19.07.17 01:50:37 (-0600) [191:0719/075037.244130:INFO:CONSOLE(8)] “Network ok”, source: globalFunctions.js (8)
19.07.17 01:50:37 (-0600) [191:0719/075037.277026:INFO:CONSOLE(30)] “Page Change Trigger”, source: events.js (30)
19.07.17 01:53:41 (-0600) Killing application 'registry2.resin.io/automata/3a1048e558447753bd8ebc2478540bf437b967af
19.07.17 01:53:41 (-0600) xinit: connection to X server lost
19.07.17 01:53:41 (-0600)
19.07.17 01:53:42 (-0600) waiting for X server to shut down (EE) Server terminated successfully (0). Closing log file.
19.07.17 01:53:42 (-0600)
19.07.17 01:53:42 (-0600) xinit: unexpected signal 15
19.07.17 01:53:42 (-0600) xauth: (argv):1: bad display name “a6382a8:0” in “remove” command

Yes, and its seems is a known issue with debian jessie, that’s why i had to use a backported driver because it doesn’t have support for skylake processors. and if i enable hardware acceleration the app crashes without even displaying anything on screen.

i am, yesterday i cloned a new repo just to try that :slightly_frowning_face:


#6

Welp Akismet didn’t showed up my post, so i’ll answer again

i was on the last commit of the repo (yesterday i cloned a new instance testing stuff), but that was when i was trying to install the backported drivers so i think i just messed everything up, i just tried adding the PR change to my code and… it doesn’t crash! :smiley: but that doesn’t fix the hardware acceleration issue so the performance is very poor (tearing and choppy animations) :disappointed:

here are the Device logs
automata_nuc7i3 dev-001-19.07.17_18_49_28_(-0600).log (4.3 KB)


#7

And the Xorg logs because the forum won’t let me post both files at once:
xorg.log (20.3 KB)


#8

Hi @Victor , I am investigating the issue, and I have a question for you:

how did you enable hw acceleration in your project? I did in the past with a branch called intel which has now been rebased so it also includes the fix for the crash with large images etc: https://github.com/resin-io/resin-electronjs/tree/intel


#9

Hello @curcuz, i’m sorry for the late reply. i’ve been busy with some other parts of the project, and now i’m retaking on this issue.

actually when i use that branch i get this issue with X: (EE) no screens found. and i get no display on the monitor.

as my understanding goes i think for Kaby Lake (and any Intel graphics since Broadwell), you need to install a new kernel and firmware from Jessie backports; for proper HW Accel.

right now i have a functional demo that does not crash but with very poor performance (which completely ruins the purpose for using a intel nuc in the first place)


#11

hi @Victor - we have figured this out recently, turns out it’s indeed related to the version of some mesa library shipped with Jessie: https://github.com/resin-os/resin-up-board/issues/26


#12

I’m actually using Jessie Backported driver in my dockerfile
Dockerfile.template.log (1.9 KB)


#13

I’m not sure if this issue is still on-going or not. @Victor, if you could let us know whether your using of the backported driver in the dockerfile has solved the issue, or whether thats more of a “I’m already trying the backport, doesn’t solve it” sort of a post.


#16

Sorry!, i’ve been out of commission for quite a few days, and yes it is an on-going issue, on the OP i wrote that i did some adjustments in the dockerfile to add the backported driver. so it was a “I’m already trying the backport, doesn’t solve it” kind of a post :sweat_smile: