Author

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

hero member
Activity: 840
Merit: 1002
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.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
FWIW, I've not been able to run a version of CGMiner higher than 3.3.1 for longer than 48 hours driving Erupter USB's on Windows 7 64 bit or Windows 8 64 bit. 3.4.0 just died on me across two rigs.

Any version that uses the new USB drivers eventually crashes on me with mwsock.dll causing the error under Windows Sad

Have there been other reports of this perchance ?

Yeah, same here.. same setup (Win7 64bit).. never really checked the crash/dump though to confirm that dll.

I got this, this morning as well.  Win7 64 bit.

In my case I was running 4 instances and the three Stratum crashed and the one Getwork was still working.

Don't know if that means anything?
Try 3.4.1 Smiley
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
New release: Version 3.4.12, 1st September 2013

Happy Father's day (in Australia, dunno about rest of the world). 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. Sorry I can't provide avalon firmware now since I went to push the reset button on my avalon and instead of it pressing it broke off... so I don't trust myself to make untested brickwarefirmware as I just mine on it via a USB cable to my PC now.

EDIT: 3.4.2 released shortly after with hotfix for crash on BFLSC


Human readable changelog:

3.4.2:
- Fixed crash with BFLSC hardware.
- Added ability to put arbitrary values in miner.php

3.4.1:
- Libusb and jansson have  both been updated to the latest version and are now part of the build tree.
- Libusb and jansson will both be built into the binary statically so all binaries will include the latest version of these libraries, avoiding the problems associated with older versions.
- There is no need for libusb dev or jansson dev to be installed when compiling cgminer now.
- Linux users will now need to install libudev dev to build for any usb devices.
- API muticast listener option --api-mcast so you can request all cgminer APIs on the local network to identify themselves on request
- Also a new $mcast option in miner.php to automatically find all your cgminers that are using the --api-mcast option and related sample Java code MCast.java/MCast.class
- New Icarus timing limit option for short and long timing, that can be set appropriately to ensure no device idle time if timing estimates the timeout badly
- Bugfixes for numerous causes of corruption/crashes in stratum, usb, avalon and bflsc code.
- Some rare errors in BFLSC messages were being ignored, they should now show up.
- 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.
- Some hardware errors were being counted in diff1shares in avalon code leading to a mismatch of diff1 vs diffa+diffr. This has been corrected, but it will make the hardware error percentage look higher (though the actual amount will not have changed).
- Maximum avalon frequency is now 1000 instead of 450 since some overclockers have pushed beyond 450.
- Use higher resolution timers consistently on windows now.


Full changelog:

3.4.2:
- take_queued_work_bymidstate should use a write lock.
- miner.php coding warning
- miner.php disable 'gen' by default
- miner.php allow formula generation of new fields
- miner.php add doctype
- miner.php remove incorrect echo
- miner.php optional error if not enough mcast rigs are found

3.4.1:
- API mcast add a description option with miner.php
- Always use a maxpacketsize buffer in usb_bulk_transfer
- bflsc ensure getinfo cannot overflow its storage buffer
- Don't decref json values in stratum parsing due to memory corruption.
- Use 64 bytes for all libusb control transfers.
- Skip dissecting opt->names in parse_config if it doesn't exist.
- Use an internal buffer in _usb_transfer_read in case the read is larger than
the buffer passed to it.
- ICA optional limit timing with short=N or long=N
- Revert to old custom tolines function since strtok_r is not portable.
- bflsc remove unused commented out code
- logging - code mistake
- logging - applogsiz() for large messages
- Provide base structures for getaddrinfo.
- Include string.h in bflsc driver.
- Get rid of linear removal of spaces in bflsc text parsing and use strstr
throughout instead.
- Use reentrant strtok in tolines() function in bflsc to avoid racing on
contextless calls.
- Show how small a too small result in bflsc is.
- Duplicate the buffer in process_results in bflsc since strtok modifies it
making debugging output limited to one line.
- Only process nonces in bflsc if the breakdown function succeeds.
- Ignore zero count messages in bflsc instead of trying to parse them.
- Return ok in tolines when it doesn't match inprocess message for bflsc.
- Remove inprocess line instead of deleting all following responses in bflsc.
- Change ok testing logic in breakdown() in bflsc and return if not ok at any
stage.
- Check the return value of tolines in bflsc driver.
- Use strtok to parse lines in bflsc driver.
- Add libusb-1.0 m4 directory and gitignore file.
- Properly convert from ranlib to lt_init in configure.ac
- Make autoconf always build for libusb.
- More autoconf fixes.
- Unconditionally build jansson statically from the cgminer source tree.
- Only test for all usb devices once in configure.ac
- Fix various libusb warnings and possible bugs on linux build.
- Add make clean and maintainer-clean to autogen
- Remove examples from libusb Makefile and generated autoconf files.
- Fix libusb subdirectory builds.
- Remove cached files from libusb autoconf on running autogen.sh
- Remove unused HAVE_LISBUSB macro and use USE_USBUTILS everywhere.
- Use direct auto* files to avoid failure of autoreconf
- Remove unused and maintainer cleaned files
- Show RT_LIBS in ./configure output.
- First import of libusb-1.0
- bflsc xlinkstr use snprintf
- Fix win32 build.
- Use take_queued_work_bymidstate in the bflsc driver to avoid the rare chance
repeated results come back from the same work item.
- Provide a function that looks up queued work by midstate and then removes it
from the device hash database.
- Fix no -rt library on darwin.
- Update included jansson to v2.4
- Fix OSX build.
- Provide an osx fix for cgtimers and a fallback to timevals for all other
platforms !linux !win32 !osx.
- Move two more timer functions out of define macros to enable them to be used
by future osx code.
- cgtimer_sub is now the same since cgtimer_t should be the same on all
platforms.
- miner.php fix missing global
- Only count submitted nonces as diff1shares if they're valid.
- Substantially raise the maximum avalon frequency for water-cooled, over-volted
designs.
- Compile MCast.java with an old java
- API Multicast sample MCast.java+MCast.class
- BTB show C/MHz/mV for device
- api.c remove unused reply string
- api.c fix mcast debug message bug
- miner.php implement API Multicast handling to automatically find your local
net miners
- API mcast only reply to remote IP's that are allowed access
- Initial API Multicast response v0.1 to find cgminer APIs
- Use timespecs on windows as cgtimer_t to capitalise on the higher resolution
clock changes.
- Abstract out the conversion of system time to an lldiv_t in decimicroseconds.
- Use our own gettimeofday implementation on windows for it to be consistent
across ming builds and higher resolution.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Actually, yes. If I wanted to know how many diff1 shares I've submitted, I would multiply. To me, and some others looking back on this thread, the new information is useless and alarming.
So what exactly would you multiply by?
You have to know the diff1 total, divide it by the old A ... and that answer you can multiply by the old A to get the diff1 total Smiley
... So yeah you can multiply as long as you already know the answer ...
You see ... not every share is the same diff ................

I know not every share is the same diff, but CGMiner shows the share diff on the screen.
No - it shows the current share diff target.
That changes.

Only with VARDIFF.
What pool doesn't?
If not - then use a proper pool Tongue

http://middlecoin.com/
Lulz a random altcoin pool
legendary
Activity: 3583
Merit: 1094
Think for yourself
FWIW, I've not been able to run a version of CGMiner higher than 3.3.1 for longer than 48 hours driving Erupter USB's on Windows 7 64 bit or Windows 8 64 bit. 3.4.0 just died on me across two rigs.

Any version that uses the new USB drivers eventually crashes on me with mwsock.dll causing the error under Windows Sad

Have there been other reports of this perchance ?

Yeah, same here.. same setup (Win7 64bit).. never really checked the crash/dump though to confirm that dll.

I got this, this morning as well.  Win7 64 bit.

In my case I was running 4 instances and the three Stratum crashed and the one Getwork was still working.

Don't know if that means anything?
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Actually, yes. If I wanted to know how many diff1 shares I've submitted, I would multiply. To me, and some others looking back on this thread, the new information is useless and alarming.
So what exactly would you multiply by?
You have to know the diff1 total, divide it by the old A ... and that answer you can multiply by the old A to get the diff1 total Smiley
... So yeah you can multiply as long as you already know the answer ...
You see ... not every share is the same diff ................

I know not every share is the same diff, but CGMiner shows the share diff on the screen.
No - it shows the current share diff target.
That changes.

Only with VARDIFF.
What pool doesn't?
If not - then use a proper pool Tongue
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Actually, yes. If I wanted to know how many diff1 shares I've submitted, I would multiply. To me, and some others looking back on this thread, the new information is useless and alarming.
So what exactly would you multiply by?
You have to know the diff1 total, divide it by the old A ... and that answer you can multiply by the old A to get the diff1 total Smiley
... So yeah you can multiply as long as you already know the answer ...
You see ... not every share is the same diff ................

I know not every share is the same diff, but CGMiner shows the share diff on the screen.
No - it shows the current share diff target.
That changes.
hero member
Activity: 737
Merit: 500
I just fetched the latest CGMiner, and oh, god, what happened to the share logging? Please change it back.
If you mean A: and R: (and WU:) no it will not be changed back to displaying meaningless information Tongue

It was very much meaningful information. It told me how many shares I have submitted.
So let me get this straight, rather than have it tell you how much work you've done that the pool will reward you for, you want a variable on the screen from the cpu mining era of diff1 shares that today correlates with absolutely nothing at all unless you happen to mine on one of the last remaining pools that accepts diff1 shares, in which case the result is equal to what's shown in the current cgminer anyway?

I like it the way it is now.  Please don't change it back.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
Actually, yes. If I wanted to know how many diff1 shares I've submitted, I would multiply. To me, and some others looking back on this thread, the new information is useless and alarming.
So what exactly would you multiply by?
You have to know the diff1 total, divide it by the old A ... and that answer you can multiply by the old A to get the diff1 total Smiley
... So yeah you can multiply as long as you already know the answer ...
You see ... not every share is the same diff ................
hero member
Activity: 574
Merit: 501
If you can multiply, you can probably divide also, right?
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
I just fetched the latest CGMiner, and oh, god, what happened to the share logging? Please change it back.
If you mean A: and R: (and WU:) no it will not be changed back to displaying meaningless information Tongue

It was very much meaningful information. It told me how many shares I have submitted.
So let me get this straight, rather than have it tell you how much work you've done that the pool will reward you for, you want a variable on the screen from the cpu mining era of diff1 shares that today correlates with absolutely nothing at all unless you happen to mine on one of the last remaining pools that accepts diff1 shares, in which case the result is equal to what's shown in the current cgminer anyway?
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
I just fetched the latest CGMiner, and oh, god, what happened to the share logging? Please change it back.
If you mean A: and R: (and WU:) no it will not be changed back to displaying meaningless information Tongue
hero member
Activity: 981
Merit: 500
DIV - Your "Virtual Life" Secured and Decentralize
legendary
Activity: 1652
Merit: 1067
Christian Antkow
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
... it ran out of memory ...
newbie
Activity: 31
Merit: 0
cgminer on my avalon just crashed, and I found this in the kernel log:

Code:
[375254.850000] miner/0 invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
[375254.850000] Call Trace:
[375254.850000] [<8006dd8c>] dump_stack+0x8/0x34
[375254.860000] [<800b6b84>] dump_header.isra.16+0x44/0x128
[375254.860000] [<800b6ec8>] oom_kill_process+0xd4/0x3b0
[375254.870000] [<800b7600>] out_of_memory+0x28c/0x2e4
[375254.870000] [<800ba698>] __alloc_pages_nodemask+0x540/0x624
[375254.880000] [<800b6194>] filemap_fault+0x294/0x3e8
[375254.880000] [<800cc380>] __do_fault+0xcc/0x444
[375254.890000] [<800cf1a8>] handle_pte_fault+0x32c/0x6dc
[375254.890000] [<800cf608>] handle_mm_fault+0xb0/0xdc
[375254.900000] [<80071208>] do_page_fault+0x110/0x354
[375254.900000] [<80060820>] ret_from_exception+0x0/0xc
[375254.910000]
[375254.910000] Mem-Info:
[375254.910000] Normal per-cpu:
[375254.920000] CPU    0: hi:    0, btch:   1 usd:   0
[375254.920000] active_anon:4982 inactive_anon:36 isolated_anon:0
[375254.920000]  active_file:2 inactive_file:54 isolated_file:0
[375254.920000]  unevictable:0 dirty:0 writeback:0 unstable:0
[375254.920000]  free:180 slab_reclaimable:232 slab_unreclaimable:784
[375254.920000]  mapped:1 shmem:130 pagetables:75 bounce:0
[375254.920000]  free_cma:0
[375254.950000] Normal free:720kB min:720kB low:900kB high:1080kB active_anon:19928kB inactive_anon:144kB active_file:8kB inactive_file:216kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:32512kB managed:28856kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:520kB slab_reclaimable:928kB slab_unreclaimable:3136kB kernel_stack:392kB pagetables:300kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:88 all_unreclaimable? yes
[375254.990000] lowmem_reserve[]: 0 0
[375255.000000] Normal: 0*4kB 0*8kB 1*16kB (R) 0*32kB 1*64kB (R) 1*128kB (R) 0*256kB 1*512kB (R) 0*1024kB 0*2048kB 0*4096kB = 720kB
[375255.010000] 191 total pagecache pages
[375255.010000] 0 pages in swap cache
[375255.010000] Swap cache stats: add 0, delete 0, find 0/0
[375255.020000] Free swap  = 0kB
[375255.020000] Total swap = 0kB
[375255.030000] 8192 pages RAM
[375255.030000] 921 pages reserved
[375255.030000] 30 pages shared
[375255.030000] 7014 pages non-shared
[375255.040000] [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name
[375255.050000] [  430]     0   430      220       15       3        0             0 ubusd
[375255.050000] [  432]     0   432      192       13       3        0             0 askfirst
[375255.060000] [  534]     0   534      368       44       5        0             0 netifd
[375255.070000] [  624]     0   624      379       22       4        0             0 crond
[375255.080000] [  632]     0   632      289       18       3        0             0 dropbear
[375255.090000] [  648]     0   648      292       28       5        0             0 uhttpd
[375255.090000] [  678] 65534   678      239       22       4        0             0 dnsmasq
[375255.100000] [  690]     0   690      375       18       4        0             0 ntpd
[375255.110000] [22605]     0 22605    14642     4592      18        0             0 cgminer
[375255.120000] [29206]     0 29206      374       17       4        0             0 sh
[375255.130000] [29207]     0 29207      374       17       5        0             0 cgminer-monitor
[375255.130000] [29213]     0 29213      374       17       5        0             0 cgminer-monitor
[375255.140000] [29214]     0 29214      193        9       3        0             0 cgminer-api
[375255.150000] [29215]     0 29215      372       11       3        0             0 grep
[375255.160000] Out of memory: Kill process 22605 (cgminer) score 605 or sacrifice child
[375255.170000] Killed process 22605 (cgminer) total-vm:58568kB, anon-rss:18368kB, file-rss:0kB
sr. member
Activity: 295
Merit: 250
1 - Reinstalled the operating system
2 - Installed all the drivers
3 - Installed any and all software
4 - Created a RESTORE POINT (IMPORTANT: Do not insert a single erupter before this point)
I wonder, would you be able to do this with a virtual machine instead? Create a VM with just Windows 7, cgminer, and the drivers installed, then save the state.  Next plug in the miners and do the USB device forwarding. Then, if there's some sort of issue, just reset the virtual machine to the saved state each time. I guess the hard part would just be forwarding 181 USB devices to the virtual machine...
hero member
Activity: 807
Merit: 500
hello!
Cgminer works well with sha256, but with scrypt does not.
It shows 850 kH (it's too much, right?), with no sound/submitted shares for 3 hours.
Is problem in config or in driver?
Code:
"kernel" : "poclbm",
I have a Radeon Hd4870 512MB+ Catalyst 11.12 + Win XP (1.5G RAM)
Pretty sure you don't want to use a sha256 kernel when you're scrypt mining.  Definitely remove that, also try Aurum's posted advice.
legendary
Activity: 1361
Merit: 1003
Don`t panic! Organize!
hello!
Cgminer works well with sha256, but with scrypt does not.
It shows 850 kH (it's too much, right?), with no sound/submitted shares for 3 hours.
Is problem in config or in driver?
(...)
I have a Radeon Hd4870 512MB+ Catalyst 11.12 + Win XP (1.5G RAM)

Probably all HW errors...
sr. member
Activity: 453
Merit: 250
dfgfdgfdg
hello! Cgminer works well with sha256, but with scrypt does not. It shows 850 kH (it's too much, right?), with no sound/submitted shares for 3 hours. Is problem in config or in driver?
Code:
{
"pools" : [
{
"url" : "stratum+tcp://127.0.0.1:3333",
"user" : "2",
"pass" : "x"
}
]
,
"scrypt" : true,
"intensity" : "5",
"vectors" : "2",
"worksize" : "64",
"kernel" : "poclbm",
"lookup-gap" : "0",
"thread-concurrency" : "0",
"shaders" : "0",
"gpu-engine" : "600-840",
"gpu-fan" : "50-100",
"gpu-memclock" : "470-900",
"gpu-memdiff" : "0",
"auto-gpu" : true,
"auto-fan" : true,
"gpu-powertune" : "0",
"gpu-vddc" : "0.000",
"temp-cutoff" : "95",
"temp-overheat" : "90",
"temp-target" : "80",
"api-port" : "4028",
"expiry" : "120",
"gpu-dyninterval" : "7",
"gpu-platform" : "0",
"gpu-threads" : "2",
"hotplug" : "5",
"log" : "5",
"no-pool-disable" : true,
"queue" : "1",
"scan-time" : "60",
"temp-hysteresis" : "2",
"shares" : "0",
"kernel-path" : "/usr/local/bin"
}
I have a Radeon Hd4870 512MB+ Catalyst 11.12 + Win XP (1.5G RAM)
Try this config for starters. Then look here to fine tune: https://en.bitcoin.it/wiki/Mining_hardware_comparison
"scrypt" : true,
"intensity" : "13",
"vectors" : "2",
"worksize" : "128",
"lookup-gap" : "2",
"thread-concurrency" : "4000",
"shaders" : "800",
"gpu-engine" : "750",
"gpu-fan" : "25-100",
"gpu-memclock" : "900",
"auto-fan" : true,
"gpu-vddc" : "0.000",
"temp-cutoff" : "95",
"temp-overheat" : "90",
"temp-target" : "80",
"api-port" : "4028",
"gpu-threads" : "1",
"hotplug" : "0",
"log" : "5",
"temp-hysteresis" : "6",
"shares" : "0",
"kernel-path" : "/usr/local/bin"
Jump to: