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

[runlinux]

I'm getting the same issue. Running the latest Minepeon with cgminer. It works just fine with bfgminer. I'd rather use cgminer though.

Both 3.1.1 and 3.2.0 return this message:

[2013-06-06 15:55:12] BitForceSC detect (2:9) get details returned nothing (0:0)

What does this mean? Is the Jalapeno busted or am I missing something?


 [2013-06-06 15:58:55] Started cgminer 3.2.0
 [2013-06-06 15:58:55] Started cgminer 3.2.0
 [2013-06-06 15:58:55] USB all: found 16 devices - listing known devices
.USB dev 0: Bus 2 Device 3 ID: 10c4:ea60
  Manufacturer: 'Silicon Labs'
  Product: 'CP2102 USB to UART Bridge Controller'
.USB dev 1: Bus 2 Device 6 ID: 10c4:ea60
  Manufacturer: 'Silicon Labs'
  Product: 'CP2102 USB to UART Bridge Controller'
.USB dev 2: Bus 2 Device 7 ID: 10c4:ea60
  Manufacturer: 'Silicon Labs'
  Product: 'CP2102 USB to UART Bridge Controller'
.USB dev 3: Bus 2 Device 8 ID: 10c4:ea60
  Manufacturer: 'Silicon Labs'
  Product: 'CP2102 USB to UART Bridge Controller'
.USB dev 4: Bus 2 Device 9 ID: 0403:6014
  Manufacturer: 'Butterfly Labs'
  Product: 'BitFORCE SHA256 SC'
 [2013-06-06 15:58:55] 5 known USB devices
 [2013-06-06 15:59:00] BitForceSC detect (2:9) get details returned nothing (0:0)
 [2013-06-06 15:59:00] Need to specify at least one pool server.
Input server details.

[1714064738]

1714064738

[1714064738]

1714064738

[sLide.]

I'm experiencing a issue with CGminer.

I recently moved my XFX 6870 from my gaming machine which was used to mine when I wasn't gaming to my first rig.  I keep getting error's from windows saying it had to stop the program from running.

MoBo: msi x58A-GD45
Proc: I7 920
Memory : 2GB
Video Card: 6870 XFX HD - CCC Version - 13.4 Direct3D Version 9.14.10.0969

Not entirely sure what the problem could be.  I've tried running as admin.  Any help?  Thanks!

I had same problem with incompatible OpenCL driver combination... Changing it might help

In event log, I'm getting this error -

- System

  - Provider

   [ Name]  Application Error
 
  - EventID 1000

   [ Qualifiers]  0
 
   Level 2
 
   Task 100
 
   Keywords 0x80000000000000
 
  - TimeCreated

   [ SystemTime]  2013-06-07T14:03:10.000000000Z
 
   EventRecordID 1752
 
   Channel Application
 
   Computer Miner1-PC
 
   Security
 

- EventData

   cgminer.exe
   0.0.0.0
   518e20db
   cgminer.exe
   0.0.0.0
   518e20db
   c0000005
   000265be
   12a0
   01ce6387bbccda57
   C:\Users\Miner1\Desktop\cgminer\cgminer-3.1.1-windows\cgminer.exe
   C:\Users\Miner1\Desktop\cgminer\cgminer-3.1.1-windows\cgminer.exe
   fc31de57-cf7a-11e2-8d68-6c626de9cc51

[-ck]

It's still the answer.

I'm not mining LTC... So SCRYPT-README doesn't apply or am I missing something? And I don't have GPU-README. I have README and I have read it. I can't find anything. Did I miss something in it? I just glance over it again. Can't find anything relevant. The only think that might apply is RAM but I have enough of it RAM. More then 1 GB still free...

EDIT: And why do I get negative intensity if I put all in dynamic and one to setting over 9. It sounds to me like a bug...

So you're mining BTC? Your problem is high cpu, right? So your hardware, along with your settings, and your driver combination are causing it. If you cpu usage is high overall, a dynamic device will be cranked right down into potentially negative levels. Stop trying to go to -I 9 with that many devices. Your bus is likely overloaded.

[-ck]

New version: 3.2.1, 7th June 2013

Tons of new stuff in 3.2 but not surprisingly this brought a few new bugs. This version fixes quite a few bugs mainly for the move to directUSB drivers for all devices.
Just to reiterate: If you are using v3.2+ you will NOT be using the ftdi drivers in either windows or linux. There will be no com ports on windows and no ttyUSB in linux. Please read the appropriate readme for how to configure your hardware to use the new drivers, and bear in mind that some devices do NOT work on usb3 ports - we're still investigating this.


Human readable changelog:

- The avalon display has been simplified to fit within the display alongside other devices - it now only shows the lowest asic cooling fanspeed instead of the case fan.
- Fixed a few crashes on hotplug/unplug/shutdown with USB devices.
- The asicminer block erupters should now work.
- The --device command line has been completely rewritten to support all devices arbitrarily instead of just GPUs and now takes multiple values instead of needing to be used multiple times. Saving device settings to a configuration file should now work  as well
eg: --device 1-3,5
- It now compiles on osx although the only testing so far has shown a bitforce usb device does not work (funny aside: osx claimed to support anonymous semaphores by putting the definition in its header files so that it can get posix compliance, but if you actually use the function it only returns an error saying it's unimplemented).
- Buffers are now used for bflsc and icarus to prevent overflow errors and more apparent hw errors.
- A huge reduction in CPU usage should be apparent with USB devices now as we can bypass the way ftdi normally reads from the device every 1ms.
- Devices that fail and go to ZOMBIE mode are now put at the bottom of the status display.
- Hotplug devices will now appear in the status display.
- If you have disabled stratum pools and are in a balance pool management strategy, the connections will now be dropped to the disabled pools instead of repeatedly connecting and disconnecting.
- Various other bugfixes.


Full changelog:

- Shorten the avalon statline to fit in the curses interface and show the lowest
speed fan cooling the asic devices.
- Set usbdev in usbutils after checking for nodev to avoid trying to access a
dereferenced value.
- AMU usbstatus correct name from enable UART
- Icarus AMU enable the UART
- Only libusb close if libusb release succeeds.
- Failed reads and writes on cgsem_post and cgsem_wait should be extremely rare.
- Implement cgminer specific cgsem semaphores to imitate unnamed semaphore
behaviour on osx which does not support them.
- Set cgusb->buffer to NULL when doing usb_buffer_disable.
- Temporarily fix apple not having semtimedop by ignoring the timeout value.
- BFLSC enable buffered USB reading
- Icarus use buffered USB reading
- bflsc & icarus use usb_ftdi_set_latency
- usb_ftdi_set_latency LOG_ERRs if called incorrectly
- add usb_ftdi_set_latency
- usbutils optional read buffering
- Set the avalon read transfer latency to avoid sleeping when no data is
returned after very short latency settings.
- correct bflsc BFLSC_BUFSIZ max calculation
- Fix build for !curses
- restore max code - since timeout is unsigned
- compile warning - remove unused max
- usb set FTDI latency higher to minimise status bytes
- Check for zero timeout on _usb_write.
- Check for zero timeout in usb read.
- Define a minimum polling time based on frequency of mandatory updates of ftdi
responses at 40ms.
- Sleep right up to the timeout instead of the first half if we find ourselves
polling in _usb_read
- Enforce half timeout sized sleeps in usb_read if we find the device is not
respecting libusb timeouts to avoid polling frequently.
- Add more ASIC documentation.
- Update README
- Remove start device limitation on log window size to allow it to get larger
with hotplugged devices.
- Switch logsize after hotplugging a device.
- Change switch_compact function name to switch_logsize to be used for other
changes.
- Only adjust cursor positions with curses locked.
- devs display - fix GPU duplicate bug
- Do not hotplug enable a device if devices have been specified and the hotplug
device falls outside this range.
- Change the --device parameter parsing and configuration to use ranges and
comma separated values.
- basic copyright statement in API.java
- devs display - show ZOMBIEs after all others
- Modify scrypt kernel message.
- Check for pool_disabled in wait_lp_current
- usbutils semun use proper def for linux which fixes OSX also
- Check for pool enabled in cnx_needed.
- Icarus add delays during intialisation
- Update documentation.
- Update copyrights of modified files.

[LogicalUnit]

+1 for USB Block Erupter support 

[Lucko]

It's still the answer.

I'm not mining LTC... So SCRYPT-README doesn't apply or am I missing something? And I don't have GPU-README. I have README and I have read it. I can't find anything. Did I miss something in it? I just glance over it again. Can't find anything relevant. The only think that might apply is RAM but I have enough of it RAM. More then 1 GB still free...

EDIT: And why do I get negative intensity if I put all in dynamic and one to setting over 9. It sounds to me like a bug...

So you're mining BTC? Your problem is high cpu, right? So your hardware, along with your settings, and your driver combination are causing it. If you cpu usage is high overall, a dynamic device will be cranked right down into potentially negative levels. Stop trying to go to -I 9 with that many devices. Your bus is likely overloaded.

Doesn't seem likely. As I wrote in EDIT. It was ccc.exe. Uninstall it and now is less then 50%. If I disable 50% of devices I still get same(I got the idea of running 2 cgminers)... And I can still LTC mine without hash penalty on CPU. So that also points that CPU is not a problem... I'm not sure how can I test BUS but if taking off or disabling the devices doesn't work... But will look into that...

[pengoau]

hey guys

I have 3 gpus in my system 1 apu and 2 dedicated gpus, how can i startup cgminer with the third gpu (gpu 2) turned off? I tried setting intensity to 0 but that doesn't work.

Do I specify it via the -d switch? If so what is the syntax?

Thanks

[-ck]

hey guys

I have 3 gpus in my system 1 apu and 2 dedicated gpus, how can i startup cgminer with the third gpu (gpu 2) turned off? I tried setting intensity to 0 but that doesn't work.

Do I specify it via the -d switch? If so what is the syntax?

Thanks

-d 0-1 --remove-disabled

[kano]

+1 for USB Block Erupter support 

Yeah funny thing about that
3.1.1 of course worked as serial-USB, the new USB version I put in 3.2.0 worked ... almost only for me

My Fedora desktop seems to auto initialise the UART in the AMU, no matter what, when it is plugged in - but other systems don't it seems.
Fortunately I found a cause and fixed it for 3.2.1

Though I will add, anyone who has a few of them and uses them could they report how it's going?
Thanks.

OK this time I will make a set of 3.2.1a ... out shortly.

[The00Dustin]

Doesn't seem likely. As I wrote in EDIT. It was ccc.exe. Uninstall it and now is less then 50%. If I disable 50% of devices I still get same(I got the idea of running 2 cgminers)... And I can still LTC mine without hash penalty on CPU. So that also points that CPU is not a problem... I'm not sure how can I test BUS but if taking off or disabling the devices doesn't work... But will look into that...

No one seems to have pointed out that you are running Windows.  I'm pretty sure it was mentioned two or three hundred pages ago that you really can't go to higher intensity levels on Windows without CPU usage.  Moreover, it sounds like you're running a really old version if you only have one README file as you mentioned a page or two back.  You've been told not to use -I 9 or higher for sha256 mining like 3 times now.  Don't do it.  When you decide to scrypt mine, which you seemed to imply you would at some point, you can try again, the -I levels are totally different for scrypt.

[CumpsD]

+1 for USB Block Erupter support 

Yeah funny thing about that
3.1.1 of course worked as serial-USB, the new USB version I put in 3.2.0 worked ... almost only for me

My Fedora desktop seems to auto initialise the UART in the AMU, no matter what, when it is plugged in - but other systems don't it seems.
Fortunately I found a cause and fixed it for 3.2.1

Though I will add, anyone who has a few of them and uses them could they report how it's going?
Thanks.

OK this time I will make a set of 3.2.1a ... out shortly.

I'll test the Block Erupter this weekend if I manage the time. Currently running 8 of them on 3.1.1 without problems

[Lucko]

Doesn't seem likely. As I wrote in EDIT. It was ccc.exe. Uninstall it and now is less then 50%. If I disable 50% of devices I still get same(I got the idea of running 2 cgminers)... And I can still LTC mine without hash penalty on CPU. So that also points that CPU is not a problem... I'm not sure how can I test BUS but if taking off or disabling the devices doesn't work... But will look into that...

No one seems to have pointed out that you are running Windows.  I'm pretty sure it was mentioned two or three hundred pages ago that you really can't go to higher intensity levels on Windows without CPU usage.  Moreover, it sounds like you're running a really old version if you only have one README file as you mentioned a page or two back.  You've been told not to use -I 9 or higher for sha256 mining like 3 times now.  Don't do it.  When you decide to scrypt mine, which you seemed to imply you would at some point, you can try again, the -I levels are totally different for scrypt.

Running windows was in original post and copy pasted... And it is recommended not to go but you can go over 9 for some cards it is recommended 11. If it helps you imagine I will go only to 9 what is currently not possible so please tell me how to do that. I have enough CPU power left. Over 50%. I'm running 2.11.4. But same problem is with 3.2.0 and 3.1.1 so I really see no point in that. 3.x version gives me disconnects from my pool. So if you have any suggestion please tell me if not then this is pointless.

EDIT: all in the original post and copy pasted...

EDIT2: or of you have a idea how to test BUS usage...

[kano]

3.2.1a
3.2.1 recompiled on 64 bit Fedora18, 64 bit xubuntu 11.04 and also on the RPi 32 (2012-12-16-wheezy-raspbian and rpi-update)

https://github.com/kanoi/cgminer-binaries

To get the 64 bit xubuntu 11.04 binary:
wget https://github.com/kanoi/cgminer-binaries/raw/master/Ubuntu_11.04_x86_64/cgminer-3.2.1a
chmod +x cgminer-3.2.1a
md5sum cgminer-3.2.1a
7586842d5038b370c3e69f28ca58aa0d  cgminer-3.2.1a
(this version should also work on Fedora 16 and Fedora 17)

To get the RPi 32bit binary:
wget https://github.com/kanoi/cgminer-binaries/raw/master/RPi_32/cgminer-3.2.1a
chmod +x cgminer-3.2.1a
md5sum cgminer-3.2.1a
8b18c3df057e144616ac5d096941f124  cgminer-3.2.1a

To get the Fedora 18 binary:
wget https://github.com/kanoi/cgminer-binaries/raw/master/Fedora18_x86_64/cgminer-3.2.1a
chmod +x cgminer-3.2.1a
md5sum cgminer-3.2.1a
d8f67d916aa00d1cc34967e234b68ef0  cgminer-3.2.1a

For anyone who didn't realise, it's just the executable file to put in place of 'cgminer'
Nothing else needs changing
On xubuntu 11.04 - first get and extract the full binary release from ckolivas and then copy my file in place of 'cgminer'

I've run all three binaries without any problems so far, with 1x6950, 1xJalapeno, 1xAMU, 1xBLT, 1xBFL, 1xICA, 1xMMQ (Total ~8.6GH/s)

All have been built with -g
The -g (instead of -O2) means it's a debug build so if anyone finds a problem and has core dumps enabled, it will dump a much more useful debug core.

Otherwise, the same configure options as cvolivas' binary version for 64 bit xubuntu 11.04
In case anyone was wondering:
CFLAGS="-g -W -Wall" ./autogen.sh --enable-bflsc --enable-icarus --enable-bitforce --enable-modminer --enable-ztex --enable-avalon --enable-scrypt
make clean
make

All USBs (only) for the RPi 32bit version
CFLAGS="-g -W -Wall" ./autogen.sh --enable-bflsc --enable-icarus --enable-bitforce --enable-modminer --enable-ztex --enable-avalon
make clean
make
You will need to install libusb-1.0.0

All USBs (only) for the Fedora18 x86_64 version
CFLAGS="-g -W -Wall" ./autogen.sh --enable-bflsc --enable-icarus --enable-bitforce --enable-modminer --enable-ztex --enable-avalon
make clean
make
You will need to install libusb-1.0.0


Note I have binary folders of ckolivas official release files in my binaries git also, for if you can't get to his downloads
To get them you select the folder (e.g. 3.2.1) then click on the file you want then right-click save-as "View Raw"


Important: Read ASIC-README or FPGA-README about USB configuration on linux and windows

[daemon]

In my previous post I described the problem.
This problem occurs stably on three computers at intervals of approximately 15 minutes.
cgminer 3.2.0
Now, for reasons of clarity, cgminer was started with the - disable-gpu

Here I found the instructions to provide more information about the problem.
The following information from the bt full command:

Thanks for that. It's hard to know if it's crashing in libusb due to a libusb bug or we're calling a libusb function with invalid parameters. I'm inclined to always blame our code first to keep looking for a bug since our code is under very heavy development. We're revamping that section of code somewhat and hopefully indirectly address it.

Thank you so much!
After "git pool && make" Today everything was good. No segfaults!

[FiatKiller]

I should be getting some eruptors next week. Are you saying with 3.2.1, I don't
need any special USB drivers or settings for WIN7? I know things are constantly in flux
with these new devices...

thanks

[bitpop]

No you still have to replace drivers.

[kano]

I should be getting some eruptors next week. Are you saying with 3.2.1, I don't
need any special USB drivers or settings? I know things are constantly in flux
with these new devices...

thanks

On linux, nothing to do, just plug them in and run 3.2.1

On windows, you need to install the WinUSB driver with Zadig, not the default windows driver, then run 3.2.1

[Dunkelheit667]

...
Though I will add, anyone who has a few of them and uses them could they report how it's going?
Thanks.
...

First of all, thank you for taking care!

And here you go. Good news, my AMUs were detected on the rpi. Bad news, declared sick after 60 seconds hashing:

Code:

 AMU 0:                | SICK  /7.402Mh/s | A:1 R:0 HW:0 U: 0.62/m
 AMU 1:                | SICK  / 0.000h/s | A:0 R:0 HW:0 U: 0.00/m
 AMU 2:                | 296.8M/130.5Mh/s | A:5 R:0 HW:0 U: 3.11/m <- got SICK two seconds later
 BLT 0:                | 388.6M/365.3Mh/s | A:4 R:0 HW:0 U: 2.49/m
 AMU 3:                | SICK  / 0.000h/s | A:0 R:0 HW:0 U: 0.00/m

And this happend unplugging and plugging them back:

Code:

 BLT 0:                | 396.0M/380.6Mh/s | A:26 R:0 HW:0 U: 6.64/m
 AMU 4:                | SICK  /2.484Mh/s | A: 1 R:0 HW:0 U: 0.26/m
 AMU 5:                | SICK  /19.96Mh/s | A: 3 R:0 HW:0 U: 0.77/m
 AMU 6:                | SICK  /36.54Mh/s | A: 4 R:0 HW:0 U: 1.02/m
 AMU 7:                | SICK  / 0.000h/s | A: 0 R:0 HW:0 U: 0.00/m
 AMU 0:                | ZOMBIE/41.13Mh/s | A: 3 R:0 HW:0 U: 0.77/m
 AMU 1:                | ZOMBIE/26.55Mh/s | A: 3 R:0 HW:0 U: 0.77/m
 AMU 2:                | ZOMBIE/ 0.000h/s | A: 0 R:0 HW:0 U: 0.00/m
 AMU 3:                | ZOMBIE/18.95Mh/s | A: 2 R:0 HW:0 U: 0.51/m

[The00Dustin]

This happened when I added 5970 and 5770 to my miner. With only 5 cores I didn't have problems. But I do have a mix of cards if that might be a problem. 6790, 6870, 5850, 2x5970, 5770. Running 2.11.4, but the same problem is on 3.2.0(3.x has problems with my pool. I get disconnected all the time).

You've been told not to use -I 9 or higher for sha256 mining like 3 times now.  Don't do it.  When you decide to scrypt mine, which you seemed to imply you would at some point, you can try again, the -I levels are totally different for scrypt.

-I 9 is included in "-I 9 or higher".  Run at -I 8.  None of the cards in your original quote start with a 7 and I'm pretty sure there has been much discussion (again, 2 or 3 hundred pages ago [and again, this may be an especially on Windows situation]) about -I 9 or higher only being useful for 7xxx cards.  Running at too high of an intensity will cause the cards to go slower, which is what you are experiencing.  I don't know how to test the bus, but I don't think you need to worry about testing the bus.  If you were running at higher than -I 8 before, and nothing changed but an additional card on the bus, that seems like a pretty good test/indicator that the bus is overloaded.  If anything else changed at the same time, then you can troubleshoot what else changed by trying to change it back and/or starting from scratch.  If you were running a higher intensity on a different program before, then the numbers don't necessarily mean the same thing on a different program.

[kano]

...
Though I will add, anyone who has a few of them and uses them could they report how it's going?
Thanks.
...

First of all, thank you for taking care!

And here you go. Good news, my AMUs were detected on the rpi. Bad news, declared sick after 60 seconds hashing:

...

Hmm - OK I'll try the AMU on my RPi, I've not plugged it into that due to it needing power.
I've run the Jalapeno, BFL FPGA and BLT (Black Arrow Lancelot) without any trouble at all so far.
Though I have heard of issues in general due to power making it back to the RPi from a powered hub.
I'll see how mine goes ... yep seeing that happen here also.
OK time to track down what's happening.