Heres another screnshot of cgminer with some weird ass numbers...
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 225. (Read 5805531 times)
September 14, 2013, 11:49:01 PM
Running 3.4.3 but notice now (it seems this issue goes back a few versions) that the accepted blocks field now shows the latest difficulty (x number of blocks found it seems) instead of total block count? Anyone got a fix for this?
Heres another screnshot of cgminer with some weird ass numbers...
Heres another screnshot of cgminer with some weird ass numbers...
September 14, 2013, 07:33:53 PM
erm.. bump?
...
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.
September 14, 2013, 11:41:46 AM
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 
)
Anyway-- running cgminer -n gives me:
So it should be ok, right? But trying to run cgminer with the usual parameters (--scrypt -o -u -p ) gives me:
I compiled cgminer with OpenCL Adreno SDK instead of AMD SDK (for obvious reasons).
)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
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).
September 14, 2013, 11:05:07 AM
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 driverOk, 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?
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.
September 14, 2013, 11:02:20 AM
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 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
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
September 14, 2013, 09:17:32 AM
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
September 14, 2013, 06:29:35 AM
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
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
September 14, 2013, 02:56:36 AM
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 driverOk, 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?
September 13, 2013, 07:28:08 PM
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.
September 13, 2013, 07:19:53 PM
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 
September 13, 2013, 07:02:47 PM
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. ./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.
September 13, 2013, 06:59:36 PM
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.
./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.
September 13, 2013, 03:55:31 PM
when using Zadig, do you select the winusb driver or one of the others?
September 13, 2013, 03:24:26 PM
Was 3.1.1 the last version to support COM functionality?
Oh, and side note: mdude, your sig is out of date.
Oh, and side note: mdude, your sig is out of date.
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
September 13, 2013, 03:20:40 PM
September 13, 2013, 03:13:41 PM
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. September 13, 2013, 01:35:20 PM
Was 3.1.1 the last version to support COM functionality?
Oh, and side note: mdude, your sig is out of date.
Oh, and side note: mdude, your sig is out of date.
September 13, 2013, 01:10:33 PM
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
September 13, 2013, 01:07:49 PM
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.
September 13, 2013, 12:48:03 PM
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.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
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
Jump to: