Author

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

member
Activity: 83
Merit: 10
My miner is having a fairly annoying problem and I have no idea of the reason or solution.
Every couple hours, I get

Code:
 [2013-08-31 13:54:18] Attempting to restart cgminer 3.4.0

in the log, then the miner slows down to around 1/5th of it's usual speed, the fans start randomly changing speeds, almost no work is produced, and cgminer becomes nearly unresponsive in some cases.

What is going on? I don't see any errors being produced, nothing's overheating. It just randomly 'attempts to restart' and then stops working right.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
My miner is having a fairly annoying problem and I have no idea of the reason or solution.
Every couple hours, I get
...
https://bitcointalksearch.org/topic/m.3052634
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Primary cgminer binary download site down. Git repo won't allow downloading of files either right now.

FYI
Down for maintenance yet again. There is an alternate download location listed in the opening post.

Yep. Hence my comment. Git repo says you can't download files of that size right now.

JR

... and ...
3.4.1a 3.4.1 recompiled on:
...
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.4.1) then click on the file you want then right-click save-as the "View Raw" link.
...
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
With the latest cgminer (3.4.1) Windows build, the SOCKS proxy option does not work and is probably broken.
I've setup a local proxy via PuTTY (localhost:9999), and have tried --socks-proxy 127.0.0.1:9999, --socks-proxy localhost:9999, and --socks-proxy socks5://127.0.0.1:9999, to no avail.
I verified that it did not work via Wireshark, which found packets being received and transmitted directly to the pool's IP.
Using (pooler's) cpuminer with the proxy option --proxy socks5://127.0.0.1:9999 works perfectly, with Wireshark not detecting any packets sent to the pool's IP.
Again: Proxies do not work with stratum on cgminer due to me using raw socket code for reliability. You need to use something like proxifier.
newbie
Activity: 50
Merit: 0
With the latest cgminer (3.4.1) Windows build, the SOCKS proxy option does not work and is probably broken.
I've setup a local proxy via PuTTY (localhost:9999), and have tried --socks-proxy 127.0.0.1:9999, --socks-proxy localhost:9999, and --socks-proxy socks5://127.0.0.1:9999, to no avail.
I verified that it did not work via Wireshark, which found packets being received and transmitted directly to the pool's IP.
Using (pooler's) cpuminer with the proxy option --proxy socks5://127.0.0.1:9999 works perfectly, with Wireshark not detecting any packets sent to the pool's IP.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
When cg crashes because you may have a card with to low voltage, is there a way to get it working at full speed again without rebooting?  I have a card (7950) that does say 650 KH/s and when it crashes will only do 390 even if rebuild the bin files. Not sure why but it does that and only a reboot helps. My system has a boot password and is remote so restarting is impossible without a hour drive. Any thoughts?

Window 7 64-bit

Thanks.

JR
It's a driver crash not a cgminer crash. That it can restart at all is a miracle. No solution, just keep tuning your settings to avoid the crash in the first place.
full member
Activity: 147
Merit: 100
When cg crashes because you may have a card with to low voltage, is there a way to get it working at full speed again without rebooting?  I have a card (7950) that does say 650 KH/s and when it crashes will only do 390 even if rebuild the bin files. Not sure why but it does that and only a reboot helps. My system has a boot password and is remote so restarting is impossible without a hour drive. Any thoughts?

Window 7 64-bit

Thanks.

JR
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Primary cgminer binary download site down. Git repo won't allow downloading of files either right now.

FYI
Down for maintenance yet again. There is an alternate download location listed in the opening post.

Yep. Hence my comment. Git repo says you can't download files of that size right now.

JR
I just clicked on one and downloaded it. Works fine. Choose view raw.
full member
Activity: 147
Merit: 100
Primary cgminer binary download site down. Git repo won't allow downloading of files either right now.

FYI
Down for maintenance yet again. There is an alternate download location listed in the opening post.

Yep. Hence my comment. Git repo says you can't download files of that size right now.

JR
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Primary cgminer binary download site down. Git repo won't allow downloading of files either right now.

FYI
Down for maintenance yet again. There is an alternate download location listed in the opening post.
full member
Activity: 147
Merit: 100
Primary cgminer binary download site down. Git repo won't allow downloading of files either right now.

FYI
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
CGMiner seems to be randomly closing. I'm running cgminer-nogpu on Win 8x64 with a BFL Little Single and 2 AMUs. It runs in a batch file that loops, and the batch file keeps restarting it, so it is closing nicely, and I haven't lost any downtime. I think it's done it about 4-5 times since I updated to 3.4.0, which was about 8 days ago? The newest one was this morning, after I had left for work. It had been running for about 2 days solid before that.

It never did this before. The AMUs are pretty new. Is it the AMUs causing it, or upgrading to 3.4.0, or both?
Hard to know without excluding one thing at a time? Try running the AMUs in their own instance and see if one the other or both crashes? Also there are debug builds which would help me find out where it's crashing and fix it.
http://ck.kolivas.org/apps/cgminer/debug/
I ran 2 instances of CGMiner-nogpu like you suggested, one with 2 SC Single (1x 30GH + 1x 60GH), and one with 2 AMUs. The instance with the 2 BFL miners was the one that crashed. I didn't see it happened, as it was about 45 minutes ago, but again my batch file seems to have restarted it. I'll try 3.4.1 and see if anything changed.
It won't debug anything unless you install the debugger as described in the debug readme in there. Anyway see how you go with 3.4.1, I found a few places that could lead to crashes that I fixed in that version. I will also update the debug binaries to be 3.4.1
hero member
Activity: 591
Merit: 500
Hi

longtime happy cgminer user here.

been running under win xp/vista/7 with great results on GPU and now ASICs.

now Im going to use a laptop I got from work so I can retire the old power hog P4/XP rig running the ASICs currently. the laptop has an intel t6600 CPU (dual core 2.2 Ghz) with 2 gigs RAM, 500 gig HD. huge overkill but it was free Smiley

HD was wiped and Im going to install *nix. just not sure which flavor.

currently have a bfl single, bfl jalapeño, and it will have a block erupter on it soon as well. it will mine BTC 24/7.

Im thinking of ubuntu 13.04 as Im somewhat familiar with it, although Ive never run cgminer on it. might even go with dual boot if its easier, ubuntu 13.04 off the HD for occasional non mining and something else via USB flash drive for mining.

any suggestions?
I used Ubuntu for all my mining until I got my Pi and it's always been great for me. Can't really go wrong with it.
legendary
Activity: 4354
Merit: 3614
what is this "brake pedal" you speak of?
Hi

longtime happy cgminer user here.

been running under win xp/vista/7 with great results on GPU and now ASICs.

now Im going to use a laptop I got from work so I can retire the old power hog P4/XP rig running the ASICs currently. the laptop has an intel t6600 CPU (dual core 2.2 Ghz) with 2 gigs RAM, 500 gig HD. huge overkill but it was free Smiley

HD was wiped and Im going to install *nix. just not sure which flavor.

currently have a bfl single, bfl jalapeño, and it will have a block erupter on it soon as well. it will mine BTC 24/7.

Im thinking of ubuntu 13.04 as Im somewhat familiar with it, although Ive never run cgminer on it. might even go with dual boot if its easier, ubuntu 13.04 off the HD for occasional non mining and something else via USB flash drive for mining.

any suggestions?
member
Activity: 83
Merit: 10
My miner is having a fairly annoying problem and I have no idea of the reason or solution.
Every couple hours, I get

Code:
 [2013-08-31 13:54:18] Attempting to restart cgminer 3.4.0

in the log, then the miner slows down to around 1/5th of it's usual speed, the fans start randomly changing speeds, almost no work is produced, and cgminer becomes nearly unresponsive in some cases.

What is going on? I don't see any errors being produced, nothing's overheating. It just randomly 'attempts to restart' and then stops working right.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
3.4.1a 3.4.1 recompiled on:
Fedora 18
64 bit xubuntu 11.04 (should also work on Fedora 16 and 17)
RPi 32bit Arch
RPi 32bit Raspbian

e.g. 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.4.1a
chmod +x cgminer-3.4.1a


The 3 others are:
https://github.com/kanoi/cgminer-binaries/raw/master/Fedora18_x86_64/cgminer-3.4.1a
https://github.com/kanoi/cgminer-binaries/raw/master/RPi_Arch/cgminer-3.4.1a
https://github.com/kanoi/cgminer-binaries/raw/master/RPi_Raspbian/cgminer-3.4.1a

The Xubuntu configure option (with GPU and scrypt):
CFLAGS="-g -W -Wall" ./autogen.sh --enable-bflsc --enable-icarus --enable-bitforce --enable-modminer --enable-ztex --enable-avalon --enable-scrypt

The rest are USB only (no GPU):
CFLAGS="-g -W -Wall" ./autogen.sh --enable-bflsc --enable-icarus --enable-bitforce --enable-modminer --enable-ztex --enable-avalon

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.

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.4.1) then click on the file you want then right-click save-as the "View Raw" link.

Important: Read README, ASIC-README or FPGA-README about USB configuration on linux and windows
legendary
Activity: 952
Merit: 1000
CGMiner seems to be randomly closing. I'm running cgminer-nogpu on Win 8x64 with a BFL Little Single and 2 AMUs. It runs in a batch file that loops, and the batch file keeps restarting it, so it is closing nicely, and I haven't lost any downtime. I think it's done it about 4-5 times since I updated to 3.4.0, which was about 8 days ago? The newest one was this morning, after I had left for work. It had been running for about 2 days solid before that.

It never did this before. The AMUs are pretty new. Is it the AMUs causing it, or upgrading to 3.4.0, or both?
Hard to know without excluding one thing at a time? Try running the AMUs in their own instance and see if one the other or both crashes? Also there are debug builds which would help me find out where it's crashing and fix it.
http://ck.kolivas.org/apps/cgminer/debug/
I ran 2 instances of CGMiner-nogpu like you suggested, one with 2 SC Single (1x 30GH + 1x 60GH), and one with 2 AMUs. The instance with the 2 BFL miners was the one that crashed. I didn't see it happened, as it was about 45 minutes ago, but again my batch file seems to have restarted it. I'll try 3.4.1 and see if anything changed.
hero member
Activity: 840
Merit: 1002
Try a release tarball instead of building from git, but I can't guarantee anything on OSX.

Here's the error compiling from the release tarball:

Code:
  CCLD   cgminer
Undefined symbols for architecture x86_64:
  "_CFDictionaryCreateMutable", referenced from:
      _darwin_init in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_CFDictionarySetValue", referenced from:
      _darwin_init in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_CFGetTypeID", referenced from:
      _darwin_devices_detached in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_CFNumberCreate", referenced from:
      _darwin_init in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_CFNumberGetTypeID", referenced from:
      _darwin_devices_detached in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_CFNumberGetValue", referenced from:
      _darwin_get_interface in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_devices_detached in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_CFRelease", referenced from:
      _darwin_get_interface in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_kernel_driver_active in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_release_interface in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_close in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_init in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_event_thread_main in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_devices_detached in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      ...
  "_CFRetain", referenced from:
      _darwin_open in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_event_thread_main in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_CFRunLoopAddSource", referenced from:
      _darwin_claim_interface in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_open in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_event_thread_main in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_CFRunLoopGetCurrent", referenced from:
      _darwin_event_thread_main in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_CFRunLoopRemoveSource", referenced from:
      _darwin_release_interface in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_close in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_event_thread_main in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_CFRunLoopRun", referenced from:
      _darwin_event_thread_main in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_CFRunLoopStop", referenced from:
      _darwin_exit in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_CFUUIDGetConstantUUIDWithBytes", referenced from:
      _darwin_claim_interface in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _usb_get_next_device in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_CFUUIDGetUUIDBytes", referenced from:
      _darwin_claim_interface in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _usb_get_next_device in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_IOCreatePlugInInterfaceForService", referenced from:
      _darwin_claim_interface in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _usb_get_next_device in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_IOIteratorIsValid", referenced from:
      _usb_get_next_device in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_IOIteratorNext", referenced from:
      _darwin_get_interface in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _process_new_device in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _usb_get_next_device in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_event_thread_main in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_devices_detached in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_IONotificationPortCreate", referenced from:
      _darwin_event_thread_main in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_IONotificationPortDestroy", referenced from:
      _darwin_event_thread_main in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_IONotificationPortGetRunLoopSource", referenced from:
      _darwin_event_thread_main in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_IOObjectRelease", referenced from:
      _darwin_get_interface in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_kernel_driver_active in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_claim_interface in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _process_new_device in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _usb_get_next_device in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_init in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_event_thread_main in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      ...
  "_IORegistryEntryCreateCFProperty", referenced from:
      _darwin_get_interface in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_kernel_driver_active in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_devices_detached in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_IOServiceAddMatchingNotification", referenced from:
      _darwin_event_thread_main in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_IOServiceGetMatchingServices", referenced from:
      _darwin_init in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_IOServiceMatching", referenced from:
      _darwin_init in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_event_thread_main in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "___CFConstantStringClassReference", referenced from:
      CFString in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      CFString in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      CFString in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      CFString in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_kCFAllocatorDefault", referenced from:
      _darwin_get_interface in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_kernel_driver_active in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_init in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_devices_detached in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_kCFAllocatorSystemDefault", referenced from:
      _usb_get_next_device in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_kCFRunLoopCommonModes", referenced from:
      _darwin_open in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_kCFRunLoopDefaultMode", referenced from:
      _darwin_release_interface in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_claim_interface in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_close in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_event_thread_main in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_kCFTypeDictionaryKeyCallBacks", referenced from:
      _darwin_init in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_kCFTypeDictionaryValueCallBacks", referenced from:
      _darwin_init in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_kIOMasterPortDefault", referenced from:
      _darwin_init in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
      _darwin_event_thread_main in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
  "_objc_registerThreadWithCollector", referenced from:
      _darwin_event_thread_main in libusb-1.0.a(libusb_1_0_la-darwin_usb.o)
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make[2]: *** [cgminer] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
hero member
Activity: 840
Merit: 1002
Try a release tarball instead of building from git, but I can't guarantee anything on OSX.
If that fails, the last known good release for osx on git was
git checkout 036c7b73f1244e52a8aedf3990ecf862d03310f4

It's not really a problem of finding a compatible version. I release both Homebrew formulas and precompiled binaries for OS X and haven't been able to provide users with either 3.4.0 or 3.4.1. I am fine with telling my users they have to use an old version of cgminer or use the newest version of some other miner.

Here is more error info, which may help pinpoint the issue:

Code:
configure.ac:39: error: required file '../../ltmain.sh' not found
libusb/Makefile.am:4: warning: source file 'os/darwin_usb.c' is in a subdirectory,
libusb/Makefile.am:4: but option 'subdir-objects' is disabled
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled.  For now, the corresponding output
automake: object file(s) will be placed in the top-level directory.  However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
libusb/Makefile.am:3: warning: source file 'os/linux_usbfs.c' is in a subdirectory,
libusb/Makefile.am:3: but option 'subdir-objects' is disabled
libusb/Makefile.am:33: warning: source file 'os/linux_netlink.c' is in a subdirectory,
libusb/Makefile.am:33: but option 'subdir-objects' is disabled
libusb/Makefile.am:33: warning: source file 'os/linux_udev.c' is in a subdirectory,
libusb/Makefile.am:33: but option 'subdir-objects' is disabled
libusb/Makefile.am:5: warning: source file 'os/openbsd_usb.c' is in a subdirectory,
libusb/Makefile.am:5: but option 'subdir-objects' is disabled
libusb/Makefile.am:6: warning: source file 'os/poll_windows.c' is in a subdirectory,
libusb/Makefile.am:6: but option 'subdir-objects' is disabled
libusb/Makefile.am:6: warning: source file 'os/windows_usb.c' is in a subdirectory,
libusb/Makefile.am:6: but option 'subdir-objects' is disabled
libusb/Makefile.am:42: warning: source file 'os/threads_windows.c' is in a subdirectory,
libusb/Makefile.am:42: but option 'subdir-objects' is disabled
libusb/Makefile.am:42: warning: source file 'os/threads_posix.c' is in a subdirectory,
libusb/Makefile.am:42: but option 'subdir-objects' is disabled
autoreconf: automake failed with exit status: 1
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Big changes to the build process, read changelog for details. If building from git, make sure to do make clean and ./autogen.sh before attempting to build the significantly changed build process.

I am trying to compile from the Git source on OS X. I am cloning into a brand new, clean directory. From there I autogen.sh like I always have, and I get an error:

Code:
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: error: cannot find input file: `Makefile.in'

I've tried using autoconf and automake as the readme file suggests under the "Build cgminer for yourself" but that does not help. I have also tried doing make clean but there is no target for 'clean' as nothing has been configured or build yet.

- Fixed the broken OSX build from 3.4.0, but so many things were changed after that in the build process that it may be broken again.

Try a release tarball instead of building from git, but I can't guarantee anything on OSX.
If that fails, the last known good release for osx on git was
git checkout 036c7b73f1244e52a8aedf3990ecf862d03310f4
Jump to: