I fixed that issue, I forgot to capitalize dmSL.
SO now the miner will start running for about 2 minutes, connect to the pool begin mining and then unexpectedly freeze and relaunch the miner.
It's been doing that for the last couple hours relaunching miner then rebooting rig.

Finally now it seems to be running stable for about 10 minutes while I was typing this reply. I made no changes so not sure the problem. Z-Enemy miner unstable?

**EDIT: been running stable for a few hours now**

Have a look at 0miner for dual modes and add one with the changes needed,
Some thing like this:
Set your coin in 1bash
COIN="DUAL_ETH_SMART"

Dont forget to set the address for both in their sections

You can also use 19-2.1 beta for a much easier way, or wait for 19-2.1 stable.

Set the TARGET_TEMP, so that temp control can lower power limit if it can not achieve that temp by fan speed and start lowering power limit.
Check which GPU fan goes too high, if its the GPU0 that gives the error too, try changing it.

Hello guys.

First of all, big thanks to all the team for the great job on this project.

Been using your Distro for 3 month now and it rocks guys. lately I've got an issue with one of my rigs, a faulty riser cause the rig to freeze without being able to complete it's reboot routing.
As Doftorul pointed out more often than not having a GPU dropping off the bus triggers a kernel panic.
So I'm sharing my workaround for those who got the same issue and have only a remote access to the rig:
Create a magic reboot script that contain (magicreboot.sh) :
#!/bin/bash
echo 1 >proc/sys/kernel/sysrq
echo s >proc/sysrq-trigger
echo u >proc/sysrq-trigger
echo s >proc/sysrq-trigger
echo b >proc/sysrq-trigger


Edit 5watchdog :
Change all the sudo reboot occurrence to sudo magicreboot.sh
Do the same in 6tempcontrol

for more reading about Sysrq: https://en.wikipedia.org/wiki/Magic_SysRq_key
Hope this could help
Big thanks to Doftorul, sizzlephizzle and all the nvOC team  

As explained in the wikipedia page you linked, those magic sysrq keys cannot work if kernel panics occurred. I had months ago a faulty riser as well and experienced the "GPUx fallen off the bus error" but it never caused kernel panics, the watchdog detected the miner error state and restarted it (with one gpu less) without rebooting. What this script is intended to do?

Note I also have Intel WDT Driver in use, may be it didn't allow me to experience those reboot hangs you mentioned.

The 2.1 tree has been patched (after a lot of work) to be 100% compatible side-by-side with other nvOC versions. It's also very easy to switch back to 2.0 if you find some issues or bugs while testing, and is easy as well getting latest patches with fixes in a matter of seconds by just performing giving (in most cases) a single command. You can even do it remotely without having to detach your ssd/hdd/usb drive. And it takes only some minutes. It's not a conversion, nvOC 2.0 will remain untouched, ready to fall back in case. Future (at least minor) updates will be likely released in the same way, so I would strongly encourage you all in getting familiar with that easy workflow.

EDIT: you can always find updated, valid install/testing guide in the GitHub nvOC wiki: https://github.com/papampi/nvOC_by_fullzero_Community_Release/wiki/nvOC-19-2.1-beta-testing

Can I run ohGodanETHlargementPill on NvOc 19.1.4?

Hey :-)
What do you think is the ideal RAM size for a motherboard running nvOC?

Yeah I'm trying a hardware solution too using RaspberryPI, and now I'm happy with the sysrq workaround as it prevent any freeze caused by faulty riser.
I'm testing the full REISUB sequence as papampi suggested, we'll give u a feed back tomorrow.