Topic: [ANN][BLC] Blakecoin Blake-256 for GPU/FPGA With Merged Mined Pools Stable Net - page 109. (Read 409641 times)

I've been solo mining blakecoin for a few days, however, the Blakecoin-QT keeps going into a state where it stops updating blocks from the network. It hasn't frozen as I can still access menus and the debug windows. It still shows "up to date" and "n active connections to blakecoin network". The miner keeps running and is clocking up blocks which will obviously never confirm.

Is this a known issue / can anyone think of a workaround? I'm using v0.8.9.0 which I think is the latest version. I'm using the cgminer.conf shown on P1 of this thread - are there any new nodes?

Thanks.

0.8.9 for MAC is here:


Please report any issues happy to add to OP if someone tests it and reports it is working  

When will a Mac wallet be released?

We just had difficulty of 32586, which is the highest so far ;]
Seems like more and more people are starting to mine blakecoin.

New post about cryptos that have games made for them.. and of course this coin is listed!
If you never heard of my blog.. its preety new but due to many followers on twitter [over 6k due to giveaways] it has big audience - over 1300 signed up email readers.
Anyways check the post and if you like it.. do not be scared to tip
http://fuk.io/cryptocoins-which-are-also-games-good-investments/

Bingo!!! It was a path issue.  I did try a cgminer bitcoin "sudo make install" before and I found ztex bitstream files in /usr/local/bin/bitstreams.  Replaced them with the blakecoin bitstreams and it is hashing great.  Thanks so much!

This is strange. My experience of removing the bitstreams folder (ie just having cgminer plus command scripts and forgetting to copy the bitstreams folder) is that cgminer will exit immediately with an error. You certainly should not see the four (green) done LEDs light on the ztex board(s) indicating a successful bitstream load.

I wonder if this is a path issue? Perhaps in the past you did a "sudo make install" on the bitcoin cgminer and it has installed the bitcoin bitstream somewhere under /etc or some other unixy place like /usr/local and this is taking precedence over blake bitstream in the local bitstreams directory? Unfortunately the makefile is fiendishly complicated and it's not easy to tease out where this may be without actually running it. So I'll try that later today on a ubuntu 12.04 LTS VM (I don't want to meddle with my raspi production installation). What you could try in the meantime is "type cgminer" (or better "which cgminer") to check if it is already installed and where, I suspect the bitstreams directory is somewhere around there. EDIT: it's likely to be /usr/local/bin from my reading of the cgminer source, you can override with --kernel-path or -K.

Yep, this definitely seems to be the right track. Take a look at the open_bitstream() function in fpgautils.c (again ridiculously overcomplicated with recursive #define's). It tries opt_kernel_path first with three subdirectories /usr/local/bin/ztex, /usr/local/bin/bitstreams and /usr/local/bin itself), only then does it try cgminer_path plus subdirectories and finally the current directory. So check for /usr/local/bin/ztex and /usr/local/bin/bitstreams as the location of ztex_ufm1_15y1.bit and overwrite this file with the blake version (with sudo). Or use --kernel-path to override as mentioned above.

One other thing I thought of was the firmware version on the ztex boards (this is programmed via the ztex java API) but this now seems unlikely given the bitstream issues.

Hi, I also have 1.15y's running on krambles linux cgminer. The only issue I have had is when using getwork instead of stratum. Eloipool rejects the majority of work with the error "bad-txn-merkleroot". It shows up as many "hardware errors" in cgminer. I have just stuck with using stratum. I see you are using stratum already.

./cgminer --disable-gpu -o stratum+tcp://ip:port -u x -p x

yes I have ztex 1.15y boards and working with ztex_ufm1_15y1-v06ad-t6-ucf-150MHz-fmax-157.bit renamed to ztex_ufm1_15y1.bit

here is my command for kramble's binary:
cgminer_fpga_pool --disable-gpu --url stratum+tcp://eu2.blakecoin.com:3334 --userpass User.Worker:Pass --ztex-clock 200:224,200:220,200:216,200:212 -Q 7

Does anybody have cgminer-3.1.1 working for ztex 1.15y? 

I get 100% HW errors on a cluster of 1.15y (version1), running Ubuntu 12.04 LTS.  I tried the 2 different bitstreams from the dropbox links
https://www.dropbox.com/s/1ffqdaj1dowkd0j/ztex_ufm1_15y1-v06ad-t6-ucf-150MHz-fmax-157.bit 
https://www.dropbox.com/s/vk3k5sb64b8641o/ztex_ufm1_15y1-v06ad-2core-ucf-140MHz-fmax-147-fixed.bit

copied the files to the cgminer-3.1.1/bitstreams folder and renamed to ztex_ufm1_15y1.bit (deleted the old file)

Neither bitstream seems to work.  I also tried downclocking to 100MHz and still 100% HW.  I am thinking it is a bitstream issue.  If I remove the whole content of the bitstreams folder, I get the same results.  I don't think it is cgminer because I have it running on a cluster of 1.15x on a separate Ubuntu box that was built the same way.   

Does anybody know how I can check to see which bitstream is loaded by cgminer?

I also want to thank Kramble for the files and personally helping me with building cgminer on ubuntu.  Thanks to hal7 for the 1.15x bitstream.

CA Coins

Awesome thanks will update OP and Site 

BlakeCoin is now available on AllCrypt.com!

Not an expert on Linux...
Can anybody compile a Linux version working on SMOS/BAMT/PIMP distro, please? THX!

Yep, that's the post which I had read previously.

Hi,

I recall reading elsewhere when trying to download the drivers that there were "issues" with the Icarus drivers on windows and the USB interface was different on Lancelot because of this.

As an experiment I've moved to another computer (win xp 32 bit instead of server 08r2) and this seems to have fixed the problem for now.

I will try a linux build over the weekend.

Thanks again.

The clock speed shouldn't have any effect on the USB comms. The failure to "end process" looks very much like a driver issue.

Looking at the schematics, the Lancelot uses a FT232RL USB chip, while the Icarus uses the PL2303HXD, so there must have been a reason for the change (the PL2303HXD is a cheaper device according to one post I found via google). Ah, found this where ngzhang cites the bad driver as a reason for the change to FT232. Anyway you should check which version of the driver you are using. My google-fu has failed to find anything much of use, though this mentions driver version 1.50 or 1.52.

If I find anything else I'll get back to you...
Another post with a link to the driver
This post and scroll down for a few more.
It seems the Avalon-2 uses this chip too (link)

And (not relevant to your problem) kano had the same issue as I did with rpi network stack locking up! Seems the fix is just to update debian (I've not bothered so far, for the same reasons, little free disk space and a reluctance to meddle with something that (mostly) works fine)

Anyway, if you've got a spare linux box, it may be worth running the icarus on that as the gist seems to be that the linux drivers are more stable than the windows one.

Tried dropping the clock from 160 to 150MHz last night, made no difference.

I'm trying a selection of cables now to see if this helps.

I have noticed that when one or more boards goes SICK / DEAD that it is impossible to close cgminer (even "end process" fails) and a reboot is required. Also the Lancelot never goes SICK.

I had this issue with some of the CM1 boards and changed the usb leads to shorter ones and solved it for me maybe same fix?

edit:
also incase its an overclock issue did you try to reduce the clocks a few MHz?

Is anyone else having problems with Icarus boards going SICK / DEAD?

I don't think it's the boards themselves as a reboot of the computer sorts the problem without turning the Icarus off / on.

I'm guessing it may be the windows USB serial drivers. Does anyone see this issue on Linux?

Thanks.

Gogogo Blake coin!!