Bitcoin Forum
December 05, 2016, 12:48:07 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 670 671 672 673 674 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 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4817580 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.
techman05
Hero Member
*****
Offline Offline

Activity: 546


View Profile WWW
February 07, 2014, 02:13:36 AM
 #14381

Hello,

Could it be that cgminer-3.12 has a memory leak?

When I run it on my RaspPI for ca. one day, the memory gets swamped like hell, as well as the swap. As soon as I stop cgminer, memory and swap load go down to near zero. I used htop to trace the memory... Also I recognized that, when I don't stop and restart cgminer, it crashes with a segmentation fault at some point (which might be the point, when there is no more memory available).

It would be great if you could check and eventually fix that Smiley


Best Regards

There may well be a memory leak. I have not seen one, but I do not run anything on an RPi. If you can run the most current code from git as a debug build and get output it would be most helpful.
See:
http://ck.kolivas.org/apps/cgminer/debug/README-debug

If I follow what the debug says it says its 3.9 when I run it and anu devices don't show up. Is there a [compiled] 3.12 debug file?

Like the info address for potential tips Wink
BTC 1CL5BnNhdL2wDVmSDwMbW1cNhZew87CAPV
* http://www.miningrigrentals.com/register?ref=563
1480898887
Hero Member
*
Offline Offline

Posts: 1480898887

View Profile Personal Message (Offline)

Ignore
1480898887
Reply with quote  #2

1480898887
Report to moderator
I HATE TABLES I HATE TABLES I HA(╯°□°)╯︵ ┻━┻ TABLES I HATE TABLES I HATE TABLES
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
February 07, 2014, 05:26:15 AM
 #14382

New version: 3.12.1, 7th February 2014

Mostly lots of bugfixes and heaps of new features for hashfast devices with upgraded firmware (due out soon).

Human readable changelog:

- Dynamic temperature based fanspeed and per-die clockspeed control for hashfast devices with the following new commands.

--hfa-fan <arg>     Set fanspeed percentage for hashfast, single value or range (default: 10-85)
--hfa-temp-target <arg> Set the hashfast target temperature (0 to disable) (default: 88)

Defaults chosen are based on extensive discussion with the design engineers responsible for the silicon and boards and basically it will keep your hashfast devices as close to the starting clockspeed as possible while keeping under~95 degrees by initially increasing fanspeed, and then decreasing the clockspeed on the hottest dies discretely. The output can be watched via the API. Enduring sweltering temperatures of up to 44 degrees here has made for an excellent real world test for this code.
- Numerous startup/reset/shutdown reliability improvements for hashfast
- Send a ping to the hashfast device at regular intervals if we don't have any work for it just so it knows cgminer is still alive to try and minimise the dreaded watchdog reboots.
- Lots of extra information in the hashfast API stats output.
- Hashfast serial number is shown as a hex value now.
- Better hashfast flushing of work on restarts - new firmware will build further on this.
- Antminer U1 overclocking support with --anu-freq note:
Quote
By default, Antminer U1 devices run at a clockspeed of 200. This command allows
you to specify a chosen frequency to attempt to run all ANU devices at and the
value must be in increments of 25. Note that cgminer reports hashrate ONLY
FROM VALID HASHES so if you increase the frequency but your hashrate does not
increase or it decreases and hardware errors start showing up, you have
overclocked it too much. In the worst case scenario it will fail to start at
too high a speed.
You basically must use --icarus-timing=short additionally to get the maximum benefit out of the overclocking (at this stage).
- Keep taking a trickle of work even if it's not being used just to keep an eye on pools and to keep the most recent work time up to date
- Make the top "window" wider since hashes these days come in the many millions and don't fit into 80 characters
- In verbose mode, the share above target message shows for which device
- Rolled back to the last good working libusb - the alleged libusb/x merge did not bring improvements and added windows instability with spontaneous exiting
- Handle better numerous non-terminal errors (the cgsem ones) that were leading to cgminer exiting
- BAB improvements courtesy of Kano
- Verbose mode will now show if it takes time to submit a stratum share, or it takes a long time to get a response from pools due to them lagging substantially, to help debug where latencies might be causing high stales.
- Added a way to zero other stats within each driver when the zero stats command is given (though no driver currently uses it).
- Fix one stale work item being passed to drivers after a block change.
- Fix a rare usbutils crash
- Pool diffs that are fractions only show one decimal place now.
- In debug mode a message will show up if there are substantial delays in getting work.
- Fix for massive data over the API
- Other random fixes.


Full changelog:

- Document new features for antminer U1 and hfa devices.
- Add support for ANU overclocking.
- Increase hfa fanspeed by more if we're rising in temp above the target than if
the temp is staying the same.
- Add debug output when get_work() is blocked for an extended period and add
grace time to the device's last valid work to prevent false positives for device
failure.
- Issue a shutdown prior to a reset command for hfa devices and lock access to
reads awaiting the response if the device is already running.
- Do not register as successful a hfa init sequence that reports the clockrate
as zero.
- Show device info in noffset nonce share above target message.
- Widen lines in top menu to fit extra large share values.
- Only show one decimal place if pool diff is not an integer.
- Show serial number as a hex value in hfa verbose startup.
- Slowly remove work even if it's not being used to keep the getwork counter
incrementing even if work is not used and as a test that pools are still
working.
- Increase the maximum diff between hfa dies to 100Mhz.
- Show which hfa die is bringing down all the others when decreasing all the
clock speeds.
- Increase the decrease when temp has increased more and we want to decrease it
on hfa.
- Give device info with share above target message.
- Allow throttling of hfa dies more frequently and increasing of speeds less
frequently.
- Wait after sending a hfa shutdown to allow the device to properly shut down
before possibly sending it more commands.
- Minimise the die clock differences in hfa to no more than 50Mhz.
- Check for when errno is set on windows as well as the windows variant for
errors.
- Revert "Update to libusb-1.0.18"
- Disable fan/die clock control in hfa if the firmware does not support it, with
notification.
- Add ability to enter ANU frequency as a multiple of 25 from 150-500.
- Decrease hfa clock by 10 if a reset is attempted due to the device remaining
idle.
- ifdef out icarus options unused without icarus built in.
- Reorder command line options alphabetically.
- Add no matching work to hfa API output.
- Change various logging message levels in the hfa driver.
- Only adjust clocks if there is no restart in hfa to avoid 2 restarts back to
back.
- Ensure we iterate over all dies adjusting temperate for hfa by starting
iterating after the last die modified.
- Clamp initial hfa fanspeed to min/max if passed as parameters.
- Allow hfa fanspeed to be set via command line.
- Further relax the target temperatures on hfa driver, targetting 88 degrees.
- Try one more time to get the hfa header on init since it can take 2 seconds
for all 3 boards on a sierra.
- Update authors for removal of gpu/scrypt.
- Wait for 5 temperature updates in hfa before adjusting fanspeed.
- Have some leeway before starting to throttle hfa dies.
- Use increments of 10 when increasing hfa clock since it may not have 5 MHz
granularity internally.
- Only perform a hfa fan speed update if we have new temps to work with.
- Correctly measure the hfa max temp and smooth out the changes in its value.
- Choose better defaults for min/max/default fan settings for hfa driver.
- bab - reduce def speed, fix speed staying in ranges and report bank/chips in
ioctl() errors
- bab - add info about number of boards/chips to each Dead Chain
- These may not be longs (eg: OSX)... fo a safe cast to ensure.
- bab - add dead boards and dead chains to stats
- Add fanspeed to hfa api output and set initial fanspeed to 10%
- Add hfa fanspeed control to try and maintain a target temperature.
- API-README correct new text format documentation
- API allow multiple commands/replies in one request
- Add op commands necessary to control hfa fanspeeds.
- Add OP_FAN to hf protocol header.
- Always show the stratum share lag time in debug mode.
- Add stratum share response lag time to verbose output if it's greater than 1
second.
- Add stratum share submission lag time to verbose information if it's over 1
second.
- Check for more interrupted conditions in util.c and handle them gracefully.
- Send a ping to hfa devices if nothing is sent for over 5 seconds.
- Add OP_PING to hfa commands
- Display the hfa serial number as a hexadecimal value.
- Add the ability to display a hexadecimal 32 bit unsigned integer to the API.
- Limit all hfa restarts for temperature control to no closer than 15 seconds
apart.
- Allow the hfa temp target to be disabled by setting it to zero.
- Handle interruptions to various select calls in util.c
- Add sanity check for silly overflows in hfa die temperature readings.
- Add per-die throttling control for hfa driver based on each die's temperature,
issuing a suitable reset to maintain the temperature below a configurable target
temperature.
- Update hf protocol
- Do not memcpy in usbutils unless data was transferred.
- Send a full allotment of jobs to the hfa device after a restart instead of
reading the status.
- Export the flush_queue function for use by drivers.
- Remove wrong goto
- Remove the unqueued work reference when we discard work from get queued as
well.
- Wake the global work scheduler when we remove a work item from the unqueued
work pointer.
- Discard work that is stale in the get_queued() function, returning NULL
instead.
- Add a call to a driver specific zero stats function when zero stats is called
to allow each driver to reset its own stats as well if desired.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
February 07, 2014, 05:40:31 AM
 #14383

Quote
By default, Antminer U1 devices run at a clockspeed of 200. This command allows
you to specify a chosen frequency to attempt to run all ANU devices at and the
value must be in increments of 25. Note that cgminer reports hashrate ONLY
FROM VALID HASHES so if you increase the frequency but your hashrate does not
increase or it decreases and hardware errors start showing up, you have
overclocked it too much. In the worst case scenario it will fail to start at
too high a speed.

Note that adding --icarus-timing=short is basically mandatory if you overclock them at this stage. The requirement for this should be fixed in a future version.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Krak
Hero Member
*****
Offline Offline

Activity: 591



View Profile WWW
February 07, 2014, 06:19:11 AM
 #14384

Quote
By default, Antminer U1 devices run at a clockspeed of 200. This command allows
you to specify a chosen frequency to attempt to run all ANU devices at and the
value must be in increments of 25. Note that cgminer reports hashrate ONLY
FROM VALID HASHES so if you increase the frequency but your hashrate does not
increase or it decreases and hardware errors start showing up, you have
overclocked it too much. In the worst case scenario it will fail to start at
too high a speed.

Note that adding --icarus-timing=short is basically mandatory if you overclock them at this stage. The requirement for this should be fixed in a future version.
Woo, now I just need a Raspbian binary and I can finally ditch bfgminer. Tongue

BTC: 1KrakenLFEFg33A4f6xpwgv3UUoxrLPuGn
plasmapelz
Newbie
*
Offline Offline

Activity: 4


View Profile
February 07, 2014, 09:45:01 AM
 #14385

There may well be a memory leak. I have not seen one, but I do not run anything on an RPi. If you can run the most current code from git as a debug build and get output it would be most helpful.
See:
http://ck.kolivas.org/apps/cgminer/debug/README-debug

There is most certainly one... it fills up slowly, more slowly than I thought. I have cgminer-3.12 running for 2 days - just now it has filled the whole memory and the PI starts to swap. I made a screenshot of htop, which I could send you per mail.

Certainly the leak exists not only on PI but also on all other platforms. At least if it is not caused by a special #ifdef, that only applies on arm compile.
I could backtrace it in valgrind and gdb... but I am not as deep in the code as you are, so you will likely be much more productive in identifying the problem. Nevertheless I can give it a try over the weekend  Smiley

loshia
Legendary
*
Offline Offline

Activity: 1372


View Profile
February 07, 2014, 11:40:34 AM
 #14386

Con,

There might be an issue caused by fa26f8df82f9213cffd8a715ac1450d3c191d459 commit

mutex_lock(&stats_lock);
cgpu->last_device_valid_work = time(NULL);
mutex_unlock(&stats_lock);
I got some locks recently. One possible reason might be.....that everywhere last_device_valid_work was changed under lock, but commit does not lock it

if (diff_t > 0) {
      applog(LOG_DEBUG, "Get work blocked for %d seconds", (int)diff_t);
      thr->cgpu->last_device_valid_work += diff_t;
   }

I am commenting it to see if locks will appear


If i wrote something stupid pls do excuse me

Best

Please help the Led Boy aka Bicknellski to make us a nice Christmas led tree and pay WASP membership fee here:
https://bitcointalk.org/index.php?topic=643999.msg7191563#msg7191563
And remember Bicknellski is not collecting money from community;D
jelin1984
Legendary
*
Offline Offline

Activity: 1274



View Profile
February 07, 2014, 12:19:23 PM
 #14387

How I can manual set the diff at my Jupiter at 512 because pool make the diff at 2048
os2sam
Legendary
*
Offline Offline

Activity: 1918


Think for yourself


View Profile
February 07, 2014, 12:22:10 PM
 #14388

How I can manual set the diff at my Jupiter at 512 because pool make the diff at 2048

That's a function of the pool not the mining software.

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?
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
February 07, 2014, 12:35:28 PM
 #14389

...
Woo, now I just need a Raspbian binary and I can finally ditch bfgminer. Tongue

I've put out 3.12.1a as I've done before
I'll make it a brief post Smiley

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 Smiley
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

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
February 07, 2014, 02:08:57 PM
 #14390

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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
KyrosKrane
Sr. Member
****
Offline Offline

Activity: 292


View Profile WWW
February 07, 2014, 02:12:37 PM
 #14391

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:

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. Smiley

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

Activity: 1372


View Profile
February 07, 2014, 02:28:38 PM
 #14392

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.
Super! I have noticed same. Good news are that commenting commit is solving  the problem for me for last hour or so.

PS my hanged again Cry the only thing from what i can see since my stable build which have changed and may be related

https://github.com/ckolivas/cgminer/commit/c4267e663aa7b4e7c2cd997fbe3c45bf87365f13
but the above commit seems good to me

 


Please help the Led Boy aka Bicknellski to make us a nice Christmas led tree and pay WASP membership fee here:
https://bitcointalk.org/index.php?topic=643999.msg7191563#msg7191563
And remember Bicknellski is not collecting money from community;D
Karin
Member
**
Offline Offline

Activity: 109



View Profile WWW
February 07, 2014, 02:55:24 PM
 #14393

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.

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
HellDiverUK
Hero Member
*****
Offline Offline

Activity: 574


View Profile
February 07, 2014, 03:15:49 PM
 #14394

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.

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.
Broadway
Newbie
*
Offline Offline

Activity: 2


View Profile
February 07, 2014, 05:34:05 PM
 #14395

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
Joshwaa
Hero Member
*****
Offline Offline

Activity: 489



View Profile
February 07, 2014, 07:08:42 PM
 #14396

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

GPU support ended after version 3.7.2

Like what I said : 1JosHWaA2GywdZo9pmGLNJ5XSt8j7nzNiF
Don't like what I said : 1FuckU1u89U9nBKQu4rCHz16uF4RhpSTV
Don't Like BFL's Project Management : 1FuckbFLZpmWLuyHyFJw1RGkWm3yRM1L5D
FalconFly
Sr. Member
****
Offline Offline

Activity: 252

Sentinel


View Profile
February 07, 2014, 07:32:44 PM
 #14397

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 Smiley

For anyone with crash issues after certain uptime, I can only recommend trying cgwatcher... Nice piece of software, works as advertised.

This forum signature is like its owner - it can't be bought
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
February 07, 2014, 08:41:23 PM
 #14398

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.

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.
Hmm I can try reinstating the attempted reset but I'm not sure it's going to fix that... How much were you overclocking them?

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Broadway
Newbie
*
Offline Offline

Activity: 2


View Profile
February 07, 2014, 08:53:16 PM
 #14399

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

GPU support ended after version 3.7.2

I have 2.9.5
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
February 07, 2014, 09:34:43 PM
 #14400

New releases: 3.12.3 - 8th February 2014

Palindromic double hotfix release...  Embarrassed

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."


Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Pages: « 1 ... 670 671 672 673 674 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 ... 830 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!