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

[-ck]

How do identify issues in cgminer if they don't get labeled sick or dead?  Do I just need to filter the output something like -m idle to see only idle messages? 

Go into the GPU menu while it's running, it shows the last initialised time. If it's not about the same time that you started cgminer (listed at the top) then you know it's been re-initialised.

[1714785202]

1714785202

[1714785202]

1714785202

[1714785202]

1714785202

[boozer]

Edit: hmm the thread does have the timestamp it was last sick though ...

Is there anyway to | more or | less the gpu management output?  on my ssh session, I only see the last 2 threads... even if i make the screen as big as I can, I only get the last 3 gpu's... I could always bump my resolution, but wondered if there was another way to do it.

[kano]

Edit: hmm the thread does have the timestamp it was last sick though ...

Is there anyway to | more or | less the gpu management output?  on my ssh session, I only see the last 2 threads... even if i make the screen as big as I can, I only get the last 3 gpu's... I could always bump my resolution, but wondered if there was another way to do it.

If you start cgminer as follows:

Code:

cgminer .... .... .... 2> "run.`date +%Y%m%d%H%M%S`.$$.log"

(where .... .... .... are of course whatever options you normally use like:
-Q 2 --api-listen --gpu-engine 700-825 700-825 700-830 700-815 700-820 700-830 --gpu-memclock 240 --auto-gpu --auto-fan --temp-target 75 -I 8 -o http://gpumax.com:8332 -u x-p x -o http://x:80 -u x -p x)
then you can use more/less on the log file it creates in the current directory

or save in a directory somewhere else like:

Code:

cgminer .... .... .... 2> "/directory/run.`date +%Y%m%d%H%M%S`.$$.log"

N.B. you can call the log file anything you like e.g. file.log
but I add that other stuff to ensure the filename is unique and easy to sort and see when it was started

Edit: But that won't show the G key output when you press the G key.
It simply logs all output that cgminer normally outputs in the scrolling window - not when you press keys and see other extra output.
the -D and --verbose options will add more output to the scroll area that will also go in the log file but that will be a lot more data.
However, in your case, that would be advisable to be able to see what's going wrong.

[abbeytim]

im wondering does the windows version work with bfl singles

i just bought a bfl single in feb and need to know since i am running windows

thankyou

[simonk83]

im wondering does the windows version work with bfl singles

i just bought a bfl single in feb and need to know since i am running windows

thankyou

Yep, works fine.

[The00Dustin]

Thank you very much!

I mentioned guiminer becuase I used it in the past to do solo mining.
It sets my username/pass for solo mining and also launches btc client in server mode.

You will need to enable the server mode yourself.

Go here: https://en.bitcoin.it/wiki/Running_bitcoind

Note that bitcoin-qt will run as a server when you have bitocin.conf in the right place, and then bitcoind will connect to it for other commands.  IOW, you can still have your GUI if you use it, although running bitcoind as the server instead of bitcoin-qt might be more stable / safer.

[Qu4k3r]

Thank you very much!

I mentioned guiminer becuase I used it in the past to do solo mining.
It sets my username/pass for solo mining and also launches btc client in server mode.

You will need to enable the server mode yourself.

Go here: https://en.bitcoin.it/wiki/Running_bitcoind

Note that bitcoin-qt will run as a server when you have bitocin.conf in the right place, and then bitcoind will connect to it for other commands.  IOW, you can still have your GUI if you use it, although running bitcoind as the server instead of bitcoin-qt might be more stable / safer.

Ok thanks.

I have 2 mining rigs.

One is running 0.3.24 version of btc client and I know "bitcoind.exe" must be run to do solo mining in it.

But, the second one is running 0.5.3.1 version (bitcoin-qt) and I don't know how to run server mode to do solo mining in it.

In both cases bitcoin.conf is located at right place "C:\Users\username\AppData\Roaming\Bitcoin\bitcoin.conf"

[The00Dustin]

But, the second one is running 0.5.3.1 version (bitcoin-qt) and I don't know how to run server mode to do solo mining in it.

In both cases bitcoin.conf is located at right place "C:\Users\username\AppData\Roaming\Bitcoin\bitcoin.conf"

I'm running 0.5.3.1 bitcoin-qt with the bitcoin.conf in the appropriate place and "bitcoind getinfo" returns a value, so I assume it supports solo mining as is.  If it doesn't, you should still be able to run bitcoind to solo mine.  Alternatively, I believe you could open the port on one computer to the other computer and solo mine on one bitcoind for both computers.  However, if you're having trouble, you should post what you have tried and what is or isn't working in order for someone to try to help you out further.

[ummas]

Hi
i got strange problem with my xubuntu.
1. i could not built my own installation - always failed with no gpu found even when i pointed right dir do AMDAPP (cat 12.2 with SDK2.6) - it was tested lots of time in diffrent systems. i was following README.txt -> there is a bug

CFLAGS="-O2 -Wall -march=native -I</etc/AMDAPP/include>" LDFLAGS="-L</opt/AMDAPP/lib/x86_64>" ./configure - bold is missing - i think
2. i downloaded built for ubuntu 11.10, but there was a problem with:
ummas@ummas-desktop:~/cgminer-2.3.1-2-x86_64-built$ ./cgminer -n
./cgminer: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory

witch was solved by:
ummas@ummas-desktop:/$ cd lib64
ummas@ummas-desktop:/lib64$ sudo ln -s libncurses.so.5.7 libtinfo.so.5

3. now see what happens:
ummas@ummas-desktop:~/cgminer-2.3.1-2-x86_64-built$ ./cgminer -n
[2012-03-18 17:09:14] CL Platform 0 vendor: Advanced Micro Devices, Inc.
[2012-03-18 17:09:14] CL Platform 0 name: AMD Accelerated Parallel Processing
[2012-03-18 17:09:14] CL Platform 0 version: OpenCL 1.1 AMD-APP (898.1)
[2012-03-18 17:09:14] Platform 0 devices: 1
[2012-03-18 17:09:14] ADL found more devices than opencl!
[2012-03-18 17:09:14] There is possibly at least one GPU that doesn't support OpenCL
[2012-03-18 17:09:14] WARNING: Number of OpenCL and ADL devices does not match!
[2012-03-18 17:09:14] Hardware monitoring may NOT match up with devices!
[2012-03-18 17:09:14] GPU 0 ATI Radeon HD 5800 Series hardware monitoring enabled
[2012-03-18 17:09:14] 1 GPU devices max detected

what brought me here, is discibed here: https://bitcointalk.org/index.php?topic=69264.0


4. is it possible to run cgminer on SDK 2.4 and having SDK2.6 to run other software?
in the future, i`m planning to put 7970 to the system.


i forgot to mention, that rig has 4 GPU, 0-5870, 1-5850, 2-5850, 3-6970 and was mining on cgminer 2.0.6 for last months.

[boozer]

The GPU's are showing Temp/RPM as you can see - so yep that means ADL is working.
That's all I was thinking there that maybe ADL wasn't able to get the Temp/RPM for some reason (even if the DISPLAY was set) so the cards were failing all the time.

There's no device failure statistics in cgminer other than HW which is 0 in your case.
Send ckolivas some BTC and ask him to implement it (or if he's not expecting to be able to do that soon - send it to me )
Then I could add a device status command in the API to return those numbers.

Edit: hmm the thread does have the timestamp it was last sick though ...

So... I still have this problem with threads being restarted and eating up memory.  Even when I run at stock speeds for all gpus.  The thread for GPU5 keeps getting restarted on both my 5970 rigs... i even tried underclocking gpu 5 on both rigs and it still occurred.  Phoenix seems to work fine.... should i try a different cgminer build?  I assume I'm the only one with this issue which makes it likely some configuration/hardware problem on my side, but I'm not sure how to isolate it.

[ummas]

so i have moved on a little. i have installed SDK 2.4 ust as inaba said in his guide.
thats result of those steps:

Code:

ummas@ummas-desktop:~/cgminer-2.3.1-2-x86_64-built$ DISPLAY=:0 ./cgminer -n     
[2012-03-19 12:28:28] CL Platform 0 vendor: Advanced Micro Devices, Inc.        
[2012-03-19 12:28:28] CL Platform 0 name: AMD Accelerated Parallel Processing   
[2012-03-19 12:28:28] CL Platform 0 version: OpenCL 1.1 AMD-APP (898.1)         
[2012-03-19 12:28:28] Platform 0 devices: 4                                     
[2012-03-19 12:28:28] GPU 0 ATI Radeon HD 5800 Series hardware monitoring enable
d                                                                               
[2012-03-19 12:28:28] GPU 1 ATI Radeon HD 5800 Series  hardware monitoring enabl
ed                                                                              
[2012-03-19 12:28:28] GPU 2 ATI Radeon HD 5800 Series  hardware monitoring enabl
ed                                                                              
[2012-03-19 12:28:28] GPU 3 AMD Radeon HD 6900 Series hardware monitoring enable
d                                                                               
[2012-03-19 12:28:28] 4 GPU devices max detected

but when i`ll run my cgminer i`ll get this.....strange....it has a problem with memory, but works now...

[nelisky]

I've hacked hotplug support into my ztex cgminer fork, but when I say 'hacked' I'm not joking, it's just a proof of concept.

There are a few things that I'd need to get this cleaned up:

 - A hotplug managing thread. I'm spawning the first ztex thread on startup as the hotplug manager which in turn will handle (re)connects, but this should be a proper top level thread.
 - Proper support for adding threads on the fly; I added a MAX_THREADS def and alloc memory for all of them on startup in thr_info[], because otherwise the other threads (long polling, watchdog, etc) would become interleaved with the mining threads and break all the "for i in len(mining_threads)" that expect 0 based and sequencial miner_threads. A simple solution to prevent the need to pre-alloc would be to move all non mining threads to the top of the array instead.
 - A little more dynamic variables handling the curses output, specifically being able to add lines to the device statuses.
 - When unplugging I'm setting deven to DEV_DISABLED, but there should really be a DEV_DISCONNECTED state too. I didn't need it because I search for devices being disabled and ztex, reusing those entries and threads as needed (because the only time ztex devices are disabled is when they are disconnected or malfunctioning) but if cgminer ever supports hotplugging for multiple device types we really need to know exactly which devices[] entries we can reuse.

There's more, but if you just look at my changes to cgminer.c you'll see what I mean.

What I've done works for me but I don't feel it is even close to clean to make a pull request out of it (without even going into the fact I changed a lot of tab indentations to double space ) but I would really love to work with the core developer(s) in order to come up with a plan that stands a chance of being accepted in the mainline.

Update code at the usual place: https://github.com/nelisky/cgminer/tree/ztex

[kano]

Question about running cgminer with icarus boards:

Can I have 5 icarus boards hooked up to a USB hub, hub hooked up to a PC, USB-COM driver maps it to COM5,
and run cgminer with "-S COM5"

How would cgminer communicate with all the icarus devices.  It opens COM5, but is there a device ID that it uses?

All I see in the cgpu_info is device_id (icarus.c), which is really a handle to opened com port.

I'm not clear how is this distribution of work done.  

By looking at the code, it seems like I'd need 5 COM ports for my 5 icarus cards.
Would the USB-COM driver "create 5 virtual COM ports" if I hookup 5 icarus cards through USB hub?

My guess is that this relates to the fact that there are USB driver problems on windows (nothing to do with cgminer)
If you go visit the Icarus thread (in my sig) there are comments about that.

I guess it means you need to update or get a new USB driver for windows - (for the USB interface that's on the Icarus card)

You should see multiple COMn on windows - one for each Icarus.

[kano]

The GPU's are showing Temp/RPM as you can see - so yep that means ADL is working.
That's all I was thinking there that maybe ADL wasn't able to get the Temp/RPM for some reason (even if the DISPLAY was set) so the cards were failing all the time.

There's no device failure statistics in cgminer other than HW which is 0 in your case.
Send ckolivas some BTC and ask him to implement it (or if he's not expecting to be able to do that soon - send it to me )
Then I could add a device status command in the API to return those numbers.

Edit: hmm the thread does have the timestamp it was last sick though ...

So... I still have this problem with threads being restarted and eating up memory.  Even when I run at stock speeds for all gpus.  The thread for GPU5 keeps getting restarted on both my 5970 rigs... i even tried underclocking gpu 5 on both rigs and it still occurred.  Phoenix seems to work fine.... should i try a different cgminer build?  I assume I'm the only one with this issue which makes it likely some configuration/hardware problem on my side, but I'm not sure how to isolate it.

When it comes to the GPU Driver/ADL I'm not too helpful.

As I mentioned before I'd guess that turning on debug (-D) and verbose (--verbose) and logging the output might help shed some light

As I sorta suggested before I'll look into making a change to get the actual numbers of bad events recorded against each device and probably also the details of the last event for each device if that is possible.
Then make this available through the API with a new command (e.g. something like 'events')
This may be of help to more easily see problems like this (though it may not help resolve them)

Edit: Though - it will of course have to be on my git until ckolivas is back in action (and give me a couple of days also)

[tucenaber]

Since perhaps two weeks I've had a problem with the aggregate cgminer stats when starting up. What happens is basically this: after 50-70 accepted shares, the total accepted shares ("A") counter stops incrementing. The "A" counter for each individual GPU keeps incrementing but on the other hand the uploaded/min "U" just increases without limit. If I restart a few times it eventually works beyond 70 shares and after that it keeps working.

When it happens only the stats seem to be wrong, the actual hashing keeps working.

Anybody else seing this problem?

[boozer]

When it comes to the GPU Driver/ADL I'm not too helpful.

As I mentioned before I'd guess that turning on debug (-D) and verbose (--verbose) and logging the output might help shed some light

As I sorta suggested before I'll look into making a change to get the actual numbers of bad events recorded against each device and probably also the details of the last event for each device if that is possible.
Then make this available through the API with a new command (e.g. something like 'events')
This may be of help to more easily see problems like this (though it may not help resolve them)

Edit: Though - it will of course have to be on my git until ckolivas is back in action (and give me a couple of days also)

Thanks.  I'm starting it with the debugging going.  I planned to run it at stock... and i didnt throw overclock values in the start command, but somehow it is running with my old overclock settings.... these are the commands I used to start
Any idea how my old overclock values are getting set when I am not specifying them in the CLI?

EDIT:  Nevermind.... I had switched to phoenix while i was working out the issue with cgminer and had set the overclocks there.... rebooted and everything is running stock now.

[vapourminer]

been getting this error on 2 of my miners lately. they run about 6 hours every time too. been crashing like clockwork for a few days now

[regular log stuff, then suddenly this]
[2012-03-20 14:04:09] Failed to create submit_work_thread
[lots of statistics]
[2012-03-20 14:04:09] API failed (Socket Error: (10004) Interrupted system call) - API will not be available
[2012-03-20 14:04:09] longpoll failed for http://api.bitcoin.cz:8408, sleeping for 30s
and thats the end, they are then sitting at "press any key to continue . . ."

same exact error on both

they are both running 2.3.1, no special flags aside from autoclock and autofan settings.

my 6870 is win7 64 bit, 11.11 driver, 2.5 sdk, and the 6770 is vista 32, 12.1, 2.3 sdk. clean installs, I never reuse bins, and delete bins when upgrading drivers and/or sdks. cgminer is always installed fresh, never over itself.

my 5830 on 11.4, 2.1 and XP with cgminer 2.2.7 runs perfect. same pool settings as the 6870 and 6770, so if its the longpoll fail thats killing the 2.3.1 miners the 2.2.7 version is OK with whatever it is.. is longpoll handled differently between 2.2.7 and 2.3.1?

any ideas?

[kano]

been getting this error on 2 of my miners lately. they run about 6 hours every time too. been crashing like clockwork for a few days now

[regular log stuff, then suddenly this]
[2012-03-20 14:04:09] Failed to create submit_work_thread
[lots of statistics]
[2012-03-20 14:04:09] API failed (Socket Error: (10004) Interrupted system call) - API will not be available
[2012-03-20 14:04:09] longpoll failed for http://api.bitcoin.cz:8408, sleeping for 30s
and thats the end, they are then sitting at "press any key to continue . . ."

same exact error on both

they are both running 2.3.1, no special flags aside from autoclock and autofan settings.

my 6870 is win7 64 bit, 11.11 driver, 2.5 sdk, and the 6770 is vista 32, 12.1, 2.3 sdk. clean installs, I never reuse bins, and delete bins when upgrading drivers and/or sdks. cgminer is always installed fresh, never over itself.

my 5830 on 11.4, 2.1 and XP with cgminer 2.2.7 runs perfect. same pool settings as the 6870 and 6770, so if its the longpoll fail thats killing the 2.3.1 miners the 2.2.7 version is OK with whatever it is.. is longpoll handled differently between 2.2.7 and 2.3.1?

any ideas?

Well the API 10004 error is interesting ...
According to Microsoft it can't happen coz the function that causes it has been removed (and I don't call it anyway)

Though, it looks exactly like a network problem with the computer?

[vapourminer]

Well the API 10004 error is interesting ...

According to Microsoft it can't happen coz the function that causes it has been removed (and I don't call it anyway)

Though, it looks exactly like a network problem with the computer?

they are all on gigabit, hardwired. all can see each other fine, matter of fact my HTPC (with the 6770) has a lot of media on the 6870 computers drives as the HTPC is low on drive space. network (seems to anyway) run flawlessly. terracopy (which verifies transfers with MD5) copies multi gig files across the network perfectly all the time.

and, no transfers were in progress, so network saturation shouldnt be it. this latest crash was while we were at work, and previously its crashed in the middle of the night while nothing was using network except the miners. not that multigig transfers have ever bothered the miners before.

router and the 6770/6870 rigs are on UPSs too.

damn thing is the 5830 is on a POS computer, no UPS, longest ethernet run with the lowest quality cable. and it runs perfect. but with 2.2.7

go figure, eh?

switched the 6870 back to 2.2.7. left the 6770 on 2.3.1. Ill see what happens tomorrow

[boozer]

When it comes to the GPU Driver/ADL I'm not too helpful.

As I mentioned before I'd guess that turning on debug (-D) and verbose (--verbose) and logging the output might help shed some light

As I sorta suggested before I'll look into making a change to get the actual numbers of bad events recorded against each device and probably also the details of the last event for each device if that is possible.
Then make this available through the API with a new command (e.g. something like 'events')
This may be of help to more easily see problems like this (though it may not help resolve them)

Edit: Though - it will of course have to be on my git until ckolivas is back in action (and give me a couple of days also)

I turned on -D and--verbose using this string and running at stock:

Code:

/usr/bin/screen -dmS cgminer /opt/miners/cgminer/cgminer -D --verbose -Q 2 --api-listen --auto-fan --temp-target 75 -I 8 -o http://x http://x 2> "/root/run.`date +%Y%m%d%H%M%S`.$$.log"

cgminer started at 175 meg resident and 415 meg virtual ram utilized.  After 4 hours, its at 284 meg resident and 607 meg virtual...  gpu5 threads were the only ones restarted according to the timestamp.

The logfile was created, but is empty...

-rw-r--r-- 1 root root       0 Mar 20 16:20 run.20120320162057.3911.log
-rw-r--r-- 1 root root       0 Mar 20 16:33 run.20120320163321.3713.log
-rw-r--r-- 1 root root       0 Mar 20 23:04 run.20120320230402.8150.log

is a stderr message supposed to be generated when the thread is restarted?