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

[ernie-]

I am having trouble compiling cgminer, pretty much any version from the past few months on either Mac OSX 10.9 (Mavericks) or 10.6.11 (Snow Leopard) I am using the Mac ports collection for the dependencies, and I was able to comilpe a few months ago but can't anymore, so something has changed.

The error I get is:

Code:

Making all in libusb-1.0
/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-recursive
Making all in libusb
  CC       os/libusb_1_0_la-darwin_usb.lo
In file included from /System/Library/Frameworks/IOKit.framework/Headers/usb/IOUSBLib.h:27:0,
                 from os/darwin_usb.h:27,
                 from os/darwin_usb.c:43:
/System/Library/Frameworks/IOKit.framework/Headers/usb/USB.h:584:9: error: too many #pragma options align=reset
 #pragma options align=reset
         ^
In file included from /System/Library/Frameworks/IOKit.framework/Headers/usb/IOUSBLib.h:27:0,
                 from os/darwin_usb.h:27,
                 from os/darwin_usb.c:43:
/System/Library/Frameworks/IOKit.framework/Headers/usb/USB.h:754:9: error: too many #pragma options align=reset
 #pragma options align=reset
         ^
/System/Library/Frameworks/IOKit.framework/Headers/usb/USB.h:806:9: error: too many #pragma options align=reset
 #pragma options align=reset
         ^
/System/Library/Frameworks/IOKit.framework/Headers/usb/USB.h:824:9: error: too many #pragma options align=reset
 #pragma options align=reset
         ^
/System/Library/Frameworks/IOKit.framework/Headers/usb/USB.h:844:9: error: too many #pragma options align=reset
 #pragma options align=reset
         ^
make[5]: *** [os/libusb_1_0_la-darwin_usb.lo] Error 1
make[4]: *** [all-recursive] Error 1
make[3]: *** [all] Error 2
make[2]: *** [all-recursive] Error 1

Using gcc 4.8, but also tried earlier versions.

I know there are pre-compiled Mac binaries around, but I would rather conquer this problem, obviously someone has.

Any suggestions?

[1537940711]

1537940711

[1537940711]

1537940711

[1537940711]

1537940711

[Hawkix]

I am using latest cgminer to solo mine on testnet and I think there is a bug with handling the testnet difficulty. After no block for 20 minutes, testnet difficulty drops down to 1.0, but cgminer still requires work of previous (high) difficulty (12.3K now).

>bitcoind getwork      returns "target" : "0000000000000000000000000000000000000000000000000d54050000000000"
>bitcoind getinfo       returns  "difficulty" : 1.00000000

Is this a bug in cgminer?

[pauljbl]

Hi I see there is support for nf2 and nf6 could you add support for nanofurys devices that are chained together as I have 5 nanofurys chained. And also to set the bit speed of each individual bitfury chip. This is possible in bfgminer

Thanks
Paul

[-ck]

Hi I see there is support for nf2 and nf6 could you add support for nanofurys devices that are chained together as I have 5 nanofurys chained. And also to set the bit speed of each individual bitfury chip. This is possible in bfgminer

Usual story with hardware I haven't seen before: I'm happy to take patches, but I cannot write the code to support them without the hardware myself or suitable sponsorship.

[Killerloop]

ckolivas I would really appreciate an answer to this question.

As far as I know this is not something asked before and could prove useful to other Bitburner Fury users too.

[-ck]

ckolivas I would really appreciate an answer to this question.

As far as I know this is not something asked before and could prove useful to other Bitburner Fury users too.

I don't have one and didn't write the support so not sure (maybe Kano can help). Generically separating dud hardware from good is always a good idea.

[helipotte]

Hi,

Having a small problem with Cgminer 4.3.3 and Blackarrow bitfury boards.

Every so often I get a (duplicate) share that is indeed a dupe of a share just before it.

I changed line 529 from #define BAB_WORK_EXPIRE_mS 7800 to 5800.  This seems to have helped.

Any suggestions?

Thanks!

Edit: My pool is Eligius.
Edit#2: Line 529 seems to have minimal effect on "dupes".
No one has any ideas?

[-ck]

New release: Version 4.3.4, 25th May 2014


Human readable changelog:

- Driver updates to spondoolies, cointerra, avalon2 and minion.
- Support for nanofury NF2 (good working) and NF6 (flaky, ?design related) USB sticks.
- Extra output in the API for NF* devices and BXM in the API for per chip information.
- Fix for pools going idle if stratum is restarted unsuccessfully.
- Fix for a crash in libusb when devices are frequently plugging/unplugging on linux.
- New benchmarking code with the --benchmark option which uses a deterministic set of work items to find a known number of different diff share nonces at regular intervals. Note that devices that don't check the entire range (mainly bitfury based devices) will not find some of these nonces so the benchmark code is suited to devices like the hashfast,  cointerra etc. Give it an hour before assessing results.
- Fix the reset counter on hashfast devices to be properly inherited.
- New ruby example for API.
- Low level code fixes and cleanups.


Full changelog:

- Add support for 2 nonces per block in spond driver
- Increase timeout on reset in cta driver to 5 seconds
- Increase max diff on spondoolies driver slightly to be well below spi comms
limitations
- Use the active contents lock and safe list iteration within the linux usbfs
code
- Add Ruby Api Example
- Automatic detect the small miners
- Update default modules from 3 to 4
- Fix the temp max. we should use currect max temp
- add avalon2-cutoff options
- Enable the cutofftemp to Avalon2. ignore longer coinbase and longer merkles
stratum
- Fix the diff value used on MM firmware
- Mark pool as idle if stratum restart is failed
- Add hacky workaround for double list removal race in libusb
- Make the work given in benchmark mode deterministic on a per-device basis
- Rework the benchmarking code to use a deterministic set of work items with a
known number of diff share nonces at regular spaced intervals
- minion - restrict nonce read result size to ioctl() limit
- minion - must check temp when overheated
- minion - idle chips that hit >100C until back to 80C
- minion - report the chip/reg when aborting due to an invalid ioctl() size
- minion - all freq in Mhz but only convert when used
- minion - remove unused ioctl debug
- minion - command queue is now larger
- minion - check rolled in stale work cleanup
- Work stats should be based on device_diff not work_difficulty since non-shares
haven't been filtered out yet
- Prevent a segfault when writing a config file containing 'rotate' option
- minion - comment out HW debug message
- minion - roll work to reduce CPU
- minion - report init_freq in stats
- api - howoldsec is only used for USB
- minion - allow setting the frequency
- minion - disable iostats by default since it slows down mining
- minion - define frequency value table
- minion - report temp/cores/freq and handle temp formatting
- minion - item is undefined
- Rationalise diffs stored in the work struct and document them to avoid further
confusion
- Add basic API stats for nfu drivers to see how many submits each chip returns
- Add output direction for the EN0 pin on nfu driver
- Support power management optimisations in newer nf* firmware
- Support variable numbers of chips with NFU and BXM drivers
- Identify number of chips in nanofury devices and change name accordingly
- Rename nf1 driver to nfu in anticipation of support for more chips
- Make hashfast reset counter rise on old instances when inheriting the value on
new ones

[stevegee58]

I'm still using 3.4.0 on a BeagleBone to run my BFL Jalapeno 7 GHs.
An oldie but a goodie. 

[techman05]

Hi,

Having a small problem with Cgminer 4.3.3 and Blackarrow bitfury boards.

Every so often I get a (duplicate) share that is indeed a dupe of a share just before it.

I changed line 529 from #define BAB_WORK_EXPIRE_mS 7800 to 5800.  This seems to have helped.

Any suggestions?

Thanks!

Edit: My pool is Eligius.
Edit#2: Line 529 seems to have minimal effect on "dupes".
No one has any ideas?

Are you maybe using load balancing or too low of a difficulty. I only get problems when I switch pools or exit and come back before it knows I 'm gone.

[kano]

Hi,

Having a small problem with Cgminer 4.3.3 and Blackarrow bitfury boards.

Every so often I get a (duplicate) share that is indeed a dupe of a share just before it.

I changed line 529 from #define BAB_WORK_EXPIRE_mS 7800 to 5800.  This seems to have helped.

Any suggestions?

Thanks!

Edit: My pool is Eligius.
Edit#2: Line 529 seems to have minimal effect on "dupes".
No one has any ideas?

Dups are expected.
I get quite a lot and I wrote the driver
Expiring the work earlier risks rejecting valid work.
The interface to the chip makes it difficult to ensure you aren't rereading the same results sometimes.
You may have noticed the low HW error %?
That's due to using more CPU and sometimes getting dups.

I've been working on the AntS2 driver and wrote a simple dup check that I can implement in any driver with a few lines.
Once I've finished the AntS2 and the updates to the BlackArrowMinion work soon, I'll probably add it to the BaB driver also, since I see the dups also - and avoiding sending them to the pool is nicer to the pool and saves ever so slightly on network usage.

Oh well about your choice of pool ...

FYI: I've got 7 boards on a V2 4 SPI controller always above 270GH/s
The code works well up to 8, but will need some SPI tuning to do more than 2 per SPI reliably.
Mine runs forever without failing - only restarts on power outages, config changes or cgminer updates.
1.25W/GHs at the wall, really is pretty amazing for these boards that have been around for so long!

[Buchi-88]

@choklivas

THX for the new version, i will test and report

regards

[tuanvie]

win 7 x86 if it works stable?
I often have problems: (

[os2sam]

win 7 x86 if it works stable?
I often have problems: (

Is that a question or a statement?

If your asking if CGMiner works with 32 bit Windoze 7?  The answer is yes.

[tuanvie]

win 7 x86 if it works stable?
I often have problems: (

Is that a question or a statement?

If your asking if CGMiner works with 32 bit Windoze 7?  The answer is yes.

I mean, I often fail to use it on win 7 x86,
and if you can help command for maximum performance?

[os2sam]

win 7 x86 if it works stable?
I often have problems: (

Is that a question or a statement?

If your asking if CGMiner works with 32 bit Windoze 7?  The answer is yes.

I mean, I often fail to use it on win 7 x86,
and if you can help command for maximum performance?

Hmm, works fine for me.

There is no command to maximize performance for my setup, which is USB BE's and a Jalapeno.  I just run CGMiner with the  pool stuff and it detects and sets everything for me.

[tadzio]

Im running 3x Bi*Furry on powered USB HUB - power is sufficient.
Randomly (after 10m - 4h) I get:

Code:

BXF 2 BXFWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT

and miner crushes (WIN 7).
Any idea?

[-ck]

Im running 3x Bi*Furry on powered USB HUB - power is sufficient.
Randomly (after 10m - 4h) I get:

Code:

BXF 2 BXFWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT

and miner crushes (WIN 7).
Any idea?

That is a sign of hardware instability, not software. If you're 100% sure you have enough power (and most people don't have as much as they think they have) then the next thing to do is actively cool them better.

EDIT: Do you mean "crashes" when you say "crushes"? In that case you may be able to help by running a debug version and following the instructions in here:
http://ck.kolivas.org/apps/cgminer/debug/

Read the README-debug file.

[tadzio]

Im running 3x Bi*Furry on powered USB HUB - power is sufficient.
Randomly (after 10m - 4h) I get:

Code:

BXF 2 BXFWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT

and miner crushes (WIN 7).
Any idea?

That is a sign of hardware instability, not software. If you're 100% sure you have enough power (and most people don't have as much as they think they have) then the next thing to do is actively cool them better.

EDIT: Do you mean "crashes" when you say "crushes"? In that case you may be able to help by running a debug version and following the instructions in here:
http://ck.kolivas.org/apps/cgminer/debug/

Read the README-debug file.

Hardware is actively cooled and working in air conditioned room - always below 42C.

Here is the debug:

Code:

cgminerBD.exe caused an Access Violation at location 74de9b60 in module msvcrt.dll Reading from location 02ec0000.

Registers:
eax=02ebfa1c ebx=02ebff20 ecx=3ffffe87 edx=00000000 esi=02ec0000 edi=02ebf87c
eip=74de9b60 esp=02ebf370 ebp=02ebf378 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206

Call stack:
74DE9B60  msvcrt.dll:74DE9B60  memcpy
00449697  cgminerBD.exe:00449697
cgminerBD.exe caused an Access Violation at location 7708e3be in module ntdll.dll Reading from location 2db62da2.

Registers:
eax=01ea9058 ebx=01ec1dd8 ecx=003c0000 edx=01ec1dd8 esi=2db62d9e edi=01ec1dd0
eip=7708e3be esp=02a3fc30 ebp=02a3fc64 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202

Call stack:
7708E3BE  ntdll.dll:7708E3BE  RtlInitUnicodeString
7708E023  ntdll.dll:7708E023  RtlFreeHeap
74DE98CD  msvcrt.dll:74DE98CD  free
004947D7  cgminerBD.exe:004947D7
00494FF2  cgminerBD.exe:00494FF2
00495072  cgminerBD.exe:00495072
00490C71  cgminerBD.exe:00490C71
004910C6  cgminerBD.exe:004910C6
00491114  cgminerBD.exe:00491114
004912BB  cgminerBD.exe:004912BB
00489F9E  cgminerBD.exe:00489F9E
0048A0FC  cgminerBD.exe:0048A0FC
0042538D  cgminerBD.exe:0042538D
004C015B  cgminerBD.exe:004C015B
74DF1287  msvcrt.dll:74DF1287  _itow_s
74DF1328  msvcrt.dll:74DF1328  _endthreadex
759A336A  kernel32.dll:759A336A  BaseThreadInitThunk
77099F72  ntdll.dll:77099F72  RtlInitializeExceptionChain
77099F45  ntdll.dll:77099F45  RtlInitializeExceptionChain

[-ck]

http://ck.kolivas.org/apps/cgminer/debug/

Read the README-debug file.

Hardware is actively cooled and working in air conditioned room - always below 42C.

Here is the debug:

Code:

Thanks. There's not much information in that. Did you use the debug cgminer.exe binary from that directory as well?