[2011-07-24 02:22:31] Failed to init GPU thread 0                                                                                                           

Aha. It never even started and you hit another bug trying to reference a thread that wasn't there. Luckily I have an idea as to why it didn't start. Perhaps osx doesn't like out of order execution enabled. Now updated in git, hopefully fixing both.

Thanks very much for the backtrace! Fixed in git.

Thanks! The backtrace helps to know why it segfaults (fixed in git now), but not why it's failing to create a command queue. I've tried backing out the compiler unloading patch as well in case that's the reason (changes are in git).

I was aware phatk was incompatible with quite a few things, which is why I kept the poclbm kernel in there. Some of the detection changes might select phatk now if they hadn't previously, so perhaps that's the issue. Try explicitly setting the kernel (new feature in 1.4.0) to poclbm with -k poclbm

Uh yeah, about that. I haven't got the foggiest how to talk [to] that library yet... There was so much I wanted to code for cgminer first that I knew I could do before looking at it (as you can probably see from the hundreds of hours of code I've put in already).

I don't use an IDE. Just a text editor (kate) on linux.

I was considering that long term. It's just that with the code and features changing so rapidly, deciding on a format for the config file that's easy to use and parse is the real issue. Currently it accepts some basic json formatted config file and working on parsing code is not remotely my strong point 

Yes it's intel only. No, I cannot make an amd implementation because I'm not an assembly coder, but I'm very happy to accept code from others (which is where the SSE4 implementation came from). SSE4 was only marginally faster than SSE2 anyway on my Intel based CPU.

NOTE: None of this has anything to do with GPU mining.

Your hardware simply does not support the full sse4 set so nothing I can do will make that sse4 code work on your machine.

CURLOPT_SOCKOPTFUNCTION (Option added in 7.15.6.)

Darn.

About speed in this new release:

Note there are a number of changes that will appear to affect reported speed in this release compared to previous ones.

First of all, there is a new kernel, which means that a new binary will be force built so the startup the first time you start it will be slower.

Second, the counters are no longer reset after all the threads have started - that was artificially raising the reported speed initially to ridiculous fake values.

Thus the reported speed will appear to be lower for a good 5 minutes or so. Give it some time.

However, the actual kernel code should be slightly faster now for 2 reasons.

First there is an updated kernel based on diapolo's modifications from here:
http://forum.bitcoin.org/index.php?topic=25860

Second, the code was audited to ensure I could allow the GPUs to run the code out-of-order.

Both of these should actually speed the kernel up.

Don't expect to see massive changes in speed, but any improvement is always welcome

Finally, dynamic mode will now throttle things much more dramatically under heavy user load to minimise the impact on the user experience. The intensity range used to go from 0-14, but now goes from -10 to +10. Levels above 10 were counter-productive, and in the opposite direction, some cards performed poorly even at intensity 0 (notably nvidia GPUs and lower spec 4x ATI cards).

Well, I made it so it would compile even if your CPU didn't support the instruction, as requested. Now ytf it apparently doesn't support the instruction generated, when you have sse4a listed in your flags, is beyond me. Clearly whatever the instructions are in it, are not supported (and that explains why it refused to compile with it previously). Specifically it searches for SSE4.1 and I don't know how that differs from sse4.2 and sse4a (google might help). It will still detect what is supported and choose sse4 if it is there. If not supported, I suspect it will automatically default to sse2.

Yes it tests any new pool added to the list to see if it's alive. Since it asks for work, it seems a shame to just throw that work out, so it adds it to its queue 

New release 1.4.0

Source:
http://ck.kolivas.org/apps/cgminer/cgminer-1.4.0.tar.bz2

Win32 build:
http://ck.kolivas.org/apps/cgminer/cgminer-1.4.0-win32.zip

Summary: lots and lots of fixes and lots of new features via the menu

Version 1.4.0 - July 23, 2011

- Feature upgrade: Add keyboard input during runtime to allow modification of
and viewing of numerous settings such as adding/removing pools, changing
multipool management strategy, switching pools, changing intensiy, verbosity,
etc. with a simple keypress menu system.
- Free up resources/stale compilers.
- Kernels are safely flushed in a way that allows out of order execution to
work.
- Sometimes the cl compiler generates zero sized binaries and only a reboot
seems to fix it.
- Don't try to stop/cancel threads that don't exist.
- Only set option to show devices and exit if built with opencl support.
- Enable curses earlier and exit with message in main for messages to not be
lost in curses windows.
- Make it possible to enter server credentials with curses input if none are
specified on the command line.
- Abstract out a curses input function and separate input pool function to allow
for live adding of pools later.
- Remove the nil arguments check to allow starting without parameters.
- Disable/enable echo & cbreak modes.
- Add a thread that takes keyboard input and allow for quit, silent, debug,
verbose, normal, rpc protocol debugging and clear screen options.
- Add pool option to input and display current pool status, pending code to
allow live changes.
- Add a bool for explicit enabling/disabling of pools.
- Make input pool capable of bringing up pools while running.
- Do one last check of the work before submitting it.
- Implement the ability to live add, enable, disable, and switch to pools.
- Only internally test for block changes when the work matches the current pool
to prevent interleaved block change timing on multipools.
- Display current pool management strategy to enable changing it on the fly.
- The longpoll blanking of the current_block data may not be happening before
the work is converted and appears to be a detected block change.     Blank the
current block be
- Make --no-longpoll work again.
- Abstract out active pools count.
- Allow the pool strategy to be modified on the fly.
- Display pool information on the fly as well.
- Add a menu and separate out display options.
- Clean up the messy way the staging thread communicates with the longpoll
thread to determine who found the block first.
- Make the input windows update immediately instead of needing a refresh.
- Allow log interval to be set in the menu.
- Allow scan settings to be modified at runtime.
- Abstract out the longpoll start and explicitly restart it on pool change.
- Make it possible to enable/disable longpoll.
- Set priority correctly on multipools.     Display priority and alive/dead
information in display_pools.
- Implement pool removal.
- Limit rolltime work generation to 10 iterations only.
- Decrease testing log to info level.
- Extra refresh not required.
- With huge variation in GPU performance, allow intensity to go from -10 to +10.
- Tell getwork how much of a work item we're likely to complete for future
splitting up of work.
- Remove the mandatory work requirement at startup by testing for invalid work
being passed which allows for work to be queued immediately.     This also
removes the requirem
- Make sure intensity is carried over to thread count and is at least the
minimum necessary to work.
- Unlocking error on retry. Locking unnecessary anyway so remove it.
- Clear log window from consistent place. No need for locking since logging is
disabled during input.
- Cannot print the status of threads that don't exist so just queue enough work
for the number of mining threads to prevent crash with -Q N.
- Update phatk kernel to one with new parameters for slightly less overhead
again.     Make the queue kernel parameters call a function pointer to select
phatk or poclbm.
- Make it possible to select the choice of kernel on the command line.
- Simplify the output part of the kernel. There's no demonstrable advantage from
more complexity.
- Merge pull request #18 from ycros/cgminer
- No need to make leaveok changes win32 only.
- Build support in for all SSE if possible and only set the default according to
machine capabilities.
- Win32 threading and longpoll keepalive fixes.
- Win32: Fix for mangled output on the terminal on exit.

Just tested it:

[2011-07-23 12:59:10] 4 cpu miner threads started, using SHA256 'sse4_64' algorithm.                   

seems to work for me??

Make sure you do make clean && ./autogen.sh before ./configure when building from git?

 

That's basically failover that you're describing... That's the default policy. Or do you mean micro delays instead of macro ones?

Thanks. Fixed in git.

Nope. Cannot reproduce :\

You can't GPU mine unless you're running an X server. It relies on the driver being in use to communicate with the card. While headless systems can have no monitors attached (like my own), they still need to be running X.

If you want it to work remotely, use
export DISPLAY=:0
after ssh'ing in.