I think you missed this a few pages back... https://bt.irlbtc.com/view/28402.msg3538435#msg3538435

We discuss it further here:
https://forum.litecoin.net/index.php/topic,6925.0.html

Others are going to pick up the pieces and continue development here: https://forum.litecoin.net/index.php/topic,6994.0.html

Here is a link to instructions.  Scroll down to the section that says Rpi freezing up.

http://projectklondike.org/how-to-run

Chad

It's unstable on my b3. The latest stable version for mine is 3.6.6, it runs strong but requires daily restarts due to filling up the very small ram on the tplink.

Use a tag
git checkout v3.7.2

or whatever

is not only Windows
Ubuntu 13.10:
cgminer 3.8

Don't look at me.  3.8.1 has been rock solid for me on Win7 and even Vista, can't believe that crap OS is working well.

The first one is doing well for me after about 4.5 19.75 hours. Don't need the lulz yet, I guess.  

Edit: updated elapsed time of run.

Edit: finally got a zombie (AMU3) after about 24.75 hours. I'll try "lulz" next, for the lulz.

Edit: "lulz" is working perfectly, 19 hours into its run.

Edit: Oops - AMU10 went zombie, 22 hours in.

New release: Version 3.8.2, 16th November 2013

Another stable release with a new driver.


Human readable changelog:

- New driver for bi*fury devices. These will come up as BXF devices. Note that if you have one of these, having 2 bitfury chips they generate a LOT of heat and will need active cooling. The first firmware for them does not have a way to stop them mining so they will get dangerously hot if you don't point a fan at them and stopping cgminer won't even cool them down. This should be fixed in their next version.
- Set priority of various threads high and low for poor performing hardware (e.g. wrt routers) or operating systems (i.e. windows) to try to minimise the influence of system usage in other ways from causing communication problems.
- Fixed a problem where it was possible for cgminer to hang after getting notification of a new block when mining via getwork.
- Low level communication fixes within libusb itself to support sending proper zero length packets on windows for more reliable communications (same as the lulz binary), along with automatically clearing pipe errors and not losing buffered data.
- More low level avalon fixes.
- Klondike fixes
- Hashfast fixes
- BaB fixes
- Hardware errors on starting BF1 devices are now minimised
- Fix for mining directly on a GBT port with --fix-protocol
- --shares is now scaled relative to diff1 shares instead of absolute number
- Fix for a rare crash on startup
- Other low level fixes
- More verbose documentation



Full changelog:

- Add more verbose documentation to the readme files for windows users.
- Add more information on libusb failure to init telling users to check README
file.
- Add information on unloading cdc drivers on osx to README
- Prevent a deadlock with use of restart_threads by spawning a thread to send
the driver flush work messages.
- Set priority of various threads if possible.
- Add bxf data to api output.
- Do not hold the mining thread lock in restart_threads when calling the driver
flush work commands.
- Send extra work regularly to the bxf device and parse the needwork command by
sending the amount of work it requests.
- Allow messages to have arbitrary offsets in the bxf parser in case we have
lingering buffered data.
- Send the maxroll command to the bxf driver and store the value to see if we
need to update it.
- Add sending of flush command to bxf on flush_work
- Add flush and version commands to bxf start up, flush buffer and try to parse
version response string.
- Abstract out bxf recv message.
- Add extra bxf commands to usbutils
- Abstract out bxf send message to allow us to easily add extra commands.
- Don't run device restart code if the device is not enabled.
- Expand size of bitfury statline
- Various driver fixes for bitfury devices, including a flag from when first
valid work appears.
- Look up work results in bxf driver from correct variable.
- Correct incorrect error code in bxf driver for usb writes and add debugging.
- Add bxf details to usbutils.
- Implement a statline showing temperature for bxf
- Add api data for bxf device, sharing the hashrate function with bf1.
- Count no matching work as a hw error on bxf
- Add BXF to udev rules.
- Work id should be hexadecimal in bxf messages.
- Add unrecognised string debugging to bxf driver.
- Implement the main scanloop for bxf, trying to prevent it from ntime rolling
work if the work protocol does not allow it.
- Parse bxf work submits fully, submitting the results.
- Provide a function for setting the work ntime.
- Implement a skeleton parse bxf submit function.
- Use the bxf read thread to set the device target and send its first work item.
- Implement a bxf send work function and set update and restart functions to
sending new work since that's the equivalent for that device.
- Add temperature parsing to bxf driver
- Create and destroy a basic bxf read thread.
- Remove the buffer from bitfury info since it is only used on one pass in the
bf1 device.
- Add a rudimentary bxf detect one function.
- Rename all bf1 specific functions in the bitfury driver, using a switch to
choose correct function.
- Rename bitfury_getinfo to bf1_getinfo since it's unique to bf1 devices.
- Separate out the bf1 reset from bitfury reset.
- Store the bitfury identity in the info struct.
- BaB - updated tested OS comment
- Uniquely identify the BF1 and BXF bitfury devices.
- Remove the default libusb WinUsb pipe policies that don't suit us.
- Only set the winusb pipe policy if it doesn't match our requirements instead
of every transfer.
- klondike - dont try to flush if not initialised
- api.c trylock() add missing locklock
- Use our new zero length packet support directly in windows.
- Enable support for zero length packet on windows and auto clear pipe stalls.
- util.c: Decreasing reference count on allocated JSON obects to prevent memory
leak
- api.c: Release apisock on error in api()
- api.c: Release io_data->ptr when releasing io_data in io_free()
- We can't connect to a GBT pool at all with fix protocol enabled.
- Initialise the stgd lock mutex earlier to prevent dereferences when pool
testing occurs before it.
- Klondike support I2C USB layout also - as KLI
- Return error codes in avalon_read() if they're not timeouts.
- Break out of the avalon idle loop if we get a send error.
- Set avalon ftdi latency to just less than the time it would take to fill the
ftdi buffer at 115200 baud
- Update example.conf
- Only limit packetsize on usb out writes.
- We must chop up every 64 bytes returned on an ftdi chip, not just the first 2
bytes so revert to parsing the data internally in the avalon instead of using
usbutils' simple ftdi parser.
- Only retry 3 times in hfa_reset.
- Only add_cgpu in hashfast driver once we have a real driver set up.
- Clean up properly if hfa_detect_common fails in the hashfast driver.
- --shares should be scaled to diff1 not absolute number of shares

My memory says it did not - I'm pretty sure, but then I'm not 100% sure of anything (too many philosophy courses).

My next lulz run had one anomaly after 20 hours - an AMU LED was on but the device did not show as a zombie. The display originally showed AMUs 0-12, as expected. Some time during the run AMUs 1 and 11 dropped from the display. One of them was apparently reallocated to 13 and the other was just missing. Presumably it was the one with the LED on - a nameless zombie.

It was cool to the touch. Unplugging it did not change the display. Replugging it produced the usual five blinks, but then the LED stayed on and cgminer did not recognize it.
A "Q" and restart fixed the issue.

I'll switch to 3.8.2 shortly.

Thanks. No point compiling KnC support since it can ONLY run off a beaglebone, and the closest thing to hashfast hardware in existence is still the fpga emulation in my hardware, but I'll look into it. Still, it's always nice to know I didn't break OSX.