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

[Proofer]

I removed the vncserver invocation from /etc/local.rc, rebooted the Ubuntu system, and then on the Mac:

This time following SAC's instruction more precisely:

Code:

proofer@miner:~$ DISPLAY=:0 cgminer
No protocol specified
[2011-12-16 16:08:55] Error: Getting Device IDs (num)
[2011-12-16 16:08:55] clDevicesNum returned error, none usable
[2011-12-16 16:08:55] Started cgminer 2.0.8

[many blank lines omitted]

[2011-12-16 16:08:55] Need to specify at least one pool server.
Input server details.
URL:

[1715080033]

1715080033

[1715080033]

1715080033

[1715080033]

1715080033

[1715080033]

1715080033

[Proofer]

That almost seems like there is no ATI driver/OpenCL installed how did you do those?

Summary: cgminer doesn't see GPUs only when accessed remotely via VNC.

Ubuntu 10.04, 3x5970, cgminer 2.0.8

When I am logged in on the mining system:

proofer@minerr:~$ cgminer -n
1 GPU devices detected
proofer@miner:~$ export DISPLAY=:0
proofer@miner:~$ cgminer -n
6 GPU devices detected
...

As to the "how" on the ATI driver/OpenCL, I downloaded the latest Catalyst package from AMD's site and installed it.  I can see the temperatures of my 5970s, etc., with the ATI utilities -- but only when logged in locally.

And if your not totally committed to the 10.04 try this guide to installing it on 11.04 works great. You would need to go into your .ssh/known_hosts file on your mac and delete the line for the 192.168.168.101 that is in there otherwise when you go to ssh into it the Mac will refuse to connect as you will have new key on the fresh install.

I'm not totally committed but I'm temporarily committed.  My instinct is that it's not a 10.04-specific issue, but my Ubuntu-specific instincts don't have seasoning behind them.

http://forum.bitcoin.org/index.php?topic=9239.0

(Describes a headless miner.)  I might go totally headless -- no monitor or keyboard -- after a while, in which case I'll be going back to that post.

I'll take some time to study the cgminer/cgminer.conf material [not quoted] -- thanks!

[Proofer]

As to the "how" on the ATI driver/OpenCL, I downloaded the latest Catalyst package from AMD's site and installed it.  I can see the temperatures of my 5970s, etc., with the ATI utilities -- but only when logged in locally.

It is my understanding that does not give you the SDK which is required to mine.

I neglected to mention that I had installed AMD-APP-SDK-v2.5-lnx64 and the required .h files from AMD ADL_SDK_3.0 .  The build of 2.0.8 confirmed that GPU mining is enabled.

...
I'm not totally committed but I'm temporarily committed.  My instinct is that it's not a 10.04-specific issue, but my Ubuntu-specific instincts don't have seasoning behind them.

Well that is getting long in the tooth as they say some of the required libraries may not be up to date enough to allow you to do what is needed to mine.

It's possible, but I don't want to go to a later Ubuntu until I know that's the case.

http://forum.bitcoin.org/index.php?topic=9239.0

(Describes a headless miner.)  I might go totally headless -- no monitor or keyboard -- after a while, in which case I'll be going back to that post.

Only in that you don't need to connect a monitor and keyboard otherwise it works fine in the mean time with them connected. Your going to want to follow at least the SDK install part of that guide plus the pyopencl and the python-jsonrpc which last I did it needed this change to get it done after having installed the bzr program. Hopefully this works for you and gets the required pieces in place to allow you to mine.

Code:

bzr checkout http://bzr.json-rpc.org/trunk ; cd trunk/python-jsonrpc

I'll double-check that I have those pieces; the guide I used was the README that came with the 2.0.8 source code.

[Proofer]

So you seen similar to this once done the ./configure step.

Code:

------------------------------------------------------------------------
cgminer 2.0.8
------------------------------------------------------------------------


Configuration Options Summary:

  OpenCL...............: FOUND. GPU mining support enabled
  ADL..................: SDK found, GPU monitoring support enabled
  ASM..................: false

Compilation............: make (or gmake)
  CPPFLAGS.............: 
  CFLAGS...............: -g -O2
  LDFLAGS..............:  -lpthread -ldl

Installation...........: make install (as root if needed, with 'su' or 'sudo')
  prefix...............: /usr/local

Here's mine:

Code:

------------------------------------------------------------------------
cgminer 2.0.8
------------------------------------------------------------------------


Configuration Options Summary:

  OpenCL...............: FOUND. GPU mining support enabled
  ADL..................: SDK found, GPU monitoring support enabled
  ASM(for CPU mining).: true

Compilation............: make (or gmake)
  CPPFLAGS.............: 
  CFLAGS...............: -O2 -Wall -march=native
  LDFLAGS..............:  -lpthread
  LDADD................: -ldl

Installation...........: make install (as root if needed, with 'su' or 'sudo')
  prefix...............: /usr/local

...
That README does not cover the miner's other pieces needed to set it up correctly if my memory severs me you need the other steps.

I'll check the guide in that post you linked to make sure.

[ancow]

[Sorry about the Ubuntu/Fedora confusion, that happens when I'm tired... ]

http://forum.bitcoin.org/index.php?topic=9239.0

(Describes a headless miner.)  I might go totally headless -- no monitor or keyboard -- after a while, in which case I'll be going back to that post.

To do the headless setup, you don't need to go totally headless. It pretty much only means that you don't have to got sit at the actual machine to do your mining. Do the gdm disabling and leave the vncserver startup wherever, and you'll have graphical remote access.

Only in that you don't need to connect a monitor and keyboard otherwise it works fine in the mean time with them connected. Your going to want to follow at least the SDK install part of that guide plus the pyopencl and the python-jsonrpc which last I did it needed this change to get it done after having installed the bzr program. Hopefully this works for you and gets the required pieces in place to allow you to mine.

Code:

bzr checkout http://bzr.json-rpc.org/trunk ; cd trunk/python-jsonrpc

Why does Proofer need the python stuff for cgminer? That should only be needed for phoenix.

[Proofer]

SOLVED!  Actually that Phoenix set-up post to which SAC linked provided the clue in an example of aticonfig.

This is from my Mac using ssh; the solution is in bold:
------------------------------------------------------------
proofer@miner:~$ DISPLAY=:0 sudo aticonfig --odgt --adapter=all
[sudo] password for proofer:

Adapter 0 - ATI Radeon HD 5900 Series
            Sensor 0: Temperature - 43.00 C

Adapter 1 - ATI Radeon HD 5900 Series
            Sensor 0: Temperature - 46.50 C

Adapter 2 - ATI Radeon HD 5900 Series
            Sensor 0: Temperature - 44.50 C

Adapter 3 - ATI Radeon HD 5900 Series
            Sensor 0: Temperature - 40.00 C

Adapter 4 - ATI Radeon HD 5900 Series
            Sensor 0: Temperature - 39.50 C

Adapter 5 - ATI Radeon HD 5900 Series
            Sensor 0: Temperature - 42.50 C
proofer@miner:~$ DISPLAY=:0 sudo cgminer -n
6 GPU devices detected
------------------------------------------------------------

ancow, SAC, The00Dustin -- thanks for the help!  (This really is a great forum.)

[ancow]

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.

[The00Dustin]

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.

[ancow]

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.

[Proofer]

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.

[Fiyasko]

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

[RedLine888]

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.

[Proofer]

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.

[mmortal03]

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.

[ancow]

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

Edit: as a quick test, you could try running cgminer with sudo again, just to see whether it works...

[Proofer]

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

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.

[ancow]

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

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

[Proofer]

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.

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.

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

[Proofer]

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]).    And server=1.  I've been invoking it with -daemon.  And the -c is in a .sh, so it's not costing much.

[Proofer]

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.