Entire computer locks up requiring hard reset whenever Cycles rendering is enabled (Linux Mint 19.1, 64 bit) #61613

New Issue

Nick · 2019-02-16T17:29:42+01:00

Nick commented

2019-02-16 17:29:42 +01:00

Operating system: Linux Mint 19.1, Mate, 64 bit
Graphics card: GeForce GTX 760, 4096 MB, proprietary NVIDIA Driver Version: 410.93
CPU: AMD FX-8150 Eight-Core Processor, 3.6 Ghz
Motherboard: ASUSTeK M5A99FX PRO R2.0
RAM: 2x4GB (8gb total) Corsair DDR3, 1600, Memtested OK

Blender Version
2.8 Beta, 2019-02-09 20:41, 66c23ea2b4
blender.runlog.post

Short description of error
Entire computer locks up requiring hard reset whenever Cycles rendering is enabled.

Steps for others to reproduce the error
Using the default startup file, go to the "rendering" tab.

Change the "Render Engine" to "Cycles" from "Eevee". It does not matter if you choose GPU or CPU.
Go back to the "layout" tab.
Change viewport rendering from "solid" (default) to "rendered" using the sphere icons in the top right.
It will start rending a bit, then the computer will lock up within a few seconds, requiring a complete power cycle. (reset switch)

Things I've tried:

I also had this problem with a Radeon HD 7000 series card that I had installed initially. Blender actually worked fine with that card (except this same Cycles problem). I replaced that card with this one when I learned it was unsupported.
Now with this newer Nvidia GTX 760 card which supports OpenGL 4+, I've done a clean install (reformat) and upgrade of the OS to Linux Mint 19.1 (from 18.3), and installed the Nvidia proprietary driver with the latest version they offer which is 410.93. (As a side note, Meshroom now works correctly without freezing the computer with this new card and drivers).
I ran MemTest86 for 12 hours and no errors were reported in the system RAM.
I'm attaching a log of the Blender run with the --debug --debug-gpu options set. It ends with a whole bunch of "\00\00\00\00\00", which I guess is the sound of a computer screaming.

Operating system: Linux Mint 19.1, Mate, 64 bit Graphics card: GeForce GTX 760, 4096 MB, proprietary NVIDIA Driver Version: 410.93 CPU: AMD FX-8150 Eight-Core Processor, 3.6 Ghz Motherboard: ASUSTeK M5A99FX PRO R2.0 RAM: 2x4GB (8gb total) Corsair DDR3, 1600, Memtested OK **Blender Version** 2.8 Beta, 2019-02-09 20:41, 66c23ea2b4a4 [blender.runlog.post](https://archive.blender.org/developer/F6630471/blender.runlog.post) **Short description of error** Entire computer locks up requiring hard reset whenever Cycles rendering is enabled. **Steps for others to reproduce the error** Using the default startup file, go to the "rendering" tab. 1. Change the "Render Engine" to "Cycles" from "Eevee". It does not matter if you choose GPU or CPU. 2. Go back to the "layout" tab. 3. Change viewport rendering from "solid" (default) to "rendered" using the sphere icons in the top right. 4. It will start rending a bit, then the computer will lock up within a few seconds, requiring a complete power cycle. (reset switch) Things I've tried: 1. I also had this problem with a Radeon HD 7000 series card that I had installed initially. Blender actually worked fine with that card (except this same Cycles problem). I replaced that card with this one when I learned it was unsupported. 2. Now with this newer Nvidia GTX 760 card which supports OpenGL 4+, I've done a clean install (reformat) and upgrade of the OS to Linux Mint 19.1 (from 18.3), and installed the Nvidia proprietary driver with the latest version they offer which is 410.93. (As a side note, Meshroom now works correctly without freezing the computer with this new card and drivers). 3. I ran MemTest86 for 12 hours and no errors were reported in the system RAM. 4. I'm attaching a log of the Blender run with the --debug --debug-gpu options set. It ends with a whole bunch of "\00\00\00\00\00", which I guess is the sound of a computer screaming.

Nick commented

2019-02-16 17:29:42 +01:00

Added subscriber: @lightnb

Sebastian Parborg commented

2019-02-18 12:09:30 +01:00

Added subscriber: @ZedDB

Sebastian Parborg commented

2019-02-18 12:09:30 +01:00

Does it happen if you render from command line? https://docs.blender.org/manual/en/latest/render/workflows/command_line.html

Nick commented

2019-02-18 19:04:41 +01:00

Yes, it freezes on command line too.

I opened the default cube file, saved it as cube.blend, closed Blender then rendered the file from CLI. Renders fine when BLENDER_EEVEE is specified, freezes computer after a few seconds when using CYCLES as the engine.

The command I ran was:

./bin/blender-2.80-66c23ea2b4a4-linux-glibc224-x86_64/blender -b ./Blender\ Projects/cube.blend -o ./Blender\ Projects/cubetest_## -E CYCLES -f 1 &> ./Blender\ Projects/renderlog.txt

I tried to capture output into a log, but the file is empty. Also, I let the computer run for several minutes in the locked/frozen state, to see if it was still rendering and it was just the xserver (etc) that was locked up, but no cube was rendered in the output file after i rebooted and nothing was written to the log, so I believe it is a full hardware lock, not just the graphics layer. Also, I cannot recover with ctrl+alt+backspace or ctrl+alt+del. Using the hardware reset switch is required for restart.

Is there a way to force Blender to use just the CPU (bypassing the graphics card and drivers completely) and/or just the GPU that I can test with to try to further isolate the problem? Like a --cpu-only flag for the command line?

Yes, it freezes on command line too. I opened the default cube file, saved it as cube.blend, closed Blender then rendered the file from CLI. Renders fine when BLENDER_EEVEE is specified, freezes computer after a few seconds when using CYCLES as the engine. The command I ran was: ./bin/blender-2.80-66c23ea2b4a4-linux-glibc224-x86_64/blender -b ./Blender\ Projects/cube.blend -o ./Blender\ Projects/cubetest_## -E CYCLES -f 1 &> ./Blender\ Projects/renderlog.txt I tried to capture output into a log, but the file is empty. Also, I let the computer run for several minutes in the locked/frozen state, to see if it was still rendering and it was just the xserver (etc) that was locked up, but no cube was rendered in the output file after i rebooted and nothing was written to the log, so I believe it is a full hardware lock, not just the graphics layer. Also, I cannot recover with ctrl+alt+backspace or ctrl+alt+del. Using the hardware reset switch is required for restart. Is there a way to force Blender to use just the CPU (bypassing the graphics card and drivers completely) and/or just the GPU that I can test with to try to further isolate the problem? Like a --cpu-only flag for the command line?

Nick commented

2019-02-18 20:43:14 +01:00

I think I've narrowed down the problem to CPU rendering. This is what I did:

Opened the default cube file.
Edit -> preferences -> system
Choose CUDA, then check only "AMD FX Eight-Core processor", leaving "GeForce GTX 760 (Display)" unchecked.
Save preferences
Rendering tab
change engine to cycles, feature set supported, device, CPU
leave Open shading Unchecked
save as CubeTestCPUOnly.blend

Opened the default cube file.
Edit -> preferences -> system
Choose CUDA, then check only "GeForce GTX 760 (Display)", leaving "AMD FX Eight-Core processor" unchecked.
Save preferences
Rendering tab
change engine to cycles, feature set supported, device, GPU compute
save as CubeTestGPUOnly.blend

closed blender

./bin/blender-2.80-66c23ea2b4a4-linux-glibc224-x86_64/blender -b ./Blender\ Projects/CubeTestGPUOnly.blend -o ./Blender\ Projects/CubeTestGPUOnly_## -E CYCLES -f 1 &> ./Blender\ Projects/CubeTestGPUOnly.txt

Renders to file without freezing computer.

./bin/blender-2.80-66c23ea2b4a4-linux-glibc224-x86_64/blender -b ./Blender\ Projects/CubeTestCPUOnly.blend -o ./Blender\ Projects/CubeTestCPUOnly_## -E CYCLES -f 1 &> ./Blender\ Projects/CubeTestCPUOnly.txt

Freezes computer.

I've also been able to get it cycles to work in the GUI, by using the same options as in the GPU test file (CPU disabled).

Hopefully that is helpful information. So this issue seems to only affect CPU rendering. I'm not sure what else to try at this point, so I'll wait for guidance.

I think I've narrowed down the problem to CPU rendering. This is what I did: Opened the default cube file. Edit -> preferences -> system Choose CUDA, then check only "AMD FX Eight-Core processor", leaving "GeForce GTX 760 (Display)" unchecked. Save preferences Rendering tab change engine to cycles, feature set supported, device, CPU leave Open shading Unchecked save as CubeTestCPUOnly.blend Opened the default cube file. Edit -> preferences -> system Choose CUDA, then check only "GeForce GTX 760 (Display)", leaving "AMD FX Eight-Core processor" unchecked. Save preferences Rendering tab change engine to cycles, feature set supported, device, GPU compute save as CubeTestGPUOnly.blend closed blender ./bin/blender-2.80-66c23ea2b4a4-linux-glibc224-x86_64/blender -b ./Blender\ Projects/CubeTestGPUOnly.blend -o ./Blender\ Projects/CubeTestGPUOnly_## -E CYCLES -f 1 &> ./Blender\ Projects/CubeTestGPUOnly.txt Renders to file without freezing computer. ./bin/blender-2.80-66c23ea2b4a4-linux-glibc224-x86_64/blender -b ./Blender\ Projects/CubeTestCPUOnly.blend -o ./Blender\ Projects/CubeTestCPUOnly_## -E CYCLES -f 1 &> ./Blender\ Projects/CubeTestCPUOnly.txt Freezes computer. I've also been able to get it cycles to work in the GUI, by using the same options as in the GPU test file (CPU disabled). Hopefully that is helpful information. So this issue seems to only affect CPU rendering. I'm not sure what else to try at this point, so I'll wait for guidance.

Nick commented

2019-02-19 05:44:34 +01:00

OK, so after a bit more playing with it, it appears that with the GPU settings per above, it still does lock up the entire computer too. But, it takes much longer to do so. You can work for maybe 5 to 30 minutes before it freezes. With the GPU settings, the freezing is more unpredictable. With the CPU settings, the freeze is also within 3-4 seconds of trying to cycles render. This could be two separate issues, or not. I'm not sure how to determine that. But both freezes occur when cycles rendering.