who can gvie me a cgminer(AMD) for MAX??
You're in the wrong place. cgminer is a bitcoin miner ONLY and has no GPU code any more. Try sgminer. 
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 128. (Read 5805649 times)
February 08, 2014, 03:42:42 AM
February 08, 2014, 03:41:27 AM
who can gvie me a cgminer(AMD) for MAX??
February 08, 2014, 02:01:45 AM
Uploaded 3.12.3 with the correct fix now, reused same announce post.
Thank you Con!I will give it a shot and report back if get work locks are gone.
However I see that you still write in last_device_valid_work get_work without a lock. Is it ok? Every where you use locks when writing to it but not in get work
Thank you
I will post back my results in a couple of hours
February 08, 2014, 01:58:35 AM
Uploaded 3.12.3 with the correct fix now, reused same announce post.
Thank you Con!I will give it a shot and report back if get work locks are gone.
However I see that you still write in last_device_valid_work get_work without a lock. Is it ok? Every where you use locks when writing to it but not in get work
Thank you
February 08, 2014, 01:47:31 AM
Uploaded 3.12.3 with the correct fix now, reused same announce post.
Thank you Con!I will give it a shot and report back if get work locks are gone.
However I see that you still write in last_device_valid_work get_work without a lock. Is it ok? Every where you use locks when writing to it but not in get work
Thank you
February 08, 2014, 01:19:09 AM
There are 2 temps.
The one passed there is the internal to the KLN temp target.
The code one is:
The abort temp:
KLN_KILLWORK_TEMP 53.5
It stops until it cools down to
KLN_COOLED_DOWN 45.5
Thanks, Kano, appreciate the reply. The one passed there is the internal to the KLN temp target.
The code one is:
The abort temp:
KLN_KILLWORK_TEMP 53.5
It stops until it cools down to
KLN_COOLED_DOWN 45.5
Does that mean the temp in the settings file isn't actually used by cgminer? It's just passed to the Klondike device itself and used there? Other than recompiling, is there a way to modify KLN_KILLWORK_TEMP? I'm guessing no; all caps usually indicates a constant in the code.
February 07, 2014, 10:56:41 PM
Couple of small questions for you guys, please.
I've got a small farm of block erupters. One of them is showing massive hardware errors, so I suspect it's going bad. Is there an easy way to identify the physical device, short of unplugging all my erupters one by one until the bad one goes zombie?
Secondly, I have a few Klondike based miners. In the config file, I have this setting:
At startup, cgminer clearly is reading the setting; it outputs a line with the Klondike setting that has the right frequency and says the cutoff temp is 65 (too fast for me to copy/paste). However, in actual hashing, the cutoff temp is 55. I remember reading something from a few months back where either Con or Kano mentioned that the 55 is hard coded, but I lost track of the issue and what the resolution was. Was that ever fixed, or is it intentional that the temp is locked at 55? I'd rather not do a personal compilation of cgminer if I can avoid it.
Thanks in advance.
There are 2 temps.I've got a small farm of block erupters. One of them is showing massive hardware errors, so I suspect it's going bad. Is there an easy way to identify the physical device, short of unplugging all my erupters one by one until the bad one goes zombie?
Secondly, I have a few Klondike based miners. In the config file, I have this setting:
Code:
"klondike-options": "340:65",
At startup, cgminer clearly is reading the setting; it outputs a line with the Klondike setting that has the right frequency and says the cutoff temp is 65 (too fast for me to copy/paste). However, in actual hashing, the cutoff temp is 55. I remember reading something from a few months back where either Con or Kano mentioned that the 55 is hard coded, but I lost track of the issue and what the resolution was. Was that ever fixed, or is it intentional that the temp is locked at 55? I'd rather not do a personal compilation of cgminer if I can avoid it.
Thanks in advance.
The one passed there is the internal to the KLN temp target.
The code one is:
The abort temp:
KLN_KILLWORK_TEMP 53.5
It stops until it cools down to
KLN_COOLED_DOWN 45.5
February 07, 2014, 10:12:37 PM
...
Woo, now I just need a Raspbian binary and I can finally ditch bfgminer.
Woo, now I just need a Raspbian binary and I can finally ditch bfgminer.
I've put out 3.12.1a as I've done before
I'll make it a brief post
https://github.com/kanoi/cgminer-binaries
For you, it'll be under the RPi_Arch or RPi_Raspbian folders.
The *bab versions are all USB + BaB so don't use them if you don't have BaB boards
The *a versions are all USB.
I've also created another git that explains how to configure linux to start cgminer and keep it running.
https://github.com/kanoi/cgminer-run
New regarding 3.12.1
There is a 'little' change in there called
"- API allow multiple commands/replies in one request"
That one is actually quite significant for anyone who uses the API a lot.
With API V3.1 you can send more than one report command in one request.
It's only for report replies that require no parameters e.g. summary, pools, devs, config, stats etc
It's simple enough, you simply send the commands '+' together.
So to get summary and config in the same reply you send summary+config as the command
See API-README for more details and the format of the reply.
https://github.com/ckolivas/cgminer/blob/master/API-README#L112
February 07, 2014, 07:29:58 PM
Uploaded 3.12.3 with the correct fix now, reused same announce post.
February 07, 2014, 06:50:11 PM
Mines still pulling blocks. I've still got some eroupters so at least they go bright green when they are bored with no work. They are like the dog you wish bit the mailman harder.
February 07, 2014, 06:32:11 PM
Okay I'm just going to go cry in the corner for a bit, for it appears the fix in 3.12.2 didn't fix it. 
(Sorry Karin)
EDIT: Hit it in a debugger so I finally know what the problem REALLY is now... wait for a hotfix to the hotfix.
(Sorry Karin)EDIT: Hit it in a debugger so I finally know what the problem REALLY is now... wait for a hotfix to the hotfix.
February 07, 2014, 05:31:08 PM
Unofficial Mac binaries have been updated for v3.12.2 and are available here.
These are precompiled universal binaries that support Mac OS X 10.5.8 through 10.9+.
These are precompiled universal binaries that support Mac OS X 10.5.8 through 10.9+.
February 07, 2014, 04:34:43 PM
New releases: 3.12.3 - 8th February 2014
Palindromic double hotfix release...
Human readable changelog:
3.12.3:
- Fix for the sitting idle doing nothing bug.
- Add temperature to API devs call for hashfast devices
3.12.2:
- Brought back USB reset attempts on communication errors.
- Fixed the need for adding icarus-timing when overclocking antminer U1devices.
Full changelog:
3.12.3:
- Put the hashfast temperature into the cgpu structure so that it shows up in
the devs API call.
- We shouldn't block on no work situations directly from the getwork scheduler
itself.
3.12.2:
- Adjust antminer U1 timing according to command line frequency set, fixing the
need for icarus timing on the command line.
- Read pipe errors that don't clear are worth attempting to reset the usb.
- Revert "Do away with usb resets entirely since we retry on both pipe and io
errors now and they're of dubious value."
Palindromic double hotfix release...
Human readable changelog:
3.12.3:
- Fix for the sitting idle doing nothing bug.
- Add temperature to API devs call for hashfast devices
3.12.2:
- Brought back USB reset attempts on communication errors.
- Fixed the need for adding icarus-timing when overclocking antminer U1devices.
Full changelog:
3.12.3:
- Put the hashfast temperature into the cgpu structure so that it shows up in
the devs API call.
- We shouldn't block on no work situations directly from the getwork scheduler
itself.
3.12.2:
- Adjust antminer U1 timing according to command line frequency set, fixing the
need for icarus timing on the command line.
- Read pipe errors that don't clear are worth attempting to reset the usb.
- Revert "Do away with usb resets entirely since we retry on both pipe and io
errors now and they're of dubious value."
February 07, 2014, 03:53:16 PM
I have tried multiple pools, ran some from a few hours to a day, and not even get recognized.
I am using a Radeon HD 4650 on LUbuntu12.04, Catalyst 13.1
It shows I am getting 300Kh/s
./cgminer -o stratum+tcp://mine-doge.cryptoculture.net:22555 -u broadway.work -p mine --api-listen --api-network --gpu-reorder --auto-fan
If I add --scrypt before the -o I will get 0Kh/s
Have tried setting --thread-concurrency --shaders and a few more with no luck
I am using a Radeon HD 4650 on LUbuntu12.04, Catalyst 13.1
It shows I am getting 300Kh/s
./cgminer -o stratum+tcp://mine-doge.cryptoculture.net:22555 -u broadway.work -p mine --api-listen --api-network --gpu-reorder --auto-fan
If I add --scrypt before the -o I will get 0Kh/s
Have tried setting --thread-concurrency --shaders and a few more with no luck
GPU support ended after version 3.7.2
I have 2.9.5
February 07, 2014, 03:41:23 PM
WARNING: There may be a problem with cgminer 3.12.1 that makes it stop retrieving work. I will investigate further and possibly release a fix in the next 24 hours. In the meantime I suggest users do not upgrade.
Sigh.
Sigh.
The Antminer U1 support isn't very stable either, mine all crapped out after an hour or so, I ended up with 50-odd as they dropped out and came back on. I have 10 of them on a Anker hub, running off a PC running Debian Wheezy.
ANU7: Comms error (werr=-9 something something)
Then it disables, and a few seconds later the miner reappears using Hotplug and gets a new number. Then I get a load of ANUxx Re-estimate: blah blah spam.
Same hardware runs the U1 on bfg perfectly for weeks on end.
I'll update the error messages when they happen again, I'm on an intermittent SSH connection through my phone from work at the moment.
February 07, 2014, 02:32:44 PM
Just in case someone remembered my crashing cgminer (currently 3.12.0) issues due to memory leak...
I ended up installing cgwatcher and set it to just auto-restart cgminer every 6 hours (very conservative approach).
Turns out that works like a charm, haven't had a single problem anymore and I can afford 30 sec downtime every 6 hours.
Since the nature of my problems remain unidentified, that workaround is good enough for me
For anyone with crash issues after certain uptime, I can only recommend trying cgwatcher... Nice piece of software, works as advertised.
I ended up installing cgwatcher and set it to just auto-restart cgminer every 6 hours (very conservative approach).
Turns out that works like a charm, haven't had a single problem anymore and I can afford 30 sec downtime every 6 hours.
Since the nature of my problems remain unidentified, that workaround is good enough for me
For anyone with crash issues after certain uptime, I can only recommend trying cgwatcher... Nice piece of software, works as advertised.
February 07, 2014, 02:08:42 PM
I have tried multiple pools, ran some from a few hours to a day, and not even get recognized.
I am using a Radeon HD 4650 on LUbuntu12.04, Catalyst 13.1
It shows I am getting 300Kh/s
./cgminer -o stratum+tcp://mine-doge.cryptoculture.net:22555 -u broadway.work -p mine --api-listen --api-network --gpu-reorder --auto-fan
If I add --scrypt before the -o I will get 0Kh/s
Have tried setting --thread-concurrency --shaders and a few more with no luck
I am using a Radeon HD 4650 on LUbuntu12.04, Catalyst 13.1
It shows I am getting 300Kh/s
./cgminer -o stratum+tcp://mine-doge.cryptoculture.net:22555 -u broadway.work -p mine --api-listen --api-network --gpu-reorder --auto-fan
If I add --scrypt before the -o I will get 0Kh/s
Have tried setting --thread-concurrency --shaders and a few more with no luck
GPU support ended after version 3.7.2
February 07, 2014, 12:34:05 PM
I have tried multiple pools, ran some from a few hours to a day, and not even get recognized.
I am using a Radeon HD 4650 on LUbuntu12.04, Catalyst 13.1
It shows I am getting 300Kh/s
./cgminer -o stratum+tcp://mine-doge.cryptoculture.net:22555 -u broadway.work -p mine --api-listen --api-network --gpu-reorder --auto-fan
If I add --scrypt before the -o I will get 0Kh/s
Have tried setting --thread-concurrency --shaders and a few more with no luck
I am using a Radeon HD 4650 on LUbuntu12.04, Catalyst 13.1
It shows I am getting 300Kh/s
./cgminer -o stratum+tcp://mine-doge.cryptoculture.net:22555 -u broadway.work -p mine --api-listen --api-network --gpu-reorder --auto-fan
If I add --scrypt before the -o I will get 0Kh/s
Have tried setting --thread-concurrency --shaders and a few more with no luck
February 07, 2014, 10:15:49 AM
WARNING: There may be a problem with cgminer 3.12.1 that makes it stop retrieving work. I will investigate further and possibly release a fix in the next 24 hours. In the meantime I suggest users do not upgrade.
Sigh.
Sigh.
The Antminer U1 support isn't very stable either, mine all crapped out after an hour or so, I ended up with 50-odd as they dropped out and came back on. I have 10 of them on a Anker hub, running off a PC running Debian Wheezy.
ANU7: Comms error (werr=-9 something something)
Then it disables, and a few seconds later the miner reappears using Hotplug and gets a new number. Then I get a load of ANUxx Re-estimate: blah blah spam.
Same hardware runs the U1 on bfg perfectly for weeks on end.
I'll update the error messages when they happen again, I'm on an intermittent SSH connection through my phone from work at the moment.
February 07, 2014, 09:55:24 AM
Unofficial Mac binaries have been updated for v3.12.1 and are available here.
These are precompiled universal binaries that support Mac OS X 10.5.8 through 10.9+.
Given Con's latest post though, I suggest Mac users not upgrade yet until the issue has been investigated.
These are precompiled universal binaries that support Mac OS X 10.5.8 through 10.9+.
Given Con's latest post though, I suggest Mac users not upgrade yet until the issue has been investigated.
Jump to: