Bitcoin Forum
June 24, 2025, 07:46:10 PM *
News: Latest Bitcoin Core release: 29.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 [725] 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 ... 843 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1  (Read 5806361 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic. (3 posts by 1+ user deleted.)
-ck (OP)
Legendary
*
Offline Offline

Activity: 4480
Merit: 1664


Ruu \o/


View Profile WWW
February 25, 2014, 08:48:45 PM
 #14481

Hi when i try to compile cgminer there is an error, can you help me.

Thanks in advance Luca

Code:
  CC       cgminer-driver-hexminera.o
  CC       cgminer-driver-hexminerc.o
There is no hexminer file in cgminer. You are trying to build a forked version of cgminer, not from my official sources. If you wish to do that you need to get help from the person who created the fork, otherwise grab from my sources.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
wolf_miner
Legendary
*
Offline Offline

Activity: 1018
Merit: 1001



View Profile
February 25, 2014, 09:00:36 PM
Last edit: February 25, 2014, 09:38:16 PM by wolf_miner
 #14482

Thanks ckolivas, i will get the official on github  Wink and i retry to build.

Thanks in advance Luca

PS solved - on my system is loaded libusb 1.0.17 so i have to use the option to compile using my system libusb library.
Ourperrin
Newbie
*
Offline Offline

Activity: 3
Merit: 0


View Profile
February 25, 2014, 10:03:26 PM
 #14483

...
Also when I ssh into the pi and start the miner when I close the connection it stops the miner, how can I stop this?
...
https://github.com/kanoi/cgminer-run

Edit: of course that requires 'screen' to be installed

Thanks Kano, how do I install this? What is the command I need to type?

Thanks
Updated the README

https://github.com/kanoi/cgminer-run/commit/79d66cce19e701557519be750fa5f0d482090b2d


Thanks again
sikke
Sr. Member
****
Offline Offline

Activity: 504
Merit: 250


View Profile
February 25, 2014, 11:26:56 PM
 #14484

This thread always has the best fights! *munching Popcorn*

Did some reading to educate myself on the past of these great miner softwares and great people making them, they are all heros to me. ..You hit the spot with popcorn.. it was so enjoyable i laughed rly.

Someday i read all this 730 pages... rly feel it is worth it.

All my support to the devs.
wolfey2014
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250


View Profile WWW
February 26, 2014, 03:37:24 AM
 #14485

Hello, is this the right thread to talk about getting my 5 GC3355 5 chip USB miners, mining?

I have them all powered up, using usb hub, loaded the drivers on my Win7 laptop but not all if any of the miners usb ports were recognized, even after plugging them in one at a time.

But I just tried the same drivers on my XP laptop, plugged in the hub, it was recognzed and loaded, plugged in each miner one at a time via the hub and each one was recognized and driver loaded.

When I try to run cgminer (is this the right program to use?) it runs but tells me "no devices found"

Stuck. Not sure what to try next.
I have never mined so I'm pretty green. Not totally green. Not a total newb. But since most of the programs are evidently still uncompiled and freeware and all in programmer speak, I'm having a hard time fast tracking to getting my miners up and making me some doe!

Please help!
I know I'm just 1 or 2 steps away from mining.

Someone should create a good old fashioned how to manual in laymens terms.

Much appreciated!
Wolfey2014

I Modify Miners Professionally! PM me for details!
-ck (OP)
Legendary
*
Offline Offline

Activity: 4480
Merit: 1664


Ruu \o/


View Profile WWW
February 26, 2014, 03:38:41 AM
 #14486

Hello, is this the right thread to talk about getting my 5 GC3355 5 chip USB miners, mining?
Alas no, the official mainline cgminer code does not support these devices, so you'll have to seek help from whoever is maintaining a fork that does.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
wolfey2014
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250


View Profile WWW
February 26, 2014, 03:52:00 AM
 #14487

Hello, is this the right thread to talk about getting my 5 GC3355 5 chip USB miners, mining?
Alas no, the official mainline cgminer code does not support these devices, so you'll have to seek help from whoever is maintaining a fork that does.

Gee! That sucks! Sad
Can you point me at the right thread/s I need?
I have not had much luck finding any real help.
Thanks for your response and understanding!
wolfey2014

I Modify Miners Professionally! PM me for details!
xjack
Hero Member
*****
Offline Offline

Activity: 539
Merit: 500



View Profile
February 26, 2014, 04:32:26 PM
 #14488

I'm playing with a 49 port tinker toy rig and have a very minor display issue I'd like to resolve. 

Is there anyway I can straighten out the device assignments to get USB devices to display together by type?  It's a headless xubuntu 12.04.2 buried in the back of a data closet.

Going to add a couple of NF and my OCD nerve is starting to twitch.

ANU0   1:29
ANU1   1:28
AMU0   1:27
AMU1   1:26
AMU2   1:25
AMU3   1:24
AMU4   1:23
ANU2   1:22
AMU5   1:21
AMU6   1:20
AMU7   1:19
AMU8   1:18
AMU9   1:17
ANU3   1:16
ANU4   1:15 etc...

4.0 is rock solid for me, but then again - it's been rock solid since 3.3 for me!  Thanks!

xjack - 1xjackDMgJCLn1LDtbgh51DYw6uRgeHVb
Reputation thread - https://bitcointalk.org/index.php?topic=482124.0
Dribble
Newbie
*
Offline Offline

Activity: 11
Merit: 0



View Profile
February 27, 2014, 03:39:49 AM
 #14489

Finally received my terraminers. After set up, I checked and found it running cgminer 3.12.0.

Am I OK running this version? Since you all are talking about 4.0

Thanks for any info regarding this matter.
-ck (OP)
Legendary
*
Offline Offline

Activity: 4480
Merit: 1664


Ruu \o/


View Profile WWW
February 27, 2014, 03:53:43 AM
 #14490

Finally received my terraminers. After set up, I checked and found it running cgminer 3.12.0.

Am I OK running this version? Since you all are talking about 4.0

Thanks for any info regarding this matter.
It's extraordinarily difficult to update the cgminer on the beaglebone TerraMiners are distributed with, and you would void your warranty if you opened the box to connect them via PC, so you don't really have any choice but to depend on cointerra releasing new firmware with a newer cgminer. On the other hand, there are not a lot of code improvements that affect the CT devices after 3.12 so it should be okay, if not the best.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
JoseSan
Member
**
Offline Offline

Activity: 117
Merit: 10


View Profile
February 27, 2014, 07:05:26 PM
 #14491

You're a funny man, Mr. Kolivas  Smiley

https://github.com/ckolivas/cgminer/pull/556
lamero
Newbie
*
Offline Offline

Activity: 6
Merit: 0


View Profile
February 27, 2014, 09:49:18 PM
Last edit: February 27, 2014, 10:18:14 PM by lamero
 #14492

from time to time my PI hang upwith CG 4.0.0?

Hanging Pi?  Try adding the slub_debug=FP boot argument as described here:

http://projectklondike.org/how-to-run#rpi-freeze
This don't helped me. I have random freeze Sad
I have 3.10.25+ firmware and CG 4.0.0
kano
Legendary
*
Offline Offline

Activity: 4676
Merit: 1858


Linux since 1997 RedHat 4


View Profile
February 27, 2014, 10:12:08 PM
 #14493

You're a funny man, Mr. Kolivas  Smiley

https://github.com/ckolivas/cgminer/pull/556
... meanwhile the person who sent the pull request ... isn't

Seriously - a pull request that puts code back into cgminer that's been removed on purpose?
Sigh.

Pool: https://kano.is - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer
JoseSan
Member
**
Offline Offline

Activity: 117
Merit: 10


View Profile
February 27, 2014, 10:36:32 PM
 #14494

You're a funny man, Mr. Kolivas  Smiley

https://github.com/ckolivas/cgminer/pull/556
... meanwhile the person who sent the pull request ... isn't

Seriously - a pull request that puts code back into cgminer that's been removed on purpose?
Sigh.
http://www.youtube.com/watch?v=xECUrlnXCqk
I subscribe to the cgminer listserv and see you guys having to shoot these down pretty often. I just found that one too beautiful not to share with this thread.

..I really hope it's clear BIGKAT is not me...
-ck (OP)
Legendary
*
Offline Offline

Activity: 4480
Merit: 1664


Ruu \o/


View Profile WWW
February 28, 2014, 03:00:24 AM
 #14495

New version: 4.0.1, 28th February 2014

A few fixes for most users on top of 4.0, and some major improvements for hashfast users that hopefully will run in tandem with their 0.4 firmware release.


Human readable changelog:

- Fixed cgminer getting stuck at startup when no pool is valid and getting itself into an endless loop
- Fixed AMUs being detected as failing and resetting them too early
- Made the check for failing devices proportional to hashrate to not get false positives
- Queue size is now adjusted up dynamically when it bottoms out regularly which it may on very high hashrates/many devices
- Fixed ANU and other icarus devices falsely showing higher hashrates by calculating hardware errors - NOTE this means if you were seriously overclocking it before, your hashrate will appear to be lower now, but it was simply reporting wrong before.
- Changed the priority of various threads to bias towards work generation instead of giving the mining threads priority.
- Fixed a crash when a device drops out during an attempt to initialise
- Ava2 voltage detection
- Show the device number on the left without padding
- Fixes for devices that ended in OFF state instead of dropping out to allow them to hotplug
- Hashfast changes:
Multiple devices are now added one by one by hotplugging according to name and then initialising instead of trying to initialise them together which made them fail previously.
Dropping the clock speed on a device failure is limited to default clock speed of 550 and the amount of drop per failure can be configured or disabled with:
Code:
--hfa-fail-drop <arg> Set how many MHz to drop clockspeed each failure on an overlocked hashfast device (default: 10)

If you overclock your hashfast device with --hfa-hash-clock and cgminer detects
it failing to return hashes, it will restart it at a lower clock speed if
possible. Changing this value will allow you to choose how much it will lower
the clock speed or to disable this function entirely.
Devices with newer firmware can be named using the op name feature, or cgminer will generically choose a suitable name for them and display it at startup
Code:
--hfa-name <arg>    Set a unique name for a single hashfast device specified with --usb or the first device found

This command allows you to specify the unique name stored in nvram on a single
hashfast device. This name can be queried from the API stats command and comes
up as "op name". Discrete names are used by cgminer to try to maintain settings
across restarts, unplugs/hotplugs and so on. If this command is used by itself,
the name will be given to the first hashfast device it encounters and then
cgminer will proceed to go back to regular mining. If you have multiple devices,
it is best to discretely choose the device you wish to use with the --usb
command. For example
'lsusb' on linux shows the following devices (297c:0001 is a hfa device):
 Bus 001 Device 079: ID 297c:0001
 Bus 004 Device 042: ID 297c:0001
If you wished to name the second device Slug you would add the commands:
 --hfa-name Slug --usb 4:42
Devices that are re-hotplugged are recognised by their name or serial number if possible and appear back as the same device number on screen
More information in API stats
Updated udev rules file to allow regular users to update firmware
Fixes for corrupt message reading and runs of crc errors
Ability to disable the core shedding feature in new firmware:
Code:
--hfa-noshed        Disable hashfast dynamic core disabling feature

Newer firmwares on hashfast devices dynamically disable cores that generate
invalid data. This command will disable this feature where possible.
Numerous low level fixes


Full changelog:

- Refresh the log window on pool failure message at startup.
- Rework the pool fail to connect at startup to not get stuck indefinitely
repeatedly probing pools with new threads and to exit immediately when any key
is pressed.
- Fix for crashes with a failed startup.
- Use an early_quit function for shutting down when we have not successfully
initialised that does not try to clean up.
- Add more information to a hfa bad sequence tail event.
- Increase the work queue at the top end if we've hit the bottom as well.
- Set the work generation thread high priority, not the miner threads.
- Bringing each hfa device online takes a lot of work generation so only ever do
one at a time.
- Increase the opt_queue if we can hit the maximum amount asked for but are
still bottoming out.
- Keep the old hfa device data intact with a clean thread shutdown to allow it
to be re-hotplugged with the old information.
- Cope with the API calling hfa on partially initialised devices having no info.
- Show only as many digits as are required to display the number of devices.
- Cold plug only one hashfast device to get started, and then hotplug many to
minimise startup delays and possible communication delays causing failed first
starts.
- Send a shutdown and do a usb_nodev if hfa_reset fails.
- Null a device driver should thread prepare fail.
- Add a function for making all driver functions noops.
- Don't try to reinit a device that's disabled.
- Disable a device that fails to prepare.
- Check for lack of thread in watchdog thread for a failed startup.
- Make all device_data dereferences in the hfa driver safe by not accessing it
in statline before when it's non-existent.
- Add an option to disable dynamic core shedding on hashfast devices.
- Do not remove the info struct on a failure to hfa prepare.
- Detect an hfa device purely on the basis of getting a valid header response to
an OP_NAME query, leaving init to hfa_prepare which will allow multiple devices
to start without holding each other up at startup.
- Store the presence and validity of opname in the hfa info.
- api - buffer size off by 1 for joined commands
- minion - clean up statline
- Only break out of usb_detect_one when a new device is found.
- Use usb_detect_one in the hfa driver.
- Provide a usb_detect_one wrapper which only plugs one device at a time,
breaking out otherwise.
- Issue a usb_nodev on a bad work sequence tail in hfa
- Read in hfa stream until we get a HF_PREAMBLE
- Add shed count to hfa API stats output.
- Display the base clockrate for hfa devices with a different name to per die
clockrates to be able to easily distinguish them.
- Use op_name if possible first with hfa devices to detect old instances and be
able to choose the starting clockspeed before sending an init sequence,
reverting to setting op name and serial number as fallbacks.
- Make hfa resets properly inherit across a shutdown.
- Don't break out of hfa_old_device early if there's no serial number.
- Fix harmless warning.
- Allow the drop in MHz per hfa failure to be specified on the command line.
- Icarus - ignore HW errors in hash rate ... and fix detection of them
- Enable the hfa shed supported feature by default.
- Add to udev rules hfa devices for firmware writing.
- Remove ENV from hashfast udev rules.
- Add a --hfa-name command that allows one to specify the unique opname for a
hashfast device.
- Ava2 decode the voltage, get the temp_max
- Set the clock rate with a work restart instead of an init when changing to old
clocks for hfa
- Set opname on hfa devices without a serial number to a hex value based on time
to not overflow the field.
- Add op name to hfa API stats output if it exists.
- Set the actual op_name in hfa devices if cgminer is choosing it itself due to
it being invalid.
- Re-init an hfa device to its old data before setting up info structures as
their sizes may change.
- Remove the usb device whenever we do a running shutdown on hfa and do a
shutdown as the imitated reinit  to allow it to hotplug again.
- Reset opt hfa dfu boot after it's used.
- Comment out windows only transfer on hfa startup.
- Clean up structures unused in case of all failures in hfa detect common
- Clear all structures should we fail to hfa reset on adjusting clock on a
hotplug.
- Set master and copy cgpu hash clock rate for hfa when dropping it on a
restart.
- Set the master hfa clock speed to lower when shutting down a copy.
- Do a clear readbuf on any hfa reset in case the device  has not yet cleanly
shut down.
- Increase hfa fanspeed slightly more when it's rising in the optimal range than
falling.
- Always decrease hfa clock speed on a running shutdown and don't try sending an
init frame since it will be dropped regardless.
- Match hfa devices to old ones based on OP_NAME values before serial numbers if
possible.
- Read off the OP_NAME if it exists and is supported on hfa devices, setting it
to the device serial number or a timestamp if it is invalid.
- Updated hf protocol
- Check for an amount along with no error in hfa clear readbuf
- Hfa clear readbuf can return a nonsense amount when there's a return error so
ignore the amount.
- Running resets always cause a shutdown on hfa meaning the device will
disappear with modern firmware so always kill off the threads to allow
re-hotplugging.
- Reset the hfa hash clock rate to the old one if we find an old instance, only
setting the device id in hfa_prepare
- Keep the device_id on the original zombie thread for HFA in case of further
resets.
- Break out of hfa inherit if there is no device data.
- Inherit the hfa zombie instance after the device id has been allocated.
- The list_for_each_cgpu macro will dereference when there are no mining threads
yet.
- Make hfa hotplug inherit some parameters from a previous instance if the
serial number exists and is matching, avoiding dropping the clock on all
devices.
- Per device last getwork won't work if the device stops asking for work.
- Use the share_work_tdiff function in the driver watchdogs.
- Provide a helper function for determining time between valid share and getwork
per device.
- Store last_getwork time on a per-device basis.
- Limit the decrease of hfa clock rate on reset to the default clockrate.
- Base the hfa failure time on the current expected hashrate instead of a static
15 seconds.
- We shouldn't be trying to read from the hfa_send_shutdown function itself.
- Reset the icarus failing flag only when a valid nonce is found.
- Transferred value is corrupt on a NODEV error in usbutils.
- Set each miner thread last valid work just before starting its hash loop in
case there are delays at startup.
- Only memcopy *transferred data in usbutils if we have received only success or
a non-fatal error.
- Increase to 25 nonce ranges on icarus fail detect.
- Set icarus device fail time to be dependent on device speed to avoid falsely
detecting failure on slower AMU devices.
- Updated hf protocol header.
- Updated BE hf protocol header.
- Take into account shed cores on hfa devices when determining how many jobs to
send.
- Fix compilation error with two avalon types.
- Fix missing A1 files from distribution.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
Karin
Member
**
Offline Offline

Activity: 109
Merit: 10



View Profile WWW
February 28, 2014, 11:01:08 AM
 #14496

Unofficial Mac binaries have been updated for v4.0.1 and tested, and are available here.

These are precompiled universal binaries that support Mac OS X 10.5.8 through 10.9+.

Also, the forum thread title is still 4.0.0 Smiley

Easiest to use bitcoin/litecoin miner for Mac: AsteroidApp.com | @AsteroidApp | Bitcointalk forum thread
Unofficial cgminer for Mac OS X | sgminer for Mac OS X
KyrosKrane
Sr. Member
****
Offline Offline

Activity: 295
Merit: 250


View Profile WWW
March 01, 2014, 03:16:56 PM
 #14497

- Fixed AMUs being detected as failing and resetting them too early
Does this mean it's now safe to use 4.0.1 with Block Erupters again?

Tips and donations: 1KyrosREGDkNLp1rMd9wfVwfkXYHTd6j5U  |  BTC P2Pool node: p2pool.kyros.info:9332
os2sam
Legendary
*
Offline Offline

Activity: 3586
Merit: 1099


Think for yourself


View Profile
March 01, 2014, 03:28:23 PM
 #14498

- Fixed AMUs being detected as failing and resetting them too early
Does this mean it's now safe to use 4.0.1 with Block Erupters again?

Give it a try and let us know.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
-ck (OP)
Legendary
*
Offline Offline

Activity: 4480
Merit: 1664


Ruu \o/


View Profile WWW
March 01, 2014, 09:13:37 PM
 #14499

- Fixed AMUs being detected as failing and resetting them too early
Does this mean it's now safe to use 4.0.1 with Block Erupters again?
That's what the change is for...

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
canford
Member
**
Offline Offline

Activity: 89
Merit: 10


View Profile WWW
March 01, 2014, 10:36:04 PM
 #14500

- Fixed AMUs being detected as failing and resetting them too early
Does this mean it's now safe to use 4.0.1 with Block Erupters again?
That's what the change is for...

Running 12 BE's with 4.0.1, working well.  Also updated Avalon Mini to 4.0.1, no issues.  Though oddly, the Mini has slowed down from 62 GH/s to 59 GH/s over a period of months, unrelated to cgminer - I suspect some of the chips have failed.

Пoльзyйтecь бecплaтнo и пишитe чтo вaм нyжнo yлyчшить:trd.ai
Bидeo, кaк пoльзoвaтьcя пpoeктoм:https://www.youtube.com/watch?v=pNhx715vOOk&feature=youtu.be
Pages: « 1 ... 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 [725] 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 ... 843 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!