Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 584. (Read 5806088 times)

Post more details.  Are you mining on GPUs or just BFLs? What crashes?
Do you have an exception?  What is the exception offset?

Here you go.

...
Thus with that code (above) the ordering naturally should be BFL first and ICA 2nd if you don't specify "-S bitforce:COM6" or "-S icarus:COM6"
...

Then the bitforce detection is broken as Tinua has reported.

Tinua try putting -S bitforce:COMXX

Then the bitforce detection is broken as this user has reported.

[2012-05-01 19:41:07] Found 0 ztex board(s) 

3. Windowsbox coming:
Means....cgminer crashing

Then the bitforce detection is broken as Tinua has reported.

Tinua try putting -S bitforce:COMXX

The detection of PGAs is something that should be fixed.  Users should be able to say, I want these com ports to use BFLs, and the other ones to use
ZTEX or Icarus. 

I think that might be something luke_jr can add to bfgminer as it looks like cgminer is blindly trying to guess what is connected to COM ports.
(and failing).  Putting device type in the config file for each COM port would speed up detection and hopefully eliminate these issues.

Doing ZTEX detection on BFL or Icarus is just asking for it.  Users know what they have connected to each port, so let them add that in the config file.

The detection code is quite straight forward for each FPGA.

If you wish to force it to be specifically BFL or ICA you can e.g. "-S bitforce:COM6" or "-S icarus:COM6"
ZTX detection is completely different so there is no real overlap (you don't specify the ztex devices, it always directly detects them)

It checks for BFL first:
It sends it a command (ZGX) which the BFL replies and is checked for the string "SHA256" in it - part of the reply is also where the "Model" in the API command 'devdetails' comes from

Next it checks for Icarus:
It simply just sends it some work and waits 0.1s for the answer
(I checked the block chain for a low nonce and found Ozcoin block 171874 nonce = (0xa2870100) = 0x000187a2 takes ~0.53ms on Rev3 Icarus to be the lowest nonce in the thousands I got a script to look at until the script bugged out)
This is mandatory for ICA since there is no identification anywhere other than the USB device identification
(which course could be used by other non Icarus devices since it's not unique)

Thus with that code (above) the ordering naturally should be BFL first and ICA 2nd if you don't specify "-S bitforce:COM6" or "-S icarus:COM6"

ZTX is detect third since that was added 3rd (though I might consider moving it up to first since it's very direct how it works and unlikely to ever affect any other device)
You don't specify -S for ZTX

Edit: for auto detection of course ZTX is always auto
ICA doesn't ever do auto
BFL does auto only in linux and only when you specify -S auto - however it has 2 methods:
 1) where it looks in /dev/serial/by-id (which can sometimes only show 1 BFL on some linux versions if you have more than 1 BFL)
 2) by libudev checking the USB Model when libudev is compiled in

Using cgminer 2.3.2
Cgminer hangs or freezes, the curl display is unresponsive not accepting any keyboard commands, mining has stopped, system is not frozen or locked up.
What is the recommended method to start up mining again?
Is it OK to 'kill ' before starting a new session?

Post more details.  Are you mining on GPUs or just BFLs? What crashes?
Do you have an exception?  What is the exception offset?

cgminer1 -o http://pool1:8332 -u worker -p pass -o http://pool2:8332 -u name -p pass --disable-gpu -S COM5 -S COM6 -S COM7 -S COM8 -S \\.\COM9 -S \\.\COM10 -S \\.\COM11 -S \\.\COM12 -S \\.\COM13 -S \\.\COM54 -S \\.\COM55 -S \\.\COM56 -S \\.\COM57 -S \\.\COM58 -S \\.\COM59 

[2012-05-01 19:41:05] Started cgminer 2.3.6
[2012-05-01 19:41:07] Found 0 ztex board(s)    

cgminer1.exe not working anymore.....blablabla

/**FPGA's will not take over once I release my Zero-Point Energy Generator. The enrergy it produces will be free, but the device is gonna cost you.  

Hi folks

If I connect more then 10 BFL's....cgminer crash by starting?
If I start 2 instances of cgminer with <10 BFL's ....cgminer run??
Any idee why?
System: Win8 x64, CGminer 2.3.6

Many thanks for help!

Hi folks

If I connect more then 10 BFL's....cgminer crash down after 2 second?
If I start 2 instances of cgminer with <10 BFL's ....cgminer run??
Any idee why?
System: Win8 x64, CGminer 2.3.6

Many thanks for help!

If you are in Windows, your basic command line should look something like this:


The '-S COM6' is the relevant part for your Single. It happens to be COM6 for me, but it will likely be something else for you.

You'll need to open up Device Manager, go to the Ports section, and you should see an entry that looks like 'USB Serial Port (COMx)'. Whatever 'COMx' is in your case, that's what you put into cgminer's '-S COMx' setting. Then your Single should be detected.

edit: I should add that if your COM port is greater than 9, you need to use the 'longhand' form for cgminer. So if, for example, your assigned COM port for your Single was COM12, your command line would need to look like this:

I have not used GIT to get the latest copy of CGMINER. I've downloaded all archives of 2.3.x versions of it, and tried to compile in Debian 5.0 "Lenny". All versions before 2.3.4 compiled successfully.

Well all I can guess is there must be something wrong with your compiler or something messed up about your git pull/clone or some issue with the ./configure options you used.

The "die:" label has been there since 2011-11-24 (go to https://github.com/ckolivas/cgminer/blame/master/api.c to check for yourself)
Also the code compiles fine on quite a few architectures including xubuntu, fedora 16, debian, MinGW on windows
I've even just done another git pull and compiled it.

What git pull/clone command did you use and what ./configure command did you use?

If you pulled on top of an old version, make sure you './autogen.sh' './configure --xxx' and 'make clean' again before compiling.

Error when CGMINER compiling. Versions 2.3.4-2.3.6. Versions 2.3.1-2.3.3 compiles fine.


Tested with NVIDIA and ATi/AMD OpenCL's. OS: Linux x86. GCC: 4.3.

ckolivas, any chance you can take a look at the possibility of churning some code out to take advantage of the Intel HD GPU's integrated into Sandy Bridge CPU's (and now Ivy Bridge)?  Apparently they just released OpenCL SDK to allow access to the GPU portion of the CPU instead of just the CPU itself.  See post #22 here - https://bitcointalksearch.org/topic/m.870723