One possible solution Link to heading

Photo by NeONBRAND on Unsplash

I recently updated my Intel NUC (model NUC6i7KYK) to run MX Linux instead of the original Debian install I had on the box. Everything is running great out of the box. Except Blender. Finding out why took a bit of sleuthing.

Short form — firing up Blender with the INTEL_DEBUG=reemit environment variable *may* clean up the crashes.

Every other box/laptop I have is running MX Linux already, and only my desktop — the Intel NUC — was still running Debian. I had just picked up a 1TB M.2 drive for that box to replace the two smaller drives (120GB and 250GB). So I was doing a re-install anyway — may as well match up everything to the same distro then.

I’m using Blender to create and tweak models for 3D Printing. Under Debian Blender just worked. Although I opted for the download/standalone version rather than installing through the APT package manager. This allowed me to use a more recent version of Blender.

The trouble started after installing MX Linux and setting up blender in the same download/standalone manner. Blender would work for a bit and then just stop. And when it stopped it took out the KDE desktop with it. The screen would just flicker. I would switch out to terminal #1 (by double tapping ctrl-alt-F1), login, and then kill the Blender process via a sudo kill -9 #### command. (where the #### was the PID number found via ps -aux or a top command). Then I’d switch back to the KDE desktop with ctrl-F7 and see that the Blender window was still displayed and the desktop was still frozen. A reboot was needed (well, that was the simplest fix I could think of at least without getting into restarting X-Windows and the window manager).

After this happened a few times and I lost a number of steps working in Blender I decided this needed to be looked into some more.

First I tried to google for “mx linux blender crash”. That was too broad. But did mention there might be some logs. I couldn’t find any specific Blender logs but did look at the /var/log/messages file. This showed me something that looked like this:

Feb 17 02:26:28 nuc kernel: [1281.614313] i915 0000:00:02.0 GPU HANG: ecode 9:1:85df9ebf, in blender[6868]

Ok, that didn’t look good. So I googled “blender GPU HANG” and came across a number of suggestions. First was to try an older blender. I had been running 2.91.2, so I tried 2.91.1 which had been working fine in Debian. That exhibited the same issues. So I tried the LTS version of Blender — 2.83.12 — and this showed the same issues. Finally I tried a native Blender install via APT — and even this showed the same issues.

Back to google then. This time I broadened my search and looked for “mx linux gpu hang”. This ultimately lead me to the fix for my specific problem as a comment found on this page.

This does not seem to be a Blender or MX Linux specific issue. It looks as though the Intel Iris Pro graphics card that is stock with the NUC has some driver issues. KDE makes use of the GPU processing for its windows effects (transparencies, shadows, animations, etc.). It looks as though the Intel drivers sometimes do not respond quite fast enough and a timeout is encountered. When that happens the GPU HANG error takes place and takes out ANYTHING that is also using the GPU.

The discussion thread I found does suggest a way to increase the timeout. However a “simpler” fix is to just set the INTEL_DEBUG environment variable when running blender.

After rebooting to clean up the login session I booted up my version of Blender with INTEL_DEBUG=reemit ./blender from within my blender directory. That started up and allowed me to work on my models normally. So after using it that way for a little while I edited my menu icon with this modified command INTEL_DEBUG=reemit /home/myuser/bin/blender-2.91.2-linux64/blender. And then I started Blender from there. Thus far I have been working in Blender for a number of hours today and have yet to experience the crash.

If you have read this far then you likely have an Intel video card that is showing a similar problem. I hope this helps solve your issue without having to dig through issue logs or GIT discussion threads.