Bitcoin Forum
December 07, 2016, 10:53:12 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 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 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4821088 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.
The00Dustin
Hero Member
*****
Offline Offline

Activity: 806


View Profile
September 13, 2013, 04:39:00 PM
 #12461

Win7 x64, just like the PCs.

I could see them being underpowered.  But cgminer doesn't see them.  It's not like it sees them and they don't work, it's like they aren't there.

M
I had the same issue. By any chance, is it a very recent PC, with a Z87 chipset? In my case, the conclusion was that my particular chipset or USB port wasn't supported by the libusb that cgminer uses. Windows was seeing the BE fine and loading the right drivers, but they still appeared invisible to cgminer. Ultimately I had to find a different platform to mine on.
That's some useful information that the developers can hopefully consider in some future build.  However, if that isn't the case, I think we need to know whether or not there is any indication that the device is visible in the OS and/or powered on since, as a general rule of thumb, I would expect underpowered ports to not power on devices that require more power than is available.  Sure, there may be some mining devices could see enough power to come on, but not enough to mine without errors.  I don't know whether or not there are, but even if there are, I would expect that to be an edge case, not something typical of underpowered USB ports (unless all underpowered USB ports provide the exact same less-than-spec amount of power for some mystical reason [or they are powered to spec and "underpowered" actually means "not overpowered"]).
1481107992
Hero Member
*
Offline Offline

Posts: 1481107992

View Profile Personal Message (Offline)

Ignore
1481107992
Reply with quote  #2

1481107992
Report to moderator
1481107992
Hero Member
*
Offline Offline

Posts: 1481107992

View Profile Personal Message (Offline)

Ignore
1481107992
Reply with quote  #2

1481107992
Report to moderator
"Bitcoin: the cutting edge of begging technology." -- Giraffe.BTC
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481107992
Hero Member
*
Offline Offline

Posts: 1481107992

View Profile Personal Message (Offline)

Ignore
1481107992
Reply with quote  #2

1481107992
Report to moderator
1481107992
Hero Member
*
Offline Offline

Posts: 1481107992

View Profile Personal Message (Offline)

Ignore
1481107992
Reply with quote  #2

1481107992
Report to moderator
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
September 13, 2013, 04:48:03 PM
 #12462

Win7 x64, just like the PCs.

I could see them being underpowered.  But cgminer doesn't see them.  It's not like it sees them and they don't work, it's like they aren't there.

M
I had the same issue. By any chance, is it a very recent PC, with a Z87 chipset? In my case, the conclusion was that my particular chipset or USB port wasn't supported by the libusb that cgminer uses. Windows was seeing the BE fine and loading the right drivers, but they still appeared invisible to cgminer. Ultimately I had to find a different platform to mine on.
That's some useful information that the developers can hopefully consider in some future build.  However, if that isn't the case, I think we need to know whether or not there is any indication that the device is visible in the OS and/or powered on since, as a general rule of thumb, I would expect underpowered ports to not power on devices that require more power than is available.  Sure, there may be some mining devices could see enough power to come on, but not enough to mine without errors.  I don't know whether or not there are, but even if there are, I would expect that to be an edge case, not something typical of underpowered USB ports (unless all underpowered USB ports provide the exact same less-than-spec amount of power for some mystical reason [or they are powered to spec and "underpowered" actually means "not overpowered"]).

It's a fairly recent laptop.  It has a 3rd gen i7 processor in it.  Device manager is showing the "Intel 7 series C216 chipset".

Windows knows about the USB device.  It installed the drivers just fine (via Zadig).  It shows in device manager.  But cgminer is none the wiser.

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
The00Dustin
Hero Member
*****
Offline Offline

Activity: 806


View Profile
September 13, 2013, 05:07:49 PM
 #12463

New chipsets take time to be supported in *nix (and presumably libusb originates in *nix, translating to Windows).  It's unfortunate, but a reality.  That having been said, the easiest way to confirm a problem is a chipset vs libusb problem would be to try to run the cgminer binaries off of a live distro (presumably the same OS & version in use by the developers).  If cgminer doesn't detect the device there, it's definietly due to the version of libusb included with cgminer.  Also unfortunate, many other libusb versions cause mining problems as seen earlier in this thread, so even if the developer's OS of choice can detect the device on your machine, that doesn't mean cgminer can use it and be stable.  Presumably you would have to hack and compile on your own to be able to have cgminer use a newer libusb whilst not being stable.  Beyond that, all you can do in this scenario is hope that a future version of libusb comes out that is stable for mining, which also requires hoping the developers are trying new libusb versions.  However, the live distro test would at least allow you to know that so you don't waste additional time troubleshooting.
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
September 13, 2013, 05:10:33 PM
 #12464

New chipsets take time to be supported in *nix (and presumably libusb originates in *nix, translating to Windows).  It's unfortunate, but a reality.  That having been said, the easiest way to confirm a problem is a chipset vs libusb problem would be to try to run the cgminer binaries off of a live distro (presumably the same OS & version in use by the developers).  If cgminer doesn't detect the device there, it's definietly due to the version of libusb included with cgminer.  Also unfortunate, many other libusb versions cause mining problems as seen earlier in this thread, so even if the developer's OS of choice can detect the device on your machine, that doesn't mean cgminer can use it and be stable.  Presumably you would have to hack and compile on your own to be able to have cgminer use a newer libusb whilst not being stable.  Beyond that, all you can do in this scenario is hope that a future version of libusb comes out that is stable for mining, which also requires hoping the developers are trying new libusb versions.  However, the live distro test would at least allow you to know that so you don't waste additional time troubleshooting.

Linux and I don't mix well.  Last time I tried it, one of us had to go, and you see who's still here.

I intend to try 3.1.1 which uses COM drivers and see if I can get it working that way.

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
KyrosKrane
Sr. Member
****
Offline Offline

Activity: 292


View Profile WWW
September 13, 2013, 05:35:20 PM
 #12465

Was 3.1.1 the last version to support COM functionality?

Oh, and side note: mdude, your sig is out of date. Smiley

Tips and donations: 1KyrosREGDkNLp1rMd9wfVwfkXYHTd6j5U  |  BTC P2Pool node: p2pool.kyros.info:9332
The00Dustin
Hero Member
*****
Offline Offline

Activity: 806


View Profile
September 13, 2013, 07:13:41 PM
 #12466

I intend to try 3.1.1 which uses COM drivers and see if I can get it working that way.
Hopefully that works.  While it doesn't prove that the issue is compatibility between your chipset and libusb, it is an easier way to narrow things down significantly and a potential workaround at the same time.
Karin
Member
**
Offline Offline

Activity: 109



View Profile WWW
September 13, 2013, 07:20:40 PM
 #12467

Unofficial Mac binaries updated to 3.4.3 at http://spaceman.ca/cgminer.
Cheesy

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

Activity: 1358


View Profile
September 13, 2013, 07:24:26 PM
 #12468

Was 3.1.1 the last version to support COM functionality?

Oh, and side note: mdude, your sig is out of date. Smiley

I think 3.1.1 was the last version to use COM.  I was using it on my mining rigs until very recently.

Thanks for the reminder on my sig, I fixed it.  One neat thing about sigs here is it always shows your current one.

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
vulgartrendkill
Hero Member
*****
Offline Offline

Activity: 518



View Profile WWW
September 13, 2013, 07:55:31 PM
 #12469

when using Zadig, do you select the winusb driver or one of the others?
DrGuns4Hands
Full Member
***
Offline Offline

Activity: 180


View Profile
September 13, 2013, 10:59:36 PM
 #12470

Just compiled from the git running good so far no issues no zombies. I did notice during the configure step that a line popped up showing

./configure: line 11925: -pthread: command not found

seems to be working without it ,but what would i need to get to fix this part.

Raspberry Pi Raspbian Wheezy 7.

-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
September 13, 2013, 11:02:47 PM
 #12471

Just compiled from the git running good so far no issues no zombies. I did notice during the configure step that a line popped up showing

./configure: line 11925: -pthread: command not found

seems to be working without it ,but what would i need to get to fix this part.

Raspberry Pi Raspbian Wheezy 7.
Nothing, it's a normal part of the libusb check.

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

Activity: 1918


Linux since 1997 RedHat 4


View Profile
September 13, 2013, 11:19:53 PM
 #12472

when using Zadig, do you select the winusb driver or one of the others?
As the screen error message says ... and the README, FPGA-README and ASIC-README says - the WinUSB driver

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
The Mafia
Jr. Member
*
Offline Offline

Activity: 50


View Profile
September 13, 2013, 11:28:08 PM
 #12473

After having a similar issue (moving from 3.1.1 to 3.4.0) and cigminer not seeing devices, I formatted and reinstalled windows and installed the winusb driver only and the devices detected again.
vulgartrendkill
Hero Member
*****
Offline Offline

Activity: 518



View Profile WWW
September 14, 2013, 06:56:36 AM
 #12474

when using Zadig, do you select the winusb driver or one of the others?
As the screen error message says ... and the README, FPGA-README and ASIC-README says - the WinUSB driver

Ok, thanks kano, I have done this and still after 30 mins or so 2 of my erupters turn into zombies.  Does this mean that the driver needs to be installed on all the erupters or do I just do it once?
martinm
Jr. Member
*
Offline Offline

Activity: 42


View Profile
September 14, 2013, 10:29:35 AM
 #12475

Hello ck,
Hello Kano,

I've a question related to the identification of a device in cgminer and the a hardware device. As I'm currently about to develop a application that creates statistics for every device, it's essential to have a clear mapping between hardware device and the related device in cgminer for that. Previously I thought that the combination of the Device Type (GPU/BAS/AVA/....) and ID provided from cgminer could achieve that task, I had the hope it works as long the devices are connected to the same Port(USB/PCE...). Unfortunately I discovered that's not right. During the run of CGMiner I unplugged an Avalon from the USBPort and reconnected after a short time. After the reconnect the Id changed from AVA0 to AVA1. Now I'm questioning myself, how I can achieve the unique identification of a hardware device by reported data from CGMiner. I hope you can give me some advice!

Thany you very much in advance 
juhakall
Sr. Member
****
Offline Offline

Activity: 422



View Profile
September 14, 2013, 01:17:32 PM
 #12476

Does anyone know a good way to cross compile libudev, so I could keep on cross compiling cgminer for ARM? I had no trouble compiling libncurses and libusb previously, but it looks like libudev has been integrated to the massive systemd project. Obviously I don't need to compile the whole systemd, but I just can't figure out how to compile libudev only.
You can't just install libudev development library?

I tried that first, but the configure script doesn't pick it up, presumably because I need to have a version compiled for arm. I'm no cross compilation expert, but that's what worked for me with libusb and libncurses. I downloaded those libraries, cross compiled them for arm and installed them to a specific directory. After pointing the configure script to search for libs and headers from that directory, the dependencies were detected.

If you have managed to cross compile cgminer without having to cross compile libudev too, I'm obviously doing something wrong here.

I'll answer myself, hopefully this helps someone else trying to cross compile.

I downloaded udev_175.orig.tar.bz2 from Debian repositories, and cross compiled it with --disable-gudev and --disable-introspection flags (to cut down the list of dependencies). I didn't have to install the whole package to my arm-linux-gnueabihf directory, make install-libLTLIBRARIES install-pkgconfigDATA install-includeHEADERS was enough.

I now have a working cross compilation system again. Only curl, ncurses & libudev had to be manually compiled. Didn't have to dive into the dependency hell of systemd after all Smiley
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
September 14, 2013, 03:02:20 PM
 #12477

Hello ck,
Hello Kano,

I've a question related to the identification of a device in cgminer and the a hardware device. As I'm currently about to develop a application that creates statistics for every device, it's essential to have a clear mapping between hardware device and the related device in cgminer for that. Previously I thought that the combination of the Device Type (GPU/BAS/AVA/....) and ID provided from cgminer could achieve that task, I had the hope it works as long the devices are connected to the same Port(USB/PCE...). Unfortunately I discovered that's not right. During the run of CGMiner I unplugged an Avalon from the USBPort and reconnected after a short time. After the reconnect the Id changed from AVA0 to AVA1. Now I'm questioning myself, how I can achieve the unique identification of a hardware device by reported data from CGMiner. I hope you can give me some advice!

Thany you very much in advance 
Avalon has no information in the device at all - I think that's something those guys like doing Tongue Icarus has nothing useful either.

Any device that has an iSerial that isn't constant would be one way to detect 2 devices being the same one that hotplugged later.

But with Avalon it's not possible - so if you unplug 2 and then plug them back in, there's no USB information to say which was which before.
The devices that don't have an iSerial, or have the same iSerial, are: AVA, AMU, BFL FPGA, MMQ
AsicMiner USBs can be reprogrammed to fix it
I've no idea what the ATI library supplies for GPUs but I'd guess nothing useful either.

These devices don't have this stupid problem: BFL SC, BLT, BTB

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

Activity: 1918


Linux since 1997 RedHat 4


View Profile
September 14, 2013, 03:05:07 PM
 #12478

when using Zadig, do you select the winusb driver or one of the others?
As the screen error message says ... and the README, FPGA-README and ASIC-README says - the WinUSB driver

Ok, thanks kano, I have done this and still after 30 mins or so 2 of my erupters turn into zombies.  Does this mean that the driver needs to be installed on all the erupters or do I just do it once?
They wont work at all without the right driver, you'll get an error from cgminer on the screen saying to use the WinUSB driver for devices that don't have it.
Zombies means either you're not using the current cgminer, they are overheating, you've got USB cable/hub/3.0 problems or ... who knows.

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
Lantis
Newbie
*
Offline Offline

Activity: 23


View Profile
September 14, 2013, 03:41:46 PM
 #12479


erm.. bump?

I managed to compile cgminer in Android and trying to run it in my SGS4 with opencl, and I have some problems running it (spare me the "why bother" response, I think running cgminer in my phone is kinda cool, and with the advancement of GPUs in the mobile space, you'll never know  Grin)

Anyway-- running cgminer -n gives me:

Code:
[2013-09-13 12:07:15] CL Platform 0 vendor: QUALCOMM
[2013-09-13 12:07:15] CL Platform 0 name : QUALCOMM Snapdragon(TM)
[2013-09-13 12:07:15] CL Platform 0 name : OpenCL 1.1 QUALCOMM build:   (CL3579225)
Build Date: 04/22/13 Mon
Local Branch: adreno_sba_20130419
Remote Branch:
Local Patches:
Reconstruct Branch:
[2013-09-13 12:07:15] Platform 0 devices: 1
[2013-09-13 12:07:15] 0          QUALCOMM Adreno(TM)
[2013-09-13 12:07:15] 1 GPU devices max detected

So it should be ok, right?  But trying to run cgminer with the usual parameters (--scrypt -o <host:port> -u <username> -p <password>) gives me:
Code:
[2013-09-13 12:08:12] Started cgminer 3.1.1
[2013-09-13 12:08:12] Probing for an alive pool
Assertion failed: !spillIs.empty() && "No spill intervals?", file vendor/qcom/proprietary/gles/adreno200/llvm/lib/CodeGen/QGPURegAlloc.cpp, line 2628

I compiled cgminer with OpenCL Adreno SDK instead of AMD SDK (for obvious reasons).

BTC : 162vF41ycBjZDWkZv1eouiaki4zxZ8PEmt
LTC : LackB1YdYLxqRpiYqvWfAzxViDe5WFjpMs
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
September 14, 2013, 11:33:53 PM
 #12480


erm.. bump?

...
No answer clearly means you have to sort it out yourself.

The GPU code is written to work with ATI library supported cards with specific drivers.

If you want to it work with others, you'll be modifying the CL and/or GPU driver.
However, it is a complete waste of time, since it will be a complete waste of electricity.

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
Pages: « 1 ... 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 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 ... 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!