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

[QiVX]

I don't know if it's me or not.
Unzipped latest version of cgminer, and tried running cgminer.exe with --scrypt and it comes up with unrecognized parameter ?

Went back to 3.7.2 and all is fine. Can't seem to mine LTC with 3.8 c:

[jedimstr]

I don't know if it's me or not.
Unzipped latest version of cgminer, and tried running cgminer.exe with --scrypt and it comes up with unrecognized parameter ?

Went back to 3.7.2 and all is fine. Can't seem to mine LTC with 3.8 c:

I think you missed this a few pages back... https://asktom.cf/index.php?topic=28402.msg3538435#msg3538435

We discuss it further here:
https://forum.litecoin.net/index.php/topic,6925.0.html

Others are going to pick up the pieces and continue development here: https://forum.litecoin.net/index.php/topic,6994.0.html

[ChipGeek]

I'm seeing a problem with 3.8.1 on an RPi running Rasbian.  Twice in the last 24 hours cgminer has stopped running.  It appears as if the "q" key was pressed even though I'm sure it was not.  This hardware has run solid for weeks before I upgraded to 3.8.1. 

I haven't had any problems with raspbian and 3.8.1 on my end so far.  I've got four instances of cgminer up on the same Rpi with each built for different hardware.  After I did an update & upgrade last week my Rpi started crashing when ever I tried mining on it.  The fix was to turn on some kind of memory debugging feature.

Chad

Hmmm...  Thanks for the info.  I did to this and perhaps that's the culprit? 

Code:

sudo apt-get update

What is the "memory debugging feature" that you turned on?

[chadtn]

I'm seeing a problem with 3.8.1 on an RPi running Rasbian.  Twice in the last 24 hours cgminer has stopped running.  It appears as if the "q" key was pressed even though I'm sure it was not.  This hardware has run solid for weeks before I upgraded to 3.8.1. 

I haven't had any problems with raspbian and 3.8.1 on my end so far.  I've got four instances of cgminer up on the same Rpi with each built for different hardware.  After I did an update & upgrade last week my Rpi started crashing when ever I tried mining on it.  The fix was to turn on some kind of memory debugging feature.

Chad

Hmmm...  Thanks for the info.  I did to this and perhaps that's the culprit? 

Code:

sudo apt-get update

What is the "memory debugging feature" that you turned on?

Here is a link to instructions.  Scroll down to the section that says Rpi freezing up.

http://projectklondike.org/how-to-run

Chad

[Ghost of USD]

Has anyone tested out the 20131112-unstable avalon firmware?

[aneutronic]

Has anyone tested out the 20131112-unstable avalon firmware?

It's unstable on my b3. The latest stable version for mine is 3.6.6, it runs strong but requires daily restarts due to filling up the very small ram on the tplink.

[ChipGeek]

I'm seeing a problem with 3.8.1 on an RPi running Rasbian.  Twice in the last 24 hours cgminer has stopped running.  It appears as if the "q" key was pressed even though I'm sure it was not.  This hardware has run solid for weeks before I upgraded to 3.8.1. 

Here is a link to instructions.  Scroll down to the section that says Rpi freezing up.
http://projectklondike.org/how-to-run
Chad

Thanks but that is not the problem I'm seeing.  My RPi does not freeze or lock up.  Instead it appears as if the 'q' key was pressed and cgminer quits for no apparent reason.  It happened again last night.  I will revert to an older version.

BTW - when getting source from github, now do I request an older version (such as 3.7.2)? 
I can't just go back to the ancient version I was using (3.4.2).

[-ck]

I'm seeing a problem with 3.8.1 on an RPi running Rasbian.  Twice in the last 24 hours cgminer has stopped running.  It appears as if the "q" key was pressed even though I'm sure it was not.  This hardware has run solid for weeks before I upgraded to 3.8.1. 

Here is a link to instructions.  Scroll down to the section that says Rpi freezing up.
http://projectklondike.org/how-to-run
Chad

Thanks but that is not the problem I'm seeing.  My RPi does not freeze or lock up.  Instead it appears as if the 'q' key was pressed and cgminer quits for no apparent reason.  It happened again last night.  I will revert to an older version.

BTW - when getting source from github, now do I request an older version (such as 3.7.2)? 
I can't just go back to the ancient version I was using (3.4.2).

Use a tag
git checkout v3.7.2

or whatever

[-ck]

Windows users with random communication problems/zombies, here's a new binary to test please (multi AMU users, I'm looking at you).

http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe

[ewibit]

Windows users with random communication problems/zombies, here's a new binary to test please (multi AMU users, I'm looking at you).

http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe

is not only Windows
Ubuntu 13.10:

Code:

AMU  0:                | ZOMBIE/182.3Mh/s | A:  1767 R:  12 HW: 139 WU:   2.4/m
 AMU  1:                | ZOMBIE/177.4Mh/s | A:  3740 R:   4 HW: 126 WU:   2.4/m
 AMU  2:                | ZOMBIE/182.5Mh/s | A:  1857 R:  13 HW: 139 WU:   2.3/m
 AMU  3:                | ZOMBIE/182.5Mh/s | A:  3919 R:  12 HW: 139 WU:   2.4/m
 AMU  4:                | ZOMBIE/155.8Mh/s | A:  1460 R:  12 HW:  93 WU:   2.1/m
 AMU  5:                | ZOMBIE/182.4Mh/s | A:  1722 R:   0 HW: 136 WU:   2.5/m
 AMU  6:                | ZOMBIE/182.0Mh/s | A:  3710 R:  16 HW: 128 WU:   2.4/m
 AMU  7:                | ZOMBIE/156.1Mh/s | A:  1425 R:  12 HW: 114 WU:   2.1/m
 AMU  8:                | ZOMBIE/182.2Mh/s | A:  1829 R:  16 HW: 144 WU:   2.5/m
 AMU  9:                | ZOMBIE/182.3Mh/s | A:  1772 R:  16 HW: 136 WU:   2.4/m
 BAL  0:  max 58C 3.27V | ZOMBIE/16.38Gh/s | A:195597 R:5755 HW:1076 WU: 227.4/m

cgminer 3.8

[-ck]

Windows users with random communication problems/zombies, here's a new binary to test please (multi AMU users, I'm looking at you).

http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe

is not only Windows
Ubuntu 13.10:

Code:

AMU  0:                | ZOMBIE/182.3Mh/s | A:  1767 R:  12 HW: 139 WU:   2.4/m
 AMU  1:                | ZOMBIE/177.4Mh/s | A:  3740 R:   4 HW: 126 WU:   2.4/m
 AMU  2:                | ZOMBIE/182.5Mh/s | A:  1857 R:  13 HW: 139 WU:   2.3/m
 AMU  3:                | ZOMBIE/182.5Mh/s | A:  3919 R:  12 HW: 139 WU:   2.4/m
 AMU  4:                | ZOMBIE/155.8Mh/s | A:  1460 R:  12 HW:  93 WU:   2.1/m
 AMU  5:                | ZOMBIE/182.4Mh/s | A:  1722 R:   0 HW: 136 WU:   2.5/m
 AMU  6:                | ZOMBIE/182.0Mh/s | A:  3710 R:  16 HW: 128 WU:   2.4/m
 AMU  7:                | ZOMBIE/156.1Mh/s | A:  1425 R:  12 HW: 114 WU:   2.1/m
 AMU  8:                | ZOMBIE/182.2Mh/s | A:  1829 R:  16 HW: 144 WU:   2.5/m
 AMU  9:                | ZOMBIE/182.3Mh/s | A:  1772 R:  16 HW: 136 WU:   2.4/m
 BAL  0:  max 58C 3.27V | ZOMBIE/16.38Gh/s | A:195597 R:5755 HW:1076 WU: 227.4/m

cgminer 3.8

That windows binary is truly a windows only thing that I implemented. Your zombies I'm gonna blame on your hardware

* ckolivas runs away screaming

[os2sam]

(multi AMU users, I'm looking at you).

Don't look at me.  3.8.1 has been rock solid for me on Win7 and even Vista, can't believe that crap OS is working well.

[-ck]

Windows users with random communication problems/zombies, here's a new binary to test please (multi AMU users, I'm looking at you).

http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe

And here's an extra one to test afterwards.

http://ck.kolivas.org/apps/cgminer/temp/cgminer-lulz.exe

[aigeezer]

Windows users with random communication problems/zombies, here's a new binary to test please (multi AMU users, I'm looking at you).

http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe

And here's an extra one to test afterwards.

http://ck.kolivas.org/apps/cgminer/temp/cgminer-lulz.exe

The first one is doing well for me after about 4.5 19.75 hours. Don't need the lulz yet, I guess.  

Edit: updated elapsed time of run.

Edit: finally got a zombie (AMU3) after about 24.75 hours. I'll try "lulz" next, for the lulz.

Edit: "lulz" is working perfectly, 19 hours into its run.

Edit: Oops - AMU10 went zombie, 22 hours in.

[xjack]

That windows binary is truly a windows only thing that I implemented. Your zombies I'm gonna blame on your hardware

* ckolivas runs away screaming

Rock solid AMU performance here from 3.8.1 on xubuntu 12.0.4 and on BeagleBone/Angstrom. 

[-ck]

New release: Version 3.8.2, 16th November 2013

Another stable release with a new driver.


Human readable changelog:

- New driver for bi*fury devices. These will come up as BXF devices. Note that if you have one of these, having 2 bitfury chips they generate a LOT of heat and will need active cooling. The first firmware for them does not have a way to stop them mining so they will get dangerously hot if you don't point a fan at them and stopping cgminer won't even cool them down. This should be fixed in their next version.
- Set priority of various threads high and low for poor performing hardware (e.g. wrt routers) or operating systems (i.e. windows) to try to minimise the influence of system usage in other ways from causing communication problems.
- Fixed a problem where it was possible for cgminer to hang after getting notification of a new block when mining via getwork.
- Low level communication fixes within libusb itself to support sending proper zero length packets on windows for more reliable communications (same as the lulz binary), along with automatically clearing pipe errors and not losing buffered data.
- More low level avalon fixes.
- Klondike fixes
- Hashfast fixes
- BaB fixes
- Hardware errors on starting BF1 devices are now minimised
- Fix for mining directly on a GBT port with --fix-protocol
- --shares is now scaled relative to diff1 shares instead of absolute number
- Fix for a rare crash on startup
- Other low level fixes
- More verbose documentation



Full changelog:

- Add more verbose documentation to the readme files for windows users.
- Add more information on libusb failure to init telling users to check README
file.
- Add information on unloading cdc drivers on osx to README
- Prevent a deadlock with use of restart_threads by spawning a thread to send
the driver flush work messages.
- Set priority of various threads if possible.
- Add bxf data to api output.
- Do not hold the mining thread lock in restart_threads when calling the driver
flush work commands.
- Send extra work regularly to the bxf device and parse the needwork command by
sending the amount of work it requests.
- Allow messages to have arbitrary offsets in the bxf parser in case we have
lingering buffered data.
- Send the maxroll command to the bxf driver and store the value to see if we
need to update it.
- Add sending of flush command to bxf on flush_work
- Add flush and version commands to bxf start up, flush buffer and try to parse
version response string.
- Abstract out bxf recv message.
- Add extra bxf commands to usbutils
- Abstract out bxf send message to allow us to easily add extra commands.
- Don't run device restart code if the device is not enabled.
- Expand size of bitfury statline
- Various driver fixes for bitfury devices, including a flag from when first
valid work appears.
- Look up work results in bxf driver from correct variable.
- Correct incorrect error code in bxf driver for usb writes and add debugging.
- Add bxf details to usbutils.
- Implement a statline showing temperature for bxf
- Add api data for bxf device, sharing the hashrate function with bf1.
- Count no matching work as a hw error on bxf
- Add BXF to udev rules.
- Work id should be hexadecimal in bxf messages.
- Add unrecognised string debugging to bxf driver.
- Implement the main scanloop for bxf, trying to prevent it from ntime rolling
work if the work protocol does not allow it.
- Parse bxf work submits fully, submitting the results.
- Provide a function for setting the work ntime.
- Implement a skeleton parse bxf submit function.
- Use the bxf read thread to set the device target and send its first work item.
- Implement a bxf send work function and set update and restart functions to
sending new work since that's the equivalent for that device.
- Add temperature parsing to bxf driver
- Create and destroy a basic bxf read thread.
- Remove the buffer from bitfury info since it is only used on one pass in the
bf1 device.
- Add a rudimentary bxf detect one function.
- Rename all bf1 specific functions in the bitfury driver, using a switch to
choose correct function.
- Rename bitfury_getinfo to bf1_getinfo since it's unique to bf1 devices.
- Separate out the bf1 reset from bitfury reset.
- Store the bitfury identity in the info struct.
- BaB - updated tested OS comment
- Uniquely identify the BF1 and BXF bitfury devices.
- Remove the default libusb WinUsb pipe policies that don't suit us.
- Only set the winusb pipe policy if it doesn't match our requirements instead
of every transfer.
- klondike - dont try to flush if not initialised
- api.c trylock() add missing locklock
- Use our new zero length packet support directly in windows.
- Enable support for zero length packet on windows and auto clear pipe stalls.
- util.c: Decreasing reference count on allocated JSON obects to prevent memory
leak
- api.c: Release apisock on error in api()
- api.c: Release io_data->ptr when releasing io_data in io_free()
- We can't connect to a GBT pool at all with fix protocol enabled.
- Initialise the stgd lock mutex earlier to prevent dereferences when pool
testing occurs before it.
- Klondike support I2C USB layout also - as KLI
- Return error codes in avalon_read() if they're not timeouts.
- Break out of the avalon idle loop if we get a send error.
- Set avalon ftdi latency to just less than the time it would take to fill the
ftdi buffer at 115200 baud
- Update example.conf
- Only limit packetsize on usb out writes.
- We must chop up every 64 bytes returned on an ftdi chip, not just the first 2
bytes so revert to parsing the data internally in the avalon instead of using
usbutils' simple ftdi parser.
- Only retry 3 times in hfa_reset.
- Only add_cgpu in hashfast driver once we have a real driver set up.
- Clean up properly if hfa_detect_common fails in the hashfast driver.
- --shares should be scaled to diff1 not absolute number of shares

[kano]

...
Edit: Oops - AMU10 went zombie, 22 hours in.

But did it hotplug back in?
In my ~1 day test run on windows with lulz, one of my 3 AMU did go zombie a few times but it always hotplugged back in shortly after.

[aigeezer]

...
Edit: Oops - AMU10 went zombie, 22 hours in.

But did it hotplug back in?
In my ~1 day test run on windows with lulz, one of my 3 AMU did go zombie a few times but it always hotplugged back in shortly after.

My memory says it did not - I'm pretty sure, but then I'm not 100% sure of anything (too many philosophy courses).

My next lulz run had one anomaly after 20 hours - an AMU LED was on but the device did not show as a zombie. The display originally showed AMUs 0-12, as expected. Some time during the run AMUs 1 and 11 dropped from the display. One of them was apparently reallocated to 13 and the other was just missing. Presumably it was the one with the LED on - a nameless zombie.

It was cool to the touch. Unplugging it did not change the display. Replugging it produced the usual five blinks, but then the LED stayed on and cgminer did not recognize it.
A "Q" and restart fixed the issue.

I'll switch to 3.8.2 shortly.

[Karin]

3.8.2 works great for Mac.  Only trouble was building in KnC and Hashfast support, and I had to leave them disabled.  I know the drivers are young, but here's the output in case it's of any use:

Code:

  CC     cgminer-driver-knc-spi-fpga.o
driver-knc-spi-fpga.c:19:25: error: linux/types.h: No such file or directory
driver-knc-spi-fpga.c:20:30: error: linux/spi/spidev.h: No such file or directory
driver-knc-spi-fpga.c: In function ‘spi_new’:
driver-knc-spi-fpga.c:216: error: ‘SPI_CPHA’ undeclared (first use in this function)
driver-knc-spi-fpga.c:216: error: (Each undeclared identifier is reported only once
driver-knc-spi-fpga.c:216: error: for each function it appears in.)
driver-knc-spi-fpga.c:216: error: ‘SPI_CPOL’ undeclared (first use in this function)
driver-knc-spi-fpga.c:216: error: ‘SPI_CS_HIGH’ undeclared (first use in this function)
driver-knc-spi-fpga.c:236: error: ‘SPI_IOC_WR_MODE’ undeclared (first use in this function)
driver-knc-spi-fpga.c:238: error: ‘SPI_IOC_RD_MODE’ undeclared (first use in this function)
driver-knc-spi-fpga.c:244: error: ‘SPI_IOC_WR_BITS_PER_WORD’ undeclared (first use in this function)
driver-knc-spi-fpga.c:246: error: ‘SPI_IOC_RD_BITS_PER_WORD’ undeclared (first use in this function)
driver-knc-spi-fpga.c:252: error: ‘SPI_IOC_WR_MAX_SPEED_HZ’ undeclared (first use in this function)
driver-knc-spi-fpga.c:254: error: ‘SPI_IOC_RD_MAX_SPEED_HZ’ undeclared (first use in this function)
driver-knc-spi-fpga.c: In function ‘spi_transfer’:
driver-knc-spi-fpga.c:283: error: storage size of ‘xfr’ isn’t known
driver-knc-spi-fpga.c:299: warning: implicit declaration of function ‘SPI_IOC_MESSAGE’
driver-knc-spi-fpga.c:283: warning: unused variable ‘xfr’
driver-knc-spi-fpga.c: In function ‘disable_core’:
driver-knc-spi-fpga.c:310: error: invalid lvalue in unary ‘&’
driver-knc-spi-fpga.c: In function ‘enable_core’:
driver-knc-spi-fpga.c:319: error: invalid lvalue in unary ‘&’
driver-knc-spi-fpga.c: In function ‘knc_process_response’:
driver-knc-spi-fpga.c:536: warning: integer constant is too large for ‘unsigned long’ type
make[1]: *** [cgminer-driver-knc-spi-fpga.o] Error 1
make: *** [install-recursive] Error 1

Code:

  CC     cgminer-cgminer.o
In file included from driver-hashfast.h:17,
                 from cgminer.c:76:
hf_protocol.h:102:28: error: hf_protocol_be.h: No such file or directory
In file included from cgminer.c:76:
driver-hashfast.h:78: error: field ‘usb_init_base’ has incomplete type
driver-hashfast.h:79: error: field ‘config_data’ has incomplete type
make[1]: *** [cgminer-cgminer.o] Error 1
make: *** [install-recursive] Error 1

[-ck]

3.8.2 works great for Mac.  Only trouble was building in KnC and Hashfast support, and I had to leave them disabled.  I know the drivers are young, but here's the output in case it's of any use:

Thanks. No point compiling KnC support since it can ONLY run off a beaglebone, and the closest thing to hashfast hardware in existence is still the fpga emulation in my hardware, but I'll look into it. Still, it's always nice to know I didn't break OSX.