[OS] nvOC easy-to-use Linux Nvidia Mining

[TheCoinMine]

So new build, similar problem to the first rig I built myself. Getting the never ending "bootloop" when I fire up my mobo with everything plugged in. I know everyone says to unplug everything and try it one part at a time, which i will indeed do, but I was wondering if anyone else had this issue and found a more uniform way to fix it? Last time it was because my RAM was loose. This time my connections are all secure.

Background: building a trio rig with 2 1080ti and a 1080 mini using a 270 mobo with 850w psu. First mobo I used for this build didn't work at all. This one fires up but then goes into the endless loop. I have tried a different psu and a different RAM as well as different GPU. Leaning towards it being a faulty cpu but curious to see if anyone else has any other suggestions before I dismantle everything.

CPUs are almost never bad; sometimes you can have a bent mobo pin that causes CPU related problems.  However, I don't think that is the case here.

Maybe this will work:

Ensure the monitor is connected to the primary GPU ( the one in the 16x slot closest to the CPU )

Disconnect the USB or SSD/HHD from the rig.

Fully power off everything: including the PSU.

Press the power button several times to clear any remaining power in the mobo.

Turn the PSU powerswitch back to | "on".

power on (without the USB attached)

See if the bios posts; if you get nothing in 20 seconds; press ctrl + alt + del repeatedly until the system reboots.

Wait and see if the bios posts.

If the bios posts attach the USB key and press ctrl + alt + delete.

Let me know if this works.

Thanks a ton, will give it a shot. And if this doesn't work? Just break everything?

[fullzero]

Hey everyone, new here and new to mining too!! and really enjoying the experience. My roommate taught me into mining and we started upgrading my gaming rig to mining too (running claymore on windows 7 with 1x Asus Rog Strix 1080 OC and 2x Asus Rog Strix 1070 OC) but now we're going to build each a rig of our own and we bought the same components. (excepted of 1 gpu)

Here is what our build are going to be ;

Motherboard : AsRock H81 PRO BTC R2.0
Processor : Intel Celeron G1840 Haswell Dual Core 2.8ghz LGA 1150
GPU 3x Asus ROG Strix GeForce GTX 1070 8Gb Gaming OC 1632MHz base/1860MHz 
Ram : G.Skill 4Gb (2x2Gb) DDR3 PC3-12800 1600Mhz NQ series Dual Channel
Psu : EVGA SuperNova 1000w P2 (Platinum) ECO
Drive : KingSpec 32GB Sata II 2.0 SSD
Risers : USB PCie 1x-16x

So basiclly this is the rig except one of them will have 2x 1070 rog strix oc and have 1x Asus Gtx 1070 Dual OC.

I also would like to specify that we would like to upgrade to 6 Gpu per rig..

I read thorough the first post and I was wondering if there is a step by step tutorial for setting up everything or we just go by our knowledge. My friend is familiar with linux but I'm not and I think learning is the best way to live so I'm ready to step in and I really want to get involved into this community!

And also if you have any recommendation towards our builds!

Thanks!

I recommend using 8gb of ram, and ensuring the risers you get are the new pcie 6 pin powered type.  I think some members are working on build guides.  Phil has made some guides that are linked on the OP.

[fullzero]

So new build, similar problem to the first rig I built myself. Getting the never ending "bootloop" when I fire up my mobo with everything plugged in. I know everyone says to unplug everything and try it one part at a time, which i will indeed do, but I was wondering if anyone else had this issue and found a more uniform way to fix it? Last time it was because my RAM was loose. This time my connections are all secure.

Background: building a trio rig with 2 1080ti and a 1080 mini using a 270 mobo with 850w psu. First mobo I used for this build didn't work at all. This one fires up but then goes into the endless loop. I have tried a different psu and a different RAM as well as different GPU. Leaning towards it being a faulty cpu but curious to see if anyone else has any other suggestions before I dismantle everything.

CPUs are almost never bad; sometimes you can have a bent mobo pin that causes CPU related problems.  However, I don't think that is the case here.

Maybe this will work:

Ensure the monitor is connected to the primary GPU ( the one in the 16x slot closest to the CPU )

Disconnect the USB or SSD/HHD from the rig.

Fully power off everything: including the PSU.

Press the power button several times to clear any remaining power in the mobo.

Turn the PSU powerswitch back to | "on".

power on (without the USB attached)

See if the bios posts; if you get nothing in 20 seconds; press ctrl + alt + del repeatedly until the system reboots.

Wait and see if the bios posts.

If the bios posts attach the USB key and press ctrl + alt + delete.

Let me know if this works.

Thanks a ton, will give it a shot. And if this doesn't work? Just break everything?

If this doesn't work I would try reimaging the USB key. (first ensure your downloaded zip produces the correct hash)

What kind of USB key are you using btw?

[salfter]

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.

[DJ ACK]

Good day!  Does anyone know of a good way to identify which PCI Lane is assigned to each physical PCI slot.  Scanning system logs, System Info, etc. it is easy to correlate which PCI lane, GPU #, GPU serial number, etc. fell off the bus.  But is there a way to correlate PCI Lane to actual PCI slot?  Short of me logging the GPU serial number as I add each card to the board, It would be nice if there was a one stop shop to display GPU PCI slot information.  

I don't believe that they are assigned sequentially during system boot up because I have seen lane assignments go from 1, 2, 5, 6, 7, 8.   It would really help in troubleshooting riser problems if physical slot assignment was easily found.  

I have learned over the years that riser board version type really does not matter (even though I have seen several posts that claim v6 is better, v7 is better, C vs. S, etc.).   It all depends on where each lot is manufactured and if they had any kind of quality assurance check prior to shipment.  Heck I have an allotment of v1s from the BTC mining days that still work great.  Some riser boards work fine if the card is not overclocked too high.  But it is never the same across the board.    

Whether the risers are purchased from eBay, Newegg, Amazon, Craig's List, etc., it all seems to be a crap shoot.  And returning products across the ocean is real pain in the a$$.  My recommendation is find one vendor that has not failed you and stick with them (regardless of the wait time)...and order EXTRAS!  Does anyone know of a US, UK or Asia based reliable vendor?      

Just some food for thought from an extremely happy nvOC user.

[dspx]

Good day!  Does anyone know of a good way to identify which PCI Lane is assigned to each physical PCI slot.  Scanning system logs, System Info, etc. it is easy to correlate which PCI lane, GPU #, GPU serial number, etc. fell off the bus.  But is there a way to correlate PCI Lane to actual PCI slot?  Short of me logging the GPU serial number as I add each card to the board, It would be nice if there was a one stop shop to display GPU PCI slot information.  

I don't believe that they are assigned sequentially during system boot up because I have seen lane assignments go from 1, 2, 5, 6, 7, 8.   It would really help in troubleshooting riser problems if physical slot assignment was easily found.  

I have learned over the years that riser board version type really does not matter (even though I have seen several posts that claim v6 is better, v7 is better, C vs. S, etc.).   It all depends on where each lot is manufactured and if they had any kind of quality assurance check prior to shipment.  Heck I have an allotment of v1s from the BTC mining days that still work great.  Some riser boards work fine if the card is not overclocked too high.  But it is never the same across the board.    

Whether the risers are purchased from eBay, Newegg, Amazon, Craig's List, etc., it all seems to be a crap shoot.  And returning products across the ocean is real pain in the a$$.  My recommendation is find one vendor that has not failed you and stick with them (regardless of the wait time)...and order EXTRAS!  Does anyone know of a US, UK or Asia based reliable vendor?      

Just some food for thought from an extremely happy nvOC user.

I identified them by setting all fans to 0 and popping them up to 100 one at a time.

[weareken]

Is anybody else experiencing nvOC hang / lockup to the point of needing a hard powerdown when Genoil crashes?  I can log in but when I try to close the miner and shutdown the OS becomes locked up. I am wondering if it is hardware related?  I am only using 4GB of ddr4 is that enough???  I believe I will be going back to Claymore.  I can't seem to get Genoil stable even dialed 300mc back from Claymore.  I will reimage a USB stick and go back to Claymore to see if stability comes back. 

Having more ram would probably help; I use 8gb on most of my rigs and I have achieved multi day stability with the ones that are using genoil by previously lowing the clocks / adjusting the powerlimits whenever a soft crash occurred.

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.

[salfter]

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.

[min3333r]

What PCIe slots do you have them plugged into?

Tried changing all the slots because there are 3 cards, tried using 123, 456, 124, 235 etc.

Looking at your MB manual I would recommend slotting the GPUs into PCIX16, PCIEX4_1, PCIEX4_2 (from top to bottom slots 2, 4, 6) Also make sure the monitor is plugged into slot 2 or PCIEX16.

If it still isn't working may need to change some settings such as changing it all to Gen 2 or Gen 1 in the BIOS.

Thanks, changing slots to 1-3-6 did help for 1 GPU, going to return one GPU as it seems broken or at lease it seems that BIOS is corrupted.

[min3333r]

This line means there is a problem with the bios (rom) on one of the GPUs:

Code:

WARNING: infoROM is corrupted at gpu 0000:07:00.0

I would return this GPU or RMA it.

You could try re flashing its rom with NVFlash; but if this doesn't work it will most likely void your warranty; so if the GPUs are new I would go the other route.

For fan speed, try setting:

Code:

SLOW_USB_KEY_MODE="YES" 

let me know if that works.

Also what kind of USB / SSD are you using?

Heya, thanks for the reply.

About to return the GPU, it's brand new bought couple of days ago. Not going to reflash it or anything not to void warranty, thanks for the tip.

About the fan speed.

Code:

m1@rig1:~$ export DISPLAY=
m1@rig1:~$ echo $DISPLAY
m1@rig1:~$ nvidia-settings -a [fan:0]/GPUTargetFanSpeed=75
Failed to connect to Mir: Failed to connect to server socket: No such file or directory
Unable to init server: Could not connect: Connection refused

ERROR: The control display is undefined; please run `nvidia-settings --help` for usage information.
m1@rig1:~$ cat Desktop/oneBash | grep 'SLOW_USB_KEY_MODE='
SLOW_USB_KEY_MODE="YES"         # YES NO
m1@rig1:~$ export DISPLAY=:0.0
m1@rig1:~$ xrandr
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 1024 x 768, current 1024 x 768, maximum 1024 x 768
default connected 1024x768+0+0 0mm x 0mm
   1024x768       0.00* 
m1@rig1:~$ echo $DISPLAY
:0.0
m1@rig1:~$ nvidia-settings -a [fan:0]/GPUTargetFanSpeed=75

** (nvidia-settings:5815): WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

ERROR: Error querying enabled displays on GPU 0 (Missing Extension).


ERROR: Error querying connected displays on GPU 0 (Missing Extension).



ERROR: Error resolving target specification 'fan:0' (No targets match target specification), specified in assignment '[fan:0]/GPUTargetFanSpeed=75'.

xorg.conf

Code:

# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 378.13  (buildmeister@swio-display-x86-rhel47-05)  Tue Feb  7 19:37:00 PST 2017


Section "ServerLayout"
    Identifier     "layout"
    Screen      0  "nvidia" 0 0
    Inactive       "intel"
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
EndSection

Section "InputDevice"

    # generated from default
    Identifier     "Keyboard0"
    Driver         "keyboard"
EndSection

Section "InputDevice"

    # generated from default
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/psaux"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5"
EndSection

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Unknown"
    HorizSync       28.0 - 33.0
    VertRefresh     43.0 - 72.0
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "intel"
    Driver         "modesetting"
    Option         "AccelMethod" "None"
    BusID          "PCI:0@0:2:0"
EndSection

Section "Device"
    Identifier     "nvidia"
    Driver         "nvidia"
    BusID          "PCI:1@0:0:0"
EndSection

Section "Device"
    Identifier     "nvidia"
    Driver         "nvidia"
    Option         "ConstrainCursor" "off"
    BusID          "PCI:4@0:0:0"
EndSection

Section "Device"
    Identifier     "nvidia"
    Driver         "nvidia"
    Option         "ConstrainCursor" "off"
    BusID          "PCI:7@0:0:0"
EndSection

Section "Device"
    Identifier     "nvidia"
    Driver         "nvidia"
    Option         "ConstrainCursor" "off"
    BusID          "PCI:8@0:0:0"
EndSection

Section "Device"
    Identifier     "nvidia"
    Driver         "nvidia"
    Option         "ConstrainCursor" "off"
    BusID          "PCI:10@0:0:0"
EndSection

Section "Screen"
    Identifier     "intel"
    Device         "intel"
    Monitor        "Monitor0"
EndSection

Section "Screen"
    Identifier     "nvidia"
    Device         "nvidia"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "AllowEmptyInitialConfiguration" "on"
    Option         "IgnoreDisplayDevices" "CRT"
    Option         "ConstrainCursor" "off"
    Option         "Coolbits" "24"
    SubSection     "Display"
        Depth       24
        Modes      "nvidia-auto-select"
    EndSubSection
EndSection

Section "Screen"
    Identifier     "nvidia"
    Device         "nvidia"
    Monitor        "Monitor0"
    Option         "AllowEmptyInitialConfiguration" "on"
    Option         "IgnoreDisplayDevices" "CRT"
EndSection

Section "Screen"
    Identifier     "nvidia"
    Device         "nvidia"
    Monitor        "Monitor0"
    Option         "AllowEmptyInitialConfiguration" "on"
    Option         "IgnoreDisplayDevices" "CRT"
EndSection

Section "Screen"
    Identifier     "nvidia"
    Device         "nvidia"
    Monitor        "Monitor0"
    Option         "AllowEmptyInitialConfiguration" "on"
    Option         "IgnoreDisplayDevices" "CRT"
EndSection

Section "Screen"
    Identifier     "nvidia"
    Device         "nvidia"
    Monitor        "Monitor0"
    Option         "AllowEmptyInitialConfiguration" "on"
    Option         "IgnoreDisplayDevices" "CRT"
EndSection

Sandisk SSD 120GB, used dd to write the img to disk. Access to rigs only possible via SSH, no TV, no RDP (maybe VGA/HDMI if required).

When having a few rigs, easier to identify them like this than by IP (atleast in my case).

Code:

# hostname rig1
# echo "rig1" > /etc/hostname
# sed -i 's/m1-desktop/rig1/g' /etc/hosts
 then in oneBash
XXX_WORKER="$HOSTNAME"

Thanks for the help, i'll keep trying to fix the fanspeed thing

[gig410]

Question for the Linux gurus. So my problems were coming from bad risers, once I changed them out, the pci bus errors messages stopped. The messages were saying that error correction had occurred. I found that there is a way to suppress these messages in grub by using the "pci=nomsi" option. So once I enabled this option the operating system works (using Simplemining, about to try this on nvoc next) and the cards seem to work. So what is the danger/consequences of enabling this option and leaving it on? At least until I get a new batch of risers from China

thanks

[newmz]

Really looking forward to all the new features slated for nvOC 0018. I tried implementing the nicehash profit switching from @salfter but it was a little beyond my Linux skills.

Any idea when we might see it released?

[tempgoga]

Really looking forward to all the new features slated for nvOC 0018. I tried implementing the nicehash profit switching from @salfter but it was a little beyond my Linux skills.

Any idea when we might see it released?

i'm actually dreading the 0018 release... i've made so many changes to the 0017 oneBash and nvOC in general that moving them to the new version is gonna take forever.. currently working on automatic rig reboot in the event of a system freeze from the miner crashing.

[OverEasy]

Hi. I cannot get Genoil to work on NiceHash.
Been trying for about an hour and finally gave up

After Genoil starts I immediately get an error about invalid argument and then it shows my BTC address.

I made a million changes to the oneBash line concerning NICE_ETHASH. Here is my latest (NOT WORKING)
My assumption is that this version of Genoil is not compatible with NH (I read somewhere NH made their own fork)
If I am wrong (hope so) please assist
Thanks

# NICE autoconverts to BTC: ensure you update BTC_ADDRESS if you use NICE
NICE_ETHASH_WORKER="nv$IP_AS_WORKER"
NICE_POOL="stratum+tcp://daggerhashimoto.usa.nicehash.com:3353"
GENOIL_NICE_POOL="daggerhashimoto.usa.nicehash.com:3353"
NICE_EXTENTION_ARGUMENTS="" 

if [ $COIN == "NICE_ETHASH" ]
then
 
if [ $GENOILorCLAYMORE == "GENOIL" ]
then
HCD='/home/m1/eth/Genoil-U/ethminer'
 
NICEADDR="$BTC_ADDRESS"
WORKER="$NICE_ETHASH_WORKER"
until $HCD -SP 2 -U -S $GENOIL_NICE_ETHASH_POOL -O $NICEADDR.$WORKER:x
 
   do
   echo "FAILURE; reinit in 5" >&2
   sleep 5
done
fi

[IAmNotAJeep]

i'm actually dreading the 0018 release... i've made so many changes to the 0017 oneBash and nvOC in general that moving them to the new version is gonna take forever.. currently working on automatic rig reboot in the event of a system freeze from the miner crashing.

@ tempgoga - I'm curious on your approach, this is next on my plate (without a remote power switch) the easiest  - that seems applicable to my setup - is to filter the Genoil watchdog script for a reduced hash rate threshold instead of just 'error' since that script filters stdout from Genoil so technically the info is there to capture already.
I haven't gotten around to this yet but I'm hoping this weekend.

Another idea that I'm thinking of is some sort of port-knocking from a remote machine - it could be enough since the rigs usually are responsive to ssh or local scripts after they "soft crash" with the video cards - but this won't help in case of a complete freeze.
Then you need a remote power cycle ability which is a whole different level of infra.

Cheers!

[TheCoinMine]

So new build, similar problem to the first rig I built myself. Getting the never ending "bootloop" when I fire up my mobo with everything plugged in. I know everyone says to unplug everything and try it one part at a time, which i will indeed do, but I was wondering if anyone else had this issue and found a more uniform way to fix it? Last time it was because my RAM was loose. This time my connections are all secure.

Background: building a trio rig with 2 1080ti and a 1080 mini using a 270 mobo with 850w psu. First mobo I used for this build didn't work at all. This one fires up but then goes into the endless loop. I have tried a different psu and a different RAM as well as different GPU. Leaning towards it being a faulty cpu but curious to see if anyone else has any other suggestions before I dismantle everything.

CPUs are almost never bad; sometimes you can have a bent mobo pin that causes CPU related problems.  However, I don't think that is the case here.

Maybe this will work:

Ensure the monitor is connected to the primary GPU ( the one in the 16x slot closest to the CPU )

Disconnect the USB or SSD/HHD from the rig.

Fully power off everything: including the PSU.

Press the power button several times to clear any remaining power in the mobo.

Turn the PSU powerswitch back to | "on".

power on (without the USB attached)

See if the bios posts; if you get nothing in 20 seconds; press ctrl + alt + del repeatedly until the system reboots.

Wait and see if the bios posts.

If the bios posts attach the USB key and press ctrl + alt + delete.

Let me know if this works.

Thanks a ton, will give it a shot. And if this doesn't work? Just break everything?

If this doesn't work I would try reimaging the USB key. (first ensure your downloaded zip produces the correct hash)

What kind of USB key are you using btw?

I've tried using the one that is on my working rig (same exact setup) and it didn't make a difference. Both USBs are Lexar JumpDrive S75 32GB

[fullzero]

I have had a lot of requests for this; so here is a new oneBash and modded switch file which implement full integration of SALFTER_NICEHASH_PROFIT_SWITCHING

see the OP for links:

Replace your current oneBash with the new one.

extract switch and move it to the:

Code:

 /home/m1

directory

(the one which opens when you click the Files icon on the left)

configure the following in oneBash

Code:

SALFTER_NICEHASH_PROFIT_SWITCHING="YES"

# LOCAL will attach the mining process to the guake terminal
# REMOTE will leave it unattached / ready for SSH 
LOCALorREMOTE="LOCAL"       # LOCAL  or  REMOTE

CURRENCY=USD
POWER_COST=0.10
MINIMUM_PROFIT=0.0
# this is salfters BTC address:
PAYMENT_ADDRESS=1TipsGocnz2N5qgAm9f7JLrsMqkb3oXe2
WORKER_NAME=nv$IP_AS_WORKER

daggerhashimoto_POWERLIMIT_WATTS=125
__daggerhashimoto_CORE_OVERCLOCK=100
daggerhashimoto_MEMORY_OVERCLOCK=100
_______daggerhashimoto_FAN_SPEED=75

equihash_POWERLIMIT_WATTS=125
__equihash_CORE_OVERCLOCK=100
equihash_MEMORY_OVERCLOCK=100
_______equihash_FAN_SPEED=75

neoscrypt_POWERLIMIT_WATTS=125
__neoscrypt_CORE_OVERCLOCK=100
neoscrypt_MEMORY_OVERCLOCK=100
_______neoscrypt_FAN_SPEED=75

lyra2rev2_POWERLIMIT_WATTS=125
__lyra2rev2_CORE_OVERCLOCK=100
lyra2rev2_MEMORY_OVERCLOCK=100
_______lyra2rev2_FAN_SPEED=75

lbry_POWERLIMIT_WATTS=125
__lbry_CORE_OVERCLOCK=100
lbry_MEMORY_OVERCLOCK=100
_______lbry_FAN_SPEED=75

pascal_POWERLIMIT_WATTS=125
__pascal_CORE_OVERCLOCK=100
pascal_MEMORY_OVERCLOCK=100
_______pascal_FAN_SPEED=75

remember to thank salfter if you use this 

[fullzero]

Good day!  Does anyone know of a good way to identify which PCI Lane is assigned to each physical PCI slot.  Scanning system logs, System Info, etc. it is easy to correlate which PCI lane, GPU #, GPU serial number, etc. fell off the bus.  But is there a way to correlate PCI Lane to actual PCI slot?  Short of me logging the GPU serial number as I add each card to the board, It would be nice if there was a one stop shop to display GPU PCI slot information.  

I don't believe that they are assigned sequentially during system boot up because I have seen lane assignments go from 1, 2, 5, 6, 7, 8.   It would really help in troubleshooting riser problems if physical slot assignment was easily found.  

I have learned over the years that riser board version type really does not matter (even though I have seen several posts that claim v6 is better, v7 is better, C vs. S, etc.).   It all depends on where each lot is manufactured and if they had any kind of quality assurance check prior to shipment.  Heck I have an allotment of v1s from the BTC mining days that still work great.  Some riser boards work fine if the card is not overclocked too high.  But it is never the same across the board.    

Whether the risers are purchased from eBay, Newegg, Amazon, Craig's List, etc., it all seems to be a crap shoot.  And returning products across the ocean is real pain in the a$$.  My recommendation is find one vendor that has not failed you and stick with them (regardless of the wait time)...and order EXTRAS!  Does anyone know of a US, UK or Asia based reliable vendor?      

Just some food for thought from an extremely happy nvOC user.

I identified them by setting all fans to 0 and popping them up to 100 one at a time.

This is a good method; I am going to start using it. 

[fullzero]

Is anybody else experiencing nvOC hang / lockup to the point of needing a hard powerdown when Genoil crashes?  I can log in but when I try to close the miner and shutdown the OS becomes locked up. I am wondering if it is hardware related?  I am only using 4GB of ddr4 is that enough???  I believe I will be going back to Claymore.  I can't seem to get Genoil stable even dialed 300mc back from Claymore.  I will reimage a USB stick and go back to Claymore to see if stability comes back. 

Having more ram would probably help; I use 8gb on most of my rigs and I have achieved multi day stability with the ones that are using genoil by previously lowing the clocks / adjusting the powerlimits whenever a soft crash occurred.

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.

With Ethash more ram up to 16gb will increase stability.  It is not that you need this much; but that: it will decrease your failure rate.  You can empirically verify this, but if you want to use 4gb of ram go ahead.  Using stable clocks and powerlimit will have a much larger impact on stability.  You can probably reach marginally higher levels of stability with more ram.

[fullzero]

This line means there is a problem with the bios (rom) on one of the GPUs:

Code:

WARNING: infoROM is corrupted at gpu 0000:07:00.0

I would return this GPU or RMA it.

You could try re flashing its rom with NVFlash; but if this doesn't work it will most likely void your warranty; so if the GPUs are new I would go the other route.

For fan speed, try setting:

Code:

SLOW_USB_KEY_MODE="YES" 

let me know if that works.

Also what kind of USB / SSD are you using?

Heya, thanks for the reply.

About to return the GPU, it's brand new bought couple of days ago. Not going to reflash it or anything not to void warranty, thanks for the tip.

About the fan speed.

Code:

m1@rig1:~$ export DISPLAY=
m1@rig1:~$ echo $DISPLAY
m1@rig1:~$ nvidia-settings -a [fan:0]/GPUTargetFanSpeed=75
Failed to connect to Mir: Failed to connect to server socket: No such file or directory
Unable to init server: Could not connect: Connection refused

ERROR: The control display is undefined; please run `nvidia-settings --help` for usage information.
m1@rig1:~$ cat Desktop/oneBash | grep 'SLOW_USB_KEY_MODE='
SLOW_USB_KEY_MODE="YES"         # YES NO
m1@rig1:~$ export DISPLAY=:0.0
m1@rig1:~$ xrandr
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 1024 x 768, current 1024 x 768, maximum 1024 x 768
default connected 1024x768+0+0 0mm x 0mm
   1024x768       0.00* 
m1@rig1:~$ echo $DISPLAY
:0.0
m1@rig1:~$ nvidia-settings -a [fan:0]/GPUTargetFanSpeed=75

** (nvidia-settings:5815): WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

ERROR: Error querying enabled displays on GPU 0 (Missing Extension).


ERROR: Error querying connected displays on GPU 0 (Missing Extension).



ERROR: Error resolving target specification 'fan:0' (No targets match target specification), specified in assignment '[fan:0]/GPUTargetFanSpeed=75'.

xorg.conf

Code:

# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 378.13  (buildmeister@swio-display-x86-rhel47-05)  Tue Feb  7 19:37:00 PST 2017


Section "ServerLayout"
    Identifier     "layout"
    Screen      0  "nvidia" 0 0
    Inactive       "intel"
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
EndSection

Section "InputDevice"

    # generated from default
    Identifier     "Keyboard0"
    Driver         "keyboard"
EndSection

Section "InputDevice"

    # generated from default
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/psaux"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5"
EndSection

Section "Monitor"
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Unknown"
    HorizSync       28.0 - 33.0
    VertRefresh     43.0 - 72.0
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "intel"
    Driver         "modesetting"
    Option         "AccelMethod" "None"
    BusID          "PCI:0@0:2:0"
EndSection

Section "Device"
    Identifier     "nvidia"
    Driver         "nvidia"
    BusID          "PCI:1@0:0:0"
EndSection

Section "Device"
    Identifier     "nvidia"
    Driver         "nvidia"
    Option         "ConstrainCursor" "off"
    BusID          "PCI:4@0:0:0"
EndSection

Section "Device"
    Identifier     "nvidia"
    Driver         "nvidia"
    Option         "ConstrainCursor" "off"
    BusID          "PCI:7@0:0:0"
EndSection

Section "Device"
    Identifier     "nvidia"
    Driver         "nvidia"
    Option         "ConstrainCursor" "off"
    BusID          "PCI:8@0:0:0"
EndSection

Section "Device"
    Identifier     "nvidia"
    Driver         "nvidia"
    Option         "ConstrainCursor" "off"
    BusID          "PCI:10@0:0:0"
EndSection

Section "Screen"
    Identifier     "intel"
    Device         "intel"
    Monitor        "Monitor0"
EndSection

Section "Screen"
    Identifier     "nvidia"
    Device         "nvidia"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "AllowEmptyInitialConfiguration" "on"
    Option         "IgnoreDisplayDevices" "CRT"
    Option         "ConstrainCursor" "off"
    Option         "Coolbits" "24"
    SubSection     "Display"
        Depth       24
        Modes      "nvidia-auto-select"
    EndSubSection
EndSection

Section "Screen"
    Identifier     "nvidia"
    Device         "nvidia"
    Monitor        "Monitor0"
    Option         "AllowEmptyInitialConfiguration" "on"
    Option         "IgnoreDisplayDevices" "CRT"
EndSection

Section "Screen"
    Identifier     "nvidia"
    Device         "nvidia"
    Monitor        "Monitor0"
    Option         "AllowEmptyInitialConfiguration" "on"
    Option         "IgnoreDisplayDevices" "CRT"
EndSection

Section "Screen"
    Identifier     "nvidia"
    Device         "nvidia"
    Monitor        "Monitor0"
    Option         "AllowEmptyInitialConfiguration" "on"
    Option         "IgnoreDisplayDevices" "CRT"
EndSection

Section "Screen"
    Identifier     "nvidia"
    Device         "nvidia"
    Monitor        "Monitor0"
    Option         "AllowEmptyInitialConfiguration" "on"
    Option         "IgnoreDisplayDevices" "CRT"
EndSection

Sandisk SSD 120GB, used dd to write the img to disk. Access to rigs only possible via SSH, no TV, no RDP (maybe VGA/HDMI if required).

When having a few rigs, easier to identify them like this than by IP (atleast in my case).

Code:

# hostname rig1
# echo "rig1" > /etc/hostname
# sed -i 's/m1-desktop/rig1/g' /etc/hosts
 then in oneBash
XXX_WORKER="$HOSTNAME"

Thanks for the help, i'll keep trying to fix the fanspeed thing

your xorg.conf is most likely the problem

I would try re imaging a USB; although depending on your version you might not need to: what version are you using?

Also I don't recommend using dd to image USBs or SSDs; use etcher for linux instead.