Bitcoin Forum
December 07, 2016, 06:46:35 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 [404] 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4821776 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
Lem
Member
**
Offline Offline

Activity: 78


View Profile
November 19, 2012, 11:04:35 AM
 #8061

It's part of my secret plan to make everyone move to stratum.

Ah, LOL, nice to know it. Smiley

--
Bye
1481136395
Hero Member
*
Offline Offline

Posts: 1481136395

View Profile Personal Message (Offline)

Ignore
1481136395
Reply with quote  #2

1481136395
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
derjanb
Newbie
*
Offline Offline

Activity: 24


View Profile
November 19, 2012, 11:05:42 AM
 #8062

New version - 2.9.4, 19th November 2012

First, thanks for your hard work! Smiley

I've updated my Ubuntu 12.04 x64 today and since the reboot cgminer 2.9.* creates coredumps. Sad Version 2.8.7 is working fine, 2.9.3 and 2.9.4 are not. The core dump is created randomly after 1 to 30 seconds after cgminer was started.

This is the gdb output:
Code:
Reading symbols from /home/user/hdd/bitcoin/cgminer-2.9.4-x86_64-built/cgminer...(no debugging symbols found)...done.
[New LWP 2833]
[New LWP 2797]
[New LWP 2800]
[New LWP 2795]
[New LWP 2822]
[New LWP 2791]
[New LWP 2799]
[New LWP 2789]
[New LWP 2790]
[New LWP 2798]
[New LWP 2796]
[New LWP 2804]
[New LWP 2793]
[New LWP 2802]
[New LWP 2792]
[New LWP 2803]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./cgminer -c ../cgminer.conf --gpu-engine 500-600 --temp-cutoff 85 --gpu-fan 45'.
Program terminated with signal 6, Aborted.
#0  0x00007f676e2d5425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007f676e2d5425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007f676e2d8b8b in __GI_abort () at abort.c:91
#2  0x00007f676e31339e in __libc_message (do_abort=2, fmt=0x7f676e41ae3f "*** %s ***: %s terminated\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:201
#3  0x00007f676e3a9807 in __GI___fortify_fail (msg=0x7f676e41add6 "buffer overflow detected") at fortify_fail.c:32
#4  0x00007f676e3a8700 in __GI___chk_fail () at chk_fail.c:29
#5  0x00007f676e3a7b69 in _IO_str_chk_overflow (fp=<optimized out>, c=<optimized out>) at vsprintf_chk.c:35
#6  0x00007f676e31b13d in _IO_default_xsputn (f=0x7f673affcba0, data=<optimized out>, n=2768) at genops.c:485
#7  0x00007f676e2e9f82 in _IO_vfprintf_internal (s=<optimized out>, format=<optimized out>, ap=<optimized out>) at vfprintf.c:1630
#8  0x00007f676e3a7c04 in ___vsprintf_chk (s=0x7f6720000b69 "0100000001", '0' <repeats 64 times>, "ffffffff4b03d52e030e00456c69676975730050aa0c473bfabe6d6dc7beb9a76e1f9fdf1bb3a777e1081161726d0f9318cf2a1237994e7c426d74a2080000"..., flags=1,
    slen=512, format=0x448ff2 "%s", args=0x7f673affccc8) at vsprintf_chk.c:86
#9  0x00007f676e3a7b4d in ___sprintf_chk (s=<optimized out>, flags=<optimized out>, slen=<optimized out>, format=<optimized out>) at sprintf_chk.c:33
#10 0x000000000040fc75 in ?? ()
#11 0x0000000000414e0b in ?? ()
#12 0x00007f676f3cbe9a in start_thread (arg=0x7f673affd700) at pthread_create.c:308
#13 0x00007f676e392cbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#14 0x0000000000000000 in ?? ()

Code:
./cgminer --ndevs
 [2012-11-19 12:02:57] CL Platform 0 vendor: Advanced Micro Devices, Inc.                   
 [2012-11-19 12:02:57] CL Platform 0 name: AMD Accelerated Parallel Processing                   
 [2012-11-19 12:02:57] CL Platform 0 version: OpenCL 1.2 AMD-APP (1016.4)                   
 [2012-11-19 12:02:57] Platform 0 devices: 1                   
 [2012-11-19 12:02:57]  0       Cypress                   
 [2012-11-19 12:02:57] GPU 0 ATI Radeon HD 5800 Series   hardware monitoring enabled                   
 [2012-11-19 12:02:57] 1 GPU devices max detected 

Just tell me if you need more info.

Do you want to get rid of all your bitcoins? This is the official trash address: 13vbLvM1Gb3fY5z15Mq1v1eCEjAxL8cPPs Smiley
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
November 19, 2012, 11:08:32 AM
 #8063

Thanks. Core dump or debugging output is not much help without debugging symbols. Either build with the debug symbols (add -g) or grab a debug build from
http://ck.kolivas.org/apps/cgminer/debug/

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
November 19, 2012, 11:14:30 AM
 #8064

Thank you, Kano and mdude77.

I know that failover-only would stop the leaking, however I've always used failover to get the highest efficiency, moreover when a new block is found and some pools are quicker than others.

The strange thing is that if I use failover-only, my Mh/s stay pretty the same in the middle of a block.

So even if cgminer thinks the primary pool is lagging (and so, with failover policy, it begins to collect a lot of work from elsewhere), this doesn't look to be true. If this were true, I think that with failover-only I should see my GPUs slow down from time to time, left with not enough work from my primary pool: but this doesn't happen.
It's not an exact science, and kicks in when it's below a threshold rather than waiting for it to fall to "not enough". It's an algorithm, and like all of them, it is prone to not being perfect. Local work generation via something like stratum makes this feature pretty much unnecessary.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Lem
Member
**
Offline Offline

Activity: 78


View Profile
November 19, 2012, 11:41:30 AM
 #8065

It's not an exact science, and kicks in when it's below a threshold rather than waiting for it to fall to "not enough". It's an algorithm, and like all of them, it is prone to not being perfect.

I understand. I just say that this algorithm worked better (for me, eh) in previous version, before 2.9.x.

BTW: is there a way for me to modify this threshold, maybe working on some cgminer parameters (queue, scantime, expiry...)?

Quote
Local work generation via something like stratum makes this feature pretty much unnecessary.

Were it to me, stratum would become the default... yesterday. Wink
But I think many little pools, and expecially the last "starving" prop pools - that are still there, though - won't rush to implement it. It's a pity.


--
Bye
derjanb
Newbie
*
Offline Offline

Activity: 24


View Profile
November 19, 2012, 11:54:02 AM
 #8066

Thanks. Core dump or debugging output is not much help without debugging symbols. Either build with the debug symbols (add -g) or grab a debug build from
http://ck.kolivas.org/apps/cgminer/debug/

Done. Smiley

Code:
Reading symbols from /home/user/hdd/bitcoin/cgminer-2.9.4-x86_64-built/cgminer...done.
[New LWP 27740]
[New LWP 23114]
[New LWP 23132]
[New LWP 23099]
[New LWP 22458]
[New LWP 23138]
[New LWP 22756]
[New LWP 23135]
[New LWP 24650]
[New LWP 23134]
[New LWP 23133]
[New LWP 23113]
[New LWP 27743]
[New LWP 22757]
[New LWP 25467]
[New LWP 23100]
[New LWP 26811]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./cgminer -c ../cgminer.conf --gpu-engine 500-600 --temp-cutoff 85 --gpu-fan 45'.
Program terminated with signal 6, Aborted.
#0  0x00007fa5177ac425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007fa5177ac425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007fa5177afb8b in __GI_abort () at abort.c:91
#2  0x00007fa5177ea39e in __libc_message (do_abort=2, fmt=0x7fa5178f1e3f "*** %s ***: %s terminated\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:201
#3  0x00007fa517880807 in __GI___fortify_fail (msg=0x7fa5178f1dd6 "buffer overflow detected") at fortify_fail.c:32
#4  0x00007fa51787f700 in __GI___chk_fail () at chk_fail.c:29
#5  0x00007fa51787eb69 in _IO_str_chk_overflow (fp=<optimized out>, c=<optimized out>) at vsprintf_chk.c:35
#6  0x00007fa5177f213d in _IO_default_xsputn (f=0x7fa4f4ff8ba0, data=<optimized out>, n=2906) at genops.c:485
#7  0x00007fa5177c0f82 in _IO_vfprintf_internal (s=<optimized out>, format=<optimized out>, ap=<optimized out>) at vfprintf.c:1630
#8  0x00007fa51787ec04 in ___vsprintf_chk (s=0x7fa4cc0020e9 "0100000001", '0' <repeats 64 times>, "ffffffff4c03d92e030f00456c69676975730050aa1ca20488fabe6d6d5ac523f49912c85158966f09972f3689830ac7371984a4d0e71335bb878f56b90800"..., flags=1,
    slen=512, format=0x448ff2 "%s", args=0x7fa4f4ff8cc8) at vsprintf_chk.c:86
#9  0x00007fa51787eb4d in ___sprintf_chk (s=<optimized out>, flags=<optimized out>, slen=<optimized out>, format=<optimized out>) at sprintf_chk.c:33
#10 0x000000000040fc75 in sprintf (__fmt=0x448ff2 "%s", __s=0x7fa4cc0020e9 "0100000001", '0' <repeats 64 times>, "ffffffff4c03d92e030f00456c69676975730050aa1ca20488fabe6d6d5ac523f49912c85158966f09972f3689830ac7371984a4d0e71335bb878f56b90800"...)
    at /usr/include/x86_64-linux-gnu/bits/stdio2.h:34
#11 gen_gbt_work (pool=0x10ec310, work=0x7fa4cc001e40) at cgminer.c:1487
#12 0x0000000000414e0b in get_work_thread (userdata=0x7fa50000a770) at cgminer.c:3066
#13 0x00007fa5188a2e9a in start_thread (arg=0x7fa4f4ff9700) at pthread_create.c:308
#14 0x00007fa517869cbd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#15 0x0000000000000000 in ?? ()

Do you want to get rid of all your bitcoins? This is the official trash address: 13vbLvM1Gb3fY5z15Mq1v1eCEjAxL8cPPs Smiley
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
November 19, 2012, 12:01:30 PM
 #8067

First, thanks for your hard work! Smiley

I've updated my Ubuntu 12.04 x64 today and since the reboot cgminer 2.9.* creates coredumps. Sad Version 2.8.7 is working fine, 2.9.3 and 2.9.4 are not. The core dump is created randomly after 1 to 30 seconds after cgminer was started.

This is the gdb output:
May be the same problem than the one I reported on IRC (and started for me at 8AM GMT today), if it is, adding --fix-protocol should be a temporary fix (it disables the switch to GBT protocol).

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
Subo1977
Sr. Member
****
Offline Offline

Activity: 345


View Profile
November 19, 2012, 12:02:41 PM
 #8068

The 2.9.3 runs the last day's without problems.

since this morning i have a problem with cgminer 2.9.3 and 2.9.4 on Windows and Linux.

on these pool's its ok. : eclipsemc, and Eligius.
after switching  or starting to p2pool the cgminer crashs after a few seconds.

after reverting to 2.8.7 already is ok.

I provide a 1000Mbit+ Torrent-Seedbox in FR and a 500Mbit Box in NL for orginal Blockchain Bootstrap.dat download. and also for Armoryclient Torrent

Tips are welcome:  15MuGdPSXU62fEFE9XbBZN3UvJMHBDVBoy
derjanb
Newbie
*
Offline Offline

Activity: 24


View Profile
November 19, 2012, 12:11:35 PM
 #8069

First, thanks for your hard work! Smiley

I've updated my Ubuntu 12.04 x64 today and since the reboot cgminer 2.9.* creates coredumps. Sad Version 2.8.7 is working fine, 2.9.3 and 2.9.4 are not. The core dump is created randomly after 1 to 30 seconds after cgminer was started.

This is the gdb output:
May be the same problem than the one I reported on IRC (and started for me at 8AM GMT today), if it is, adding --fix-protocol should be a temporary fix (it disables the switch to GBT protocol).

You're right "--fix-protocol" fixes cgminer too. Wink Funny thing, cause 2.9.3 was working fine the last 3 days.

Do you want to get rid of all your bitcoins? This is the official trash address: 13vbLvM1Gb3fY5z15Mq1v1eCEjAxL8cPPs Smiley
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
November 19, 2012, 12:23:46 PM
 #8070

You're right "--fix-protocol" fixes cgminer too. Wink Funny thing, cause 2.9.3 was working fine the last 3 days.
I use p2pool, but apparently Bitminter and Eligius (which both use GBT) in my backup pools can trigger the bug since this morning even if they aren't used.
Posted a backtrace to #cgminer, hopefully it will help debug the problem.

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
rav3n_pl
Legendary
*
Offline Offline

Activity: 1320


Don`t panic! Organize!


View Profile
November 19, 2012, 01:09:10 PM
 #8071

You're right "--fix-protocol" fixes cgminer too. Wink Funny thing, cause 2.9.3 was working fine the last 3 days.
I use p2pool, but apparently Bitminter and Eligius (which both use GBT) in my backup pools can trigger the bug since this morning even if they aren't used.
Posted a backtrace to #cgminer, hopefully it will help debug the problem.
If you mine in p2pool use another p2pool node as backup. There is few public nodes open for everyone.

1Rav3nkMayCijuhzcYemMiPYsvcaiwHni  Bitcoin stuff on my OneDrive
My RPC CoinControl for any coin https://bitcointalk.org/index.php?topic=929954
My SatoshDice bot https://bitcointalk.org/index.php?topic=897685
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
November 19, 2012, 01:32:27 PM
 #8072

You're right "--fix-protocol" fixes cgminer too. Wink Funny thing, cause 2.9.3 was working fine the last 3 days.
I use p2pool, but apparently Bitminter and Eligius (which both use GBT) in my backup pools can trigger the bug since this morning even if they aren't used.
Posted a backtrace to #cgminer, hopefully it will help debug the problem.
If you mine in p2pool use another p2pool node as backup. There is few public nodes open for everyone.
None of those (AFAIK) support decentralized mining, though. Nor is it really practical as GBT's bandwidth use is absurd with p2pool's 10 second blocks.
There's no reason to prefer p2pool over Eligius or Bitminter anyway, so long as you're decentralized mining.

kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
November 19, 2012, 02:28:09 PM
 #8073

You're right "--fix-protocol" fixes cgminer too. Wink Funny thing, cause 2.9.3 was working fine the last 3 days.
I use p2pool, but apparently Bitminter and Eligius (which both use GBT) in my backup pools can trigger the bug since this morning even if they aren't used.
Posted a backtrace to #cgminer, hopefully it will help debug the problem.
If you mine in p2pool use another p2pool node as backup. There is few public nodes open for everyone.
None of those (AFAIK) support decentralized mining, though. Nor is it really practical as GBT's bandwidth use is absurd with p2pool's 10 second blocks.
There's no reason to prefer p2pool over Eligius or Bitminter anyway, so long as you're decentralized mining.
FFSake can you stop with the FUD - Eligius and Bitminter are not decentralized - learn English, not whatever warped, deluded, zealot language you use.

There is a perfectly simple reason to use p2pool and not go anywhere near ANY centralised GBT pool like Eligius or Bitminter and that is the 2 orders of magnitude larger amount of data GBT transfers across the internet to your miner compared to the old getwork or new stratum pool protocol.
Even a bitcoin dev has said that the GBT data design is not designed for a WAN (or even a LAN)
Quote
The RPC protocol was never designed to minimize data transfer. It's meant for controlling a bitcoind instance on the localhost, in which case the amount of data is of no essence (hence the choice of JSON, too).
... as per my Issue I raised on the bitcoin code (where you sneaked in your botnet support into bitcoind/GBT)
https://github.com/bitcoin/bitcoin/issues/1985
I also do not understand why you supported botnets on Eligius and now added support of them into bitcoind that everyone now has in their bitcoind

Bitminter and Eligius ARE centralised - there is one place that controls all the work - the pool - just like every other non-p2pool pool does.
On Eligius GBT, the centralised pool decides what is valid work and what is not valid work.
On p2pool it is the p2peers that decide ... and if suddenly half the peers decide one type of work is valid and the other half decide a different type of work is valid, you will then get 2 p2pools running with 2 different sharechains
Be it half the miners or just one miner, the miner can keep mining no matter what it decides is valid - each sharechain is simply the list of p2pool miners that agree in it's contents ... and that is by definition decentralised.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Roy Badami
Hero Member
*****
Offline Offline

Activity: 562


View Profile
November 19, 2012, 10:34:53 PM
 #8074

It looks like stratum backup pools aren't detected as alive when specified with a stratum+tcp:// URL (though, strangely, they work fine if you put in an http:// URL pointing to the stratum port).

At least with EMC.

ETA, unless I don't understand what a stratum URL is supposed to look like.

With the default (failover) strategy, if I specify my pools as follows then only whichever pool I put first is detected as alive (and if that's down it *doesn't* failover).

stratum+tcp://us1.eclipsemc.com:3333
stratum+tcp://us2.eclipsemc.com:3333
stratum+tcp://us3.eclipsemc.com:3333

If I specify them as follows then it connects with stratum, detects all pools live, and failover seems to work:

http://us1.eclipsemc.com:3333
http://us2.eclipsemc.com:3333
http://us3.eclipsemc.com:3333

ETA again: Although to be fair some of the evidence that lead me to the above conclusion was collected from a version of git master HEAD somewhere between 2.9.3 and 2.9.4.  But I'm certainly seeing backup pools report as down in 2.9.4 - can't say for sure that failover is actually not working.
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
November 20, 2012, 01:01:31 AM
 #8075

alas, 2.9.4 crashed on me today on my windows 8 box while pointing to oz.  11 hours before I got home from my day job. Sad

I'm going to try --verbose and see if it stops doing that.

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
November 20, 2012, 06:36:00 AM
 #8076

alas, 2.9.4 crashed on me today on my windows 8 box while pointing to oz.  11 hours before I got home from my day job. Sad

I'm going to try --verbose and see if it stops doing that.

M
Did you have a GBT pool as a backup somewhere? I think there's a crash unique to pools that send GBT info. If so, --fix-protocol should prevent it, so you'll have to specify the stratum pools' urls/ports directly.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
November 20, 2012, 10:56:20 AM
 #8077

alas, 2.9.4 crashed on me today on my windows 8 box while pointing to oz.  11 hours before I got home from my day job. Sad

I'm going to try --verbose and see if it stops doing that.

M
Did you have a GBT pool as a backup somewhere? I think there's a crash unique to pools that send GBT info. If so, --fix-protocol should prevent it, so you'll have to specify the stratum pools' urls/ports directly.

I probably do.  I don't know which ones use GBT and which ones don't.

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
louisBSAS
Member
**
Offline Offline

Activity: 89



View Profile
November 20, 2012, 04:13:42 PM
 #8078

Quick question @ckolivas

Just flashed over to check that all miner are up - saw this...




What is "Harmful miner version detect" - using 2.6.1 on bitminter?

I run Linux 10.10, don't have any backup pools, don't usually upgrade anything, because my rigs just mine continuously with no problems.

Mining at : 12t4H9FdmimXvjMLPzgxCTs3Mwi7LWcnro
Bitmessage: BM-2D8F9QZnigjB3ovYUGwTSQWiubzhz6VmhD
juhakall
Sr. Member
****
Offline Offline

Activity: 422



View Profile
November 20, 2012, 04:50:32 PM
 #8079

What is "Harmful miner version detect" - using 2.6.1 on bitminter?

If you run a cgminer or bfgminer version below 2.7:
You are causing yourself and all other miners to lose transaction fee income on the blocks you make. You were causing slow server response and a high reject ratio, before these changes. You are getting work slower than others on the pool. You are probably getting more stales too. I know this isn't something you intended to do and you may not have been aware of it before. But you are running a very old miner version with some serious bugs in it. Upgrade today! Smiley
louisBSAS
Member
**
Offline Offline

Activity: 89



View Profile
November 20, 2012, 06:02:30 PM
 #8080


... But you are running a very old miner version with some serious bugs in it. Upgrade today! Smiley

Thanks for the info.  That machine is just an old MB with a card plugged in. I guess I need to drag a monitor over to it and upgrade it.  My other rigs are running 2.7.6 with no problems. My GPU days are numbered anyway...

Mining at : 12t4H9FdmimXvjMLPzgxCTs3Mwi7LWcnro
Bitmessage: BM-2D8F9QZnigjB3ovYUGwTSQWiubzhz6VmhD
Pages: « 1 ... 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 [404] 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 ... 830 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!