OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[juhakall]

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

[kano]

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

[kano]

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.

[Lantis]

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:

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

[kano]

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.

[Oldminer]

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

[twmz]

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?

Not sure what coin you're mining, but on the bitcoin network, cgminer now shows the number of "diff 1 shares" found for the accepted field.  So, if you're pool has a higher share difficulty, the counter will increase by whatever the difficulty of the associated job was each time a share is found.

That's not a bug.  If you really want the number of actual shares found (even though they are not as useful in a world that is moving towards variable difficulty mining), you can get them from the API.

[Lantis]

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.

well with all the other replies I thought it was missed, having this kind of answer is better since now I know I need to proceed with a different approach in solving it.

[martinm]

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

Thank you for the clear answer!

[vekt0r7]

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?

Not sure what coin you're mining, but on the bitcoin network, cgminer now shows the number of "diff 1 shares" found for the accepted field.  So, if you're pool has a higher share difficulty, the counter will increase by whatever the difficulty of the associated job was each time a share is found.

That's not a bug.  If you really want the number of actual shares found (even though they are not as useful in a world that is moving towards variable difficulty mining), you can get them from the API.

I would like to point out that there is A BUG ASSOCIATED WITH THAT FEATURE.
And that is, that as soon as the "Number of accepted Shares" reaches 10 Million, CGMiner crashes/stops working. I mine on an LTC-Pool with high difficulty and I have to restart CGMiner on a regular basis to make sure the miner just doesn't stop working because it has reached 10 Million diff 1 shares again.

Is there an "official" way to report bugs or is ckolivas going to read this?

[Oldminer]

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?

Not sure what coin you're mining, but on the bitcoin network, cgminer now shows the number of "diff 1 shares" found for the accepted field.  So, if you're pool has a higher share difficulty, the counter will increase by whatever the difficulty of the associated job was each time a share is found.

That's not a bug.  If you really want the number of actual shares found (even though they are not as useful in a world that is moving towards variable difficulty mining), you can get them from the API.

Thanks for your response but this IS a bug. If you look again you will see I am solo mining. Should just be showing me accepted blocks NOT shares.

[kano]

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

Thank you for the clear answer!

Oh lol - I just realised I made a rather silly comment there
You can't unplug a GPU while it's mining so GPUs would not be relevant to your comment.

[-ck]

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?

Not sure what coin you're mining, but on the bitcoin network, cgminer now shows the number of "diff 1 shares" found for the accepted field.  So, if you're pool has a higher share difficulty, the counter will increase by whatever the difficulty of the associated job was each time a share is found.

That's not a bug.  If you really want the number of actual shares found (even though they are not as useful in a world that is moving towards variable difficulty mining), you can get them from the API.

Thanks for your response but this IS a bug. If you look again you will see I am solo mining. Should just be showing me accepted blocks NOT shares.

It's accepted blocks * the difficulty at the time of solving them, not shares.

[martinm]

Hello Kano,

the comment wasn't so silly, the major objective was related to the identification of a device in cgminer, so it also counts if the ID's are the same after a restart of cgminer. Means for GPU's it would depend if the ATI Lib provides the GPU's in the same order. I will just assume the lib would provide the GPU's in the same order, at least as long there is no additional GPU added/removed.
Another issue I'm facing is the mapping of ID's provided from cgminer between different API command. For "DEV" and "DEVDETAILS" cgminer provides an ID, but once with a detail type (BAS,BFL,ICA,AVA,....) and once with a generic type (GPU,PGA,ASC,....). Are the ID generated for each group separately or are they related. As example, I run an instance of cgminer with 2 ICA, 2 AVA and 2 BAS devices. If the ID's are related, I would expect following result:

DEV command:
Name=PGA,ID=0
Name=PGA,ID=1
Name=ASC,ID=2
Name=ASC,ID=3
Name=ASC,ID=4
Name=ASC,ID=5

DEVDETAILS command:
Name=ICA,ID=0
Name=ICA,ID=1
Name=AVA,ID=2
Name=AVA,ID=3
Name=BAS,ID=4
Name=BAS,ID=5

By this it would be easy to generate a mapping between these devices, as the ID is program wide unique. But if the ID is just unique for each group, I would expect following result.

DEV command:
Name=PGA,ID=0
Name=PGA,ID=1
Name=ASC,ID=0
Name=ASC,ID=1
Name=ASC,ID=2
Name=ASC,ID=3

DEVDETAILS command:
Name=ICA,ID=0
Name=ICA,ID=1
Name=AVA,ID=0
Name=AVA,ID=1
Name=BAS,ID=0
Name=BAS,ID=1

In this case I could just assume that I have to rely on the order of the devices in the Json. Unfortunately I cant test the case (and also don't have the appropiate C++ skills to analyze the source), I hope you can help me and explain how cgminer is handling the ID's, so that I can do the right mapping.

Many thanks in advance!

[kano]

I'm not sure what the confusion is but ...
DEV
 PGA=0,Name=AMU,ID=0

DEVDETAILS
 DEVDETAILS=0,Name=AMU,ID=0

There is no trick to the association ... Name+ID from one to the other

... except ... missing from DEVS for a GPU, is it has no Name or ID

In miner.php I generate it easily enough:

Code:

function joinsections($sections, $results, $errors)
{
 global $sectionmap;

 // GPU's don't have Name,ID fields - so create them
 foreach ($results as $section => $res)
.
.
.

The names GPU, PGA, ASC in the API are to allow for device selection in the API via a number.
So if you want to affect the first PGA, with a PGA command, it is PGA=0, for the 10th one it is PGA=9
i.e. independent of the screen display - the screen display is Name,ID

I was planning once to also allow selection via the Name,ID but ... as is common I got side tracked ... and since most of the development I do in cgminer is for myself (I get very few donations) I usually do what I feel needs to be done.
I do of course appreciate the donations I get from a few people indeed - but they are not as common for me ... as others

Edit: though of course I get hardware donations and indeed work on the drivers for them as required

[Acejam]

Anyone ever get a crash with cgminer? I'm using Windows 7 x64. This happened after about 24 hours.

[kano]

mwsock.dll ... hmm I wonder how many times that's been reported in here ... and your not running the latest version

[Acejam]

mwsock.dll ... hmm I wonder how many times that's been reported in here ... and your not running the latest version

I have now updated to 3.4.3. I just searched through this thread and didn't seem to find any solutions for fixing the mwsock.dll issue. Any thoughts?

[-ck]

mwsock.dll ... hmm I wonder how many times that's been reported in here ... and your not running the latest version

I have now updated to 3.4.3. I just searched through this thread and didn't seem to find any solutions for fixing the mwsock.dll issue. Any thoughts?

Unfortunately we have no solution for a microsoft provided dll crashing. It should not be possible for our software to crash the dll unless there's a bug in the dll. The only suggestions are checking you have the latest dll and there are no virus/trojans that have attached to it.

[twmz]

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?

Not sure what coin you're mining, but on the bitcoin network, cgminer now shows the number of "diff 1 shares" found for the accepted field.  So, if you're pool has a higher share difficulty, the counter will increase by whatever the difficulty of the associated job was each time a share is found.

That's not a bug.  If you really want the number of actual shares found (even though they are not as useful in a world that is moving towards variable difficulty mining), you can get them from the API.

Thanks for your response but this IS a bug. If you look again you will see I am solo mining. Should just be showing me accepted blocks NOT shares.

When solo mining, the job difficulty is just = the the network difficulty.  So a share = a block, and the counter is going to increment by the difficulty of each block found.  I still don't think that is a bug.  ckolivas can clarify, but I don't think there was an intention of a "block found counter".  You're in a somewhat unique situation, and if you need a block found counter, I would suggest using the API (in which shares = blocks, when solo mining).