I use nvoc for dual mining: DUAL_ETC_PASC
for ETC I can use only etc.nanopool.org or etc.ethermine.org servers, in all other ETC POOL servers I receive the message:
ETH: Authorization failed
: {"id":2,"jsonrpc":"2.0","result":null,"error":{"code":-1,"message":"Invalidlogin"}}
Stratum - reading socket failed, disconnect
ETH: Job timeout, disconnect, retry in 20 sec...
Please help me to find a solution.
Even i get this with various coins if i change my pool. I'm not sure why? Different stratum implementations. The Genoil miner knows how to deal with these: -SP, --stratum-protocol <n> Choose which stratum protocol to use:
0: official stratum spec: ethpool, ethermine, coinotron, mph, nanopool (default)
1: eth-proxy compatible: dwarfpool, f2pool, nanopool
2: EthereumStratum/1.0.0: nicehash
The Claymore miner doesn't have this option...though you mention using it with Nanopool and Ethermine, and I've used it briefly with NiceHash, so that covers the types that Genoil knows about. Perhaps it adjusts automatically, but still runs into issues with some pools. |
|
|
|
I compiled both alexis78 and Tpuvot 2.2 ccminer clients and added at download link to them on the OP. I will include them in v0019 of course.
The alexis78 miner appears to be OK (at least /home/m1/ASccminer/ccminer --help works), but the and tpruvot miners exit on my rig with an illegal-instruction error. My rig runs on a Celeron G3920 (Skylake core). (The help output worked for the alexis78 miner, but when it tried mining with it, it fell over.) |
|
|
|
ccminer works great on Windows, I want to build the latest source code on ubuntu 16.04 x64, I downloaded the source code from https://github.com/tpruvot/ccminer, run build.sh, it throws a couple of errors: bignum.hpp:63:24: error: invalid use of incomplete type ‘BIGNUM {aka struct bignum_st}’
class CBigNum : public BIGNUM
^
In file included from /usr/local/include/openssl/bn.h:32:0,
from bignum.hpp:20,
from bignum.cpp:8:
/usr/local/include/openssl/ossl_typ.h:80:16: note: forward declaration of ‘BIGNUM {aka struct bignum_st}’
typedef struct bignum_st BIGNUM;
^
[...]
Same error here, and I've tried past releases all the way back to 1.8.2. |
|
|
|
I took a stab at updating 1bash for the new switcher. Instead of writing a bunch of small files, a heredoc with the necessary JSON is written, and then the switcher is started with that JSON file. The following patch should work: --- 1bash.orig 2017-07-20 05:26:02.000000000 -0700
+++ 1bash 2017-07-23 20:50:43.995192600 -0700
@@ -1021,79 +1021,92 @@
echo ""
fi
-rm /home/m1/currency
-rm /home/m1/pwrcost
-rm /home/m1/minprofit
-rm /home/m1/paymentaddr
-rm /home/m1/minername
-rm /home/m1/f
-rm /home/m1/g
-rm /home/m1/h
-#rm /home/m1/ii
-rm /home/m1/j
-rm /home/m1/k
-rm /home/m1/l
-#rm /home/m1/m
-rm /home/m1/n
-rm /home/m1/o
-rm /home/m1/p
-#rm /home/m1/q
-rm /home/m1/r
-rm /home/m1/s
-rm /home/m1/t
-#rm /home/m1/u
-rm /home/m1/v
-rm /home/m1/ww
-rm /home/m1/x
-#rm /home/m1/y
-#rm /home/m1/z
-#rm /home/m1/za
-#rm /home/m1/zb
-#rm /home/m1/zc
sleep 2
cd /home/m1
-echo $CURRENCY > '/home/m1/currency'
-echo $POWER_COST > '/home/m1/pwrcost'
-echo $MINIMUM_PROFIT > '/home/m1/minprofit'
-echo $PAYMENT_ADDRESS > '/home/m1/paymentaddr'
-echo $WORKER_NAME > '/home/m1/minername'
-
-echo $daggerhashimoto_POWERLIMIT_WATTS > '/home/m1/f'
-echo $__daggerhashimoto_CORE_OVERCLOCK > '/home/m1/g'
-echo $daggerhashimoto_MEMORY_OVERCLOCK > '/home/m1/h'
-#echo $_______daggerhashimoto_FAN_SPEED > '/home/m1/ii'
-
-echo $equihash_POWERLIMIT_WATTS > '/home/m1/j'
-echo $__equihash_CORE_OVERCLOCK > '/home/m1/k'
-echo $equihash_MEMORY_OVERCLOCK > '/home/m1/l'
-#echo $_______equihash_FAN_SPEED > '/home/m1/m'
-
-echo $neoscrypt_POWERLIMIT_WATTS > '/home/m1/n'
-echo $__neoscrypt_CORE_OVERCLOCK > '/home/m1/o'
-echo $neoscrypt_MEMORY_OVERCLOCK > '/home/m1/p'
-#echo $_______neoscrypt_FAN_SPEED > '/home/m1/q'
-
-echo $lyra2rev2_POWERLIMIT_WATTS > '/home/m1/r'
-echo $__lyra2rev2_CORE_OVERCLOCK > '/home/m1/s'
-echo $lyra2rev2_MEMORY_OVERCLOCK > '/home/m1/t'
-#echo $_______lyra2rev2_FAN_SPEED > '/home/m1/u'
-
-echo $lbry_POWERLIMIT_WATTS > '/home/m1/v'
-echo $__lbry_CORE_OVERCLOCK > '/home/m1/ww'
-echo $lbry_MEMORY_OVERCLOCK > '/home/m1/x'
-#echo $_______lbry_FAN_SPEED > '/home/m1/y'
-
-#echo $pascal_POWERLIMIT_WATTS > '/home/m1/z'
-#echo $__pascal_CORE_OVERCLOCK > '/home/m1/za'
-#echo $pascal_MEMORY_OVERCLOCK > '/home/m1/zb'
-#echo $_______pascal_FAN_SPEED > '/home/m1/zc'
+if [ "$INDIVIDUAL_CLOCKS" == "YES" ]
+then
+ gpu_clks_daggerhashimoto="[$__CORE_OVERCLOCK_0,$__CORE_OVERCLOCK_1,$__CORE_OVERCLOCK_2,$__CORE_OVERCLOCK_3,$__CORE_OVERCLOCK_4,$__CORE_OVERCLOCK_5,$__CORE_OVERCLOCK_6,$__CORE_OVERCLOCK_7,$__CORE_OVERCLOCK_8,$__CORE_OVERCLOCK_9,$__CORE_OVERCLOCK_10,$__CORE_OVERCLOCK_11,$__CORE_OVERCLOCK_12,$__CORE_OVERCLOCK_13]"
+ mem_clks_daggerhashimoto="[$MEMORY_OVERCLOCK_0,$MEMORY_OVERCLOCK_1,$MEMORY_OVERCLOCK_2,$MEMORY_OVERCLOCK_3,$MEMORY_OVERCLOCK_4,$MEMORY_OVERCLOCK_5,$MEMORY_OVERCLOCK_6,$MEMORY_OVERCLOCK_7,$MEMORY_OVERCLOCK_8,$MEMORY_OVERCLOCK_9,$MEMORY_OVERCLOCK_10,$MEMORY_OVERCLOCK_11,$MEMORY_OVERCLOCK_12,$MEMORY_OVERCLOCK_13]"
+ gpu_clks_equihash=$gpu_clks_daggerhashimoto
+ mem_clks_equihash=$mem_clks_daggerhashimoto
+ gpu_clks_neoscrypt=$gpu_clks_daggerhashimoto
+ mem_clks_neoscrypt=$mem_clks_daggerhashimoto
+ gpu_clks_lyra2rev2=$gpu_clks_daggerhashimoto
+ mem_clks_lyra2rev2=$mem_clks_daggerhashimoto
+ gpu_clks_lbry=$gpu_clks_daggerhashimoto
+ mem_clks_lbry=$mem_clks_daggerhashimoto
+else
+ gpu_clks_daggerhashimoto="$__daggerhashimoto_CORE_OVERCLOCK"
+ mem_clks_daggerhashimoto="$daggerhashimoto_MEMORY_OVERCLOCK"
+ gpu_clks_equihash="$__equihash_CORE_OVERCLOCK"
+ mem_clks_equihash="$equihash_MEMORY_OVERCLOCK"
+ gpu_clks_neoscrypt="$__neoscrypt_CORE_OVERCLOCK"
+ mem_clks_neoscrypt="$neoscrypt_MEMORY_OVERCLOCK"
+ gpu_clks_lyra2rev2="$__lyra2rev2_CORE_OVERCLOCK"
+ mem_clks_lyra2rev2="$lyra2rev2_MEMORY_OVERCLOCK"
+ gpu_clks_lbry="$__lbry_CORE_OVERCLOCK"
+ mem_clks_lbry="$lbry_MEMORY_OVERCLOCK"
+fi
+
+if [ "$INDIVIDUAL_POWERLIMIT" == "YES" ]
+then
+ pwr_lim_daggerhashimoto="[$INDIVIDUAL_POWERLIMIT_0,$INDIVIDUAL_POWERLIMIT_1,$INDIVIDUAL_POWERLIMIT_2,$INDIVIDUAL_POWERLIMIT_3,$INDIVIDUAL_POWERLIMIT_4,$INDIVIDUAL_POWERLIMIT_5,$INDIVIDUAL_POWERLIMIT_6,$INDIVIDUAL_POWERLIMIT_7,$INDIVIDUAL_POWERLIMIT_8,$INDIVIDUAL_POWERLIMIT_9,$INDIVIDUAL_POWERLIMIT_10,$INDIVIDUAL_POWERLIMIT_11,$INDIVIDUAL_POWERLIMIT_12,$INDIVIDUAL_POWERLIMIT_13]"
+ pwr_lim_equihash=$pwr_lim_daggerhashimoto
+ pwr_lim_neoscrypt=$pwr_lim_daggerhashimoto
+ pwr_lim_lyra2rev2=$pwr_lim_daggerhashimoto
+ pwr_lim_lbry=$pwr_lim_daggerhashimoto
+else
+ pwr_lim_daggerhashimoto=$daggerhashimoto_POWERLIMIT_WATTS
+ pwr_lim_equihash=$equihash_POWERLIMIT_WATTS
+ pwr_lim_neoscrypt=$neoscrypt_POWERLIMIT_WATTS
+ pwr_lim_lyra2rev2=$lyra2rev2_POWERLIMIT_WATTS
+ pwr_lim_lbry=$lbry_POWERLIMIT_WATTS
+fi
+
+cat <<EOF >/home/m1/1bash_conf.json
+{
+ "currency": "$CURRENCY",
+ "pwrcost": $POWER_COST,
+ "min_profit": $MINIMUM_PROFIT,
+ "payment_addr": "$PAYMENT_ADDR",
+ "miner_name": "$WORKER_NAME",
+ "performance":
+ {
+ "daggerhashimoto": {
+ "speed": 0.087, "power": 0.397,
+ "power_limit": $pwr_lim_daggerhashimoto, "gpu_oc": $gpu_clks_daggerhashimoto, "mem_oc": $mem_clks_daggerhashimoto, "fan": 0,
+ "cmd": "/home/m1/eth/Genoil-U/ethminer -SP 2 -S daggerhashimoto.usa.nicehash.com:3353 -O {ADDR}.{MINER}:x -U"
+ },
+ "equihash": {
+ "speed": 0.000001140, "power": 0.397,
+ "power_limit": $pwr_lim_equihash, "gpu_oc": $gpu_clks_equihash, "mem_oc": $mem_clks_equihash, "fan": 0,
+ "cmd": "/home/m1/zec/v3_4/miner --eexit 3 --fee 0 --pec --server equihash.usa.nicehash.com --user {ADDR}.{MINER} --pass z --port 3357"
+ },
+ "neoscrypt": {
+ "speed": 0.002160, "power": 0.397,
+ "power_limit": $pwr_lim_neoscrypt, "gpu_oc": $gpu_clks_neoscrypt, "mem_oc": $mem_clks_neoscrypt, "fan": 0,
+ "cmd": "/home/m1/SPccminer/ccminer -a neoscrypt -o stratum+tcp://neoscrypt.usa.nicehash.com:3341 -u {ADDR}.{MINER} -p x"
+ },
+ "lyra2rev2": {
+ "speed": 0.081, "power": 0.386,
+ "power_limit": $pwr_lim_lyra2rev2, "gpu_oc": $gpu_clks_lyra2rev2, "mem_oc": $mem_clks_lyra2rev2, "fan": 0,
+ "cmd": "/home/m1/SPccminer/ccminer -a lyra2v2 -o stratum+tcp://lyra2rev2.usa.nicehash.com:3347 -u {ADDR}.{MINER} -p x"
+ },
+ "lbry": {
+ "speed": 0.639, "power": 0.392,
+ "power_limit": $pwr_lim_lbry, "gpu_oc": $gpu_clks_lbry, "mem_oc": $mem_clks_lbry, "fan": 0,
+ "cmd": "/home/m1/SPccminer/ccminer -a lbry -o stratum+tcp://lbry.usa.nicehash.com:3356 -u {ADDR}.{MINER} -p x"
+ }
+ }
+}
+EOF
echo "LAUNCHING: SALFTER_NICEHASH_PROFIT_SWITCHING "
echo ""
-python2.7 '/home/m1/switch'
+python2.7 '/home/m1/switch' /home/m1/1bash_conf.json
if [ $LOCALorREMOTE == "LOCAL" ]
then
|
|
|
|
Hey salfter / Scott, is it possible to add individual OC settings to the JSON file? For instance: Original: "power_limit": [115,115,95], "gpu_oc": -200, "mem_oc": 600, "fan": [70,75,70] Individual OC: "power_limit": [115,115,95], "gpu_oc": [-200,0,50], "mem_oc": [600,1000,800], "fan": [70,75,70] From what I could see in the "for i in range(0, cards)" loop in switch.py, you already implemented that.  So, just checking if my understanding is correct -- otherwise, I'd like to suggest it as a new feature. That's exactly how it works. I left in examples configured both ways. |
|
|
|
I've updated my switcher to separate out the configuration from the rest of the code: https://gitlab.com/salfter/nvoc-nicehash-switcherConfiguration now resides in a JSON file that is easily edited, whether manually or automatically. I'm looking at the latest 1bash to have it generate this file at runtime. I also think I've found and eliminated a source of instability in my mining rig:  After moving from a tower case to a Spotswood frame, I noticed that the power cable feeding one of the GPUs was noticeably warm, and so were the Molex connectors on that cable that plugged into the adapter shown above. I suspect the wiring on the Molex-connector cable on this power supply isn't as beefy as the others, on the theory that it'll only have some fans and (very rarely) a floppy drive hanging off of it, not a hard drive (since those are all SATA now) or anything more power-hungry. daggerhashimoto was the only algo running with any stability, and a voltmeter on one of the unused Molex connectors showed a drop on the +12V line down to 11.3V. Nearly any other algo would cause the GPU to drop off the bus. I picked up different adapters at Fry's this afternoon that go from two SATA connectors to one PCIe connector. (I already had one of these in use powering another GPU with an 8-pin connector. I bought two more for the 8- and 6-pin connectors on the problematic GPU.) I swapped them in when I got home, fired up the rig, and saw that the drop on +12V had improved to 11.65V, which I think is in spec. Not only that, but I benchmarked all algos supported by the switcher with the new three-GPU configuration, and not once did I have to reboot. Now I just need my PCIe risers to arrive...and maybe also to replace the 650W ATX power supply I'm currently using with one of those server power supplies with an adapter that provides lots of PCIe outputs, as this one's nearly maxed out for connectivity. (Three 1070s and an Asus Prime Z270-AR also draw about 400W with the cards underclocked.) I remember seeing one company bundling a picoPSU with theirs so you could run the motherboard off a PCIe cable. |
|
|
|
This is what you do when your mining frame has arrived, but your risers are still on the slow boat from China and you want to get your mining rig moved into its new home ASAP:  Flip the rear GPU bracket so it's on the outside of the frame, and position it low enough that the GPUs' mounting brackets are just above it. Replace the M4-0.7x6 GPU mounting bolts with M4-0.7x10 bolts and a couple of 1/8x3/4 fender washers (two washers per bolt). For each GPU, sandwich the tab between the washers and tighten the bolt to hold it in place. Cooling would be better if the second and third GPUs were further apart, but that's how the slots are positioned. This is only a temporary measure until the risers get here, at which point they can be spaced a sensible distance apart from each other. |
|
|
|
I'm planning to experiment with Salfter's NiceHash switcher, but by reading the relevant code in 1bash and switch, it seems that the individual OC settings (per card) defined in 1bash won't be used at all - only the ones set per coin, applied to all the cards. Since I have a mix of different cards, each one must take different core and mem OC values. I have an initial idea of the code changes needed, but before doing that, I'd like to check if there's another way to do that already implemented (which I missed), or something already being developed in that sense.
I've not gotten around to it yet, but I have an idea for how to enable per-card, per-algorithm settings. I've updated the switcher to accept either an integer or an array of integers for the various overclocking settings. If you use arrays, you can provide custom settings to each card. https://gitlab.com/salfter/nvoc-nicehash-switcher/commit/7480fc8c04622277fb638b46c5337c183908d855 |
|
|
|
Also I have noticed a problem when using both PROFIT_SWITCHING and or WATCHDOG together; I will make changes to the next 1bash to fix it.
Would this happen to be the problem where all the executables disappear, you can't log back in after logging out, etc.? I noticed that earlier this week when I gave v18 a shot...something would happen after it had been running an hour or two to where it wouldn't respond to anything but either SysRq-B at the keyboard or a reset or power cycle. Also, the GPUs appeared to still be under full load, but NiceHash reported no activity. I still had v17 on its stick, so dropping back to it was no problem. |
|
|
|
saflter your newest version of switch was causing problems when run with a monitor connected (LOCAL); I would recommend relying on the:
IAmNotAJeep_and_Maxximus007_WATCHDOG
to handle miner crashes / 0 hashrates.
I spent a couple hours testing this, and it is very effective; it is worth noting that it currently only works when the mining process is launched in a screen ( I will make it work for all the clients even when run locally soon: so don't spend a lot of time upgrading rigs with this)
I've been laying low the past few days, doing stability checks. Unloading/reloading the driver while switching hasn't completely eliminated crashes, so I'm thinking that a watchdog process would work better. My latest commit comments out the GPU-resetting code, and also logs whenever it switches coins to algo-log. I definitely need to look into the existing watchdog code, as it seems that avoiding crashes is nearly impossible. I'm not even overclocking my cards, except for one algo (daggerhashimoto) where the GPU is underclocked and the memory is overclocked. It seems that if a GPU is going to hang, it nearly always does so right after an algo switch. If it doesn't hang then, it'll most likely run indefinitely. |
|
|
|
With this fix in place, most miners respond well to the switch...except the Pascal miner. It takes its time responding to SIGTERM, and there's a higher likelihood of a GPU still falling off the bus, locking up, or whatever, necessitating a reboot. Given that it's moving well into negative territory WRT profitability anyway (currently -$0.23 on my rig), I might just disable it and continue testing with the other miners.
So far, it's switched at least once without issue, as it's now running an equihash miner instead of a daggerhashimoto miner. If I can get through another 24 hours without having to reset the miner, I think we can call the current iteration good. Current profitability: neoscrypt: 0.00083226 BTC/day (1.95 USD/day)
lyra2rev2: 0.00033541 BTC/day (0.79 USD/day)
daggerhashimoto: 0.00145476 BTC/day (3.42 USD/day)
lbry: 0.00025065 BTC/day (0.59 USD/day)
equihash: 0.00157431 BTC/day (3.70 USD/day)
sia: 0.00019036 BTC/day (0.45 USD/day) |
|
|
|
I've done some testing with shell scripts that shows a way forward: stop the previous miner, stop X, unload the nVidia driver, reload the driver, restart X, and start the next miner. This puts the GPUs back to a known-good state before getting back to mining. I've switched back and forth between a known-troublesome pair of miners, and it hasn't failed yet. I'm going to put these changes into the switcher next and see how it goes.
This part seems to be working well, but now I'm running into a problem where ccminer (used by several algos) doesn't want to start within a screen session. It works fine if started at the command line by itself. It works fine inside an already-running screen session. It falls on its face when the invocation is preceded by "screen -dmS miner": /home/m1/SPccminer/ccminer: error while loading shared libraries: libcudart.so.8.0: cannot open shared object file: No such file or directorylibcudart.so.8.0 is in /usr/local/cuda-8.0/lib64. There appears to be something different in the environment when screen is starting up vs. the rest of the time. Here's a quick hack which fixes it, but I suspect this really shouldn't be necessary: sudo ln -s /usr/local/cuda-8.0/lib64/libcudart.so.8.0 /usr/lib/ With this fix in place, most miners respond well to the switch...except the Pascal miner. It takes its time responding to SIGTERM, and there's a higher likelihood of a GPU still falling off the bus, locking up, or whatever, necessitating a reboot. Given that it's moving well into negative territory WRT profitability anyway (currently -$0.23 on my rig), I might just disable it and continue testing with the other miners. |
|
|
|
I think I've figured out why my profitability switcher was having problems with some coins. I noticed it when I tried switching my rig from Genoil back to Claymore (I'm having trouble getting Genoil to run for more than 24 hours without crashing)...the script would run, and I'd end up with two or more instances of the Claymore miner running.
pgrep and pkill, when called with the -f option (to look at the whole command line), need to have "+" escaped for some reason...most likely the pattern is processed as a regular expression and not a simple string. Any miner command string that included "stratum+tcp" (that's basically all of them except the equihash and Genoil daggerhashimoto miners) thus wasn't searchable or killable.
I've committed a fix that should take care of that. It also prepends the search string with "^" to match on the miner process itself, not the screen process that spawned it. (Killing the miner will automatically kill the parent screen process.)
Please test and ensure with confidence; that it is rock solid: then I will integrate these changes. It would be helpful if you did so with the integrated oneBash + switch version I made (swap the relevant part of switch with your updated code); so I can be sure it works as intended. The script looks like it's stopping and starting miners properly, but that has only caused another problem to surface: GPUs start crashing on the switch, and the only way to reboot is either SysRq-B or the reset switch. I've had this problem in the past with my other switchers; if I had to guess, some miners leave the GPU in a state that other miners don't expect when they start up. I've done some testing with shell scripts that shows a way forward: stop the previous miner, stop X, unload the nVidia driver, reload the driver, restart X, and start the next miner. This puts the GPUs back to a known-good state before getting back to mining. I've switched back and forth between a known-troublesome pair of miners, and it hasn't failed yet. I'm going to put these changes into the switcher next and see how it goes. |
|
|
|
|
I think I've figured out why my profitability switcher was having problems with some coins. I noticed it when I tried switching my rig from Genoil back to Claymore (I'm having trouble getting Genoil to run for more than 24 hours without crashing)...the script would run, and I'd end up with two or more instances of the Claymore miner running.
pgrep and pkill, when called with the -f option (to look at the whole command line), need to have "+" escaped for some reason...most likely the pattern is processed as a regular expression and not a simple string. Any miner command string that included "stratum+tcp" (that's basically all of them except the equihash and Genoil daggerhashimoto miners) thus wasn't searchable or killable.
I've committed a fix that should take care of that. It also prepends the search string with "^" to match on the miner process itself, not the screen process that spawned it. (Killing the miner will automatically kill the parent screen process.)
|
|
|
|
so, i might have a problem!
using the latest version and today, before i leave to work i had 17,5 BRL(my country currency), but, now, i've logged remotely to my pc at home and had just 0,50 BRL!
A few things to consider: Last payment was 4th of July and the next was supposed to be 25th!
I wasn't expecting another payment until next Tuesday, but one came through this morning at less than the usual minimum: https://blockchain.info/tx/c3e7b8d8d8148813fe2a3f9dbbad38dbc12548b30c125ac41672c086a40025a9I'm seeing lots of payouts under BTC0.01 in there, not just mine. Anyone know what triggered it? Is it the once-every-4-weeks payout of balances over BTC0.001? |
|
|
|
On a 4 x 1060 rig I use 1.1GB of RAM. On a 6 x 1060 rig I use 1.3GB of RAM. Unless there are spikes of memory usage or a memory leak somewhere, I don't see why 4GB would be more than enough. It certainly shouldn't have any effect on Genoil stability. Genoil seems to give comparable/better hash rates even with lower clocks and power limits than Claymore requires. I've found that dropping the clocks has definitely increased stability without reducing hash rate.
I have two 1070s, and since switching from Claymore to Genoil a few days ago, I've had two or three instances where the rig has crashed on me. My overclock settings had been -200 for GPU and +1200 for memory, which had been stable with Claymore. I've dropped the memory overclock back to +1000; hopefully the crashes will stop. Even with the reduced setting, though, I'm still seeing an extra 2-3 MH/s with Genoil that Claymore wasn't delivering...and that's before you factor in the lack of a fee for the miner. |
|
|
|
Any idea why when i try to SSH into nvOC as root with miner1 as my password i get "Permission denied" but as m1 it works?
EDIT: nevermind figured it out, my linux knowledge is very limited so i wasn't aware i can jump into root with "sudo su", anyhow after that "sudo echo b > /proc/sysrq-trigger" did manage to restart the rig.
Password-based root login is disabled for security reasons. You can either log in as a normal user and use sudo to get root (as you did) or use public-key authentication to log into root directly. |
|
|
|
m1-desktop kernel: [105577.938217] pcieport 0000:00:1b.0: [ 0] Receiver Error (First)
m1-desktop kernel: [105577.949736] pcieport 0000:00:1b.0: AER: Corrected error received: id=00d8
m1-desktop kernel: [105577.949750] pcieport 0000:00:1b.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=00d8(Receiver ID)
m1-desktop kernel: [105577.949757] pcieport 0000:00:1b.0: device [8086:a2eb] error status/mask=00000001/00002000
no idea what those mean
Those look like the errors I was getting with some crappy PCIe extenders I had recently ordered. Here's a closeup of the inadequate soldering on the bit that goes in the slot; the other end of the riser is probably similar. Click for the full-res original:  I'll be sending these back. There were no reviews when I bought them, but since then someone else has left a 1-star review. I've bought these as replacements, at fullzero's recommendation. |
|
|
|
So my rig crashed again, it was up for about 19 hours with the current settings. The previous it crashed I had not been able to see it crash, I just knew it because the screen was blank and the fans on the gpus went up to 100 percent. This time I was siting in front of it doing something else when the screen went blank and the fans kicked up to 100 percent. My question is if there is some kind of log that could be looked at to see what caused the crash or can one be enabled that only keeps the last one hour of activity?
ssh in and look at the tail end of /var/log/dmesg. I have some crappy PCIe extenders here that would interrupt the connection between the GPU and the computer as soon as mining software fired up. The errors show up toward the end of /var/log/dmesg. There's also /var/log/messages, but that tends to be less useful for hardware errors. |
|
|
|
|
Show Posts
