Author

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

member
Activity: 266
Merit: 36
cgminer 2.0.8, Ubuntu 10.04

I first ran cgminer this evening on my newly-built 3x5970 rig.  I access the rig from a Mac on a LAN via SSH.  And since this was to be a first familiarization run, I started with solo mining, pointing cgminer at an instance of bitcoind on my Mac.
Since you say you just built this - why not 11.04 or 11.10?

This is my first Unix/Linux and the idea of LTS and the implied stability was appealing.

However, you happened to ask during the process of my upgrading from 10.04 to 10.10, on the way to 11.04 and then 11.10.  Or is there a cgminer-related reason to stop at 11.04?
legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
cgminer 2.0.8, Ubuntu 10.04

I first ran cgminer this evening on my newly-built 3x5970 rig.  I access the rig from a Mac on a LAN via SSH.  And since this was to be a first familiarization run, I started with solo mining, pointing cgminer at an instance of bitcoind on my Mac.
Since you say you just built this - why not 11.04 or 11.10?
member
Activity: 266
Merit: 36
Somehow the curses stuff isn't working properly, which at the very least explains why keyboard input isn't working. Since the output seems normal when you turn off ncurses support (-T flag), that's the first problem I'd try to track down, but since I have no experience programming with ncurses, you may want to ask ckolivas for help on that one (unless someone else steps forward).

The output is the same without -T.  It's the -D that was producing output.

Each of six threads was using 16-17%, i.e., about 100% total.

Here, each thread uses ~3%. I'd accept something higher if you're using dynamic intensity, otherwise you're probably being hit by the CPU usage bug. (BTW, how many cores?)

One core (Sempron 145).  Maybe sometime I'll attempt to unlock the other, but it hasn't seemed important as I wasn't anticipating CPU intensity.

Quote
Personally, I'd try a newer version of Ubuntu, since those are more likely to be tested (I'd go for 11.04 or 11.10). Also, I'd really try using a pool since default output would be more verbose that way.

It's been my intention to use a pool; this solo experiment was just for intitial test and familiarization.  I'd be shocked if adding a pool cures what seems to be a problem of the software hanging after a couple of seconds.  But I'll add the pool just to be sure.  And then, if I'm not shocked, I'll start researching the minimum-loss way to upgrade Ubuntu.
full member
Activity: 373
Merit: 100
I have libncurses5-dev 5.7+20080803-2ubuntu3 and my configure output looks exactly the same.

Somehow the curses stuff isn't working properly, which at the very least explains why keyboard input isn't working. Since the output seems normal when you turn off ncurses support (-T flag), that's the first problem I'd try to track down, but since I have no experience programming with ncurses, you may want to ask ckolivas for help on that one (unless someone else steps forward).

Each of six threads was using 16-17%, i.e., about 100% total.

Here, each thread uses ~3%. I'd accept something higher if you're using dynamic intensity, otherwise you're probably being hit by the CPU usage bug. (BTW, how many cores?)


Personally, I'd try a newer version of Ubuntu, since those are more likely to be tested (I'd go for 11.04 or 11.10). Also, I'd really try using a pool since default output would be more verbose that way.
member
Activity: 266
Merit: 36
I can't see anything wrong with your debug output. When you start without the flags I gave above, do you ever see anything like this?
Code:
 cgminer version 2.0.8 - Started: [2011-12-16 15:15:41]
--------------------------------------------------------------------------------
 (5s):20.6 (avg):14.5 Mh/s | Q:5875  A:290  R:0  HW:0  E:5%  U:0.20/m
 TQ: 1  ST: 1  SS: 0  DW: 1201  NB: 150  LW: 0  GF: 9  RF: 0
 Connected to http://btcguild.com:8332 with LP as user ancow_others
 Block: 000004caebe22c739601e76b3f8632be...  Started: [15:46:28]
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0: 65.5C 30% | 20.5/14.5Mh/s | A:290 R:0 HW:0 U:0.20/m I:2
--------------------------------------------------------------------------------

No; without the flags I've never seen anything except the "starting" line except for the time that bitcoind wasn't running on my Mac.

Quote
If not, you probably didn't compile with curses support (If you want us to check, just post the complete output of your configure run). Make sure you have the appropriate libncurses-dev package installed (here in debian it's called libncurses5-dev).

If you want to check for yourself, the last few lines before the makefile generations should look similar to this:
Code:
checking for OpenCL... yes
checking for pthread_create in -lpthread... yes
checking for json_loads in -ljansson... no
checking for ADL_SDK/adl_sdk.h... yes
checking for library containing addstr... -lncurses
checking for addstr in -lncurses... yes
checking for addstr in -lpdcurses... no
checking for yasm... /usr/bin/yasm
checking if yasm version is greater than 1.0.1... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for LIBCURL... yes

I have libncurses5-dev 5.7+20080803-2ubuntu3 and my configure output looks exactly the same.

Quote
Just saw your latest post: is top (or htop) showing that cgminer is using above/below average CPU usage?

Each of six threads was using 16-17%, i.e., about 100% total.
full member
Activity: 373
Merit: 100
I can't see anything wrong with your debug output. When you start without the flags I gave above, do you ever see anything like this?
Code:
 cgminer version 2.0.8 - Started: [2011-12-16 15:15:41]
--------------------------------------------------------------------------------
 (5s):20.6 (avg):14.5 Mh/s | Q:5875  A:290  R:0  HW:0  E:5%  U:0.20/m
 TQ: 1  ST: 1  SS: 0  DW: 1201  NB: 150  LW: 0  GF: 9  RF: 0
 Connected to http://btcguild.com:8332 with LP as user ancow_others
 Block: 000004caebe22c739601e76b3f8632be...  Started: [15:46:28]
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0: 65.5C 30% | 20.5/14.5Mh/s | A:290 R:0 HW:0 U:0.20/m I:2
--------------------------------------------------------------------------------

If not, you probably didn't compile with curses support (If you want us to check, just post the complete output of your configure run). Make sure you have the appropriate libncurses-dev package installed (here in debian it's called libncurses5-dev).

If you want to check for yourself, the last few lines before the makefile generations should look similar to this:
Code:
checking for OpenCL... yes
checking for pthread_create in -lpthread... yes
checking for json_loads in -ljansson... no
checking for ADL_SDK/adl_sdk.h... yes
checking for library containing addstr... -lncurses
checking for addstr in -lncurses... yes
checking for addstr in -lpdcurses... no
checking for yasm... /usr/bin/yasm
checking if yasm version is greater than 1.0.1... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for LIBCURL... yes


Just saw your latest post: is top (or htop) showing that cgminer is using above/below average CPU usage?
member
Activity: 266
Merit: 36
As far as I know, everything's OK except it's not taking keypress input.

I think I spoke (wrote) too soon.  W/r my previous post showing terminal output, I thought I had screwed up with the screen program and that's why the output seemed to stop.  But a subsequent test shows that after a couple of seconds there's no more output.  Here is the end of the second test's output, two seconds after start:

Code:
[2011-12-17 06:55:36] Pushing work to requesting thread                    
[2011-12-17 06:55:36] Pushing work to getwork queue                   
[2011-12-17 06:55:36] Popping work to stage thread                   
[2011-12-17 06:55:37] initCl() finished. Found Cypress                   
[2011-12-17 06:55:37] Pushing ping to thread 6                   
[2011-12-17 06:55:37] Init GPU thread 6                   
[2011-12-17 06:55:37] List of devices:                   
[2011-12-17 06:55:37] 0 Cypress                   
[2011-12-17 06:55:37] 1 Cypress                   
[2011-12-17 06:55:37] 2 Cypress                   
[2011-12-17 06:55:37] 3 Cypress                   
[2011-12-17 06:55:37] 4 Cypress                   
[2011-12-17 06:55:37] 5 Cypress                   
[2011-12-17 06:55:37] Selected 0: Cypress                   
[2011-12-17 06:55:37] Preferred vector width reported 4                   
[2011-12-17 06:55:37] Max work group size reported 256                   
[2011-12-17 06:55:37] Loaded binary image phatk110817Cypressbitalignv2w128long8.bin                   
[2011-12-17 06:55:37] Initialising kernel phatk110817.cl with BFI_INT patching, 2 vectors and worksize 128                   
[2011-12-17 06:55:37] Popping ping in gpuminer thread                   
[2011-12-17 06:55:37] Queueing getwork request to work thread                   
[2011-12-17 06:55:37] Popping work to work thread                   
[2011-12-17 06:55:37] Popping work from get queue to get work                   
[2011-12-17 06:55:37] DBG: sending http://192.168.168.103:8332 get RPC call: {"method": "getwork", "params": [], "id":0}
                   
[2011-12-17 06:55:37] Pushing work to requesting thread                   
[2011-12-17 06:55:37] Pushing work to getwork queue                   
[2011-12-17 06:55:37] Popping work to stage thread                   
[2011-12-17 06:55:37] Pushing work to requesting thread                   
[2011-12-17 06:55:37] Pushing work to getwork queue                   
[2011-12-17 06:55:37] Popping work to stage thread                   

At this writing it's six minutes later and that's still the end of the output.
member
Activity: 266
Merit: 36
Make sure to have rpcallowip=*, server=1 and daemon=1 in your bitcoin.conf on your Mac and going with a real pool is a better idea plus the cgminer.conf if put into a .cgminer directory in your home directory on your ubuntu machine will be loaded automatically no need for the -c in the start command then.

I have rpcallowip=192.168.168.* which is my LAN.  I see no need for strangers to come knocking (even if they could climb over the fence [firewall]).  Smiley  And server=1.  I've been invoking it with -daemon.  And the -c is in a .sh, so it's not costing much.
member
Activity: 266
Merit: 36
By (*.bin) do you mean phatk110817Cypressbitalignv2w128long8.bin?  Does cgminer create that the first time it runs in any given directory?
That's the one, and yes. Is it larger than 0 bytes?

Yes, it's 750880 long.

Quote
I'm a little confused now; did it ever work or not?
When connecting to your own bitcoind, it is quite usual that you won't see a lot of output. Obviously it should respond to keyboard input, though. Anyway, I'd try running it without stderr redirection, and deleting the *.bin file beforehand. If that doesn't work or yield usable output, try one of the debugging options (-D, -T, -P).

It's never accepted keypress commands, but otherwise seems to be working (see below).  I did delete the .bin last night and it was re-created but owned by me rather than root.

Quote
(BTW, it will take a few seconds to compile the kernel initially; you are waiting long enough, aren't you?)

Yes, it ran for up to about 10 minutes several times.  ...Here's the initial output with -D -T:
Code:

[2011-12-17 06:17:16] Started cgminer 2.0.8
[2011-12-17 06:17:16] Testing pool http://192.168.168.103:8332
[2011-12-17 06:17:16] Popping work to stage thread
[2011-12-17 06:17:16] Popping work to work thread
[2011-12-17 06:17:17] Successfully retrieved and deciphered work from pool 0 http://192.168.168.103:8332
[2011-12-17 06:17:17] Pushing pooltest work to base pool
[2011-12-17 06:17:17] Pool 0 http://192.168.168.103:8332 active
[2011-12-17 06:17:17] Pushing work to getwork queue
[2011-12-17 06:17:17] Popping work to stage thread
[2011-12-17 06:17:17] Setting GPU 0 engine clock to 950
[2011-12-17 06:17:17] Setting GPU 1 engine clock to 950
[2011-12-17 06:17:17] Failed to ADL_Overdrive5_FanSpeedInfo_Get
[2011-12-17 06:17:17] GPU 1 doesn't support rpm or percent write
[2011-12-17 06:17:17] GPU 1 doesn't support rpm or percent write
[2011-12-17 06:17:17] Setting GPU 2 engine clock to 950
[2011-12-17 06:17:17] Setting GPU 3 engine clock to 950
[2011-12-17 06:17:17] Failed to ADL_Overdrive5_FanSpeedInfo_Get
[2011-12-17 06:17:17] GPU 3 doesn't support rpm or percent write
[2011-12-17 06:17:17] GPU 3 doesn't support rpm or percent write
[2011-12-17 06:17:17] Setting GPU 4 engine clock to 950
[2011-12-17 06:17:17] Setting GPU 5 engine clock to 950
[2011-12-17 06:17:17] Failed to ADL_Overdrive5_FanSpeedInfo_Get
[2011-12-17 06:17:17] GPU 5 doesn't support rpm or percent write
[2011-12-17 06:17:17] GPU 5 doesn't support rpm or percent write
[2011-12-17 06:17:17] Pushing ping to thread 0
[2011-12-17 06:17:17] Init GPU thread 0
[2011-12-17 06:17:17] List of devices:
[2011-12-17 06:17:17]   0       Cypress
[2011-12-17 06:17:17]   1       Cypress
[2011-12-17 06:17:17]   2       Cypress
[2011-12-17 06:17:17]   3       Cypress
[2011-12-17 06:17:17]   4       Cypress
[2011-12-17 06:17:17]   5       Cypress
[2011-12-17 06:17:17] Selected 0: Cypress
[2011-12-17 06:17:17] Preferred vector width reported 4
[2011-12-17 06:17:17] Max work group size reported 256
[2011-12-17 06:17:17] Loaded binary image phatk110817Cypressbitalignv2w128long8.bin
[2011-12-17 06:17:17] Initialising kernel phatk110817.cl with BFI_INT patching, 2 vectors and worksize 128
[2011-12-17 06:17:17] initCl() finished. Found Cypress
[2011-12-17 06:17:17] Pushing ping to thread 1
[2011-12-17 06:17:17] Init GPU thread 1
[2011-12-17 06:17:17] List of devices:
[2011-12-17 06:17:17]   0       Cypress
[2011-12-17 06:17:17]   1       Cypress
[2011-12-17 06:17:17]   2       Cypress
[2011-12-17 06:17:17]   3       Cypress
[2011-12-17 06:17:17]   4       Cypress
[2011-12-17 06:17:17]   5       Cypress
[2011-12-17 06:17:17] Selected 1: Cypress
[2011-12-17 06:17:17] Preferred vector width reported 4
[2011-12-17 06:17:17] Max work group size reported 256
[2011-12-17 06:17:17] Loaded binary image phatk110817Cypressbitalignv2w128long8.bin
[2011-12-17 06:17:17] Initialising kernel phatk110817.cl with BFI_INT patching, 2 vectors and worksize 128
[2011-12-17 06:17:17] Popping ping in gpuminer thread
[2011-12-17 06:17:17] Queueing getwork request to work thread
[2011-12-17 06:17:17] Popping work to work thread
[2011-12-17 06:17:17] Popping work from get queue to get work
[2011-12-17 06:17:17] DBG: sending http://192.168.168.103:8332 get RPC call: {"method": "getwork", "params": [], "id":0}

[2011-12-17 06:17:17] initCl() finished. Found Cypress
[2011-12-17 06:17:17] Pushing ping to thread 2
[2011-12-17 06:17:17] Init GPU thread 2
[2011-12-17 06:17:17] List of devices:
[2011-12-17 06:17:17]   0       Cypress
[2011-12-17 06:17:17]   1       Cypress
[2011-12-17 06:17:17]   2       Cypress
[2011-12-17 06:17:17]   3       Cypress
[2011-12-17 06:17:17]   4       Cypress
[2011-12-17 06:17:17]   5       Cypress
[2011-12-17 06:17:17] Selected 2: Cypress
[2011-12-17 06:17:17] Preferred vector width reported 4
[2011-12-17 06:17:17] Max work group size reported 256
[2011-12-17 06:17:17] Loaded binary image phatk110817Cypressbitalignv2w128long8.bin
[2011-12-17 06:17:17] Initialising kernel phatk110817.cl with BFI_INT patching, 2 vectors and worksize 128
[2011-12-17 06:17:17] Popping ping in gpuminer thread
[2011-12-17 06:17:17] Queueing getwork request to work thread
[2011-12-17 06:17:17] Popping work to work thread
[2011-12-17 06:17:17] Popping work from get queue to get work
[2011-12-17 06:17:17] DBG: sending http://192.168.168.103:8332 get RPC call: {"method": "getwork", "params": [], "id":0}

[2011-12-17 06:17:17] initCl() finished. Found Cypress
[2011-12-17 06:17:17] Pushing ping to thread 3
[2011-12-17 06:17:17] Init GPU thread 3
[2011-12-17 06:17:17] List of devices:
[2011-12-17 06:17:17]   0       Cypress
[2011-12-17 06:17:17]   1       Cypress
[2011-12-17 06:17:17]   2       Cypress
[2011-12-17 06:17:17]   3       Cypress
[2011-12-17 06:17:17]   4       Cypress
[2011-12-17 06:17:17]   5       Cypress
[2011-12-17 06:17:17] Selected 3: Cypress
[2011-12-17 06:17:17] Preferred vector width reported 4
[2011-12-17 06:17:17] Max work group size reported 256
[2011-12-17 06:17:17] Loaded binary image phatk110817Cypressbitalignv2w128long8.bin
[2011-12-17 06:17:17] Initialising kernel phatk110817.cl with BFI_INT patching, 2 vectors and worksize 128
[2011-12-17 06:17:17] Popping ping in gpuminer thread
[2011-12-17 06:17:17] Queueing getwork request to work thread
[2011-12-17 06:17:17] Popping work to work thread
[2011-12-17 06:17:17] Popping work from get queue to get work
[2011-12-17 06:17:17] DBG: sending http://192.168.168.103:8332 get RPC call: {"method": "getwork", "params": [], "id":0}

[2011-12-17 06:17:17] initCl() finished. Found Cypress
[2011-12-17 06:17:17] Pushing ping to thread 4
[2011-12-17 06:17:17] Init GPU thread 4
[2011-12-17 06:17:17] List of devices:
[2011-12-17 06:17:17]   0       Cypress
[2011-12-17 06:17:17]   1       Cypress
[2011-12-17 06:17:17]   2       Cypress
[2011-12-17 06:17:17]   3       Cypress
[2011-12-17 06:17:17]   4       Cypress
[2011-12-17 06:17:17]   5       Cypress
[2011-12-17 06:17:17] Selected 4: Cypress
[2011-12-17 06:17:17] Preferred vector width reported 4
[2011-12-17 06:17:17] Max work group size reported 256
[2011-12-17 06:17:17] Loaded binary image phatk110817Cypressbitalignv2w128long8.bin
[2011-12-17 06:17:17] Initialising kernel phatk110817.cl with BFI_INT patching, 2 vectors and worksize 128
[2011-12-17 06:17:17] Popping ping in gpuminer thread
[2011-12-17 06:17:17] Queueing getwork request to work thread
[2011-12-17 06:17:17] Popping work to work thread
[2011-12-17 06:17:17] Popping work from get queue to get work
[2011-12-17 06:17:17] DBG: sending http://192.168.168.103:8332 get RPC call: {"method": "getwork", "params": [], "id":0}

[2011-12-17 06:17:17] initCl() finished. Found Cypress
[2011-12-17 06:17:17] Pushing ping to thread 5
[2011-12-17 06:17:17] Init GPU thread 5
[2011-12-17 06:17:17] List of devices:
[2011-12-17 06:17:17]   0       Cypress
[2011-12-17 06:17:17]   1       Cypress
[2011-12-17 06:17:17]   2       Cypress
[2011-12-17 06:17:17]   3       Cypress
[2011-12-17 06:17:17]   4       Cypress
[2011-12-17 06:17:17]   5       Cypress
[2011-12-17 06:17:17] Selected 5: Cypress
[2011-12-17 06:17:17] Preferred vector width reported 4
[2011-12-17 06:17:17] Max work group size reported 256
[2011-12-17 06:17:17] Loaded binary image phatk110817Cypressbitalignv2w128long8.bin
[2011-12-17 06:17:17] Initialising kernel phatk110817.cl with BFI_INT patching, 2 vectors and worksize 128
[2011-12-17 06:17:17] Popping ping in gpuminer thread
[2011-12-17 06:17:17] Queueing getwork request to work thread
[2011-12-17 06:17:17] Popping work to work thread
[2011-12-17 06:17:17] Popping work from get queue to get work
[2011-12-17 06:17:17] DBG: sending http://192.168.168.103:8332 get RPC call: {"method": "getwork", "params": [], "id":0}

[2011-12-17 06:17:17] initCl() finished. Found Cypress
[2011-12-17 06:17:17] Pushing ping to thread 6
[2011-12-17 06:17:17] Init GPU thread 6
[2011-12-17 06:17:17] List of devices:
[2011-12-17 06:17:17]   0       Cypress
[2011-12-17 06:17:17]   1       Cypress
[2011-12-17 06:17:17]   2       Cypress
[2011-12-17 06:17:17]   3       Cypress
[2011-12-17 06:17:17]   4       Cypress
[2011-12-17 06:17:17]   5       Cypress
[2011-12-17 06:17:17] Selected 0: Cypress
[2011-12-17 06:17:17] Preferred vector width reported 4
[2011-12-17 06:17:17] Max work group size reported 256
[2011-12-17 06:17:17] Loaded binary image phatk110817Cypressbitalignv2w128long8.bin
[2011-12-17 06:17:17] Initialising kernel phatk110817.cl with BFI_INT patching, 2 vectors and worksize 128
[2011-12-17 06:17:17] Pushing work to requesting thread
[2011-12-17 06:17:17] Pushing work to getwork queue
[2011-12-17 06:17:17] Popping work to stage thread
[2011-12-17 06:17:18] Popping ping in gpuminer thread
[2011-12-17 06:17:18] Queueing getwork request to work thread
[2011-12-17 06:17:18] Popping work to work thread
[2011-12-17 06:17:18] Popping work from get queue to get work
[2011-12-17 06:17:18] DBG: sending http://192.168.168.103:8332 get RPC call: {"method": "getwork", "params": [], "id":0}

[2011-12-17 06:17:18] Pushing work to requesting thread
[2011-12-17 06:17:18] Pushing work to getwork queue
[2011-12-17 06:17:18] Popping work to stage thread
[2011-12-17 06:17:18] Pushing work to requesting thread
[2011-12-17 06:17:18] Pushing work to requesting thread
[2011-12-17 06:17:18] Pushing work to requesting thread
[2011-12-17 06:17:18] Pushing work to getwork queue
[2011-12-17 06:17:18] Popping work to stage thread
[2011-12-17 06:17:18] Pushing work to getwork queue
[2011-12-17 06:17:18] Popping work to stage thread
[2011-12-17 06:17:18] Pushing work to getwork queue
[2011-12-17 06:17:18] Popping work to stage thread
[2011-12-17 06:17:18] [thread 4: 16777216 hashes, 15970331 khash/sec]
[2011-12-17 06:17:18] [thread 3: 16777216 hashes, 15663626 khash/sec]
[2011-12-17 06:17:19] Pushing work to requesting thread
[2011-12-17 06:17:19] Pushing work to getwork queue
[2011-12-17 06:17:19] Popping work to stage thread

As far as I know, everything's OK except it's not taking keypress input.
EDIT:  Not true: see my second later post.
full member
Activity: 373
Merit: 100
I use something really similar and it works, so there are pretty much two options:
a) from your previous run with sudo, the kernel file (*.bin) is owned by root and can't be opened by cgminer (this might concern other files, too)
b) there is a problem with library versions, which would be pretty hard to track down, so you better hope it's a)... Wink

Edit: as a quick test, you could try running cgminer with sudo again, just to see whether it works...
Quick test:  sudo doesn't make a difference.

By (*.bin) do you mean phatk110817Cypressbitalignv2w128long8.bin?  Does cgminer create that the first time it runs in any given directory?
That's the one, and yes. Is it larger than 0 bytes?

I do have a *little* more info:  for the first try with sudo I had forgotten to start bitcoind on my Mac and cgminer cleared the console and put out a long lament about not being able to connect, having  no work, and generally feeling lonely.  So we know that it can output to the console more than its starting announcement.

I'm a little confused now; did it ever work or not?
When connecting to your own bitcoind, it is quite usual that you won't see a lot of output. Obviously it should respond to keyboard input, though. Anyway, I'd try running it without stderr redirection, and deleting the *.bin file beforehand. If that doesn't work or yield usable output, try one of the debugging options (-D, -T, -P).

(BTW, it will take a few seconds to compile the kernel initially; you are waiting long enough, aren't you?)
member
Activity: 266
Merit: 36
I use something really similar and it works, so there are pretty much two options:
a) from your previous run with sudo, the kernel file (*.bin) is owned by root and can't be opened by cgminer (this might concern other files, too)
b) there is a problem with library versions, which would be pretty hard to track down, so you better hope it's a)... Wink

Edit: as a quick test, you could try running cgminer with sudo again, just to see whether it works...
Quick test:  sudo doesn't make a difference.

By (*.bin) do you mean phatk110817Cypressbitalignv2w128long8.bin?  Does cgminer create that the first time it runs in any given directory?

I do have a *little* more info:  for the first try with sudo I had forgotten to start bitcoind on my Mac and cgminer cleared the console and put out a long lament about not being able to connect, having  no work, and generally feeling lonely.  So we know that it can output to the console more than its starting announcement.

I'm going to bed with a heavy b) heart.
full member
Activity: 373
Merit: 100
Code:
DISPLAY=:0 cgminer -c cgminer.conf 2> logs/$now.log

(Confidential to those helping me earlier today:  I was logged in on the rig, so I dropped the sudo.)

[...]

OK guys, I have braced myself for looking stupid:  why is it unresponsive to the terminal and producing no output?

I use something really similar and it works, so there are pretty much two options:
a) from your previous run with sudo, the kernel file (*.bin) is owned by root and can't be opened by cgminer (this might concern other files, too)
b) there is a problem with library versions, which would be pretty hard to track down, so you better hope it's a)... Wink

Edit: as a quick test, you could try running cgminer with sudo again, just to see whether it works...
legendary
Activity: 1762
Merit: 1011
so two things
One(obviously) My antivirus software is bitching about the miner, Blahblah. Dont really care, Just thought it should be said.

Yep, I saw this with Microsoft Security Essentials today.
member
Activity: 266
Merit: 36
cgminer 2.0.8, Ubuntu 10.04

I first ran cgminer this evening on my newly-built 3x5970 rig.  I access the rig from a Mac on a LAN via SSH.  And since this was to be a first familiarization run, I started with solo mining, pointing cgminer at an instance of bitcoind on my Mac.

I use this small script to run it:
Code:
#!/bin/bash
now="`date +%Y%m%d%H%M%S`"
cd ~/miners
DISPLAY=:0 cgminer -c cgminer.conf 2> logs/$now.log

(Confidential to those helping me earlier today:  I was logged in on the rig, so I dropped the sudo.)

When cgminer starts, I notice two things immediately:
It outputs a line on the terminal saying it started;
The GPU fan speeds increase substantially.

I also notice a little later via ps that there are six cgminer processes, which I hope is normal at one per GPU core.  I also notice a file in the current directory:
-rw-r--r-- 1 root root 750880 2011-12-16 22:36 phatk110817Cypressbitalignv2w128long8.bin

The log file is created, but it's empty.  Nor is there any further console output.

Here's the thing:  it's not responsive to the keyboard.  Keypress commands such as P, G, or Q are merely echoed.  I wondered if this had something to do with using a remote terminal, so I tried running it locally.  Whoops, I had specified an -intensity of 8 for all six cores, so in effect I was locked out of my monitor.  (I know about "d" but the .conf was intended for remote use and I had forgotten that.)

So each time I ran it I stopped it (and dropped the GPU fan revs) by rebooting.

Here's the .conf file, based on the example that came with the source code:
Code:
{
"pools" : [
{
"url" : "http://192.168.168.123:8332",
"user" : "oboy",
"pass" : "supersekrit"
}
],

"intensity" : "8",
"gpu-engine" : "0-950",
"gpu-fan" : "0-85",
"temp-cutoff" : "95,95,95,95,95,95",
"temp-overheat" : "85,85,85,85,85,85",
"temp-target" : "75,75,75,75,75,75",

"auto-fan" : true,
"auto-gpu" : true,
"expiry" : "120",
"gpu-threads" : "2",
"log" : "5",
"queue" : "1",
"retry-pause" : "5",
"scan-time" : "60",
"temp-hysteresis" : "3",
"worksize" : "0",

"donation" : "0.00",
"shares" : "0",
"kernel-path" : "/usr/local/bin"
}

OK guys, I have braced myself for looking stupid:  why is it unresponsive to the terminal and producing no output?

Edit:  I changed intensity to "d,8,8,8,8,8" to try another local run but I was still locked out of the monitor.
I said the log files were empty, but in fact each contains the "cgminer started" message.
full member
Activity: 236
Merit: 109
Ok, I will try but the thing is when a VGA works ALONE the hashrate is high as it is used to be. The hashrate drops when I activate the 2nd VGA and drops even more if I activate the 3rd one.

Just out of curiosity, what kind of hardware problems have you eliminated so far?
One reason I can think of why a second card might cause another to slow is that the power supply's output isn't high enough, but I'd expect a much higher impact on hashrate in that case.
What I'd expect to be much more likely is that those graphics cards all use the same bus to communicate with the CPU/whatever, which would result in the behaviour you describe.

One more thing for you to try, though (in case it is a software problem): if you manually set the intensity of the first card (start, say, with 3 and use cgminer's menu to go from there), does that help at all? What effects does that have (on the second and third cards, the effect on the first should be obvious)?

(Just because I'm a little anal about these things: this is what "VGA" means: http://en.wikipedia.org/wiki/VGA)

Concearning H/W problems did you mean my rig?
PSU is Corsair AX1200 6 months old.

"What I'd expect to be much more likely is that those graphics cards all use the same bus to communicate with the CPU/whatever, which would result in the behaviour you describe" What to do about that?

Changing the intensity on any of GPUs (instead of VGA:)) did not lead to any improvement on others.

But the thing I noticed is when I run phoenix and change the cpu affinity all the GPUs perform well (less hashrate than it was earlier but stable. I did not downgrade drivers) I will downgrade drivers and hope the hashrate will return to normal.




legendary
Activity: 1428
Merit: 1001
Okey Dokey Lokey
so two things
One(obviously) My antivirus software is bitching about the miner, Blahblah. Dont really care, Just thought it should be said.

Second, Hey, Does anyone have a GUI for CGminer? The ONLY reason why i havent switched to CGminer and why im still using GUIminer, Is for the GUI
member
Activity: 266
Merit: 36
Since ancow reminded me that using root is dangerous, I will point out that this is what I was saying might work in my earlier post.  However, I don't think having X running not logged in is saving resources, so I would re-suggest logging into the main X session with the user that you are connecting to a separate VNC session with, then you won't need to use sudo because that user will have access to the display.  Since you would be using VNC on a non-GPU display to control it, only the CPUs would be doing anything for that display (as they are anyway).  Also, note that in either scenario (with sudo or with the main X session logged in as the same user) you could do the same thing with SSH instead of VNC to use even less resources.

(At least for now I've switched from VNC to SSH.  If I get desperate for GUI I can ssh -X, etc.)

If I understand correctly, you're suggesting a physical interaction on the miner machine to log in.  I was trying to avoid that, but now I'm not sure that would save me any significant inconvenience as there should be very few restarts as opposed to power-ups.  I guess it would save me about 30 seconds of waiting for the log-in prompt on each power-up -- not a big deal.  And (saving a separate reply) I'll also consider SAC's auto-login approach.
full member
Activity: 373
Merit: 100
Your welcome. I don't need the sudo but my machines auto-login to the desktop so that may be the difference.

That's actually a pretty nice idea; set you login manager to auto-login to a minimalistic DE like wm2, and you at least don't need root permissions. Obviously don't have anything important on that account or anyone with physical access to your computer gets access to that, too.
hero member
Activity: 807
Merit: 500
proofer@miner:~$ DISPLAY=:0 sudo aticonfig --odgt --adapter=all
[...]
proofer@miner:~$ DISPLAY=:0 sudo cgminer -n

It's always the simplest things, huh?
I was actually avoiding suggesting root permissions, what with them providing a great way to fuck up any system. Glad it worked out for you, though.
Since ancow reminded me that using root is dangerous, I will point out that this is what I was saying might work in my earlier post.  However, I don't think having X running not logged in is saving resources, so I would re-suggest logging into the main X session with the user that you are connecting to a separate VNC session with, then you won't need to use sudo because that user will have access to the display.  Since you would be using VNC on a non-GPU display to control it, only the CPUs would be doing anything for that display (as they are anyway).  Also, note that in either scenario (with sudo or with the main X session logged in as the same user) you could do the same thing with SSH instead of VNC to use even less resources.
full member
Activity: 373
Merit: 100
proofer@miner:~$ DISPLAY=:0 sudo aticonfig --odgt --adapter=all
[...]
proofer@miner:~$ DISPLAY=:0 sudo cgminer -n

It's always the simplest things, huh?
I was actually avoiding suggesting root permissions, what with them providing a great way to fuck up any system. Glad it worked out for you, though.
Jump to: