Quote from: MaxMidnite on September 17, 2018, 06:56:47 AM

Thanks I added this line "PASS" : "x"
"WORKBATCH" : "HIGH"}
To my user config file, but soon as I run the miner goes crazy, doesnt work windows keep popping up.
In next version can you check it, also why the need for two windows, can we keep all in one like other miners.

You missed a "," because every line needs a comma at its end except for the last line in the block - I think its the json parser complaining here.

---------

Quote from: CygnusMinor on September 16, 2018, 11:32:45 PM

So I'm seeing an odd behavior with 144.5 mining (zelcash in this case, 2 Vega64's, 3 Vega56's). If/when I lose connection to the pool, the moment the worker is reauthorized, my linux box crashes and reboots:
...
and then the immediate reboot. I don't see the kernel panic in the log, but I see ubuntu 18 uses syslog caching by default. I've removed caching and we'll see if it catches something on the next crash.

This is more of an FYI unless you see something in your reconnect code that might cause a panic. However, I'm not even sure whether the lost connection is a symptom of an imminent crash or the actual cause. Who knows, it could simply be instability with one of my risers...

I'll see if I can track down more info in the logs next time.

edit: I also notice that if I ctrl-c out of the miner, it's a 50/50 toss up that restating the miner causes a reboot on reconnect. So this is likely related. Perhaps something about the state that the card is left in during an abnormal stop? Reuse that card and cause the panic? I find that I usually have to power off the clear the cards before the system is stable again. Just speculating...

I'm undervolting and using the latest amd 18.30 drivers for ubuntu.

Hmm have not seen this till now, but may be. ctrl+c is a bit difficult to handle because it stops program immediately, so I even can not catch this to wait until cards have stopped what they just did to exit gracefully. Maybe I must think of an other way to stop the miner.