Author

Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 172. (Read 5805527 times)

-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
AMU10 has gone zombie about one hour in to a 3.8.2 run.

Hot-swap did not fix it, but Q and a restart did. (Win7 64 zipped version).

I believe I've finally found out why they weren't hotplugging again, and it would affect any operating system, not just windows. I have committed a fix for it into master git, and here's a binary to try out:
http://ck.kolivas.org/apps/cgminer/temp/cgminer-undead.exe
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
I'm on mac... I got the USBtoUART driver installed.
Better uninstall it then. As per the README which I keep trying to point you towards, cgminer doesn't use drivers for the USB devices. You are putting drivers there that are stopping cgminer from working.
hero member
Activity: 896
Merit: 500
how to get my ASICMiner Block erupter to work?
Code:
cgminer -o stratum.bitcoin.cz -u  -p 
then what?

Thanks
Then you hit enter Wink
The code is ok for run, you do not need and additional options in command line.
[2013-11-16 22:42:24] Icarus detect (250:10) failed to initialise (incorrect de
vice?)

Did you installed Zadig ( http://ck.kolivas.org/apps/cgminer/zadig/ ) to change USB drivers on Windows?

I'm on mac... I got the USBtoUART driver installed.
member
Activity: 122
Merit: 10
how to get my ASICMiner Block erupter to work?
Code:
cgminer -o stratum.bitcoin.cz -u  -p 
then what?

Thanks
Then you hit enter Wink
The code is ok for run, you do not need and additional options in command line.
[2013-11-16 22:42:24] Icarus detect (250:10) failed to initialise (incorrect de
vice?)

Did you installed Zadig ( http://ck.kolivas.org/apps/cgminer/zadig/ ) to change USB drivers on Windows?
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
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

Well I'm still on holiday for another week yet, but having just caught up with the last week's messages, I'm itching to do some more testing! My ongoing run with "ymmv" seems to be down from 11Gh/s to 9.xGh/s - so it looks like several AMUs have stopped working (I can't access the machine to check directly - I'm just looking at my pool stats.) Laterz...


Heh, well there's really nothing newer than the latest actual stable release in terms of changes for windows. I have nothing new to test for the time being.
hero member
Activity: 896
Merit: 500
how to get my ASICMiner Block erupter to work?
Code:
cgminer -o stratum.bitcoin.cz -u  -p 
then what?

Thanks
Then you hit enter Wink
The code is ok for run, you do not need and additional options in command line.
[2013-11-16 22:42:24] Icarus detect (250:10) failed to initialise (incorrect de
vice?)
member
Activity: 122
Merit: 10
how to get my ASICMiner Block erupter to work?
Code:
cgminer -o stratum.bitcoin.cz -u  -p 
then what?

Thanks
Then you hit enter Wink
The code is ok for run, you do not need and additional options in command line.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
how to get my ASICMiner Block erupter to work?
Code:
cgminer -o stratum.bitcoin.cz -u  -p 
then what?
Then read the documentation that says README?
hero member
Activity: 896
Merit: 500
how to get my ASICMiner Block erupter to work?
Code:
cgminer -o stratum.bitcoin.cz -u  -p 
then what?

Thanks
newbie
Activity: 56
Merit: 0
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

Well I'm still on holiday for another week yet, but having just caught up with the last week's messages, I'm itching to do some more testing! My ongoing run with "ymmv" seems to be down from 11Gh/s to 9.xGh/s - so it looks like several AMUs have stopped working (I can't access the machine to check directly - I'm just looking at my pool stats.) Laterz...

legendary
Activity: 1450
Merit: 1013
Cryptanalyst castrated by his government, 1952
AMU10 has gone zombie about one hour in to a 3.8.2 run.

Hot-swap did not fix it, but Q and a restart did. (Win7 64 zipped version).
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
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.
member
Activity: 109
Merit: 10
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
legendary
Activity: 1450
Merit: 1013
Cryptanalyst castrated by his government, 1952
...
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.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
...
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.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
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
hero member
Activity: 539
Merit: 500
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. 
legendary
Activity: 1450
Merit: 1013
Cryptanalyst castrated by his government, 1952
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.   Smiley

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.


-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
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

legendary
Activity: 3583
Merit: 1094
Think for yourself
(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.
Jump to: