OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 615.

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: ?? on ??

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.

nelisky

legendary

Activity: 1540

Merit: 1002

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

ummas

sr. member

Activity: 274

Merit: 250

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

boozer

sr. member

Activity: 309

Merit: 250

Quote from: kano on March 17, 2012, 10:33:50 PM

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

sr. member

Activity: 274

Merit: 250

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" LDFLAGS="-L" ./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://bitcointalksearch.org/topic/xubuntu-1104-sdk24-sdk26-and-cat116-122-problem-69264

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.

The00Dustin

hero member

Activity: 807

Merit: 500

Quote from: Qu4k3r on March 18, 2012, 11:11:54 AM

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.

Qu4k3r

newbie

Activity: 50

Merit: 0

Quote from: The00Dustin on March 18, 2012, 06:01:35 AM

Quote from: Qu4k3r on March 17, 2012, 01:50:27 PM

Thank you very much! Wink

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

hero member

Activity: 807

Merit: 500

Quote from: Qu4k3r on March 17, 2012, 01:50:27 PM

Thank you very much! Wink

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.

simonk83

hero member

Activity: 798

Merit: 1000

Quote from: abbeytim on March 18, 2012, 04:14:40 AM

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.

abbeytim

sr. member

Activity: 438

Merit: 250

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

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: boozer on March 17, 2012, 11:14:07 PM

Quote from: kano on March 17, 2012, 10:33:50 PM

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.

boozer

sr. member

Activity: 309

Merit: 250

Quote from: kano on March 17, 2012, 10:33:50 PM

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.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: boozer on March 17, 2012, 10:11:43 PM

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.

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

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

boozer

sr. member

Activity: 309

Merit: 250

Quote from: kano on March 17, 2012, 09:40:50 PM

I guess related to that

(I mean ckolivas comment above)
Are the GPU's showing Temp & RPM?
If ADL isn't working (e.g. missing "export DISPLAY=:0" or the display isn't available for other reasons) then I guess the cards could just keep failing over and over.

Yea, I have the export Display=:0 as part of my start script. I also have export GPU_USE_SYNC_OBJECTS=1... would that cause any issues since there are no 7970's?

Its been running for 6 hours now, but is up to 522 Meg of RAM... however it seems to be able to run longer since I lowered my intensity like ckolivas suggested.

When I did cgminer on my 7970's, it was real easy to tell a clock issue, as they would get sick and/or die... however, I have not seen any problems like that on here, normally when I log on to check, everything appears normal except RAM usage is going up..... But again, ckolivas explained why this could be since he said the 59x0 series can recover easily.

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? I trust ckolivas post above that clocks are the issue, but is there away to find which GPU(s) being restarted?

Code:

27782 root      20   0 1057m 522m  55m S  5.0 29.5  18:21.41 cgminer


cgminer version 2.3.1f - Started: [2012-03-17 15:52:48]
--------------------------------------------------------------------------------
 (5s):2263.1 (avg):2225.3 Mh/s | Q:12003  A:10923  R:94  HW:0  E:91%  U:31.16/m
 TQ: 4  ST: 5  SS: 13  DW: 387  NB: 46  LW: 0  GF: 25  RF: 119
 Connected to http://gpumax.com:8332 with LP as user x
 Block: 0000066396107079d1f26f4324da7369...  Started: [21:35:17]
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0:  72.5C 4453RPM | 375.8/374.0Mh/s | A:1850 R:13 HW:0 U: 5.28/m I: 8
 GPU 1:  74.5C 4453RPM | 376.9/372.4Mh/s | A:1863 R:22 HW:0 U: 5.31/m I: 8
 GPU 2:  75.5C 4463RPM | 378.4/374.4Mh/s | A:1858 R:21 HW:0 U: 5.30/m I: 8
 GPU 3:  68.5C 4463RPM | 372.0/367.5Mh/s | A:1689 R:13 HW:0 U: 4.82/m I: 8
 GPU 4:  74.5C 3979RPM | 372.3/364.9Mh/s | A:1807 R:13 HW:0 U: 5.15/m I: 8
 GPU 5:  74.0C 3983RPM | 378.7/372.1Mh/s | A:1856 R:12 HW:0 U: 5.29/m I: 8
--------------------------------------------------------------------------------

[2012-03-17 21:43:28] Accepted 00000000.46f55b55.50517462 GPU 3 thread 6 pool 0
[2012-03-17 21:43:30] Accepted 00000000.b048d923.17e692c8 GPU 5 thread 10 pool 0
[2012-03-17 21:43:30] Accepted 00000000.98616a0b.58522de7 GPU 2 thread 5 pool 0
[2012-03-17 21:43:30] Accepted 00000000.39d5a007.49107274 GPU 0 thread 0 pool 0
[2012-03-17 21:43:30] Accepted 00000000.26108520.1ac3378d GPU 0 thread 1 pool 0
[2012-03-17 21:43:31] Accepted 00000000.cda7345f.774b39e8 GPU 5 thread 10 pool 0
[2012-03-17 21:43:38] Accepted 00000000.8e7044df.5236adda GPU 4 thread 8 pool 0

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: boozer on March 17, 2012, 09:30:54 PM

Quote from: kano on March 17, 2012, 08:47:00 PM

Hmm OK, so it's effectively 12 devices.
That's a lot of GPU devices

Edit: oh I just noticed another thing ... you have 2 pools and the main is GPUMax - does it swap pools a lot?

Sorry for the confusion, I have 2 rigs with 3 5970's each that have the this issue (so 6 GPU's max in one of my rigs), the 2 rigs with 3 7970's each that work fine.
I haven't noticed a lot of pool swapping... occasionally one core will swap back and forth.

I guess related to that

(I mean ckolivas comment above)
Are the GPU's showing Temp & RPM?
If ADL isn't working (e.g. missing "export DISPLAY=:0" or the display isn't available for other reasons) then I guess the cards could just keep failing over and over.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: boozer on March 17, 2012, 08:33:35 PM

They are all 5970's (dual gpu) so those temps are okay. I was actually using Phoenix until I just recently started with cgminer and had those clocks stable on phoenix for several weeks. Not sure how often BAMT requests via API. I have BAMT running on 2 rigs with 3 7970's each with same version of cgminer and do not see the issue on there. I'll try running stock for awhile and see what happens.

58x0 are amazing hashing beasts for so many reasons, and this is one of them - they're one of the few GPUs that actually recovers after dying a "soft" death and cgminer restarts their threads a short while later. Nonetheless, you should try and find clocks that don't make the GPUs ever crash as I'm pretty certain this is your problem.

boozer

sr. member

Activity: 309

Merit: 250

Quote from: kano on March 17, 2012, 08:47:00 PM

Hmm OK, so it's effectively 12 devices.
That's a lot of GPU devices

Edit: oh I just noticed another thing ... you have 2 pools and the main is GPUMax - does it swap pools a lot?

Sorry for the confusion, I have 2 rigs with 3 5970's each that have the this issue (so 6 GPU's max in one of my rigs), the 2 rigs with 3 7970's each that work fine.
I haven't noticed a lot of pool swapping... occasionally one core will swap back and forth.

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: -ck on March 17, 2012, 08:47:40 PM

Quote from: kano on March 17, 2012, 08:21:23 PM

Going idle can be for two reasons, as you suggested if GPUMax isn't providing you with any work, but of course the normal reason is as ckolivas said, if your setting are too high.

Going idle can only be for ONE reason and that is the GPU not responding. Waiting on work from a server or network lag/outage does NOT register a mining thread as being idle. It makes no sense restarting a thread that is just waiting on work.

OK, yep I'm just using bad nomenclature.
I simply meant if the device itself was not processing there could only be 2 reasons I can think of

Not getting work or being a problem with it.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: kano on March 17, 2012, 08:21:23 PM

Going idle can be for two reasons, as you suggested if GPUMax isn't providing you with any work, but of course the normal reason is as ckolivas said, if your setting are too high.

Going idle can only be for ONE reason and that is the GPU not responding. Waiting on work from a server or network lag/outage does NOT register a mining thread as being idle. It makes no sense restarting a thread that is just waiting on work.

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