Bitcoin Forum
June 23, 2018, 05:10:16 AM *
News: Latest stable version of Bitcoin Core: 0.16.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 [639] 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 ... 847 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.10.0  (Read 5756423 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.
mdude77
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001



View Profile
October 12, 2013, 09:55:56 PM
 #12761

3.1.1 needs the USB to UART driver in addition to Zadig (winUSB).  

You can't have both, even though I do. Each is resident but you have to choose one or the other.
From my view, If devices and printers shows com numbers for all be's, then you have silabs in charge.
If all be's are present with no com numbers, WinUSB is in charge.
Neither selection is working for me.

You *can* have both.  Both use WinUSB (put there by Zadig).  However 3.1.1 uses COM ports, so you need Silab to map that USB to a COM port.

For 3.4.3+, you don't want the Silabs there, as cgminer can theoretically use the WinUSB driver directly.

You are correct, if you see COM ports for each of your BEs, you need to be using 3.1.1.  If you see USB entries for BE, you need to be using 3.4.3+.

I've tried cgminer on 4 computers now, all with different motherboards.  Two 3.4.3 sees them just fine.  Two they do not.  One of those two I'm running 3.1.1 with Silabs, the 4th one I haven't tried.

M

I mine at Kano's Pool because it pays the best and is completely transparent!  Come join me!
1529730616
Hero Member
*
Offline Offline

Posts: 1529730616

View Profile Personal Message (Offline)

Ignore
1529730616
Reply with quote  #2

1529730616
Report to moderator
1529730616
Hero Member
*
Offline Offline

Posts: 1529730616

View Profile Personal Message (Offline)

Ignore
1529730616
Reply with quote  #2

1529730616
Report to moderator
1529730616
Hero Member
*
Offline Offline

Posts: 1529730616

View Profile Personal Message (Offline)

Ignore
1529730616
Reply with quote  #2

1529730616
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Wipeout2097
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250


Blockchain powered authentication from the future


View Profile
October 12, 2013, 10:05:43 PM
 #12762

May I suggest a donation mining option for cgminer?

        ██████████
     ████████████████
   ████████████████████
  ██████▀▀     ▀▀███████
 ██████           ███████
▐█████             ██████▌
▐█████             ██████▌
▐██████           ███████▌
 ████████        ████████
  █████████   ▐█████████
    ███████    ███████
    ▐████▌     ▐████▌
    █████       █████
   ▐████▄▄▄     ▐████▌  
   ███████████   █████▄▄██▌
  ▐██████████▌   ▐█████████
  █████   ▀▀▀     ████████▀▀
 ▐████▌           ▐████▌
 █████             █████
      ██████       ▐████▌
     ▐█████▌        █████
     ██████
███
███
 ██
 ██
 ██
 ██
 ██
 ██
 ██
 ██
 ██
 ██
███
███
███
███
 ██
 ██
 ██
 ██
 ██
 ██
 ██
 ██
 ██
 ██
███
███
■  Telegram
■  Twitter
■  Reddit
■  ANN
■  Ambassador
■  GitHub
os2sam
Legendary
*
Offline Offline

Activity: 2464
Merit: 1001


Think for yourself


View Profile
October 12, 2013, 10:23:19 PM
 #12763

May I suggest a donation mining option for cgminer?

Because..., it was such a huge success the last time it was tried?

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
Moderator
Legendary
*
Offline Offline

Activity: 2562
Merit: 1096


Ruu \o/


View Profile WWW
October 12, 2013, 10:44:04 PM
 #12764

Re: Zadig

Most of the confusion stems from the fact people think of it as a driver when it is not.

Zadig is a tool to associate a driver with a device and it comes prepackaged with the WinUSB driver which is what cgminer uses with all USB devices.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
markm
Legendary
*
Offline Offline

Activity: 2072
Merit: 1000



View Profile WWW
October 13, 2013, 12:02:19 AM
 #12765

I have been running BLT and AMU devices on Fedora Core 17 using cgminer 3.2.0 but even a fresh clone of the github repo, which builds as 3.5.0, does not work for my AMU devices. It detects my BLTs but not the AMUs. I for now I have had to go back to using the old 3.2.0.

(I even tried bfgminer again, but a git pull of that to get its latest code results in one that wont' detect my BLTs as well as not detecting  my AMUs so for me bfgminer is still looking less useful than cgminer because at least the ancient 3.2.0 of cgminer will run my eruptors and lancelots.

I would like to be able to update though. Does anyone know why more-recent versions than 3.2.0 do not work?

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2562
Merit: 1096


Ruu \o/


View Profile WWW
October 13, 2013, 02:55:25 AM
 #12766

I have been running BLT and AMU devices on Fedora Core 17 using cgminer 3.2.0 but even a fresh clone of the github repo, which builds as 3.5.0, does not work for my AMU devices. It detects my BLTs but not the AMUs. I for now I have had to go back to using the old 3.2.0.

(I even tried bfgminer again, but a git pull of that to get its latest code results in one that wont' detect my BLTs as well as not detecting  my AMUs so for me bfgminer is still looking less useful than cgminer because at least the ancient 3.2.0 of cgminer will run my eruptors and lancelots.

I would like to be able to update though. Does anyone know why more-recent versions than 3.2.0 do not work?

-MarkM-

Bizarre. Nothing in the new code that shouldn't detect what the old code could. Check your permissions and udev rules file and that you built in full support since you're compiling it for yourself.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
markm
Legendary
*
Offline Offline

Activity: 2072
Merit: 1000



View Profile WWW
October 13, 2013, 03:42:17 AM
 #12767

Someone told me how to switch to the 3.5.1 branch since I had only been getting 3.5.0; the 3.5.1 works fine.

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
Taugeran
Hero Member
*****
Offline Offline

Activity: 658
Merit: 500


CCNA: There i fixed the internet.


View Profile
October 13, 2013, 03:47:31 AM
 #12768

Code:
[2013-10-12 23:39:07] USB scan devices: checking for ICA devices
 [2013-10-12 23:39:07] ICA looking for ICA 067b:2303 but found 10c4:ea60 instead
 [2013-10-12 23:39:07] ICA looking for and found AMU 10c4:ea60
 [2013-10-12 23:39:07] USB lock Icarus 20-9
 [2013-10-12 23:39:07] RES: Icarus (20:9) lock=1
 [2013-10-12 23:39:07] USB res lock Icarus 20-9
 [2013-10-12 23:39:07] RES: Icarus (20:9) lock ok=1
 [2013-10-12 23:39:07] USB init, claim ifinfo 0 interface 0 failed, err -3 - AMU device 20:9
 [2013-10-12 23:39:07] USB free AMU
 [2013-10-12 23:39:07] Icarus detect (20:9) failed to initialise (incorrect device?)
 [2013-10-12 23:39:07] USB unlock Icarus 20-9

what does this mean on a mac?

also getting:
Code:
[2013-10-12 23:34:49] USB scan devices: checking for BF1 devices
 [2013-10-12 23:34:49] BF1 looking for and found BF1 03eb:204b
 [2013-10-12 23:34:49] USB lock bitfury 20-7
 [2013-10-12 23:34:49] RES: bitfury (20:7) lock=1
 [2013-10-12 23:34:49] USB res lock bitfury 20-7
 [2013-10-12 23:34:49] RES: bitfury (20:7) lock ok=1
 [2013-10-12 23:34:49] USB init, claim ifinfo 0 interface 1 failed, err -3 - BF1 device 20:7-i1
 [2013-10-12 23:34:49] USB free BF1
 [2013-10-12 23:34:49] bitfury detect (20:7) failed to initialise (incorrect device?)
 [2013-10-12 23:34:49] USB unlock bitfury 20-7
 [2013-10-12 23:34:49] BF1 looking for BF1 03eb:204b but found 05ac:0252 instead
 [2013-10-12 23:34:49] RES: bitfury (20:7) lock=0
 [2013-10-12 23:34:49] BF1 looking for BF1 03eb:204b but found 0424:2513 instead
 [2013-10-12 23:34:49] USB res unlock bitfury 20-7

Bitfury HW & Habañero : 1.625Th/s
tips/Donations: 1NoS89H3Mr6U5CmP4VwWzU2318JEMxHL1
Come join Coinbase
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2562
Merit: 1096


Ruu \o/


View Profile WWW
October 13, 2013, 03:57:25 AM
 #12769

Someone told me how to switch to the 3.5.1 branch since I had only been getting 3.5.0; the 3.5.1 works fine.

-MarkM-

It still shouldn't have been a problem on the master branch... (which still reads 3.5.0 but is actually the branch under active development).

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2562
Merit: 1096


Ruu \o/


View Profile WWW
October 13, 2013, 04:52:52 AM
 #12770

Code:
[2013-10-12 23:39:07] USB init, claim ifinfo 0 interface 0 failed, err -3 - AMU device 20:9

what does this mean on a mac?

also getting:
Code:
[2013-10-12 23:34:49] USB init, claim ifinfo 0 interface 1 failed, err -3 - BF1 device 20:7-i1
I wish I knew. -3 is an access permissions problem, whatever the heck that means on osx.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
Taugeran
Hero Member
*****
Offline Offline

Activity: 658
Merit: 500


CCNA: There i fixed the internet.


View Profile
October 13, 2013, 05:28:07 AM
 #12771

Code:
[2013-10-12 23:39:07] USB init, claim ifinfo 0 interface 0 failed, err -3 - AMU device 20:9

what does this mean on a mac?

also getting:
Code:
[2013-10-12 23:34:49] USB init, claim ifinfo 0 interface 1 failed, err -3 - BF1 device 20:7-i1
I wish I knew. -3 is an access permissions problem, whatever the heck that means on osx.

could it be due  to the kernel usb to serial drivers?

*dont hit me*

Bitfury HW & Habañero : 1.625Th/s
tips/Donations: 1NoS89H3Mr6U5CmP4VwWzU2318JEMxHL1
Come join Coinbase
Picmin
Newbie
*
Offline Offline

Activity: 23
Merit: 0


View Profile
October 13, 2013, 04:12:00 PM
 #12772

Just built from git on my raspberry pi.
Version is listed as 3.5.0.

Downloaded one of your compiled versions for windows.
Version is 3.5.1.

Did I build from the wrong branch with git clone https://github.com/ckolivas/cgminer?
git clone https://github.com/ckolivas/cgminer --branch 3.5

Oh thanks !

Does the the master branch include someone42 pull requests? i have installed with git clone https://github.com/ckolivas/cgminer on minepeon and the '--bitburner-voltage' parameter doesn't work anymore.
Always set to max : 1100mv on a Bitburner Fury.

Wipeout2097
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250


Blockchain powered authentication from the future


View Profile
October 13, 2013, 07:18:24 PM
 #12773

Let's try this again ...
May I suggest a donation mining option for cgminer?

Because..., it was such a huge success the last time it was tried?

        ██████████
     ████████████████
   ████████████████████
  ██████▀▀     ▀▀███████
 ██████           ███████
▐█████             ██████▌
▐█████             ██████▌
▐██████           ███████▌
 ████████        ████████
  █████████   ▐█████████
    ███████    ███████
    ▐████▌     ▐████▌
    █████       █████
   ▐████▄▄▄     ▐████▌  
   ███████████   █████▄▄██▌
  ▐██████████▌   ▐█████████
  █████   ▀▀▀     ████████▀▀
 ▐████▌           ▐████▌
 █████             █████
      ██████       ▐████▌
     ▐█████▌        █████
     ██████
███
███
 ██
 ██
 ██
 ██
 ██
 ██
 ██
 ██
 ██
 ██
███
███
███
███
 ██
 ██
 ██
 ██
 ██
 ██
 ██
 ██
 ██
 ██
███
███
■  Telegram
■  Twitter
■  Reddit
■  ANN
■  Ambassador
■  GitHub
os2sam
Legendary
*
Offline Offline

Activity: 2464
Merit: 1001


Think for yourself


View Profile
October 13, 2013, 07:40:58 PM
 #12774

Let's try this again ...
May I suggest a donation mining option for cgminer?

Because..., it was such a huge success the last time it was tried?

My snarky remark wasn't wasn't meant to imply that I thought it was a bad idea.  And if they incorporated it into CGMiner again I would certainly use it.

But, if I remember correctly, it ended up increasing the development workload for ckolivas dramatically more than the revenue it brought in was worth plus it ticked off allot of people.

But maybe it would be a different story now with the increased value of bitcoin and the stratum protocol?

I just would hate to see ckolivas and kano's workload increase with little or no benefit.  But hey who knows.

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
Moderator
Legendary
*
Offline Offline

Activity: 2562
Merit: 1096


Ruu \o/


View Profile WWW
October 13, 2013, 08:55:58 PM
 #12775

Actually we've reached a time where almost no one is making a profit mining which won't pass for maybe another year. Is it really time that people would be interested in a donation option?

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
Trongersoll
Hero Member
*****
Offline Offline

Activity: 490
Merit: 500



View Profile
October 13, 2013, 09:01:11 PM
 #12776

Actually we've reached a time where almost no one is making a profit mining which won't pass for maybe another year. Is it really time that people would be interested in a donation option?

Sounds like a Mining Tax, or Software Usage Tax. Roll Eyes
jedimstr
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1000



View Profile
October 14, 2013, 01:44:57 AM
 #12777

With this new feature in 3.5.1:

Quote
- If we switch away from a pool in failover mode, we will now only switch back to it if it's up for at least 5 minutes to avoid reconnecting to pools that are only intermittently up - good for DDoS situations which we've seen a lot of lately.

Is there a way to adjust the switch back timing?  When mining Altcoins on a multi coin pool like Middlecoin or Hashcows, 5 minutes is way too long since fail-over gets triggered upon switch of coin. So if the pool is mining a certain most profitable scrypt coin for a round of 10 minutes only, then half that is lost because of this new feature!  The ideal would be to set it down to 1 minute or even just 30 seconds.

-ck
Moderator
Legendary
*
Offline Offline

Activity: 2562
Merit: 1096


Ruu \o/


View Profile WWW
October 14, 2013, 10:52:54 AM
 #12778

New version: 3.6.01 - 14th October 2013

The substantial rewrite of the usb code has stabilised. Basically cgminer no longer depends anywhere near as much now on libusb, doing a lot of extra work itself to avoid bugs in the libusb code. Numerous drivers should benefit from this in both performance and stability. Also a new driver in this version. The code base diverged from that of 3.5.1 so some of the changes between them were not shared since the issues were tackled a different way, while many of the changes in the changelog are repeated from 3.5.1. Sorry, some of the build request changes for macosx and other architectures did not get looked at due to lack of time. A lot of the driver changes are in preparation for new devices around the corner along with tackling head on long standing issues with libusb we have been unable to address.


Human readable changelog:

3.6.1:
- Fixed the breakage of devices dependent on control transfers (like AMUs).

3.6.0:
- Rewrite of the usb communication code to using all the asynchronous functions of libusb and doing all timeouts internally within the cgminer code. This should dramatically reduce or even obliterate the long timeout errors people were seeing with some devices and makes communication less prone to failure. Here's hoping the AMU devices finally perform reliably on windows with it. Overall, latency, errors and overhead should be lower while performance slightly higher.
- Completely separate read/write communications on USB allowing them to happen concurrently for the few devices that can benefit from this.
- Support for bitburner fury boards
- Updates to klondike code
- Fixes for newer GPU SDKs on older GPUs that would fail to start.
- Cleaner shutdowns for USB to minimise risk of hanging on shutdown.
- New driver skeleton design for devices that wish to do their own work management or do not need to split work up into parts - currently only used by BPMC bitfury devices.
- Minor performance/overhead improvements.
- Low level bugfixes/improvements.
- Most of the other changes from 3.5.0->3.5.1


Full changelog:

3.6.1:
- Emulate the libusb_control_transfer sync setup in our async variant.
- usbutils - make all libusb_error_name messages the same

3.6.0:
- increasing max miners for avalon driver
- using separate identifier for bitburner fury boards
- changes to bitburner driver for bitburner fury boards
- hexstr is too small in test_work_current
- Windows uses errno for WSAETIMEDOUT
- Convert the usb callback function to using cgsem_t timed waits to avoid race
conditions with conditionals/mutexes.
- Give correct return code in cgsem_mswait
- Check for correct timeout error in cgsem_mswait
- Fix util.h exports for cgsem_mswait
- Implement a generic cgsem_mswait similar to sem_timedwait
- Use the one LIBUSB_ERROR_TIMEOUT for cancelled transactions since this error
is explicitly tested for in various drivers.
- Do not use locking on usb callback function pthread signalling to prevent
deadlock with libusb's own event lock.
- Use a write lock when performing any USB control transfers to prevent
concurrent transfers.
- Free a libusb transfer after we have finished using it to avoid a dereference
in usb_control_transfer
- Do not perform bfi int patching for opencl1.2 or later.
- Although async transfers are meant to use heap memory, we never return before
the transfer function has completed so stack memory will suffice for control
transfers, fixing a memory leak in the process.
- klondike - correct/reverse min/max stats
- api incorrect message name
- klondike - use a link list queue rather than a circular buffer - and add
timing stats
- Use a timeout with usb handle events set to a nominal 200ms and wait for the
polling thread to shut down before deinitialising libusb.
- Use stack memory for hex used in stratum share submissions.
- Use stack memory in test_work_current, avoiding a malloc/free cycle each time.
- Provide a lower level __bin2hex function that does not allocate memory itself.
- Convert the bitfury driver to use the hash_driver_work version of hash_work.
- Add a hash_driver_work function to allow for drivers that wish to do their own
work queueing and management.
- Convert all usb control transfers to asynchronous communication with our own
timeout management as well.
- Klondike - increase circular read buffer size
- Klondike - extra zero value and range checking in temp conversion
- klondike - display MHz also
- Make pthread conditional timeouts handle all bulk usb transfer timeouts
performing libusb_cancel_transfer, disabling timeouts within libusb itself.
- Avoid calling get_statline_before on exit to avoid trying to use it on drivers
in an indeterminate state.
- Avoid calling get_statline on exit.
- Add a small amount to the usb timeout before cancelling to allow for a regular
usb polling interval to pass.
- Do not attempt to clear a usb halt before sending the cancel message since all
transfers should normally be cancelled before attempting to clear a halt
condition, and only change the return message to a timeout if it's consistent
with a cancellation.
- Retry up to USB_RETRY_MAX times to clear a halt condition before failing.
- Show the error number as well as the description in erroring bulk transfers.
- Drop logging level for failed to connect to stratum to verbose mode only since
we hit it regularly.
- We are always dependent on libusb handling events so use the blocking
libusb_handle_events in the polling thread and use a bool to know if we should
continue polling.
- Use fractional hashrate return values in bitfury_scanhash to minimise the
number of times we return 0 based on hashrate so far to further damp out
displayed hashrate.
- Check for presence of driver name in DRIVER_COUNT_FOUND to prevent strcmp on a
null pointer when a driver is not built in.
- CMR allow sending flash and clock commands
- Kill off threads that have failed using hash_sole_work instead of just
disabling them.
- Make the bf1 getinfo size a macro
- Failing to add_cgpu in bitfury should be a terminal failure.
- Check return values when attempting to open a BF1 device and set the msg size
as a macro.
- Display errors on failed usb read and write and consider sequential IO errors
a permanent failure.
- Use libusb's own error name function instead of hand coding the error names.
- Limit ms_tdiff to 1 hour as a sanity check.
- Enable the usb buffer in avalon driver.
- Check for async transfer variants of error messages.
- Remove unused variables.
- Try switching pools if for some reason we end up with only idle pools and have
ended up current_pool set to an idle one.
- Check a pool is stable for >5 mins before switching back to it.
- Minimise the time between dropping the read devlock and grabbing the write
devlock to avoid tons of logging spam in the interim.
- Check for libusb transfer stall error to be consistent with async IO errors
returned for a halt condition.
- Check for continuous IO errors on USB and consider the device inactive if more
than retry max.
- Make the devlock a cglock in usbutils and only grab the write lock for
fundamental changes allowing us to send and receive transfers concurrently
without lock contention.
- Prevent overflows in us_tdiff and ms_tdiff.
- Change second initialise message on bitfury verbose mode.
- Submitting an ntime offset nonce needs to be done on a copy of the work
instead of the original so abstract out shared components as much as possible,
minimising strdups in copy_work and make submit_work_async work take copied
work, cleaning up code in the process.
- Provide a way for drivers to submit work that it has internally rolled the
ntime value by returning the amount it has ntime rolled to be added.
- Typo in configure.ac
- Remove unmaintained broken ztex driver.
- Icarus - use a data structure for I/O rather than magic numbers
- delete old tracked ccan/opt/*.o files
- klondike correct cvtKlnToC() temperature calculation
- klondike - correct 1st reply debug based on define
- klondike - debug dump structured replies
- klondike - avoid division by zero if maxcount is unexpectedly zero
- klondike store and report errorcount and noise
- klondike - fix chipstats api stats buffer overrun with 16 chips
- klondike add new nonecount only once
- klondike - report mh/s based on nonces found + put old estimate into API stats
- klondike use a memcpy
- klondike fix bracket tabs indenting
- api.c missing Klondike from ASIC list
- Klondike update code to current git
- Add 2nd CMR to 01-cgminer.rules
- Add Klondike to 01-cgminer.rules
- Klondike to main directory
- Klondike consistent code spacing
- Klondike update driver code to current git
- update firmware for 16 chips, add dist files
- beta final 0.3.0 release
- updated firmware, IOC method
- prevent nonces when not state W
- added driver config option support
- fixes for 300 MHz, fix K1 parts list
- update driver, docs
- update firmware & utils
- updated cgminer driver for 3.3.1
- update firmware and driver, create new cgminer fork
- update klondike driver
- add cgminer driver file as-is
- Add API output displaying USB cancellations.
- Store statistics on how often we have to cancel async bulk transfers and add a
debug message whenever we do.
- Treat any unexpected timeouts waiting for async transfers as though there may
be a usb halt condition and attempt to clear the halt before cancelling the
tranfer.
- Remove zero packet flag on usb as it's unsupported outside linux and
unnecessary.
- Fake the libusb transfer timed out message if we force cancel it with our own
async functions.
- Use asynchronous transfers for all bulk transfers, allowing us to use our own
timers and cancelling transfers that take too long.
- Add libusb error warning message when significant error occurs.
- Icarus CMR2 detect FPGA setup
- Disable bitfury device thread on it disappearing.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
RaTTuS
Hero Member
*****
Offline Offline

Activity: 792
Merit: 1000


Bite me


View Profile
October 14, 2013, 11:07:27 AM
 #12779

3.5.1 works for me but
3.6.0 with
./configure --enable-icarus --enable-bitfury --disable-opencl
will not find any USB Eruptors now


In the Beginning there was CPU , then GPU , then FPGA then ASIC, what next I hear to ask ....

1RaTTuSEN7jJUDiW1EGogHwtek7g9BiEn
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2562
Merit: 1096


Ruu \o/


View Profile WWW
October 14, 2013, 11:10:18 AM
 #12780

3.5.1 works for me but
3.6.0 with
./configure --enable-icarus --enable-bitfury --disable-opencl
will not find any USB Eruptors now


I hear AMUs and BF1s don't like to work together somewhat. Try unplugging them and replugging them while it's running or some other combination.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
Pages: « 1 ... 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 [639] 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 ... 847 »
  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!