OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[K1773R]

after zeroing the stats i see this:

Code:

Block: 02401ea22d6ffac5...  Diff:2.98M  Started: [17:01:51]  Best share: 0   K

the K didnt got deleted and stays there forever.

[1713860481]

1713860481

[1713860481]

1713860481

[1713860481]

1713860481

[BitMinerN8]

I am having some issues compiling 2.10.4. I've been following the same steps to compile for months and can compile 2.9.7 and prior versions without issue, it's just 2.10.x versions. I think it might be a dependency, but I'm not that linux savy. I have run "apt-get update && apt-get upgrade" to make sure things are current. This is running on a Atom based Mini-ITX MB running Debian 6 with 7 BFLs. (Other than this new compile issue, it's been running great for 6 months)

I did read back around 15 pages to the point where 2.10.0 was released and did not see anyone having any issues with compiling. I also checked the README.txt and it looks like I have all the dependencies. If anyone can point me in the right direction, I'd appreciate it. Thank you.

Code:

CFLAGS="-g -O2 -W -Wall" ./autogen.sh --enable-bitforce --with-libudev

Returns the following:

Code:

------------------------------------------------------------------------
cgminer 2.10.4
------------------------------------------------------------------------

Configuration Options Summary:

  curses.TUI...........: FOUND: -lncurses
  OpenCL...............: NOT FOUND. GPU mining support DISABLED
  scrypt...............: Disabled (needs OpenCL)
  ADL..................: SDK NOT found, GPU monitoring support DISABLED

  BitForce.FPGAs.......: Enabled
  Icarus.FPGAs.........: Disabled
  ModMiner.FPGAs.......: Disabled
  Ztex.FPGAs...........: Disabled
  libudev.detection....: yes

Compilation............: make (or gmake)
  CPPFLAGS.............:
  CFLAGS...............: -g -O2 -W -Wall
  LDFLAGS..............:  -lpthread
  LDADD................:  -L/usr/lib -lcurl compat/jansson/libjansson.a -lpthread     -lm -ludev

Installation...........: make install (as root if needed, with 'su' or 'sudo')
  prefix...............: /usr/local

Looks OK, but then I get these errors when running "make": (I have tried make clean first as well)

Code:

make[2]: Leaving directory `/opt/miners/ckolivas-cgminer-b53372b/ccan'
make[2]: Entering directory `/opt/miners/ckolivas-cgminer-b53372b'
  CC     cgminer-cgminer.o
  CC     cgminer-util.o
util.c: In function âkeep_curlaliveâ:
util.c:207: error: âCURLOPT_TCP_KEEPALIVEâ undeclared (first use in this function)
util.c:207: error: (Each undeclared identifier is reported only once
util.c:207: error: for each function it appears in.)
util.c:207: warning: type defaults to âintâ in declaration of â_curl_optâ
util.c:208: error: âCURLOPT_TCP_KEEPIDLEâ undeclared (first use in this function)
util.c:208: warning: type defaults to âintâ in declaration of â_curl_optâ
util.c:209: error: âCURLOPT_TCP_KEEPINTVLâ undeclared (first use in this function)
util.c:209: warning: type defaults to âintâ in declaration of â_curl_optâ
make[2]: *** [cgminer-util.o] Error 1
make[2]: Leaving directory `/opt/miners/ckolivas-cgminer-b53372b'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/opt/miners/ckolivas-cgminer-b53372b'
make: *** [all] Error 2

[-ck]

I am having some issues compiling 2.10.4. I've been following the same steps to compile for months and can compile 2.9.7 and prior versions without issue, it's just 2.10.x versions. I think it might be a dependency, but I'm not that linux savy. I have run "apt-get update && apt-get upgrade" to make sure things are current. This is running on a Atom based Mini-ITX MB running Debian 6 with 7 BFLs. (Other than this new compile issue, it's been running great for 6 months)

I did read back around 15 pages to the point where 2.10.0 was released and did not see anyone having any issues with compiling. I also checked the README.txt and it looks like I have all the dependencies. If anyone can point me in the right direction, I'd appreciate it. Thank you.

Code:

CFLAGS="-g -O2 -W -Wall" ./autogen.sh --enable-bitforce --with-libudev

Returns the following:

Code:

  curses.TUI...........: FOUND: -lncurses

Looks OK, but then I get these errors when running "make": (I have tried make clean first as well)

Code:

util.c:207: error: âCURLOPT_TCP_KEEPALIVEâ undeclared (first use in this function)

That looks like your curl installation is a version that somehow should support CURLOPT_TCP_KEEPALIVE (version 7.25.0+) but then actually doesn't.

That should not happen since it is supposed to detect what version of curl you have installed and choose appropriate support. Perhaps you have only a partly installed or mixed installation of libcurl development libraries.

[BitMinerN8]

I am having some issues compiling 2.10.4. I've been following the same steps to compile for months and can compile 2.9.7 and prior versions without issue, it's just 2.10.x versions. I think it might be a dependency, but I'm not that linux savy. I have run "apt-get update && apt-get upgrade" to make sure things are current. This is running on a Atom based Mini-ITX MB running Debian 6 with 7 BFLs. (Other than this new compile issue, it's been running great for 6 months)

I did read back around 15 pages to the point where 2.10.0 was released and did not see anyone having any issues with compiling. I also checked the README.txt and it looks like I have all the dependencies. If anyone can point me in the right direction, I'd appreciate it. Thank you.

Code:

CFLAGS="-g -O2 -W -Wall" ./autogen.sh --enable-bitforce --with-libudev

Returns the following:

Code:

  curses.TUI...........: FOUND: -lncurses

Looks OK, but then I get these errors when running "make": (I have tried make clean first as well)

Code:

util.c:207: error: âCURLOPT_TCP_KEEPALIVEâ undeclared (first use in this function)

That looks like your curl installation is a version that somehow should support CURLOPT_TCP_KEEPALIVE (version 7.25.0+) but then actually doesn't.

That should not happen since it is supposed to detect what version of curl you have installed and choose appropriate support. Perhaps you have only a partly installed or mixed installation of libcurl development libraries.

I did an apt-get remove libcurl4-gnutls-dev && apt-get install libcurl4-gnutls-dev

Code:

Unpacking libcurl4-gnutls-dev (from .../libcurl4-gnutls-dev_7.21.0-2.1+squeeze2_i386.deb) ...
Processing triggers for man-db ...
Setting up libcurl4-gnutls-dev (7.21.0-2.1+squeeze2) ...

So is that the wrong version? (Still no love on the make clean / make) Any clue on how to get the 7.25.0+ version you speak of?
Thank you for your time.

[-ck]

I am having some issues compiling 2.10.4. I've been following the same steps to compile for months and can compile 2.9.7 and prior versions without issue, it's just 2.10.x versions. I think it might be a dependency, but I'm not that linux savy. I have run "apt-get update && apt-get upgrade" to make sure things are current. This is running on a Atom based Mini-ITX MB running Debian 6 with 7 BFLs. (Other than this new compile issue, it's been running great for 6 months)

I did read back around 15 pages to the point where 2.10.0 was released and did not see anyone having any issues with compiling. I also checked the README.txt and it looks like I have all the dependencies. If anyone can point me in the right direction, I'd appreciate it. Thank you.

Code:

CFLAGS="-g -O2 -W -Wall" ./autogen.sh --enable-bitforce --with-libudev

Returns the following:

Code:

  curses.TUI...........: FOUND: -lncurses

Looks OK, but then I get these errors when running "make": (I have tried make clean first as well)

Code:

util.c:207: error: âCURLOPT_TCP_KEEPALIVEâ undeclared (first use in this function)

That looks like your curl installation is a version that somehow should support CURLOPT_TCP_KEEPALIVE (version 7.25.0+) but then actually doesn't.

That should not happen since it is supposed to detect what version of curl you have installed and choose appropriate support. Perhaps you have only a partly installed or mixed installation of libcurl development libraries.

I did an apt-get remove libcurl4-gnutls-dev && apt-get install libcurl4-gnutls-dev

Code:

Unpacking libcurl4-gnutls-dev (from .../libcurl4-gnutls-dev_7.21.0-2.1+squeeze2_i386.deb) ...
Processing triggers for man-db ...
Setting up libcurl4-gnutls-dev (7.21.0-2.1+squeeze2) ...

So is that the wrong version? (Still no love on the make clean / make) Any clue on how to get the 7.25.0+ version you speak of?
Thank you for your time.

It's still supposed to work with older curls. Somewhere it is thinking you have a later version installed which you don't. Anyway I usually install libcurl4-openssl-dev

[allinvain]

Is anyone else having difficulties with the reliability of using a raspberry pi with cgminer (and bfgminer) to manage fpga miners (in my case bitforce and icarus). I've found that cgminer 2.10.4 gives out comm errors on bitforce miners (at random). Bfgminer has problems as well outlined in this thread: https://bitcointalk.org/index.php?topic=128789.msg1426976#msg1426976

The main point here is that I believe there is either some bug with cgminer (kinda doubt this) or some major problem with the raspberry itself (possibly USB driver issue? etc) or the wheezy debian distro. I'm using the distro put together by the OP on the thread I pasted above.

I'm sure someone else is also using a pi to manage their fpga miners, so I ask has anyone managed to get it to run reliably without any errors, restarts, etc.?

I've updated the firmware via rpi-update and updated the distro with apt-get update & apt-get upgrade & apt-get dist-upgrade. Problem with 2.10.4 of cgminer still persists.

[-ck]

Is anyone else having difficulties with the reliability of using a raspberry pi with cgminer (and bfgminer) to manage fpga miners (in my case bitforce and icarus). I've found that cgminer 2.10.4 gives out comm errors on bitforce miners (at random). Bfgminer has problems as well outlined in this thread: https://bitcointalk.org/index.php?topic=128789.msg1426976#msg1426976

The main point here is that I believe there is either some bug with cgminer (kinda doubt this) or some major problem with the raspberry itself (possibly USB driver issue? etc) or the wheezy debian distro. I'm using the distro put together by the OP on the thread I pasted above.

I'm sure someone else is also using a pi to manage their fpga miners, so I ask has anyone managed to get it to run reliably without any errors, restarts, etc.?

I've updated the firmware via rpi-update and updated the distro with apt-get update & apt-get upgrade & apt-get dist-upgrade. Problem with 2.10.4 of cgminer still persists.

The usb on rpi is known to be really flaky. The addition of a powered usb hub usually fixes most problems as it acts as a usb filter as well as running more usb devices better.

[allinvain]

Is anyone else having difficulties with the reliability of using a raspberry pi with cgminer (and bfgminer) to manage fpga miners (in my case bitforce and icarus). I've found that cgminer 2.10.4 gives out comm errors on bitforce miners (at random). Bfgminer has problems as well outlined in this thread: https://bitcointalk.org/index.php?topic=128789.msg1426976#msg1426976

The main point here is that I believe there is either some bug with cgminer (kinda doubt this) or some major problem with the raspberry itself (possibly USB driver issue? etc) or the wheezy debian distro. I'm using the distro put together by the OP on the thread I pasted above.

I'm sure someone else is also using a pi to manage their fpga miners, so I ask has anyone managed to get it to run reliably without any errors, restarts, etc.?

I've updated the firmware via rpi-update and updated the distro with apt-get update & apt-get upgrade & apt-get dist-upgrade. Problem with 2.10.4 of cgminer still persists.

The usb on rpi is known to be really flaky. The addition of a powered usb hub usually fixes most problems as it acts as a usb filter as well as running more usb devices better.

Well that's the thing. I am of course using a powered usb hub, and it gave me no troubles when connected to a windows box.

One thing that I noticed is that the pi powered itself up when I plugged in the usb hub to it so it's drawing from the usb hub (as it should/can) but I still have the power brick plugged in on the pi as well. Should I shutdown the pi and power it up with it's own power brick first and THEN connect the USB hub? Does this order make any difference? I have doubts whether it will resolve the flaky usb issues but it's worth a try, no?

[AmDD]

Sorry if this has been mentioned before, I looked through the readme but didnt see anything. I also have not kept up on this thread or Stratum in general.

How do you disable stratum on cgminer? I was running my rigs on Coinlab and decided to upgrade BAMT to the (at the time) latest cgminer and have not been able to mine there since. I can however mine on any pool that supports Stratum but would like to go back to Coinlab.

[-ck]

Sorry if this has been mentioned before, I looked through the readme but didnt see anything. I also have not kept up on this thread or Stratum in general.

How do you disable stratum on cgminer? I was running my rigs on Coinlab and decided to upgrade BAMT to the (at the time) latest cgminer and have not been able to mine there since. I can however mine on any pool that supports Stratum but would like to go back to Coinlab.

There is nothing about stratum support that precludes mining on regular getwork pools. If they support both getwork and stratum and they specify the stratum header, cgminer will automatically switch to stratum, unless you add the "--fix-protocol" option. But if the pool does not support stratum, like coinlab, it will just use getwork.

[AmDD]

Sorry if this has been mentioned before, I looked through the readme but didnt see anything. I also have not kept up on this thread or Stratum in general.

How do you disable stratum on cgminer? I was running my rigs on Coinlab and decided to upgrade BAMT to the (at the time) latest cgminer and have not been able to mine there since. I can however mine on any pool that supports Stratum but would like to go back to Coinlab.

There is nothing about stratum support that precludes mining on regular getwork pools. If they support both getwork and stratum and they specify the stratum header, cgminer will automatically switch to stratum, unless you add the "--fix-protocol" option. But if the pool does not support stratum, like coinlab, it will just use getwork.

I first assumed this which is why I upgraded. However after upgrading it would not mine on coinlab and will not on Ozcoin either unless it is on the Stratum pool. Maybe its something with the way BAMT talks to cgminer?

[-ck]

Sorry if this has been mentioned before, I looked through the readme but didnt see anything. I also have not kept up on this thread or Stratum in general.

How do you disable stratum on cgminer? I was running my rigs on Coinlab and decided to upgrade BAMT to the (at the time) latest cgminer and have not been able to mine there since. I can however mine on any pool that supports Stratum but would like to go back to Coinlab.

There is nothing about stratum support that precludes mining on regular getwork pools. If they support both getwork and stratum and they specify the stratum header, cgminer will automatically switch to stratum, unless you add the "--fix-protocol" option. But if the pool does not support stratum, like coinlab, it will just use getwork.

I first assumed this which is why I upgraded. However after upgrading it would not mine on coinlab and will not on Ozcoin either unless it is on the Stratum pool. Maybe its something with the way BAMT talks to cgminer?

Pool issues. I know ozcoin has had issues with its getwork pools lately, but I have no idea about coinlab.

[AmDD]

Sorry if this has been mentioned before, I looked through the readme but didnt see anything. I also have not kept up on this thread or Stratum in general.

How do you disable stratum on cgminer? I was running my rigs on Coinlab and decided to upgrade BAMT to the (at the time) latest cgminer and have not been able to mine there since. I can however mine on any pool that supports Stratum but would like to go back to Coinlab.

There is nothing about stratum support that precludes mining on regular getwork pools. If they support both getwork and stratum and they specify the stratum header, cgminer will automatically switch to stratum, unless you add the "--fix-protocol" option. But if the pool does not support stratum, like coinlab, it will just use getwork.

I first assumed this which is why I upgraded. However after upgrading it would not mine on coinlab and will not on Ozcoin either unless it is on the Stratum pool. Maybe its something with the way BAMT talks to cgminer?

Pool issues. I know ozcoin has had issues with its getwork pools lately, but I have no idea about coinlab.

Possible I guess, however I have 2 different rigs both running BAMT. One I never upgraded cgminer and it is still mining on coinlab with zero issues, the other is having issues.

[-ck]

Thought I'd give you all a heads up warning.

I'll be away overseas, enjoying Japan from the 5th to the 23rd of January.... While this is the time frame that perhaps one of the first ASICs comes into existence, the fact is that I really couldn't care less while travelling. Thus I wish to inform you that my right hand man, Kano(i), will be the only person around who will be producing officially sanctioned cgminer code while I'm away. So if and when the hardware does appear, and you wish to use cgminer to mine on that hardware, please use source and/or binaries provided by him.

[K1773R]

Thought I'd give you all a heads up warning.

I'll be away overseas, enjoying Japan from the 5th to the 23rd of January.... While this is the time frame that perhaps one of the first ASICs comes into existence, the fact is that I really couldn't care less while travelling. Thus I wish to inform you that my right hand man, Kano(i), will be the only person around who will be producing officially sanctioned cgminer code while I'm away. So if and when the hardware does appear, and you wish to use cgminer to mine on that hardware, please use source and/or binaries provided by him.

enjoy ur holiday

[Joshwaa]

Lucky you! Have a great time!!

[PatMan]

Upgraded, but had to turn stratum off on p2pool as my DOA/Stale rate went through the roof, even after lowering my intensity on both Linux & windoze rigs. Anyone else had this problem?

[K1773R]

no DoA/Orphans here

[mdude77]

Upgraded, but had to turn stratum off on p2pool as my DOA/Stale rate went through the roof, even after lowering my intensity on both Linux & windoze rigs. Anyone else had this problem?

Same problem here.

M

[Vyacheslav]

Hello.
Anyone who knows and knows how to use the command cgminer --gpu-map?
I got a problem:

OpenCl number corresponds to the number of devices is not ADL and the decision - is to use this command.
In the map units, the last card is marked as
....
6. 09:00
7. 0a: 00
8. 0b: 00

I do not understand how to use it and how to write config. Help, who can ....